自行車店庫存系統
一家自行車店其實是共用一間庫房的三門生意：一間擺滿高價整車的展示廳、一整面裝著成千上萬種細小耗材零件的零件牆，還有一個悄悄從兩邊取貨的維修部門。大多數現成的 POS 工具把這一切硬塞進一份扁平的商品清單，於是一台 5000 美元的電動自行車和一個五毛錢的氣嘴蓋被同樣地計數，到了夏天數字就全亂了。本文將帶你走一遍一家車店真正需要的庫存系統，以及如何把它當成一個運行中、託管的應用程式建置在 ybuild 上、透過你自己的網域對外提供服務。
痛點
- 每一款車型都以尺寸和顏色組成的矩陣形式出貨，所以「庫存有一台 Trek Marlin」這句話毫無意義。在你向顧客承諾之前，你需要知道它是一台霧面藍的 M 號車，正躺在 R3 號儲位上。
- 整車和電動車都帶有車架序號，但它們要嘛塞在鞋盒裡，要嘛躺在一張試算表裡，於是只要有人拿著一個序號和一段說詞走進店裡，保固理賠和失竊尋回就當場瓦解。
- 維修部門整天都在安裝鏈條、線管和內胎，而這些零件幾乎從來沒有被扣減過，於是整個季節裡貨架上的數字都在悄無聲息地偏離真實。
- 旺季波動劇烈，但如果沒有按每個變體設定的補貨點和真實的售出資料，季前進貨就是一場瞎猜，結果要嘛壓著一堆賣不動的滯銷庫存，要嘛在四月份把人人都想要的那個尺寸賣到缺貨。
你能打造什麼
一套兩層結構的商品目錄：車型（Trek Marlin 7，2026 款）是一個商品，而每一種尺寸與顏色的組合都是它自己的變體，各自擁有獨立的條碼、成本、售價、數量和儲位。整車和電動車還會成為帶序號的單件，每一副實體車架對應一行，於是庫存永遠不是一個含糊的車型層級數字。從第一次建置起，它就在 ybuild 上以線上託管的方式運行。
一個收車與工單畫面，技師針對一輛顧客的車開一張工單、加入工時明細、並領用零件。每加入一個零件，都會從銷售區所出售的同一份庫存裡扣減，於是店後場的維修間和店前面的賣場終於共用同一份誠實的數字。
一個進貨檢視，浮現出每一個低於補貨點的變體，按供應商分組、按售出速率排序，並附上所有顧客的特別訂貨。你從這裡草擬採購單，按這些採購單收貨，庫存就帶著正確的成本和儲位落位——全都在你那個線上運行的 ybuild 應用程式裡完成。
數據模型
系統裡的一天
- 早晨：來自經銷商的一批貨到店。你逐箱掃描，按那張未結的採購單收貨，於是庫存帶著正確的成本和儲位落到對應的變體上。
- 這批貨裡的每一台整車，都會被掃描車架序號、登錄為一件帶序號的單件並標記為 in_stock，把那副具體的實體車架和它的變體綁在一起。
- 一位到店顧客想要一台綠色的 M 號礫石公路車。你查一下變體矩陣，看到 R3 號儲位上還有一台庫存，便把它預留下來，免得別人搶在他前面把它賣掉。
- 結帳時，這筆銷售扣減那個變體、把這件帶序號的單件翻轉為 sold、連同一個保固到期日一併綁定到顧客名下，並提示你去登記車架序號以備日後失竊尋回。
- 一位熟客把車留下來做保養。你針對他那件單件的序號開一張工單、設定一個承諾取車日期，工單便進入維修佇列。
- 技師加入了工時，外加一根新鏈條、兩根線管和一條內胎。每個零件在被加進工單時就從庫存裡扣減，於是無論零件是從櫃檯賣出去還是在後場裝上車，數字都保持真實。
- 一天結束時，補貨儀表板標出每一個低於補貨點的變體、按供應商分組、並草擬採購單，其中也包括那些正等著你店裡沒有存的尺寸的顧客的特別訂貨明細。
- 你盤點一個儲位，把實物點數與系統對帳，任何差異都會記在那個變體名下，於是損耗變得可見，而不再是年終時的一個意外。
AI 容易出錯的地方
- 把一款車型當成一個 SKU。車型不是庫存，尺寸與顏色的變體才是。如果資料表結構不把車型和變體拆開、不讓每個變體各自攜帶自己的數量、成本、條碼和儲位，你就會超賣一個自己根本沒有的尺寸，整份庫存也隨之淪為虛構。
- 用同一種方式給帶序號的整車和散裝零件建模。一副車架是一個獨一無二的單件，擁有唯一的序號和一條生命週期（收貨到售出到保固）；而一箱內胎則是可互換的數量。若強行用一種模型套住兩者，你要嘛得給內胎編造假序號，要嘛會把一台 5000 美元電動車的序號弄丟。你需要一個數量層和一個序號層。
- 讓維修工單繞開庫存。技師裝上的每一個零件都必須從賣場所出售的同一份庫存裡扣減，否則數字整個季節都在漂移。粗糙的做法只追蹤工時，卻忘了一張工單同樣是一筆庫存交易。
- 打斷「序號—顧客—保固」這條鏈。保固理賠和失竊尋回都取決於車架序號加購買日期加車主。如果序號只是一條自由文字備註，而不是一條互相關聯的記錄，那麼當一副失竊車架送上門時你答不出「這是不是我們店賣的車？」，兩年後也沒法處理一次保固。
- 把單件的狀態混為一談。已預留、已售出、送修保固中是三種不同的狀態。把它們合併，一台實物已經不在的車會仍然顯示為可售，或者一筆已預留的特別訂貨被賣給了一位到店顧客。要把單件狀態明確地建模，並且絕不讓庫存變成負數。
- 那套兩層目錄：商品到變體（每個變體各自的數量、成本、條碼、儲位），再加上給整車用的帶序號單件。這是其餘一切都掛靠其上的骨幹。
- 銷售點扣減：掃描一個變體條碼或一個車架序號，把它賣出去，看著數量下降、單件翻轉為已售、並關聯到顧客身上。
- 那個補貨檢視：每一個低於補貨點的變體，按供應商分組，隨時可以轉成一張採購單。
- 一套完整的會計總帳。匯出一份 CSV 給你的記帳員或 QuickBooks，而不是在應用程式裡重建一套總分類帳。
- 一個面向顧客的線上店面以及網路商店同步。v1 階段做的是店內賣場，不是全通路；等數字變得可信之後，再把線上補上。
- 自動化的供應商目錄和 EDI 資料接口。先從手動輸入採購單和收貨做起；等核心流程穩固之後，再接上電子經銷商目錄。
常見問題
一款車型有五個尺寸、三種顏色，我該怎麼處理？
把它建成一套兩層目錄。車型（Trek Marlin 7，2026 款）是一條商品記錄，而每一種尺寸與顏色的組合都是它自己的變體，各自擁有獨立的條碼、成本、售價、數量和儲位。庫存永遠落在變體上、絕不落在車型上，所以「庫存有三台」永遠是指某個具體的尺寸和顏色，你也就絕不會不小心賣掉一台自己其實沒有的大號車。
我真的有必要追蹤車架序號嗎？
對整車和電動車來說，有必要。車架序號正是把某一件具體單車與它的買家、它的保固期以及任何失竊理賠綁在一起的東西。把這些車建成帶序號的單件，每一副實體車架對應一行、各帶一個狀態，而把內胎、線管和螺栓保留為單純的數量。在銷售當下把序號登記到像 Bike Index 這樣的公共登記平台上，萬一日後失竊，也有助於把它尋回。
維修工單怎樣才不會把我的庫存數字搞亂？
讓工單成為一筆庫存交易。當技師往一張工單裡加入一根鏈條或一條內胎時，那個零件就從賣場所出售的同一份庫存裡扣減。工時另行計費，但每一個離開貨架的實物零件——無論是從櫃檯賣出，還是在後場裝上車——都出自同一份數字。
如果顧客想要一件我店裡沒存的東西，它能處理這種特別訂貨嗎？
能。一筆特別訂貨就是一條綁定到某位顧客的採購單明細。你向供應商訂下那個具體的變體，貨到時按採購單收貨並被標記為已被預訂、而非自由庫存，於是在你的顧客來取貨之前，它不會被賣給一位到店顧客。
這套系統對季前進貨和季節性有什麼幫助？
因為每個變體都帶著一個補貨點、系統也在追蹤真實的售出速率，補貨儀表板會在臨近春天時顯示哪些貨在動、哪些已經跌破門檻。你就從那個檢視裡向供應商下採購單。重點不是把進貨決策自動化，而是把「貨架 對 需求」的畫面擺得一清二楚，讓你在最忙的幾個月到來之前不必再靠猜。
參考來源
- NBDA 2025 專業自行車零售通路研究 — 美國自行車經銷商協會（NBDA）的產業基準報告，基於 200 多家美國零售商編製，涵蓋庫存管理、維修營運和技術採用。
- Bike Index — 一個非營利的自行車登記平台，許多車店在銷售當下用它登記車架序號，從而支援失竊尋回和保固查詢。
- Bicycle Retailer and Industry News：零售現況（POS 調查） — 對車店老闆的訪談，談他們所使用的 POS 與庫存系統，突顯即時庫存和單品售出速度報表是他們最為倚重的功能。
描述它，一次上線到你自己的網域——託管、全端、免伺服器。免費開始。