一句話結論：「對話式下單」不必一開始就做語音助理。真正的前置條件是把訂購流程背後的資料與規則整理清楚：品項有唯一代號、客戶有專屬價格、庫存與交期查得到、重複訂單能被辨識。這些整理好之後，不管未來透過表單、對話介面還是系統對接，都接得上；反之，介面做得再炫也接不住。
B2B 的訂購流程常見的狀況是：老客戶打電話或傳 LINE 給業務，業務手動查價格與庫存，再手動開單進系統。這個流程能運作，但它依賴特定的人，而且每一筆都要花時間。
所謂「對話式下單」的願景是讓客戶用自然語言表達需求就能完成訂購。這個願景可行，但多數公司跳過了前置工作，直接想做介面，結果做出一個看起來很新但實際上還是要人工處理的系統。這篇文章談的是前置工作該做什麼。
為什麼傳統表單在 B2B 特別難用
B2C 的購物車模式在 B2B 經常水土不服，原因不是介面設計不好，而是 B2B 的交易結構本來就不同。
| B2B 的實際狀況 | 標準購物車的問題 |
|---|---|
| 不同客戶有不同價格 | 標準購物車顯示統一定價 |
| 一次訂十幾個品項與不同數量 | 要逐項搜尋、加入、調整數量 |
| 常常是重複訂購上次的內容 | 每次都要從頭操作 |
| 有月結額度與付款條件 | 結帳流程預設要線上付款 |
| 需要確認庫存與交期才下單 | 下單後才知道缺貨 |
| 下單的人與付款的人不同 | 單一帳號無法處理簽核 |
所以問題不在「表單 vs 對話」，而在流程設計。一個針對 B2B 設計好的訂購介面（有專屬價格、有歷史訂單一鍵重訂、有即時庫存、支援月結）就已經能解決大部分痛點。對話式介面是更進一步的便利，但如果上述這些都沒處理，換成對話介面也一樣不好用。
對話式下單真正的前置條件
不管最終用什麼介面，底層都需要這幾件事到位。這些就是實際要花時間的部分。
- 品項要有唯一且穩定的代號。如果同一個產品在不同部門有不同叫法、Excel 裡有三個版本的料號，任何自動化都會出錯。這是最基礎也最花時間的一步。
- 客戶專屬價格要能被程式查到。如果價格在業務的腦袋裡或散在報價單檔案裡，系統就算不出金額。需要把價格規則整理進系統。
- 庫存與交期要能即時查詢。這決定了下單時能不能立刻回覆可行性。如果庫存數字本身不準，先不要自動化——會把錯誤放大。
- 要能辨識重複訂單。B2B 很大比例是重訂上次的內容，所以歷史訂單必須可查、可複製。這一項的使用率通常最高。
- 要有防重複送出的機制。對話或自動流程最容易出現的錯誤是同一筆訂單被送出兩次。需要用訂單編號或唯一鍵做冪等處理。
- 要有審核關卡。金額較大或規格特殊的訂單，應該進入待確認狀態由人核對，而不是直接成立。
如果只做一件事，做第 4 項。把「歷史訂單一鍵重訂」做好，對 B2B 老客戶的效益通常最立即。這一項技術難度不高，不需要任何 AI，但它解決的是客戶每次都要重新操作的真實痛點。
模糊需求要怎麼對應到正確品項
客戶實際說出口的是「上次那個，一樣的量」或「那個白色的，要兩箱」。要把這類表達對應到正確料號，需要的不只是語言理解，更是乾淨的對應資料。
| 客戶的說法 | 系統需要什麼才能對應 |
|---|---|
| 「上次那個」 | 該客戶的歷史訂單可查 |
| 「白色的那款」 | 品項有顏色屬性欄位，不只在品名文字裡 |
| 「兩箱」 | 單位換算規則（一箱等於幾個） |
| 「跟上次一樣但加厚」 | 品項屬性有結構，能做相近品項比對 |
| 客戶自己的內部料號 | 客戶料號與我方料號的對照表 |
最後一項很常被忽略但效益很高。很多 B2B 客戶是用自己的料號溝通的。如果系統裡有「客戶料號對照表」，客戶就能用他習慣的叫法下單，不必查你的料號。這一項不需要 AI，純粹是資料結構，但對客戶體驗的改善很直接。
API 先行：為什麼介面不該先做
比較穩健的架構順序是先把功能做成 API，再在上面接各種介面。這樣做的好處是：不管未來要接網頁、要接對話介面、要接客戶的系統，底層都不用重做。
| 先做介面 | 先做 API | |
|---|---|---|
| 換介面時 | 邏輯寫在介面裡，要重做 | 只換前端，邏輯不動 |
| 客戶要系統對接 | 沒有可對接的入口 | 直接開放既有 API |
| 多通路 | 每個通路各寫一套邏輯，容易不一致 | 共用同一套規則 |
| 測試 | 只能靠操作介面測 | 可自動化測試 |
| 初期成本 | 較低 | 略高 |
實務上的建議是：即使現在只打算做一個網頁訂購介面，也把查價、查庫存、建立訂單這幾個功能做成獨立的 API。初期多花的成本不多，但之後要加任何通路都省事。
分階段導入：從最小可行開始
這類專案最常見的失敗模式是規劃得太完整，結果一年都沒上線。建議切成可以各自獨立上線的階段。
- 第一階段：料號與價格整理。不做任何新功能，純粹把資料整理乾淨。這一階段沒有畫面可以看，但它是所有後續的基礎。
- 第二階段：客戶登入後可查專屬價格與歷史訂單。只做查詢不做下單，風險低，而且客戶立刻有感。
- 第三階段：歷史訂單一鍵重訂。使用率通常最高的功能，技術難度不高。
- 第四階段：即時庫存與交期顯示。需要與內部系統串接，前提是資料準確。
- 第五階段：線上建立新訂單（含審核關卡）。真正開始寫入訂單，必須有防重複與審核機制。
- 第六階段：對話式或語音介面。這時候底層都備齊了，介面只是換一個入口。
注意第一階段沒有畫面。這會讓專案在內部不好推，因為「看不到成果」。但跳過它直接做後面的階段，一定會在上線後遇到料號對不上、價格算錯的問題。建議在專案開始時就讓決策者知道這一階段的必要性，並把它當成獨立的交付項目驗收。
風險與該先想清楚的事
訂單重複送出
自動化流程最常見的錯誤。必須用唯一鍵（例如客戶單號或系統產生的交易編號）做冪等處理，確保同一筆請求重複送出時不會建立兩筆訂單。這一項在設計階段就要定清楚。
價格或庫存回覆錯誤
如果系統回覆了錯的價格而客戶已下單，後續處理很麻煩。建議在初期設定金額門檻，超過門檻一律進人工確認，並在介面上明確標示「價格與交期以正式回覆為準」。
權限與簽核
B2B 常見下單的人沒有核決權。需要先確認客戶端的流程：是誰下單、誰確認、要不要寄確認信給第三人。這屬於流程設計，不是技術問題，但沒釐清就會出事。
我們做過幾個 B2B 訂購與系統串接的案子，最花時間的從來不是開發，而是資料整理——料號不統一、客戶專屬價格散在報價單裡、庫存數字在系統裡本來就不準。所以我們現在的做法是把「資料盤點與整理」當成獨立的第一階段，明確列在報價與時程裡，而不是當成開發的附帶工作。另外我們會建議一定要有防重複送出與金額門檻的人工關卡，這兩項在初期加上成本很低，但少了它們出問題時代價很高。
常見問題
一定要做對話式或語音介面嗎？
不一定。多數 B2B 的痛點用一個設計得好的訂購介面就能解決：客戶專屬價格、歷史訂單一鍵重訂、即時庫存、支援月結。對話介面是更進一步的便利，但如果這些基礎沒處理，換成對話介面也一樣不好用。
投報率最高的單一功能是什麼？
通常是「歷史訂單一鍵重訂」。B2B 有很大比例是重訂上次的內容，這項功能技術難度不高、不需要 AI，但直接解決客戶每次都要重新操作的痛點，使用率通常也最高。
我們的庫存數字不太準，可以做即時顯示嗎？
不建議。接到網站上只會把錯誤放大，而且是放大到客戶面前。較務實的做法是先顯示「有／無／請洽詢」這類粗略狀態，同時處理內部資料準確度，等數字穩定後再做精確的即時顯示。
為什麼要先做 API 而不是先做畫面？
因為邏輯寫在 API 裡，未來換介面、增加通路、或客戶要直接系統對接時都不必重做。初期多花的成本不多，但之後省下的重做成本很可觀。即使現在只打算做一個網頁介面，也建議把查價、查庫存、建單做成獨立 API。
最該注意的風險是什麼？
訂單重複送出。自動化流程中同一筆請求可能被送出兩次，必須用唯一鍵做冪等處理。另外建議設金額門檻，超過門檻進人工確認，並在介面明確標示價格與交期以正式回覆為準。這兩項在設計階段加入成本很低。
甫東科技提供哪些相關服務？
甫東科技提供 B2B 訂購流程盤點與資料整理規劃、客戶專屬價格與歷史訂單功能開發、ERP 或進銷存系統的 API 串接、訂單冪等與審核機制設計，以及分階段導入的專案規劃。服務以高雄、屏東、台南為核心，嘉義、台東與全台皆可遠端合作。
想評估線上訂購該從哪一階段開始？
甫東科技提供免費流程盤點，檢視你的料號、價格規則與庫存資料現況，告訴你哪些要先整理、哪一階段最快能讓客戶有感。
預約免費流程盤點 →甫東科技有限公司｜高雄市大寮區鳳林一路 184 巷 20-11 號
電話 07-641-8686｜Email service@fulldot.com.tw｜了解企業系統開發
