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 天不是什麼特殊成績。這就是當你不用等別人審批流程時，時間線本來應有的樣子。