3 日上線：唔走官方認證佇列接收 WhatsApp 入站訊息 — UnifyPort

2026 年初，一個做東南亞電子產品零售嘅小團隊，撞上咗一個熟悉嘅死胡同。佢哋 WhatsApp 客服查詢量已經多過人手 Inbox 可以應付嘅，需要後端系統自動接收同路由入站訊息。計劃好清晰：接入 WhatsApp Business API，收取入站 webhook 事件，交畀客服路由邏輯處理。

佢哋一月底提交咗 Business Verification。審核佇列一路排到三月。

問題唔係查詢量，係等待

等緊嗰陣，佢哋 Inbox 繼續靠人手堆積。買家用 WhatsApp 問物流進度、改訂單、問貨存——因為呢個係買家習慣用嘅渠道。訊息一條一條噉入嚟。唔係冇人願意回。瓶頸係架構嘅問題：每條訊息都要人睇、人回，因為 API 權限未批，自動化根本冇得開始。

兩個客服每日要花大概四個鐘去分揀 WhatsApp 訊息——訂單狀態查詢呢啲後端一秒就答得到嘅嘢、唔需要判斷力嘅 FAQ 回覆、幾條規則就搞掂嘅路由分流。等待唔只係煩，係有實際成本嘅，而且每個星期都係咁疊落去。

換個方向

二月中，等咗三個星期仲未有審核回音，團隊重新諗過。佢哋真正需要嘅唔係官方 API，而係可以將入站訊息當結構化事件接收，讓路由系統處理。官方 API 係一條路，但唔係唯一嗰條。

佢哋將原本做客服用嘅 WhatsApp 帳號——一個一直用緊嘅普通號——接入咗 UnifyPort。配置花咗一個下午。冇文件、冇審核視窗、冇等待。

由此之後，每條買家入站訊息都以 message.received webhook 事件嘅形式到達後端，結構統一：訊息正文、發送者識別、對話串 ID、時間戳。嗰套一路等緊 API 權限、被迫空轉嘅路由邏輯，終於有嘢可以處理喇。

頭三日係點嘅樣

第 1 日： 帳號接入，webhook 端點配置好，收到第一批測試訊息並記錄。團隊確認事件 payload 格式符合後端預期，並驗證 HMAC-SHA256 簽名可以正常校驗。

第 2 日： 路由規則上線。訊息正文含訂單號 → 自動查狀態、自動回覆。新發件人首次聯絡 → 建立 CRM 聯絡人並加入銷售跟進佇列。其餘 → 標記為人工審核，並預填好訊息上下文。

第 3 日： 正式對接真實用戶流量。兩個原本花半個更分揀 WhatsApp 訊息嘅客服，精力轉移到升級處理——嗰啲真正需要人工判斷嘅對話。

第三日結束時，系統已在自動處理約 70% 嘅入站訊息量。剩低 30% 以預分類工單形式到達客服，唔係原始 DM 訊息。

之後嘅數字

上線後頭三十日：

• 首次回覆時間：由人工分揀時平均 2.4 個鐘，降至自動回覆 90 秒以內，升級處理 8 分鐘以內
• 客服喺 WhatsApp 嘅時間：由兩人合計約 4 個鐘/日，降至 45 分鐘以內，全部集中喺真正需要判斷力嘅案例
• 訂單狀態查詢（最多嗰個訊息類別）：94% 嘅情況全程唔需要人手介入

Business Verification 最終係三月底批咗。嗰時團隊已經跑咗六個星期自動化入站。佢哋冇從已經運作緊嘅嘢遷走。

唔需要嘅嗰啲嘢

冇向第三方平台提交公司登記文件。冇建立並審批範本庫。冇按訊息類別同接收國家分層追蹤嘅按條計費。處理入站訊息嘅帳號，就係團隊原本人手客服時一直用緊嗰個——一個買家通訊錄裡已有嘅普通號。

佢哋搭建嘅路由邏輯由一開始就同渠道無關。後來當佢哋為部分買家群體加入 Telegram 時，同一套路由規則照常生效。message.received 事件格式完全一樣。HMAC 簽名驗證完全一樣。payload 裡唯一嘅分別，係發件人所在平台嗰個欄位。

呢個規律

呢件事唔係呢支團隊獨有嘅。同樣嘅鏈條喺商家客服營運入面反覆出現：需要入站自動化 → 預設走官方 API → 認證同資格要求將一個軟件問題變成採購問題 → 乜都未建好就過咗好幾個星期。

呢條非官方入站路——接入現有帳號、接收歸一化事件、對接已有路由邏輯——將呢個鏈條壓縮咗。軟件問題就係軟件問題。UnifyPort 做嘅就係呢個連接：將 WhatsApp、Telegram、LINE、TikTok、Zalo 同 X 嘅入站事件歸一化成一套 schema，帶 HMAC 簽名投遞到你嘅端點，唔需要認證佇列。

3 日唔係乜特別成績。呢就係當你唔使等人哋嘅審批流程時，時間線本來應有嘅樣。