ybuild 助力經銷與批發

適合誰

• 管理 B2B 訂單的經銷商和批發商
• 已經撐不住試算表的快速消費品與供應鏈團隊
• 需要協調業務員、路線和庫存的團隊

ybuild 如何契合

• 訂單、商品型錄與庫存，統一在一套託管的全端系統裡
• 上線到你自己的網域，配備託管資料庫與身分驗證
• 業務員和後勤用的是同一份即時資料——不必重複輸入
• 版本歷史與當機復原讓接單作業不中斷

接單的一天：從業務員的手機到最終發票

看一看一張訂單在一家中型經銷商內部實際是怎麼流轉的，你就會明白試算表為什麼會崩。一名業務員按路線開車到一家便利商店，繞著貨架走一圈，把訂單寫在本子上，或者直接發進 WhatsApp：330ml 的來十二箱、新品 SKU 來六小盒、其餘照老樣子。這張訂單就一直躺在手機裡，直到辦公室有人把它重新敲進試算表，再拿它去核對一張昨天上午才最後準確過一次的庫存表，然後確認價格——而這個價格並不是牌價，因為這個客戶是二級價格層，還有一條產品線簽了長期特價。把這套流程乘以四十名業務員、三百個客戶，光是重複輸入本身就是一份全職工作，產出的卻是錯誤而不是價值。

接著，後勤還得回答試算表答不上來的問題：這個客戶是不是超了信用額度、這件貨到底還有沒有、還是早就許給了另外三張訂單、這單該排今天的路線還是明天的。揀貨員拿著一張列印單幹活，可單子傳到倉庫時早就過時了。發票開出來、用電子郵件寄出去，然後被拖三十天、六十天、九十天地追款，卻沒有人能很快說清哪些客戶逾期了、逾期多少。

上面每一個環節，都是一套託管系統可以替掉一通電話或一次重複輸入的地方。業務員只輸入一次訂單，直接對著即時庫存和這個客戶自己的價格層，輸入完就是一張訂單——而不是一則還要別人謄寫的訊息。訂單一旦確認，庫存立刻扣減，下一名業務員看到的就是真正還剩多少。信用額度和帳期掛在客戶身上，超額的訂單會在出貨前就被標記出來，而不是出完貨才發現。揀貨單、配送路線、發票，全都讀同一筆記錄。這就是軟體和試算表的差別：一份共享的唯一事實來源，業務員、倉庫和後勤同時基於它工作。

先做訂單，再做商品型錄，最後做業務員端

直覺會讓你先做商品型錄，因為它感覺像是地基，但在經銷裡回本最快的其實是訂單。先從對著即時庫存的接單做起：一個畫面，讓業務員或買家選商品、看到適用於這個客戶的價格、然後送出——訂單一確認，庫存就隨之扣減。就這一個閉環，就幹掉了這門生意裡最燒錢的習慣：同一張訂單輸入兩三遍。先把它跑起來、放到你自己的網域上，讓幾名業務員先用上一個星期，再去加別的任何東西。

商品型錄排第二，而它絕不只是一張商品清單。批發商品型錄裡裝著計量單位——個、小盒、整箱、棧板——以及彼此之間的換算，這樣買家可以按箱下單，而庫存按個計數。它還裝著針對不同客戶的定價：牌價、分層價、合約價、量價折扣，以及業務員談下來的一次性特價。把這些建模一次，之後每張訂單都會自動繼承正確的數字。給每件商品錨定一個真實的 SKU，如果你還供貨給零售端，再加一個 GTIN，這樣同一件貨在訂單上、揀貨單上、發票上指的都是同一樣東西。

業務員端排第三。等訂單和定價都穩了，再給外勤團隊一個屬於他們自己的檢視畫面：他們的客戶、他們的訂單歷史、一個「照老樣子再來一單」的快捷按鈕，以及在承諾之前先看清庫存的能力。這也正是如今 B2B 買家所期待的——自助回購，而不是乾等一通回電。至於後勤工具——缺貨補單處理、一個簡單的揀貨檢視、一張逾期發票清單——哪裡痛了再加，別提前加。按這個順序來打造，意味著第一週之後你手裡就有一套跑得起來、能賺回成本的託管系統，而且你是對著真實使用去迭代它，而不是一開始就憑空猜需求。ybuild 把每一塊都做成全端——資料庫、邏輯、畫面——所以「加上業務員登入」或者「加上量價折扣定價」是一句提示語，而不是一個專案。

定價、帳期，以及經銷系統容易做砸的地方

經銷的定價從來不是一個數字，一套假裝它是一個數字的系統，一碰到現實就垮。同一箱貨，出給這個客戶是牌價，出給那個客戶是供貨協議裡鎖定的合約價，出給第三個客戶則是只有超過最小起訂量才生效的量價折扣。帳期也各不相同：這個買家是月結 30 天，那個是月結 60 天，新客戶在證明自己之前一律貨到付款，而且每個客戶都有一個本該在揀貨之前就攔下訂單的信用額度。配送又是單獨的一層——訂單要按路線批次歸攏，有些客戶只在特定的日子收貨，先出一部分、其餘轉缺貨補單也是常態，而不是例外。從一開始就把模型建得能容下這一切，軟體才會在你做大的過程中一直好用；把單一價格、單一帳期寫死進去，不出一個月你就又回到試算表上了。

有五個錯誤專門把這類系統做砸。第一，想一口吃成胖子——一上來就要把整套 ERP 全換掉，而不是先上線訂單閉環再逐步擴展。第二，無視針對不同客戶的定價，把牌價當成唯一的價格；一個報錯價的工具，業務員會直接棄用。第三，忘了計量單位，於是一張按箱的訂單被悄悄記成了按個，庫存數字就此漂移。第四，SKU 和 GTIN 上沒有紀律，商品型錄裡堆滿重複項，庫存數字變得毫無意義。第五，權限給得太浮濫——讓每名業務員都能看到每一個客戶、看到成本或毛利資料，而其實業務員只該看自己名下的客戶，錢的事該由後勤看。

勝出的團隊會把範圍收得很緊、讓系統一直在線。他們把訂單閉環放到自己的網域上，讓業務員先用起來，再隨著業務的需要陸續加上定價規則、缺貨補單和報表——一套會成長的託管系統，而不是五個互不相通的訂閱。因為整套東西都跑在 ybuild 上，迭代很安全：版本歷史和當機復原意味著，就算週中改動了某個價格層，也不會把接單作業弄癱。

常見問題

ybuild 能處理針對不同客戶的批發定價和分層定價嗎？

能。把你的牌價、分層價、合約價和量價折扣描述出來，ybuild 就會把它們做進商品型錄，讓每張訂單都為對應客戶取到正確的數字。整套系統託管在 ybuild 上，跑在你自己的網域。

業務員能在外勤時用手機接單嗎？

可以。業務員會得到一個適配手機的檢視畫面，看到自己名下的客戶、即時庫存和一個回購按鈕，訂單直接寫進後勤正在用的同一套託管系統——不必重複輸入，也不用再謄寫 WhatsApp 訊息。

它能按不同的計量單位追蹤庫存嗎——個、箱、棧板？

能。把你的各種單位和它們之間的換算建模一次，即便買家按箱下單、而你按個計數，系統也能把數量算得清清楚楚，一張按箱的訂單絕不會被悄悄記成一個單件。

我能只從接單做起、其餘功能以後再加嗎？

可以，而且這正是推薦的路徑。先把訂單閉環做出來，上線到你自己的網域，然後用一句句提示語加上定價規則、缺貨補單、業務員登入和報表。版本歷史會在你迭代的同時保證線上系統的安全。

要讓它一直跑著，我需要伺服器或者工程師嗎？

不需要。ybuild 會把這套全端系統建置出來並託管在你自己的網域上，配備託管資料庫、身分驗證和當機復原，所以沒有任何東西需要你自己部署，也沒有伺服器要你盯著。