會找這組字的，多半是做批發、原物料、零組件或代理經銷的公司，手上有一批固定往來的客戶，訂單目前靠業務、通訊軟體、傳真或電話在接，想把這件事搬到線上。另一種人則是資訊或電商窗口，被主管交代評估要不要建置給企業客戶用的下單系統。這兩種人真正需要知道的不是「電子商務」的定義，而是企業對企業的交易在系統上跟一般購物有哪些結構性的不同，以及規劃時哪些事情不先決定，之後就要打掉重做。
企業客戶的下單流程，跟一般消費者不是同一件事
一般購物網站假設每個訪客看到的價格相同、下單即付款、買完就結束。企業採購的假設完全相反：價格因客戶而異、下單前可能要先出報價單、付款可能在出貨後很久、同一份清單每個月會重複購買。若把消費端的購物流程直接搬過來，業務端第一天就會發現對不上。
規劃時建議先把實際的交易流程畫出來：詢價、報價、確認、出貨、對帳、請款，每一段目前是誰在做、用什麼工具。系統要取代的是哪幾段、哪幾段仍然留給人處理，這件事先講清楚，功能範圍才不會無限膨脹。
客戶分級與價格政策是整個平台的地基
企業客戶最在意的往往是「我看到的價格對不對」。常見的做法有幾層：依客戶等級套用不同折數、針對特定品項給特定客戶專案價、依採購數量設階梯價、某些品項對某些客戶完全不開放。這幾種規則會互相疊加，設計資料結構時就要決定優先順序，否則系統上線後會出現業務也解釋不了的價格。
另一個要先決定的是價格的可見性。有些公司希望未登入者完全看不到金額，只看得到規格；有些則願意公開建議售價，登入後才顯示合約價。這個選擇同時牽涉到商業考量與網站被搜尋引擎收錄的範圍，值得跟業務主管一起討論而不是由開發端自行決定。
一個客戶、多個採購人員的權限設計
企業端經常不只一個人使用同一個帳戶：採購負責下單、主管負責核准、會計負責看帳。如果只給一組共用帳號密碼，後續會出現無法追查是誰下的單、人員離職卻改不了密碼等問題。
- 子帳號機制：同一家客戶底下可開多個使用者，各自登入。
- 角色權限：誰能看價格、誰能送出訂單、誰只能查詢進度。
- 內部簽核：金額超過門檻時，先送給主管確認再成立訂單。
- 收貨地點管理：同一個客戶有多個廠區或門市，出貨地址要能各自維護。
大量品項與重複採購的操作效率
企業採購一次可能買數十甚至上百個品項，用消費端那種一頁一頁點進商品再加入購物車的方式會非常痛苦。實務上比較受歡迎的是幾種輸入方式：直接用料號批次貼上、把上一張訂單整張重下、把常買的清單存成採購範本、以規格條件快速篩選。
此外，庫存與交期的呈現方式也要想清楚。企業客戶通常可以接受分批出貨或預估交期，但不能接受下單之後才知道缺貨。把可售數量、預計進貨時間顯示在下單當下，能省掉業務大量的追問。
要不要跟內部系統串接，先看資料誰說了算
多數公司在導入時都會遇到同一個問題：商品、庫存、客戶與價格，到底以進銷存系統為準，還是以網站為準。建議先定義每一類資料的唯一來源，再決定同步方向與頻率，而不是兩邊都能編輯。兩邊都能改，最後一定會出現對不起來的數字。
串接的深淺也可以分階段。初期先做商品與庫存的單向同步、訂單以檔案或介面回拋，就能解決大部分的重工；等流程穩定，再考慮把應收帳款、額度控管納入。一開始就要求全面即時雙向同步，開發成本與失敗風險都會明顯上升。
自建與租用現成方案的取捨
現成的方案上線快、維護責任外部化，適合價格規則單純、品項不算太複雜的公司。自行開發則能完全貼合既有的交易慣例與內部系統，代價是時間與後續維護。判斷的方式可以很務實：把你獨有、又不能妥協的規則列出來，如果現成方案有八成以上能用設定處理，通常沒有必要自建。
影響開發報價的因素也集中在這幾件事：品項與價格規則的複雜度、要串接哪些既有系統、是否需要多語系與多幣別、有沒有審核與額度控管、以及舊資料要不要搬移。報價前把這些條件寫清楚，各家報出來的數字才有比較的基礎。
上線後最常卡住的，其實是客戶願不願意改習慣
系統做得再完整，長期用電話與通訊軟體下單的客戶不一定會主動改變。比較有效的做法是給誘因與過渡期：線上下單才能查得到即時庫存與歷史對帳、線上才有專屬清單、業務協助前幾次操作、舊管道保留一段時間再逐步收斂。同時也別忽略內部，業務如果覺得系統會削弱自己的角色，推動就會停在原地。
常見問題
我們客戶習慣用通訊軟體和電話下單，導入線上系統會不會反而更麻煩？
短期內確實會多一段適應期，因此不建議一次全面切換。可以先讓業務把重複性最高的補貨型訂單引導到線上，客戶會先感受到查詢庫存與對帳變方便；至於需要討論規格的案子，仍然由業務處理。等到線上訂單佔比穩定成長，再逐步減少舊管道，抗拒感會小很多。
企業客戶的價格不想被同業看到，網站還能被搜尋到嗎？
可以。常見做法是把商品的規格、用途、應用說明等資訊公開，讓搜尋引擎收錄，價格則放在登入後才顯示。這樣既能靠內容帶來新的詢問，也不會揭露合約價。要注意的是，公開頁面必須有足夠的實質內容，只放一張圖與一句「請登入查看」的頁面很難獲得曝光。
同時要做企業端與一般消費端，該用同一個網站嗎？
兩種模式的價格、稅務呈現、出貨與客服邏輯都不同，硬塞在同一套流程裡容易互相干擾。比較常見的處理是共用同一份商品與庫存資料，但前台分成兩個入口，各自套用不同的價格與結帳規則。若品牌形象需要一致，可以在視覺與網域規劃上做整合。
有帳期與信用額度的客戶，系統要怎麼處理付款？
這類客戶通常不會在下單時線上刷卡，而是採月結。系統要做的是記錄未結清金額、在超出額度時提示或擋單，並產出可對帳的明細。額度與帳期的資料多半來自財會系統，因此需要同步機制；若初期不想串接，也可以先由財會人員在後台維護，等流程穩定再自動化。
舊有的報價單與歷史訂單資料，有必要搬進新平台嗎？
建議至少搬近期的交易紀錄，因為客戶登入後看得到自己的採購歷史，才有動機使用線上系統，重複下單與對帳的功能也才發揮得出來。太久遠或格式殘缺的資料則不必勉強轉入，可以保留在原系統供查詢。搬移前要先確認品號與客戶編號的對應規則，否則資料進來也接不上。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
相關主題
下一步
如果你正在評估「b2b 電子 商務 平台」相關的規劃，可以參考我們的官網與電商網站服務，或直接與我們聯繫，我們會依你的產業與現況給出務實的建議。
