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