需求确认不是走过场，而是电商项目的“地基”
很多企业启动电商开发时，把大量精力花在功能清单、页面设计、技术选型上，却对需求确认环节草草了事。等到系统上线，运营团队开始实际使用时，才发现后台流程卡顿、数据对不上、促销规则算错账——这时候再回头改代码，成本往往是开发期的3到5倍。根据我们服务过的上百个电商项目复盘，以下5个需求确认环节最容易被忽略，却直接决定项目成败。
一、订单状态机：不只是“待付款”和“已完成”
绝大多数企业只描述了订单的基本状态：待支付、已支付、已发货、已完成。但真实业务中，订单会经历部分发货、退款中、换货待入库、拒收退回、风控锁定等十几种分支状态。如果需求文档里没有定义清楚“从A状态到B状态必须满足什么条件”，开发人员就会自行假设，最终导致运营在后台找不到“取消并退款”按钮，或者用户端显示“已发货”但物流单号却是空的。
建议做法
- 画出完整的订单状态流转图，标注每个动作（用户取消、客服介入、超时自动关闭）的触发条件。
- 明确“退款”与“退货退款”的差异：是仅原路退回金额，还是需要先收到货再验货退款？
- 确认库存扣减时机：下单时锁库存，还是支付成功后扣减？这直接影响超卖风险。
二、促销规则叠加逻辑：优惠计算顺序错一位，账就乱了
满减、折扣券、会员价、新人专享价、秒杀活动……每个规则单独看都清楚，但一旦叠加，计算顺序就非常容易出问题。例如：用户购买一件原价200元商品，店铺有满199减30活动，用户又有一张9折券。是先减30再打9折（实付153元），还是先打9折再减30（实付150元）？两种结果只差3元，但如果订单量上千，财务对不上账，客服就会收到大量投诉。
常见陷阱
- 优惠券是否适用于秒杀商品或清仓特价品？
- 多个促销活动（如满减+满赠）能否同时参与？
- 会员折扣是否与优惠券互斥？
建议在需求文档中写清“优先级公式”，并让开发人员做一版促销计算模拟器，用真实价格测试后再进入开发。
三、售后流程中的“时间窗口”和“责任判定”
很多企业只写了“用户可申请退款”，但忽略了售后环节中大量时间节点和角色分工。例如：用户申请退货，商家应在几小时内审核？审核通过后，用户需在几天内寄回商品？仓库收到退货后，质检流程需要多久？如果超时未处理，系统是自动退款还是通知人工介入？
更关键的是责任判定规则：商品破损是物流责任还是用户责任？如果用户提供的照片模糊，系统是否支持二次举证？这些细节如果没有明确，开发出来的售后模块只能处理“无理由退货”这一种简单场景，遇到纠纷就卡死。
四、库存同步与多仓逻辑：别让“有货”变成“空欢喜”
如果企业只有单仓直发，库存逻辑相对简单。但涉及线上线下库存共享、多仓发货（如华东仓、华南仓）、或者第三方平台（天猫、京东）库存同步时，需求确认必须细化到“哪个仓库优先发货”和“库存低于多少时自动锁单”。
我们曾遇到一个客户，线上显示有货，用户下单后仓库却找不到实物，原因是线下门店已售出但未及时同步。最终通过设置“可售库存=实物库存-锁单库存-门店预留库存”才解决。这个公式看起来简单，但如果不提前确认，开发完成后只能靠人工每日核对Excel，效率极低。
五、数据埋点与报表口径：没有指标，运营就是瞎子
多数需求文档只提“要一个数据看板”，但从不定义统计口径。例如“销售额”是含运费还是不含运费？“客单价”是否包含退款订单？“转化率”的分子是支付成功人数还是下单人数？如果这些口径不一致，运营和技术人员每天扯皮，甚至导致管理层看到错误数据做出错误决策。
需求确认时至少明确以下埋点
- 用户行为：浏览商品、加入购物车、提交订单、支付成功、取消订单
- 营销效果：每个优惠券的领取量、核销量、带来的GMV
- 商品分析：每个SKU的曝光量、点击量、加购转化率
建议在开发前输出一份《数据字典》，写明每个字段的业务含义、取值逻辑、更新频率。这样后期对接BI工具或第三方分析系统时，能节省大量沟通成本。
最后提醒：需求确认必须“写下来”并“签字确认”
以上5个环节，往往不是技术难题，而是业务方与开发方之间的认知偏差。口头沟通不算数，必须将这些规则写入需求文档，并组织业务负责人、财务、运营、开发、测试共同评审。尤其要注意，不要用“类似淘宝那样”来描述需求，因为淘宝的规则极其复杂，且不同行业（如生鲜、服装、虚拟商品）差异巨大。
电商开发不是一次性买卖，上线后还会持续迭代。前期多花一周时间确认这些边界场景，后期就能少花一个月去修补漏洞。如果您的项目正处于需求阶段，建议对照本文逐条自查，把遗漏项补上再动工。