ทีมซัพพอร์ตในเวียดนามรวม Zalo, WhatsApp และ LINE เข้าเป็นคิวข้อความขาเข้าเดียวได้อย่างไร

เวลา 8:12 เช้าวันจันทร์ในโฮจิมินห์ หัวหน้าทีมซัพพอร์ตยังไม่ทันเปิดแล็ปท็อป ข้อความ Zalo แรกก็เข้ามาแล้ว ลูกค้าต้องการเปลี่ยนที่อยู่จัดส่งก่อนรอบรับพัสดุ อีกสี่นาทีต่อมา ซัพพลายเออร์ในกรุงเทพฯ ส่งข้อความ LINE มาบอกว่ากล่องหนึ่งจะล่าช้า เวลา 8:27 ลูกค้าประจำจากสิงคโปร์ถามเงื่อนไขการรับประกันผ่าน WhatsApp

ข้อความเหล่านี้ไม่ได้แปลกอะไร ปัญหาคือมันอยู่คนละที่ อยู่บนโทรศัพท์คนละเครื่อง และอยู่กับคนละคน ภายในเวลา 9 โมง ทีมก็แคปหน้าจอสองรูปไปลง Slack ส่งต่อข้อความหนึ่งให้ฝ่ายขาย และลืมไปแล้วว่าลูกค้าคนไหนถามเรื่องการรับประกัน

บริษัทนี้เป็นทีมปฏิบัติการและซัพพอร์ต 5 คนของแบรนด์ความงามขนาดเล็กที่ดูแลคำสั่งซื้อข้ามประเทศ ลูกค้าส่วนใหญ่อยู่ในเวียดนาม ไทย และสิงคโปร์ ช่องทางจึงเป็นแบบที่คาดได้: ลูกค้าเวียดนามใช้ Zalo, พาร์ตเนอร์ไทยใช้ LINE, ซัพพลายเออร์และลูกค้าต่างประเทศใช้ WhatsApp ทีมไม่ได้ต้องการแคมเปญ ไม่ต้องการ broadcast template และไม่อยากเปลี่ยน CRM สิ่งที่ต้องการคือทำให้ทุกข้อความขาเข้าเป็นงานที่ติดตามได้

สาม inbox แต่ SLA เดียว

ก่อนปรับระบบ กระบวนการทำงานเป็นแบบ manual แต่คุ้นเคย Zalo อยู่บนโทรศัพท์ของหัวหน้าซัพพอร์ตเวียดนาม LINE อยู่กับผู้ประสานงานที่ดูแลซัพพลายเออร์ไทย WhatsApp อยู่กับผู้ก่อตั้ง เพราะลูกค้าเก่าหลายคนยังมีเบอร์ของเขา ทุกเช้า ทีมเปิด Slack แล้วแปะ screenshot ของข้อความที่ดูเร่งด่วน

วิธีนี้พอใช้ได้เมื่อปริมาณข้อความยังน้อย แต่เมื่อเริ่มเยอะขึ้น ปัญหาก็ชัดขึ้น ข้อความเปลี่ยนที่อยู่ที่พลาดก่อนรอบรับพัสดุกลายเป็นการคืนเงิน ข้อความ LINE จากซัพพลายเออร์เรื่องสินค้าล่าช้าถูกเห็นหลังจากคลังสัญญาว่าจะส่งของวันเดียวกัน คำถามเรื่องรับประกันใน WhatsApp ค้างอยู่ เพราะผู้ก่อตั้งกำลังเดินทาง

ในสองสัปดาห์ ทีมบันทึกการตอบช้าได้ 31 ครั้ง ส่วนใหญ่ไม่ใช่ปัญหาทางเทคนิค แต่เป็นปัญหาการมองเห็น มีคนหนึ่งเห็นข้อความ แต่ทีมที่เหลือไม่เห็น หรือคนที่ควรจัดการไม่ว่าง และคนอื่นไม่รู้ด้วยซ้ำว่ามีข้อความนั้นอยู่

เส้นทาง official ของแต่ละแพลตฟอร์มแก้ปัญหาที่ใหญ่กว่านั้น Zalo Official Account เหมาะกับการบริหารบัญชีทางการและ template notification LINE Official Account เหมาะกับ rich menu, broadcast และภาพลักษณ์แบรนด์ WhatsApp Cloud API เหมาะกับ business messaging แบบ template ในระดับใหญ่ แต่ทีมนี้ไม่ได้ต้องการเริ่มบทสนทนาจำนวนมาก บทสนทนาสำคัญมาจากลูกค้าหรือซัพพลายเออร์ก่อนเสมอ

ดังนั้นโจทย์จึงเปลี่ยนไป ไม่ใช่ “ติดตั้ง business messaging stack ทางการสามชุด” แต่เป็น “ทำให้ทุกข้อความขาเข้าเป็น queue item ที่เชื่อถือได้”

webhook ที่ทีมต้องการจริง ๆ

ทีมสร้าง endpoint เดียวใน backend:

POST /inbound/messages

จากนั้นเชื่อมบัญชี Zalo หนึ่งบัญชี, WhatsApp หนึ่งบัญชี และ LINE หนึ่งบัญชีผ่าน UnifyPort ทั้งสามบัญชีส่ง event ไปยัง webhook endpoint เดียวกัน ทุก delivery ใช้ envelope เดียวกัน: id, type, provider, account_id, occurred_at และ data

ข้อความ Zalo หลัง normalize มีหน้าตาแบบนี้:

{
  "id": "evt_7f4c20a91d",
  "type": "message.received",
  "provider": "zalo",
  "account_id": "acc_vn_support",
  "occurred_at": "2026-07-02T01:12:16Z",
  "data": {
    "conversation": { "id": "zalo_user_1942", "type": "user", "title": "Minh Anh" },
    "sender": { "id": "zalo_user_1942", "type": "user", "name": "Minh Anh" },
    "message": {
      "id": "zalo_msg_8831",
      "type": "text",
      "text": "Em muốn đổi địa chỉ giao hàng trước 11h được không?",
      "direction": "inbound",
      "sent_at": "2026-07-02T01:12:15Z"
    },
    "event": { "kind": "message_received" }
  }
}

handler เดียวกันประมวลผล WhatsApp และ LINE ด้วย สิ่งที่เปลี่ยนคือ provider ไม่ใช่ parser ของแต่ละแพลตฟอร์ม

ก่อนเชื่อ payload endpoint จะตรวจสอบลายเซ็นของ delivery ก่อน endpoint มี signing_secret ดังนั้นแต่ละ request จะมี X-Device-Timestamp และ X-Device-Signature signature คือ HMAC-SHA256 hex digest ของ timestamp, จุดหนึ่งตัว และ raw request body

import crypto from 'crypto';
import express from 'express';

const app = express();
const secret = process.env.WEBHOOK_SIGNING_SECRET;

app.post('/inbound/messages', express.raw({ type: 'application/json' }), async (req, res) => {
  const timestamp = req.get('X-Device-Timestamp');
  const signature = req.get('X-Device-Signature');

  const hmac = crypto.createHmac('sha256', secret);
  hmac.update(timestamp + '.');
  hmac.update(req.body);
  const expected = hmac.digest('hex');

  const valid = signature.length === expected.length &&
    crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected));

  if (!valid) {
    res.status(401).end();
    return;
  }

  const event = JSON.parse(req.body.toString('utf8'));
  await enqueueInboundMessage(event);
  res.status(200).end();
});

queue item เก็บ 5 ฟิลด์ที่ทีมต้องใช้จริง: แพลตฟอร์ม, ชื่อลูกค้า, ข้อความ, conversation ID และ account ID ส่วนที่เหลือเก็บเป็น raw event metadata เพื่อ audit ภายหลัง

routing rule ที่ทุกคนอธิบายได้

เวอร์ชันแรกของ routing ตั้งใจให้ธรรมดา

ข้อความ Zalo ไปที่ lane ของทีมซัพพอร์ตเวียดนาม ข้อความ LINE ไปที่ lane ของซัพพลายเออร์ ข้อความ WhatsApp ไปที่ lane ของลูกค้าต่างประเทศ ถ้ามีเลขออร์เดอร์ จะสร้าง CRM note ถ้ามี keyword เกี่ยวกับการจัดส่ง จะโพสต์ไปยัง Slack channel #fulfillment

สัปดาห์แรกไม่มี AI classifier ทีมต้องการระบบที่ debug ได้ระหว่างที่ออร์เดอร์ยังเดินอยู่ พวกเขาใช้ชื่อ rule เช่น delivery_change, supplier_delay, warranty_question และทุก item แสดง rule ที่ match

สัปดาห์ที่สอง ทีมเพิ่มแค่ชั้นช่วยเหลือ: draft suggestion สำหรับคำถามซ้ำ ๆ สามประเภท การเปลี่ยนที่อยู่จะได้ draft ขอที่อยู่ใหม่และเลขออร์เดอร์ คำถามรับประกันจะได้ draft พร้อมช่วงเวลารับประกันและรูปที่ต้องใช้ ข้อความซัพพลายเออร์แจ้งล่าช้าจะได้ draft ถามเวลาส่งมอบใหม่ draft เหล่านี้โพสต์เข้า Slack เท่านั้น ไม่ส่งอัตโนมัติ

ขอบเขตนี้สำคัญ ทีมไม่ได้ต้องการให้ automation คุยแทนคน แต่ต้องการให้การกระทำถัดไปของมนุษย์ชัดเจนขึ้น

หลังจากสี่สัปดาห์

การเปลี่ยนแปลงที่เห็นชัดที่สุดเรียบง่ายมาก ไม่มีใครต้องเฝ้าดูโทรศัพท์สามเครื่องอีกแล้ว หัวหน้าซัพพอร์ตเปิด queue เดียวทุกเช้า และเห็น Zalo, WhatsApp, LINE อยู่ในรายการเดียวกัน ทีมยัง filter ตาม provider ได้ แต่ default view คือ inbound work เรียงตามเวลา

median first response time ลดจาก 2 ชั่วโมง 18 นาที เหลือ 26 นาที ข้อความที่ค้างเกิน 4 ชั่วโมงลดจาก 31 ข้อความในสองสัปดาห์ เหลือ 3 ข้อความในสองสัปดาห์ถัดมา ที่สำคัญกว่านั้น screenshot ไม่ใช่ operational record อีกต่อไป ทุก inbound event มี event ID, provider, account ID และ timestamp ที่ชัดเจน

CRM ก็มีประโยชน์ขึ้น ก่อนหน้านี้ประวัติ Zalo ของลูกค้าอยู่บนโทรศัพท์เครื่องเดียว และบริบท LINE ของซัพพลายเออร์อยู่กับผู้ประสานงานหนึ่งคน หลังจากเปลี่ยนระบบ CRM แสดงข้อความล่าสุดได้ไม่ว่ามาจากช่องทางไหน เมื่อผู้ก่อตั้งเตรียมคุยต่อสัญญา เขาไม่ต้องขอให้ทีมค้น chat ให้ เขาเปิด contact record ได้เลย

ลูกค้าไม่ได้ถูกย้ายไปช่องทางใหม่ พวกเขายังส่งข้อความไปยังบัญชี Zalo, WhatsApp หรือ LINE เดิม สิ่งที่เปลี่ยนคือ backend path หลังจากข้อความมาถึง

รูปแบบที่ควรจำ

สำหรับทีมเล็ก สิ่งสำคัญคือแยก inbound support ออกจาก outbound campaign infrastructure ผลิตภัณฑ์ business ทางการมีคุณค่าเมื่อคุณต้องการ verified presence, broadcast, template, rich menu หรือ campaign operations แต่ถ้าปัญหาตอนนี้คือ “ลูกค้าส่งมาก่อน แล้วทีมพลาดข้อความ” ระบบแรกที่ต้องมีคือ inbound routing layer

ด้วย UnifyPort ทีมนี้มองทุกแพลตฟอร์มเป็น event stream เดียว message.received กลายเป็น contract ร่วม HMAC-SHA256 verification ทำให้ delivery เชื่อถือได้ ฟิลด์ provider บอก queue ว่าข้อความมาจากไหน และ workflow ของซัพพอร์ตยังคง platform-neutral

สำหรับทีม 5 คน เท่านี้ก็พอแล้ว หนึ่ง webhook หนึ่ง queue และเครื่องมือที่ทีมใช้อยู่แล้ว