B2B 網站應公開價格還是索取報價？按交易條件選擇展示方式

先看買家能否在同一條件下比較

公開一個數字並不等於資訊透明。如果一家公司報的是每件未組裝產品，另一家報的是每套連測試與包裝，買家仍無法作有效比較。決定公開價格前，先定義規格、計價單位、包含項目和需要另行確認的費用，讓銷售與網頁使用同一種說法。

本文處理的是「用哪種方式呈現價格」的決策。最低訂購量、樣品與交期應在產品資料中另行說明，不能靠一句「按量報價」代替所有採購條件。也不要假設公開價格一定會提高詢盤或搜尋排名；不同客戶的決策方式，需要用實際資料觀察。

按交易穩定程度選擇價格展示

下面是內容形式比較，不是任何公司的價格政策。先選一個系列試行，列明由誰確認和更新，再決定是否擴展到整個網站。

公開單價時，把限制放在數字附近

買家在手機上可能只看價格區塊便截圖轉發，因此幣別、每件或每套、適用規格和必要條件應在附近呈現。若運送、安裝或客製另行確認，也要直接說明。不要把影響價格的重要條件藏在另一頁長篇備註中。

「由某金額起」需要有真實可提供的對應範圍。若最低價只適用於特定配置，便說明該配置；若連最低範圍也未確認，就先提供影響預算的因素。可以用假設配置示範買家應提交哪些資料，但要清楚標示為示意，不應讓示例被理解為公司的現行報價。

索取報價也應提供能幫助初步判斷的答案

沒有公開售價的頁面，仍可解釋供應範圍、報價需要的資料、評估步驟，以及收到資料後會由甚麼角色處理。買家應知道提交表格是要求估算、正式報價還是安排討論。只有「價格請洽」而沒有任何指引，會把所有理解工作留給對方。

W3C 的表格說明教學支持清楚交代必填項目和輸入要求。實作上可先收產品、數量範圍、用途和聯絡方式，讓未知資料標示待確認；真正必需的圖稿或規格，則說明原因及可接受的形式。提交成功後顯示已收到哪些需求，不應自動生成未經業務核實的價格承諾。

價格資料與搜尋標記必須表達同一件事

Google 的 Product snippet 文件中，Offer 的 price 表示產品價格，0 代表無需付款。若網站實際是「索取報價」，不能為了讓測試工具通過而填 0，或隨意填最低可能數字。是否使用價格相關結構化資料，應由真實且可公開的內容決定。

請開發者核對可見價格、JSON-LD、下載價目表和相關產品卡片是否一致。價格改動時，若只改正文而遺漏標記或舊 PDF，搜尋展示與買家看到的資料便可能不同。若沒有適合的價格資料，就記下不使用該標記的原因；沒有某種豐富搜尋結果，不代表頁面不能服務採購需求。

以一個系列試行，觀察查詢的質素

先選資料較穩定、負責人明確的系列，記錄試行前後的展示方式與日期。除了看表格提交數，也核對買家是否更常提供合適數量、是否仍誤解計價單位、銷售需要多少輪補充資料。這些是評估內容是否清楚的方法，不是承諾公開價格後一定減少溝通。

價格頁的更新責任應和產品資料放在同一份底稿：核對人、有效條件、下次檢查時間，以及變動後需要同步的語言與文件。若團隊無法持續維護大量數字，可以縮小公開範圍，保留完整詢價說明。讓買家讀到準確的現有資訊，比展示一張沒有人負責的價目表更可用。