目錄
背景
行業概況
服裝批發是一個體量很大的傳統行業。以廣州十三行、杭州四季青、深圳南油為代表的服裝批發市場，聚集了大量批發檔口，以及背後的中小服裝企業。檔口就是市場裡攤位式的店鋪。這些企業的日常營運很依賴"人治"：老闆用筆記本記帳，店員手寫開單，倉庫靠記憶找貨，客戶資訊散落在微信聊天記錄裡。
市場上有一部分批發商在用傳統的進銷存軟體（進貨、銷售、庫存一體的管理軟體），比如多年前的單機版管家婆。這些軟體普遍有幾個問題：介面老舊，只能在 Windows 電腦上執行，不支援多店資料互通，沒有手機端。更關鍵的是，它們只解決"記帳"的問題，不解決"做生意"的問題，比如怎麼識別常來的客戶、怎麼做促銷、怎麼看出哪些款式好賣。
我加入的公司定位是服裝批發零售 SaaS 服務商（SaaS 即按訂閱付費、線上使用的軟體），瞄準"傳統進銷存軟體升級換代"這個機會。核心客戶有兩類：
- 批發商：在批發市場有檔口或小型展廳，主要做批發生意，關心庫存準確、開單快、對帳清楚。
- 零售商：有幾家門店的服裝店主，需要管庫存、管會員、管收銀。
我加入時，公司已經有一個初步的進銷存原型，但功能很基礎，本質上是一個"線上 Excel"，只能記錄商品入庫和出庫。團隊有十來個人，要在一年內把產品打磨成可以規模化售賣的商業版本。
市場視窗
當時市場上還沒有真正統治服裝批發零售領域的 SaaS 產品。傳統軟體廠商的體驗落後，新興網際網路公司更關注電商，較少關注線下批發。這是一個明確的視窗期：誰能用更好的體驗先拿下批發市場的頭部客戶，誰就能建立壁壘。
挑戰
挑戰一：使用者習慣很頑固，遷移成本高
服裝批發商多是四五十歲的個體經營者，手寫單據加舊軟體，已經幹了十幾年甚至幾十年。不是舊系統有多好，而是"習慣了"。我對接過一位批發商老闆，他說："我閉著眼都能打單，換了新系統我開單慢一半，耽誤做生意。"
這意味著新系統在遷移成本上必須做到極致：資料遷移要順暢，介面要能在幾天內上手，打單、查庫存這些關鍵功能要比舊系統更快，否則商家沒有理由切換。
挑戰二：服裝行業的季節性波動很強
服裝有春夏秋冬四季，加上各種節日促銷。旺季時，一個批發檔口一天能開出很多單，店員忙到沒時間喝水；淡季時，一天可能只有幾單。這對系統的要求是：
- 旺季必須穩定、響應快。開單頁面每慢一秒，都可能造成排隊。
- 淡季要能幫商家"找事做"：資料分析、會員行銷、庫存最佳化，這些是商家在淡季更願意花時間做的事。
挑戰三：多店多倉的複雜性
服裝批發零售的庫存管理比想像中複雜：
- 一家店可能有實體倉庫、檔口展示區、臨時堆放區三個位置，貨在這些位置之間頻繁流轉。
- 多店之間可以調撥（即門店之間調貨），但調撥的物流、損耗、記帳都很麻煩。
- "一品多色多碼"是服裝行業的標準情況：同一款衣服有多種顏色，每種顏色又有多個尺碼。傳統進銷存軟體在這一點上做得很痛苦。
- 部分商家做代銷：先把貨放在店裡賣，賣完再和供應商結帳，賣不完可以退回。這種模式對庫存和資金的管理要求完全不同。
挑戰四：定價與付費意願的拉扯
批發商習慣了"買斷制"（一次性花錢買軟體，用很多年），對按月付費的 SaaS 模式本能地抗拒。我們的產品按店鋪數收費，一個多店客戶每月要付一筆不小的費用，對很多小微服裝企業來說，這是一筆看得見的成本。產品必須讓商家在省下的時間和減少的差錯裡，感受到遠超訂閱費的價值，否則續約就是大問題。
我的解法
階段一：核心進銷存，做到比舊系統快得多（前 5 個月）
策略：不追求功能多，只把三個核心場景做到極致：開單快、查庫存快、對帳清楚。
具體動作：
開單效率：這是整個專案最關鍵的設計。我花了三週時間蹲點調研，在批發市場看店員開單，計時、錄影、分析每一個動作。發現最大的痛點是：舊系統開一張單，要依次選商品、選顏色、選尺碼、輸入數量、選客戶、輸入價格，至少十幾次點選。
解決方案是"快捷開單"模式：搜尋商品後，系統自動展開該商品的所有顏色和尺碼，店員直接在表格裡填每個規格的數量，一行搞定。PC 端配合回車鍵跳到下一行。熟練店員開單的時間明顯縮短。
這個功能上線後，在試點客戶那裡口碑很好。一位老闆的評價大意是：以前旺季高峰期，店員開單已經到了極限，現在開單快了很多，而且不會漏錯尺碼。
一品多色多碼的庫存設計：參考了電商的 SKU（庫存量單位，即每個顏色尺碼組合對應一個編碼）管理思路，但做了裁剪。傳統進銷存為了資料"規範"，要求每個顏色尺碼組合都錄成獨立商品。但服裝批發商的實際做法是：一個款式就是一個"商品"，顏色和尺碼是它的"屬性"。我堅持用"商品-變體"的模型：
- 商品層面：管理圖片、採購價、零售價、供應商。
- 變體層面（顏色 × 尺碼）：管理庫存數量、條碼、實際售價。
這個設計裡有一個後來證明非常關鍵的細節：允許一個變體掛多個條碼。服裝批發中，同一批貨可能來自不同供應商，每家的條碼體系不同，但貨是同一件。允許多條碼繫結，就能把不同批次、不同來源的同一款式統一管理。
多場景庫存移動：設計了入庫、出庫、調撥、盤點、報損五種庫存操作。每種操作都有獨立的單據號、可選的審批流程和記錄追蹤。這五種操作基本覆蓋了商家日常庫存變動的絕大多數場景。針對代銷模式，我設計了"代銷入庫"：貨進入代銷倉庫時不計入採購成本，賣出後才生成採購結算單。這個功能上線後，有幾家做代銷的批發商主動找上門要求接入。
資料遷移工具：這是降低切換成本的關鍵。我安排了一位後端同事兼做，寫了一個資料匯入工具，支援把市面主流舊系統匯出的 CSV（一種通用的表格檔案格式）或 Excel 批次匯入新系統。匯入時自動做資料清洗：去重、統一格式、標記異常值。開業遷移時，產品團隊親自去客戶現場陪同遷移，確保資料不丟。
結果：到第 5 個月，產品在一批批發商中正式上線，日處理訂單量明顯上升。客戶最核心的回饋是"開單真的快了"，這驗證了"效率優先"的方向是對的。
階段二：會員和行銷，幫商家"做大生意"（第 6–10 個月）
策略：進銷存只是工具，能幫商家把生意做大的功能，才有議價能力。第二階段圍繞"客戶經營"展開。
具體動作：
會員管理：服裝批發商其實也有會員，就是那些經常來拿貨的老客戶。但他們的"會員管理"全在腦子裡："張老闆拿貨多，給他打個折；李老闆結款快，優先給他留新款。"
我設計的會員系統包括：會員檔案、消費記錄、標籤分組、積分和等級。核心原則是"讓商家不用改變原來的經營習慣"：會員不是靠系統強制積累的，而是在開單時順手錄入的。
一個關鍵設計是"一鍵開卡"：開單時輸入客戶手機號，系統自動查詢是否已有會員檔案。有就直接關聯；沒有就彈窗提示"是否新建會員檔案？"，點一下確認即可。這把會員註冊的成本降到了幾乎為零。上線半年後，有客戶積累了不少會員，老客戶的回頭購買率明顯提升。
促銷引擎：服裝批發商經常做促銷，比如滿十件打八折、買一送一、第二件半價。舊系統完全不支援這類複雜促銷，商家只能靠人工算帳。
我設計了一套規則化的促銷引擎：促銷類型（滿減、滿折、贈品、組合價）、促銷條件（金額、數量、指定商品、指定會員等級）、促銷時間（按時間段、按星期、按日期範圍），三個維度可以任意組合。開單時，系統自動匹配適用的促銷規則，在單據上清楚顯示優惠明細。
促銷引擎上線後，出現了一個有意思的現象：很多批發商開始主動研究"怎麼做促銷"，因為系統第一次讓他們看到了促銷的效果，比如哪些促銷更能帶動成交，哪些老客戶被促銷重新激活了。
收銀端整合：對於有門店的零售商，我們增加了收銀 POS（收銀機系統）。收銀端支援掃碼商品、識別會員、自動計算促銷，支援現金、微信、支付寶和記帳等付款方式。收銀資料與進銷存即時同步：賣出即出庫，不用二次錄入。
這裡遇到一個很實際的問題：很多門店的收銀電腦規格很低，跑不動網頁應用。我調整了策略，做了一個輕量的 Windows 用戶端，只有收銀一項功能，啟動快、不卡頓，斷網也能收銀。進銷存管理仍然用網頁端。
結果：到第 10 個月，付費商家有了明顯增長，會員數量也達到了相當的規模。老客戶的回頭購買率比上線前明顯提高。
階段三：資料驅動決策（第 11 個月以後）
策略：商家積累了幾個月的資料後，幫他們"看懂自己的生意"。
具體動作：
經營儀表盤：設計了一塊簡潔的經營看板，核心指標包括：今日營收、本月營收、庫存週轉天數（貨從進貨到賣出，平均要幾天）、暢銷的前十名商品、滯銷商品清單、會員消費趨勢。看板的目標使用者是老闆，所以設計原則是"一屏看懂"：關鍵指標都在首屏，不需要滾動或切換頁面。
智慧補貨建議：基於歷史銷售、當前庫存和季節趨勢，給出每個規格的補貨建議。這個功能最開始很簡單，只是"庫存低於安全線就提醒"（安全線即庫存降到這個數量以下就該補貨的底線），後來逐步加入季節因子，比如參考去年同期的銷售資料。
客戶標籤與精準行銷：系統根據會員的消費資料自動打標籤，比如"高價值客戶""沉睡客戶""新品偏好""促銷敏感"。商家可以一鍵篩選出目標客戶群，傳送行銷通知。這還不是完全自動化的行銷引擎，但已經讓很多商家第一次體會到"資料指導經營"是什麼感覺。
通用方法提煉
方法一：B 端進銷存 SaaS 的"效率—經營—資料"三層架構
服裝批發零售 SaaS 的迭代路徑，可以抽象成一個通用模型。B 端指賣給企業的產品。
| 層級 | 核心命題 | 衡量指標 | 時間節奏 |
|---|---|---|---|
| 第一層：效率 | 比舊系統快多少 | 開單時間、庫存準確率 | 前 5 個月 |
| 第二層：經營 | 幫商家多賺多少錢 | 老客戶回頭購買率、客單價（每位客人平均每次的消費金額） | 第 6–10 個月 |
| 第三層：資料 | 幫商家做對決策 | 庫存週轉率、爆款命中率（進的貨裡賣得好的款佔比） | 第 11 個月以後 |
這個模型的要點是：每一層都要先做紮實，才能進入下一層。如果進銷存的效率問題沒解決，商家連單都不願意用系統開，後面的會員、行銷、資料都是空談。
方法二："遷移成本"是 B 端 SaaS 的核心壁壘
這件事給我最大的啟發是：B 端 SaaS 的競爭對手不只是其他 SaaS 公司，更是使用者的舊習慣。
降低遷移成本的有效辦法：
- 資料可以帶走：承諾資料可以匯出，打消"資料被鎖定"的顧慮。
- 陪跑式上線：上線第一週有專人現場支援。
- 保留舊的操作入口：部分功能在新系統裡可以用"快捷方式"模擬舊系統的操作路徑。
- 新舊並行期：允許新舊系統並行使用一到兩週。
方法三："剛需—頻率"矩陣
資源有限時，功能優先順序是我每天都在做的決策。有一個簡單的矩陣很實用：
- 高頻 + 剛需：必須做，而且要做到極致，比如開單、查庫存。
- 低頻 + 剛需：做，但求快，不求完美，比如庫存盤點。
- 高頻 + 非剛需：謹慎做，考慮做成增值功能，比如資料報表。
- 低頻 + 非剛需：不做，除非有明確的付費意向，比如進階資料分析。
反思
如果再讓我做一次，哪裡會不同
1. 收銀端應該更早啟動
收銀 POS 是我們到第二階段才開始做的，但對零售商來說，收銀是每天最高頻的操作。如果提前兩個月啟動收銀端，那些零售客戶可能更早完成從舊系統到新系統的切換。收銀端的價值不只是功能本身，更重要的是它是"資料入口"：客戶的每一筆交易都發生在系統裡，而不是事後補錄。
2. 不要低估"一品多色多碼"的技術複雜度
"商品-變體"模型在設計上看起來很簡單，但開發時，搜尋、排序、庫存計算、報表統計等每個環節都要相容變體邏輯。這塊功能在後端和前端實現上，都比預期多花了不少工時。如果重來，我會在技術方案評審階段就拉上全棧開發一起做技術預研，而不是等產品設計完成後再交給開發評估。
3. 定製化需求的"度"需要持續校準
專案後期，有大型批發商提出定製需求，比如特殊的結算週期、品類專屬的報表格式。我們做了一些定製。它們帶來了短期收入和客戶口碑，但長期看增加了產品複雜度，也增加了新人上手的難度。現在回頭看，更好的做法是：把定製功能做成可設定的開關，不侵入核心邏輯，也不影響普通使用者的操作介面。
4. 定價策略需要更靈活
我們最初的定價是統一的按店鋪按月收費。後來發現，不同商家對價格的敏感度差別很大：小檔口覺得每月的費用就很貴，連鎖零售商則覺得同樣的價格很值。後期我們按功能模組、訂單量、店鋪數做了分層定價，付費比例因此明顯提升。早些做分層定價，可能會更早推動增長。
適合誰讀
- 進銷存或 SaaS 產品經理：特別是做服裝、零售、快消品類進銷存產品的人。本文的"三層架構"和功能優先順序思路可以直接複用。
- 面向中小企業的 SaaS 創業者：如何處理使用者遷移成本、如何做定價策略、如何平衡標準化與定製化，這些是每個 toB 創業者都會遇到的問題。
- 傳統軟體廠商的產品負責人：正在考慮從買斷制轉向 SaaS 模式的團隊，本文在遷移策略和產品設計上的思考可供參考。
- 服裝行業 IT 從業者：瞭解一個真實服裝批發零售 SaaS 產品的設計邏輯和背後的取捨。
本文是作者在一家服裝批發零售 SaaS 公司主導產品時的覆盤。公司名、客戶和經營資料不公開，方法論部分可複用。