客戶對話
查單問題，不用經人手
「我張單去到邊」是店家收得最多的一句，而回答它其實是查表，不是對話。難的不是那句回覆，而是要有一個機器讀得到的狀態；還有一點：那句自由文字之所以可以發出，只因為客戶先開口。過幾個鐘頭，同一句說話就要用 WhatsApp 預先批准的模板才發得出。
- 觸發
- 兩個
- 執行頻率
- 每 15 分鐘
- 工具
- 5 件
- 需要 durable execution
- 不需要
流程
上面那條負責維持一個答得出口的狀態。下面那條是對話本身，它讀上面那張表，而不是每次再問速遞公司。
每 15 分鐘
n8n 排程
抓取出貨狀態
n8n · Make
寫入狀態表
Sheets · Airtable
客戶發訊息
WhatsApp Cloud API
判斷意圖與訂單編號
OpenAI · Anthropic
找到訂單？
n8n IF
回覆狀態
WhatsApp Cloud API
轉交人手
Slack · WhatsApp
逐步拆解
- 01
每 15 分鐘
n8n 排程狀態更新按自己的時鐘跑，所以有人問的時候答案已經在。不是等客戶在線上等你去查。
- 02
抓取出貨狀態
n8n · Make由網店和速遞公司讀回每一張未完成訂單的現況。追蹤編號要保留——客戶問的就是這個，而這個數字無法用文字轉述。
- 03
寫入狀態表
Sheets · Airtable一張未完成訂單一行，以客戶手上那個訂單編號為鍵。回覆由這張表組成，所以答錯就是某一行錯，可以找得到。
- 04
客戶發訊息
WhatsApp Cloud API訊息到達時 webhook 觸發。同一刻，24 小時客服視窗開始計時——下面那句回覆可以用自由文字，唯一原因就是這個。
- 05
判斷意圖與訂單編號
OpenAI · Anthropic分類這是不是查單問題，並從句子中抽出訂單編號。模型只做這兩件事：它不去查狀態，也不負責寫那句回覆。
- 06
找到訂單？
n8n IF把抽出來的編號和狀態表對。接近但不完全相同，一律當作找不到：把另一位客人的包裹講得斬釘截鐵，代價遠高於轉交人手。
- 07
回覆狀態
WhatsApp Cloud API發出現況和追蹤編號。如果有多於一張未完成訂單，用互動清單讓客戶自己揀，不用再打一次編號。
- 08
轉交人手
Slack · WhatsApp對不上就立即交給人，並附上原文。自助流程沒有出口，就只是一堵牆。
平台不容許的事
用自由文字回覆並不是設計選擇，而是一個會過期的權限；接手它的東西，必須在你需要之前就已經存在。
文件寫明：「When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts. If the user messages or calls you again before the timer expires, the timer resets to 24 hours.」即時回覆落在這個視窗之內，所以不需要預先批准。
WhatsApp Cloud API — Send messages「When the window closes, you can only send pre-approved template messages.」凌晨兩點回覆兩日前的一句提問，不可能用自由文字——所以這句回覆的「過夜版本」必須是一個早已存在的模板。
WhatsApp Cloud API — Send messages互動清單最多「up to 10 sections, with up to 10 rows for all sections combined」，每行標題上限 24 字元、說明上限 72 字元。訂單紀錄長的客戶無法一次過全部列出，而一行標題也放不下完整的貨品名稱。
WhatsApp Cloud API — Interactive list messages快速回覆按鈕最多三粒，每粒文字上限 20 字元。「查另一張單／找同事」已經用掉整個額度，再豐富一點就必須改用清單。
WhatsApp Cloud API — Interactive reply buttons messages
什麼情況不值得做
以下三種情況，維護成本會高於重複回答的代價。
你的訂單狀態不存在於任何機器讀得到的地方。追蹤資料如果只在速遞公司的 PDF 或某位同事的記憶裡，流程根本無從答起——但它仍然會答，而且答得肯定。
你實際收到的不是「我張單去到邊」，而是「有沒有其他尺碼」。攔錯了問題，訊息量原封不動，還多了一道客戶要繞過的關卡。
沒有人負責「對不上」那一條分支。任何自助流程最終都會有對不上的一刻，那條路如果沒有出口，客戶面對的就是一部既幫不到又轉不走的機器。