一個 LINE Webhook 統領全日本團隊：福岡初創企業如何將 LINE 訊息分流至 Slack、CRM 及 AI

週二上午九時四十七分，大阪一位客戶透過 LINE 向其業務經理發送訊息：「CSV 匯出功能一直失敗——這是已知問題嗎？」該業務經理當時正在開會，訊息在她的手機上閒置了三個小時。待她回覆時，客戶早已透過官網提交了支援工單——還在 X 上標記了公司，質問究竟有沒有人在看他們的 LINE 頻道。

這並非平台限制的問題。LINE 作為通訊軟件本身運作良好。問題在於，福岡辦公室的六人各自在自己的 LINE 帳號接收客戶訊息，使用各自的手機，對於誰在回覆哪些訊息，完全沒有全局視野。這家公司是一支 B2B SaaS 團隊，向日本及東南亞各地的倉儲企業銷售物流規劃工具——業務規模早已超出「每人自行查看 LINE」即可應付客戶支援的階段。然而所有替代方案似乎都要求客戶遷離 LINE，在日本這是完全不可行的。

形同虛設的佇列

該團隊於 2026 年初的支援架構如下：三位業務代表及兩位支援工程師各自擁有一個 LINE 帳號，客戶將其加為好友。訊息送達各人的手機，沒有共用收件箱、沒有回覆追蹤、沒有 SLA。一旦有人請病假，其訊息便無人查閱直至歸來。若客戶在晚上七時後發送訊息，則需等到下一個工作天——並非團隊不願協助，而是無人知悉訊息已到。

公司曾考慮申請 LINE 官方帳號（OA），該方案提供共用收件箱及部分自動化功能。但 OA 申請流程需時長達 60 個工作天進行驗證，而未驗證等級的好友上限為 500 人——對於客戶群已接近 800 人的團隊而言，這是硬性的上限。已驗證及進階等級雖可解鎖更高限額，但伴隨月費及互動窗口規則，規限商戶何時可主動聯繫用戶。這支團隊從不主動聯繫客戶，只負責回覆。OA 的群發功能要解決的，並非他們的痛點。

與此同時，維持現狀的營運成本持續攀升。2026 年首季，團隊記錄了 23 宗客戶訊息逾四小時未獲回覆的個案，當中七宗導致客戶經其他渠道升級支援工單，兩宗引發 X 上的公開投訴。支援主管 Kenji 起初以試算表追蹤漏回訊息，至第六週便不再更新。

一個 Webhook，三個去向

轉捩點並非什麼危機——而是公司 CTO 在 Slack 上的一則訊息，他一直在研究以 webhook 為基礎的訊息分流方案。構思相當簡單：與其讓各人自行查看自己的 LINE，不如透過統一介面連接全部六個 LINE 帳號，將收到的訊息轉發至團隊已在使用的工具。Slack 用作實時掌握狀況，CRM 用作記錄及跟進，而針對常見問題，則由 AI 草擬回覆供團隊審核後方發送。

團隊以 QR Code 驗證方式將 LINE 帳號連接至 UnifyPort——這是 LINE 在該平台上唯一支援的驗證模式。每個帳號掃描約需 30 秒，不足一小時，六個帳號悉數上線，單一 webhook 端點以 message.received 事件接收所有入站 LINE 訊息。

Webhook 的 payload 如下：

{
  "id": "evt_9a3f7c2e01",
  "type": "message.received",
  "provider": "line",
  "account_id": "acc_4b82d1",
  "occurred_at": "2026-05-12T01:47:23Z",
  "data": {
    "conversation": {
      "id": "U4af2c891...",
      "type": "user",
      "title": "Tanaka-san"
    },
    "sender": {
      "id": "U4af2c891...",
      "type": "user",
      "name": "Tanaka-san"
    },
    "message": {
      "id": "msg_18420...",
      "type": "text",
      "text": "The CSV export keeps failing — is this a known issue?",
      "direction": "inbound",
      "sent_at": "2026-05-12T01:47:22Z"
    },
    "event": {
      "kind": "message_received"
    }
  }
}

每次推送均附帶 X-Device-Signature 標頭——乃將時間戳與原始請求內體串接後，以 webhook 的 signing_secret 進行 HMAC-SHA256 簽章所產生的十六進位摘要。團隊的 Express 處理器會在執行任何邏輯前先行驗證簽章：

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

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

app.post('/webhook', 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');

  if (!crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return res.status(401).end();
  }

  const event = JSON.parse(req.body.toString('utf8'));
  if (event.type === 'message.received') {
    await routeMessage(event);
  }
  res.status(200).end();
});

重點不在 webhook 處理器本身——每個整合都有這類處理器。真正的關鍵在於驗證通過後執行的 routeMessage 函數。分流邏輯並非將所有訊息一股腦兒扔進同一個佇列，而是根據訊息內容及對話脈絡決定其去向。

分流邏輯：Slack、CRM、AI——或三者兼用

團隊的分流規則在前兩週反覆調整，最終版本分為三層：

第一層——Slack 通知（每則訊息）。 所有入站 LINE 訊息均發佈至 Slack 的 #support-line 頻道，附帶發送者名稱、訊息預覽及 account_id，讓團隊知悉是哪位同事的帳號接收了該訊息。單是此舉已解決「訊息閒置在某人手機上」的問題。若帳號持有人正在開會，團隊中任何其他人均可在 Slack 上查閱該訊息，並透過 UnifyPort 的 POST /v1/messages 端點，使用原始訊息中的 reply_to.reply_token 作出回覆。

第二層——CRM 記錄（每則訊息）。 一個平行呼叫在 CRM 中建立或更新聯絡人記錄，包含完整訊息文字、時間戳及對話 ID。在此之前，客戶在 LINE 上的互動對 CRM 而言完全不可見——僅存在於手機上的個別聊天記錄中。如今每段 LINE 對話均具備完整稽核軌跡，與電郵及網站工單的歷史並列。

第三層——AI 草稿（僅限常見問題）。 一個簡單的關鍵字分類器將入站訊息與常見主題清單進行比對：CSV 匯出、帳單、登入問題、API 文件查詢。若命中匹配項，訊息將被轉發至內部 LLM 端點，並附帶包含相關文件段落的系統提示。AI 的回覆草稿發佈至 #support-drafts Slack 頻道，附設「審核並傳送」按鈕。未經人工核准的回覆絕不會發送——但草稿數秒內即準備就緒，業務代表只需一鍵確認。

async function routeMessage(event) {
  const { conversation, sender, message } = event.data;
  const accountId = event.account_id;

  // Tier 1: Always notify Slack
  await postToSlack('#support-line', {
    account: accountId,
    sender: sender.name,
    preview: message.text?.slice(0, 120),
    reply_token: message.reply_token,
  });

  // Tier 2: Always log to CRM
  await crm.upsertContact({
    external_id: sender.id,
    platform: 'line',
    name: sender.name,
    last_message: message.text,
    last_message_at: message.sent_at,
  });

  // Tier 3: AI draft for routine questions
  const topic = classifyTopic(message.text);
  if (topic) {
    const draft = await generateDraft(topic, message.text, sender.name);
    await postToSlack('#support-drafts', {
      sender: sender.name,
      topic,
      draft,
      account_id: accountId,
      reply_token: message.reply_token,
    });
  }
}

classifyTopic 函數刻意從簡——採用關鍵字對應表，而非神經網絡分類器。「CSV」、「export」、「download」對應匯出文件主題。「請求」、「料金」、「支払い」對應帳單主題。維持基於規則的設計，意味着團隊可在數分鐘內——而非數小時——排查分流錯誤。

以對話標籤確立團隊權責

團隊在第二週開始採用 UnifyPort 的對話標籤功能。透過 POST /v1/conversations/labels 端點，他們為每位成員建立標籤：kenji、yuki、hiro、sales。訊息到達時，分流函數為對話標上帳號持有人的標籤。若帳號持有人不在辦公室（透過簡單的日曆整合確認），對話則重新標記予當值人員。

這意味着在任何時刻，任何團隊成員均可調用 GET /v1/conversations/labels，準確查看哪些對話被分配給自己——涵蓋全部六個 LINE 帳號。共用收件箱的問題並非透過另建收件箱來解決，而是在現有多個帳號上為對話加上標籤。

標籤同時驅動每週報告：一個排程任務拉取所有被標上每位業務標籤的對話，計算回覆時間（從 message.received 的 occurred_at 至首次出站 POST /v1/messages 呼叫的時間差），並於每週一早上將摘要發佈至 #support-metrics。

第一週 vs 第四週

數據說明一切。Webhook 上線前一週，團隊在 LINE 上的中位回覆時間為 3 小時 40 分鐘，有 11 則訊息逾四小時未獲回覆。至第四週，中位回覆時間縮短至 22 分鐘，零則訊息逾四小時未回覆——最長的一次為 1 小時 15 分鐘，發生於全公司外出活動期間。

AI 草稿層級處理了約 35% 的入站訊息。團隊核准並直接發送約 80% 的草稿，無需修改。餘下 20% 需作小幅改寫——通常是因為客戶的問題涉及關鍵字分類器遺漏的細微之處。即使在該等情況下，草稿仍為業務代表提供了起點，將撰寫時間從數分鐘縮短至數秒。

CRM 整合帶來一項意想不到的附加效益：業務團隊開始善用 LINE 對話記錄為續約電話做準備。在 webhook 之前，業務代表在續約會議中完全沒有客戶過去在 LINE 上的支援互動記錄。如今他們可查閱每一則訊息、每一次回覆時間及每一個解決方案——全部自動記錄。

團隊沒有改變的事

客戶對一切渾然不覺。他們仍然向已使用數月的同一批 LINE 帳號發送訊息，仍然收到同一批人的回覆。唯一的分別是回覆來得更快，而且若其慣常的業務代表不在，會有其他人接手——因為訊息在 Slack 上對整個團隊可見，而非埋沒在某一個人的手機裏。

團隊亦繼續維持 LINE 帳號為個人帳號，而非 OA 帳號。UnifyPort 的 webhook 不論帳號類型均會推送入站訊息——OA 驗證排隊及互動窗口屬於出站群發的考量，而這支團隊的工作流程完全是入站。倘若他日決定進行主動推廣（季節性促銷、產品公告），OA 方案便會具有意義。在此之前，那只是一層不必要的行政程序。

這個模式

這不僅是 LINE 的故事。任何在多個個人帳號上接收客戶訊息的團隊——不論是 WhatsApp、Telegram、X 還是 Zalo——都面對同樣的分流問題。Webhook 不在乎訊息來自哪個平台；provider 欄位會改變，但 payload 結構、HMAC-SHA256 驗證及分流邏輯完全相同。這支福岡團隊已在規劃將其 WhatsApp 帳號（東南亞倉儲合作夥伴所使用）納入同一套分流系統。一個處理器、一組標籤、一條指標管線。

若你團隊的客服策略是「每人自行查看自己的訊息」，問題不在於是否需要更好的平台——而在於你的訊息是否需要更佳的分流層。一個 webhook 端點、20 行分流邏輯，加上你現有的工具，或許已經足夠。