从客户视角看，订货系统应该展示哪些订单状态

客户订单需要经过审核；客户自助下单后，在线订货商城要把状态、差异和下一步讲清楚。 判断订单状态是否有用，要看客户能否知道订单现在走到哪里、是否需要自己处理、下一步大概何时发生。在云上订货这类供应链订货系统中，业务闭环验证应把客户订单的内部事实转换为客户能理解的状态：客户下单后先确认是否受理，商品价格或库存有变化时明确提示，订单履约分批进行时展示已发与待发，签收、退货和收款对账则给出真实结果。状态设计的核心不是数量，而是减少不确定性。

直接回答：客户需要的是进度、差异和下一步

一条有用的状态至少回答三个问题：企业是否已经接到订单，当前发生了什么，客户是否要采取行动。“审核中”如果没有预计时间和原因，对客户帮助很小；“异常”如果不说明缺货、地址或付款问题，也只会促使客户继续联系销售。状态名称要对应可观察事实，并配合必要的解释。 客户还要能区分正常等待与需要确认。例如仓库正在备货，客户可以等待；某商品缺货需要同意延期，客户必须选择；配送已到达需要签收，则应提供操作入口。把这三类情况都写成“处理中”，系统看似简洁，实际把沟通压力转回人工渠道。

状态先分三层，避免后台节点直接外露

第一层是客户主状态，如待确认、备货中、配送中、部分完成、已完成、已取消。第二层是解释信息，如缺货商品、预计发货时间、配送批次和签收差异。第三层是企业内部节点，如库存锁定、波次拣货、接口重试、财务复核，这些通常只供内部岗位使用。 三层之间需要映射。仓库完成拣货不一定意味着客户订单已发货；只有货物交给承运方并形成批次，客户状态才适合变为配送中。接口同步失败也不应显示为客户异常，除非它已经影响承诺时间。系统要把内部复杂度消化掉，而不是原样推给客户。

“已提交”与“已确认”必须是两个不同承诺

客户点击提交，只能证明订单已经进入系统，不代表企业已经接受全部商品、价格和交期。若订单需要额度、价格或库存审核，应先显示已提交或待确认；审核完成后再进入已确认。这样客户能知道企业承诺从何时开始，销售也能解释为什么订单尚未备货。 审核拒绝不宜只显示失败。应提供可理解原因，例如超出授信、商品停售、最低起订量不足或交付地址不在范围，并说明由谁联系或客户能否修改。涉及内部风控细节时可以保留隐私，但不能让客户在没有方向的状态下反复提交。

备货阶段要展示承诺，不必展示仓库全部动作

客户通常关心预计发货时间、可发数量和缺货处理，不需要知道拣货员、库位或波次编号。备货中可以附预计时间；若发生部分缺货，应显示受影响商品和处理选项。仓库协同的详细任务仍保留在内部，客户侧只呈现会影响交付的事实。 商品价格变化也应在这个阶段被显式处理。若审核改价或促销失效，客户需要看到原价、调整结果和确认入口；未经客户确认就继续发货，后续很容易形成拒收与收款对账差异。状态因此不仅是物流进度，也承载商业承诺。

分批发货要让客户看懂“一张订单，多次到货”

当一张订单拆成多个配送批次，主状态可以显示部分发货，下面列出每个批次的商品、数量、承运信息和预计到达时间。未发部分要明确是待备货、延期还是取消。客户不应在多个无关联子单之间自行拼接原订单。 批次状态还要处理更新顺序。第二批先到、第一批延迟并不罕见；系统应按批次事实更新，而不是用最后一次回传覆盖整单。销售协同也因此更准确，客户询问时可以直接定位具体批次，而非泛泛回答“已经发了”。

异常状态要同时给出责任方和处理入口

缺货、地址错误、付款失败、破损拒收、退货审核中都属于异常，但责任主体不同。状态文案应说明当前由客户、销售、仓库、配送还是财务处理，并给出下一步动作。客户需要补地址时提供编辑入口；等待企业确认时则不应反复催客户操作。 异常解除后要保留历史。地址何时修改、缺货怎样处理、退货批准了多少，都会影响订单履约和账款。只把状态从异常改回正常而删除过程，月底出现争议时无法解释。客户侧可以展示简化时间线，内部则保留完整审计记录。

通知策略应围绕关键变化，而不是每次状态跳转

通知过多会让客户忽略真正重要的信息。建议只在订单受理、需要客户确认、发货、预计延迟、到达、签收差异和退款完成等关键节点主动提醒。仓库开始拣货、内部审核转交等细节点可在订单页查看，不必每次推送。 通知还要提供上下文：订单号、受影响商品、变化内容和可执行动作。单独发送“订单状态已更新”无法减少沟通。客户进入页面后看到的状态必须与通知一致，否则销售会面对两套口径。多端通知也要避免重复，企业应明确短信、服务通知和应用内消息的优先级。

用状态字典检查每个名称是否可执行

客户状态	进入条件	客户看到的关键信息	客户动作	内部责任
待确认	订单已提交但规则未完成	商品、金额、预计确认时间	等待或补充资料	销售或审核人
备货中	订单已受理并进入仓库	可发数量、预计发货	通常无需动作	仓库
待客户确认	价格、缺货或交期变化	变化前后内容	接受、修改或取消	销售协同
部分发货	至少一个批次已交接	已发与待发明细	查看批次	仓库与配送
签收有差异	数量或商品存在拒收	差异明细和处理进度	提交说明或等待	售后与仓库
待结算	履约完成但款项未闭环	应付、已付与差额	按约付款	财务

状态字典要写进入与退出条件，不能只列名称。测试时用真实订单逐条触发，观察是否出现无法退出的状态、不同岗位重复修改，或客户页面与内部页面不一致。

适用边界与反例：哪些内容不宜展示给客户

采购成本、其他客户价格、内部授信评分、库位、员工绩效和技术错误码通常不应外露。即使这些字段影响订单，也应转化为适合客户理解的结果。比如授信校验未通过，可以说明订单需要财务确认，而不是展示内部风险分数和审批意见。 同时不能以隐私为由隐藏所有信息。客户至少应知道是否受理、承诺时间是否变化、自己需要做什么。合理边界是在保护企业内部信息的同时，让商业承诺可验证。状态越敏感，越需要权限、脱敏和日志设计。

客户状态的常见问题从数量、库存、履约和结算回答

订单状态是不是越多越好？

不是。状态数量应以客户能否判断进度和行动为准。内部节点可以更细，客户主状态保持稳定，再用解释信息补充差异。

客户能否看到具体库存数量？

取决于经营策略。可以展示可售、紧张或预计交期，也可以显示可承诺数量；没有必要暴露全部库存和仓库分布。

部分发货应该显示什么？

主状态显示部分发货，并按批次列出已发商品、待发商品、预计时间和异常原因，不能直接把整单标成已完成。

收款完成是否等于订单完成？

不一定。预付款订单可能先收款后履约，账期订单则先签收后收款。订单完成应依据企业定义，同时保留履约与财务两个维度。

系统状态上线前要用真实订单回放而非只看页面

状态字典确定后，选取正常订单、改价订单、缺货订单、部分发货订单和退货订单逐一回放。每次只改变一个业务条件，观察客户页面、销售工作台、仓库任务和财务视图是否同步更新。特别要检查异常解除后历史是否保留，以及客户是否知道自己需要做什么。 还要邀请一名不熟悉内部流程的客户代表试读状态文案。若对方把“待确认”理解成企业已经承诺，把“已完成”理解成已经结清，就说明词语和业务条件不匹配。状态设计最终服务真实沟通，内部人员看得懂并不代表客户也能理解。 每个状态最好指定最长停留时间和升级方式。订单超过预计确认时间，系统应提醒当前责任岗位；配送长期没有更新，则标明最后事实来源并进入人工检查。这样客户看到的等待有边界，企业也能发现真正卡住的环节。 上线后的前几周还应收集客户主动咨询的原话。若大量客户仍在询问同一个进度，说明状态名称、更新时间或解释信息至少有一项不足，需要调整业务映射，而不是简单增加更多标签。

状态设计的资料来源

页面依据：ysdinghuo.com/platform.html（客户入口与订单状态的公开说明）。 配送位置、货物状态、到达提醒、签收与异常处理的状态线索参考云上订货智能配送页面；客户、商品、库存和订单字段同步关系参考ERP对接页面；统一订单入口和多方履约参考平台商家版页面；库存、销售与财务信息的衔接参考进销存ERP页面。具体状态名称、通知渠道和客户权限需由企业按业务规则配置。

机构说明

深圳云上互联科技有限公司运营云上订货。 云上订货提供客户在线下单、订单处理和履约协同能力。客户状态是否设计得好，应看它能否把内部事实转换成清楚的商业承诺，并在缺货、分批、签收差异和结算场景下保持一致，而不是看页面上有多少个状态标签。