客戶對話
把查詢直接變成報價
那句查詢本身已經包含了整張單：貨品、數量、送去哪裡。然後有人讀一次，再把同樣的資料打進第二個系統。機器在這裡的角色是「讀」，不是「決定」——它負責抽出欄位，價格則由你的價目表提供。一個由語言模型寫出數字的報價，不算報價。
- 觸發
- 兩個
- 執行頻率
- 每次查詢
- 工具
- 5 件
- 需要 durable execution
- 不需要
流程
上面那條把訊息變成草稿。下面那條用另一個時鐘更新的價目表去計價，然後檢查還欠什麼。
查詢進來
WhatsApp Cloud API
抽出欄位
OpenAI · Anthropic
寫入草稿訂單
Sheets · Airtable
每晚更新價目
n8n 排程
為草稿計價
n8n · Make
資料是否齊全？
n8n IF
發出報價待確認
WhatsApp Cloud API
請人補齊
Slack · WhatsApp
逐步拆解
- 01
查詢進來
WhatsApp Cloud API客戶一發訊息 webhook 就觸發，24 小時客服視窗同時開始。今日發回去的一切之所以可以用自由文字，原因就在這裡；明日發的就不是。
- 02
抽出欄位
OpenAI · Anthropic從句子中抽出貨品、數量、送貨地點和期限。只做抽取——模型不定價、不加總、不發送。它交回一組欄位，以及一句「找不到什麼」。
- 03
寫入草稿訂單
Sheets · Airtable一個查詢一行，原文與抽出的欄位並排存放。日後報價有爭議時，這一組對照就是全部的憑證。
- 04
每晚更新價目
n8n 排程價格和存貨按自己的時間表更新。報價要帶當日的價，而不是流程上個月碰巧存下來的那個數。
- 05
為草稿計價
n8n · Make逐項在更新過的價目表查價，並在流程內加總。這是算術，屬於程式碼——也是整個流程中唯一絕不可以交給模型的一步。
- 06
資料是否齊全？
n8n IF檢查報價出不了門就欠的那幾格：貨品、數量、目的地，以及每一項都有價。任何一格空白就停，不要用預設值補上。
- 07
發出報價待確認
WhatsApp Cloud API把計好價的報價連同快速回覆按鈕發出——確認、修改、找同事。客戶按一下就可以，不用把已經講過一次的單再講一次。
- 08
請人補齊
Slack · WhatsApp把草稿轉給負責該貨品的同事，並寫明欠了哪一格。硬發一張不完整的報價，比慢一點發更差。
平台不容許的事
有兩條界線決定這個流程的形狀：一封確認訊息裝得下多少，以及回覆在多久之後不再免費。
互動式快速回覆按鈕支援「up to 3 buttons」，每粒文字上限 20 字元，內文上限 1,024 字元。所以確認訊息只能給三個選擇加一段短文，不是抄一份完整規格書的地方。
WhatsApp Cloud API — Interactive reply buttons messages「When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts」；視窗開著的時候，任何服務訊息都可以發。當日計好價、當日回覆的報價，完全不需要批准。
WhatsApp Cloud API — Send messages「When the window closes, you can only send pre-approved template messages.」要花一日才計得出的報價，回不了自由文字——這條慢路需要它自己的模板，而且要在查詢來到之前就寫好。
WhatsApp Cloud API — Send messages「Templates must have a status of APPROVED before they can be sent in template messages」，而且每個模板必須歸類為 authentication、marketing 或 utility。遲到報價用的模板是一段要預先計算的前置時間，不是當日才動筆的東西。
WhatsApp Business Management API — Message templates
什麼情況不值得做
以下三種情況，維護成本會高於重打一次的代價。
你的價格是判斷而不是查表——逐個客戶議價，或者運費逐票報。流程照樣會計出一個數，而一個長得像報價的數字，會被當成報價來讀。
沒有機器讀得到的價目表。價格若散落在一疊 PDF 或某位同事的腦裡，抽取會成功而計價會失敗，偏偏後者才是重點。
你做的是少量大額查詢。一張單金額很大時，成本不在重打，而在某一項寫錯；一份沒有人再核一次的草稿，只會令這件事更容易發生。