从交易发起到售后处理，订单系统贯穿电商业务全链路。本文以“订单篇”为核心，拆解正向与逆向订单的设计要点与业务逻辑，是电商产品人构建系统思维的关键一课。
商品是交易的基础，上篇聊了《商品篇》这篇聊聊订单-交易的核心，所有商业活动最终的目的都是为了促进订单的产生。
订单之所以重要，因为在交易环节中扮演3个角色：
1. 交易的凭证
包含两层意思：
一是企业对外披露经营数据的基础，经营数据不可能凭空产生，必须依赖订单。
二是用户权益保障的基础，一旦用户点击了“提交订单”，系统会立即生成一份快照，记录当时的商品、价格、优惠、地址等关键信息，作为后续争议的判断依据。
2. 履约的驱动器
支付完成之后，仓库要发货，物流要揽收，客服要跟进，这些动作都因订单而产生，并影响订单状态变化。
3. 售后的锚点
退款、退货、换货都必须基于一笔原始订单来展开。没有订单，就无法判断退款金额、物流责任、售后时效。
所以在一个完整的商业系统中，订单即交易，承担着“承上启下”的作用：承上连接用户与商品，启下推动履约承载售后。
乍一看，订单似乎只是“下单 → 支付 → 发货 → 收货 → 完成”的简单流程，但实际做过电商接触过订单的同学明白，订单远比想象复杂。
订单的复杂主要体现在几方面：
不同业态对订单有完全不同的诉求：
同一业态不同商品类型也有很大差异：
这意味着一个通用的订单模型必须能覆盖多种业务形态，否则会影响业务发展。
订单上游承接商品用户，下游承接支付、履约和售后，需要和多系统交互。
系统交互的时序依赖、高并发性、低延迟要求决定订单系统具备更高的复杂度。
订单的生命周期不仅有“正向”的下单到完成，还要覆盖“逆向”的取消、退款、退货、部分退货，可能同时发生。为了更好地支持业务，衍生出父子订单概念。
几个常见场景，比如：
这些判定不仅要依赖订单本身的状态，还要结合商品类型（虚拟/实物）、平台规则、商家配置、甚至外部物流状态。要求售后体系既要和订单主流程解耦，又必须保持强关联，这也增加了订单模型的复杂度。
要理解订单，绕不开的就是状态机。一个清晰的状态机不仅能帮助研发实现稳定的逻辑，也能提升用户、运营、客服对订单的可读性，提升体验和效率。
很多新人 PM 在设计时只关注正向流程，忽略逆向流程的复杂性。结果一旦遇到用户取消订单或申请退货，就会发现状态机根本兜不住。
在了解状态机之前，需要再了解几个概念：
1.1 父订单
业务系统定义的基础订单，一般是商户后台看到的订单。比如淘宝按商户划分订单，用户购买 ABC 三个商户的商品，就会生成 3 个父订单。
1.2 子订单
根据业务需求演变出来的概念。比如京东用户一次性购买 3 个商品，其中 ab 在广州仓，c 在南京仓。为了让用户更清晰地看到订单流转状态，系统会把 ab 和 c 拆成 2 个子订单进行发货处理。
1.3 支付订单
支付视角下的订单。以淘宝为例，用户可一次性支付多个商户订单，此时一笔支付订单对应多笔父订单。
订单状态机设计，建议区分多维度，包括主状态、支付状态、物流状态和售后状态，同时区分父子订单状态。
通过多状态组合，避免用单一状态承载多种业务含义，从而保持设计的灵活性与扩展性。
以通用的电商平台为例，支付前展示支付订单，支付后拆解为多个子订单：
2.1 订单状态
注意：这里的状态指后端状态，前端用户视角显示可灵活定义。
2.2 状态对应操作
根据多状态组合，在用户侧显示不同提示，常见操作如下，其中退款/退货退款针对商品维度展开。
设计状态机时要遵循单向流转、避免回退。一旦允许状态回退（例如已发货状态还能回到待发货），容易提升复杂度，引发各类bug。
接下来，我们顺着正向链路来拆解订单生命周期。
用户点击“提交订单”时，如果校验通过，系统会立即生成订单记录。这个动作同时会触发：
如果用户迟迟不支付，订单会在设定时间内（如 15 分钟）自动关闭，并释放库存和优惠。
订单创建后即可根据规则拆单，考虑支付便捷性，支付时可展示父订单。
常见的拆单维度：
拆单的目的是为了保证用户查看的体验、交付的效率和流畅，可根据业务复杂度逐步扩展升级。
一般来说订单必须支付，极端情况优惠后是0元的订单，也需要支付0.1元，便于系统统一规则和优惠分摊记账。
正常一笔订单对应1笔有效支付流水。特殊玩法，比如预售，先交定金再付尾款，可对应多笔支付流水。
异常情况会出现一笔订单用户重复支付，系统需要有退款机制，初期可人工审核，后续可自动化退款。
明确规则的，支付前校验提醒，比如黑名单、限购、库存不足等。有概率的风控机制，一般支付后拦截：
这一环节往往是“合规”与“体验”的拉锯战：严格的风控可能增加拦截率，宽松的策略又可能引发交易损失。
不同商品类型对应不同的发货逻辑：
这一步通常会伴随物流状态的变化，是用户最敏感的环节。发货延迟、物流信息异常，都会成为投诉高发点。
当用户确认收货，或系统在超时后自动确认收货时，订单进入“已收货”状态。已收货状态可以引导评价等
订单收货意味着正向流程的闭环，但不代表生命周期的结束。多数平台仍支持在完结后的若干天内申请售后，这就是逆向流程的切入点。
指订单相关的所有正向与逆向流程全部结束，包括售后申请、维修、价保等。
当售后时效结束，且不存在未结的售后单时，订单才真正进入生命周期意义上的最终终态。
订单的逆向流程，就是“仅退款、退货退款、换货、维修等”。这一部分常被称为“逆向物流”，复杂度甚至高于正向。
不同平台的定义略有差异，本文采用主流电商的常见划分，取“已收货”作为分界线，逆向流程可分为“售中”和“售后”：
时间范围：从用户下单支付开始，到订单状态变为“已完成”（或“确认收货”）之前。
核心特征：商品处于在途或待验收状态。所有权和风险尚未完全转移给买家。
这个阶段的服务主要围绕订单的执行和交付过程，主要服务内容：
时间范围：从订单状态变为“已收货”之后开始，直到国家法律或平台政策规定的保修期/售后时效结束（如7天无理由退换货、15天换货、1年保修等）。
核心特征：商品已被买家签收并验收，交易流程已完结。服务转入以“商品使用”和“权益保障”为核心的阶段。
这个阶段的服务主要围绕商品的品质、功能和消费者的长期权益保障。主要服务内容：
售中和售后背后是独立的售后单，包括仅退款、退货退款、换货、维修等类型，售后单典型状态机：
售后单独立于主订单存在，订单状态和售后状态互相影响，订单状态决定能否发起售后，售后状态反过来影响订单状态。
这种设计能保证逆向逻辑不污染主订单表，又能保持两者之间的关联。
结合前面内容，订单设计注意事项：
1、拆单合理性
过于简单无法应对业务复杂度，过于灵活，带来系统的复杂和维护成本，结合业务需要，寻找平衡。
2、售后与订单状态耦合过深
有些系统把售后状态直接塞进主订单表，造成状态混乱和复杂，最佳实践是单独建“售后单”。
3、复杂业态未覆盖
没有预先考虑业务的多样形态，后续补救代价极大。
订单模型是商业产品的核心，它既是交易的凭证，也是履约与售后的驱动器。
对初级 PM 来说，理解订单模型的第一步，是画清楚正向与逆向的状态流转图，确保每一个状态都有清晰的入口和出口。
对进阶 PM 来说，更重要的是思考订单模型如何支撑多业态：如何在统一模型下，既能覆盖电商、服务，又能支撑跨境、预售、拼团；如何在状态机的基础上，解耦出支付、物流、售后子系统，既保证灵活性，又保持一致性。
订单看似是“表格里的几行数据”，但实际上，它承载了整个商业闭环的关键逻辑。理解订单，就理解了商业产品的底层运行机制。
产品经理系列文章：
产品经理认知体系《用户篇》：认识你的用户，从定义到生命周期全景指南
产品经理认知体系《需求篇》：从发现真需求到落地复盘，产品经理的核心战场
产品经理认知体系《商品篇》：SPU、SKU傻傻分不清？一次讲透商品模型！
专栏作家
观剑，微信公众账号：观剑，人人都是产品经理专栏作家。10年+电商产品经理，前阿里专家，熟悉电商前台营销、后台采购、库存仓储全链路。
本文原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。