一個越南客服團隊點樣將 Zalo、WhatsApp 同 LINE 放入同一個入站隊列

星期一朝早 8:12，胡志明市嘅客服主管都未開電腦，第一條 Zalo 訊息已經入咗嚟。客戶想喺物流收件前改送貨地址。4 分鐘後，曼谷供應商用 LINE 話有一箱貨會延遲。8:27，一位新加坡舊客又喺 WhatsApp 問保養條款。

呢啲訊息本身唔出奇。問題係，佢哋分別落喺三個入口、三部手機、三個人手上。到 9 點，團隊已經將兩張截圖貼咗去 Slack，轉發咗一條訊息俾銷售，仲唔記得邊個客問過保養。

呢間係一個小型美妝品牌嘅五人營運客服團隊，負責跨境訂單支援。客戶主要喺越南、泰國同新加坡，所以渠道組合好典型：本地買家用 Zalo，泰國合作方用 LINE，供應商同國際回頭客用 WhatsApp。團隊唔需要大型推廣活動、唔需要群發模板，亦唔想換 CRM。佢哋需要嘅，只係將入站訊息變成一個可以處理嘅工作項目。

三個 inbox，一個回覆要求

改造之前，流程好手動，但好常見。Zalo 喺越南客服主管手機上，LINE 喺負責泰國供應商嘅營運同事手上，WhatsApp 喺創辦人手機上，因為好多舊客仍然有佢個號碼。每日朝早，大家打開 Slack，將睇落緊急嘅訊息截圖貼入去。

訊息量低嗰陣，呢套方法仲頂得住。後來問題開始好具體：物流收件前冇睇到改地址訊息，最後要退款；供應商喺 LINE 提醒延遲，被睇到嗰陣倉庫已經承諾即日出貨；創辦人出差，WhatsApp 入面嘅保養問題就一直冇人處理。

兩星期內，團隊記錄咗 31 次遲覆。大部分唔係技術故障，而係可見性故障。有人見到訊息，但其他人冇。或者應該處理嘅人唔喺度，其他人連呢條訊息存在都唔知。

官方平台路徑各自解決更大嘅問題。Zalo Official Account 適合官方帳號營運同通知模板；LINE Official Account 適合 rich menu、群發同品牌化客戶入口；WhatsApp Cloud API 適合大規模模板式商務訊息。但呢個團隊唔係要主動發起大量對話。重要對話都係客戶或者供應商先發嚟。

所以項目目標變咗。佢唔係「導入三套官方商務訊息系統」，而係「將每條入站訊息變成可信嘅隊列任務」。

佢哋真正需要嘅 webhook

團隊喺後端開咗一個入口：

POST /inbound/messages

然後透過 UnifyPort 接入一個 Zalo 帳號、一個 WhatsApp 帳號同一個 LINE 帳號。三個帳號都投遞到同一個 webhook endpoint。每次投遞都用同一套 envelope：id、type、provider、account_id、occurred_at 同 data。

歸一化後嘅 Zalo 訊息係咁：

{
  "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，唔係解析方式。

喺信任 payload 之前，endpoint 會驗證投遞簽名。endpoint 設咗 signing_secret，所以每個 request 都會帶 X-Device-Timestamp 同 X-Device-Signature。簽名係 timestamp、一個點，同原始 request body 嘅 HMAC-SHA256 十六進制摘要。

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();
});

隊列任務只抽出團隊最關心嘅五個欄位：平台、客戶名、訊息內容、conversation ID 同 account ID。其他內容保留做原始事件 metadata，方便之後查核。

團隊講得明嘅路由規則

第一版路由刻意做得簡單。

Zalo 訊息入越南客服隊列。LINE 訊息入供應商隊列。WhatsApp 訊息入國際客戶隊列。任何帶訂單號嘅訊息都會建立 CRM note。任何包含配送關鍵字嘅訊息都會發到 Slack #fulfillment channel。

第一星期冇 AI 分類器。團隊需要一個訂單流轉期間都可以排查嘅系統。佢哋用 delivery_change、supplier_delay、warranty_question 呢類規則名，每個任務都顯示命中咗邊條規則。

第二星期，佢哋只加咗一層輔助：為三類常見問題產生回覆草稿。改地址會產生要求新地址同訂單號嘅回覆；保養問題會產生包含保養期同相片要求嘅模板；供應商延遲訊息會產生詢問新交接時間嘅回覆。草稿只貼去 Slack，唔會自動發俾客戶。

呢個界線好重要。團隊唔想自動化直接同客戶對話，只想下一個人工動作變得清楚。

四星期後有咩改變

最明顯嘅改變好簡單：冇人再盯住三部手機。客服主管每日朝早只開一個隊列，就睇到 Zalo、WhatsApp 同 LINE。團隊仍然可以按 provider 篩選，但預設視圖係按時間排序嘅入站工作。

首次回覆中位數由 2 小時 18 分鐘降到 26 分鐘。超過 4 小時未處理嘅訊息，由兩星期 31 條降到之後兩星期 3 條。更重要係，團隊唔再用截圖做營運記錄。每個入站事件都有穩定 event ID、provider、account ID 同 timestamp。

CRM 亦變得更有用。以前客戶嘅 Zalo 歷史喺一部手機，供應商嘅 LINE 上下文喺某位營運同事度。改造後，CRM 可以見到每個渠道最近一條訊息。創辦人準備續約電話時，唔再要團隊翻聊天紀錄，直接打開 contact record 就得。

客戶冇被搬去新入口。佢哋仍然發訊息去原本嘅 Zalo、WhatsApp 或 LINE 帳號。改變只發生喺訊息到達之後嘅後端路徑。

呢個模式適合邊類團隊

對小團隊嚟講，關鍵係分清「入站客服」同「出站營銷基礎設施」。官方商務產品喺需要認證展示、群發、模板、rich menu 或活動營運時好有價值。但如果眼前痛點係「客戶先發訊息，而團隊漏睇」，第一個需要嘅係入站路由層。

透過 UnifyPort，呢個團隊將各平台當成同一條事件流處理。message.received 成為共同合約，HMAC-SHA256 驗證令投遞可信，provider 欄位話俾隊列知訊息來自邊度，其餘客服流程保持平台無關。

對五人團隊嚟講，咁就夠。一個 webhook、一個隊列，再加上佢哋本身已經用緊嘅工具。