目录
背景
行业概况
服装批发是一个体量很大的传统行业。以广州十三行、杭州四季青、深圳南油为代表的服装批发市场，聚集了大量批发档口，以及背后的中小服装企业。档口就是市场里摊位式的店铺。这些企业的日常运营很依赖"人治"：老板用笔记本记账，店员手写开单，仓库靠记忆找货，客户信息散落在微信聊天记录里。
市场上有一部分批发商在用传统的进销存软件（进货、销售、库存一体的管理软件），比如多年前的单机版管家婆。这些软件普遍有几个问题：界面老旧，只能在 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 公司主导产品时的复盘。公司名、客户和经营数据不公开，方法论部分可复用。