从订单本质谈谈订单的设计要点

互联网出现之前“订单”就已经出现，它承载着线下交易的整套采购信息。交易离不开“人货场”，如今互联网作为一个重要的交易“场”所，自然将“订单”的概念带到了线上。那么线上订单的实现要点有哪些？一起来看一下吧。

对于产品人来说“订单”一词并不陌生：电商、团购、甚至共享单车的产品结构里，都有“订单”的身影。在互联网出现之前“订单”就已经出现，它承载着线下交易的整套采购信息，线下的交易离不开“人、货、场”三个核心要素，如今互联网作为一个重要的交易“场”所，也就自然的将“订单”的概念带到了线上。

那么线上订单的实现要点有哪些？今天我们来对此进行讨论。

一、订单的本质

讨论订单的实现，先从订单的本质入手，笔者认为线上订单有三个特质，简要来讲就是：交易、信息、凭证。

订单的生成源自交易的产生，订单作为交易信息的载体，不但要体现交易的具体内容、还需要忠诚的体现交易过程的始末，让交易得以公平透明的进行。

订单承载交易不仅是抽象意义上的，更是可见的事实，订单中包含交易的重要信息：买卖双方是谁、交易的物品规格和价格、交付的周期和方式等。订单一旦生成，代表买卖双方认可了订单中包含的信息，双方承诺按照订单内容履约，因此订单也是交易出现问题时需要参考的凭证。

了解订单的本质后，就可以以此为方向，对订单的产品逻辑进行设计。

二、交易始末：订单状态的设计

订单承载着交易，需要记录静态的交易内容，同时还需要对交易的动态节点进行追踪，即订单的交易状态。订单的各个状态节点代表着订单从开始到结束过程中的关键里程碑，即一个代表性动作完0成、另一个动作需要开始。

1. 基本状态

本着“一手交钱、一手交货”的基本交易逻辑，订单的状态需要体现钱款和货物的情况，付款意味着买方对交易的实际认可和真正的启动交易、发货意味着卖方对交易完成步骤的推进，也就是“货款交换”的实际完成。

2. 状态设计时的要点

在实际的订单状态设计中，有两个点值得注意：

1）交易关闭状态的条件

待支付是指的用户发起了交易的申请，但是没有实际支付货款的情况。在这种状态下，用户可能会超时未完成支付或是主动取消订单，这里需要考虑到等待用户支付的时间，因为订单往往与商品的库存强相关，有些商家下单就会占用库存（另外一种是支付后占库存），那么订单的待支付时间就不能太久，以免影响其他用户下单；

待发货是指的商家未提供物流凭证，即物流单号。一些平台允许在未发货时极速退款，如果同时允许买家在这一阶段退款一部分商品，则需要考虑部分退款可以支持的次数、以及多次部分退款累计成为全部退款所对应的订单状态；

已发货状态是指商家提供了物流信息。这种状态下要参考实际的物流状态，商家选择了已发货但是未提供物流单号的，或者物流单号虽然提供了但是未关联到物流信息的，也可以考虑支持部分退款的情况，同时也需要考虑次数与全部退款后状态的影响；

理论上：待发货是商家没有声明发货、已发货是商家声明了发货。但是，待发货不一定是商品尚未邮寄（可能正在发一批货还没录入快递）、已发货也并不一定意味着商品已经邮寄出去（可能只是打出来了快递单），所以这两种状态下的退款，都应该由商家进行确认，避免操作时差带来的交易纠纷。

2）交易完成状态的条件

买家签收意味着钱与货的顺利交换，代表着交易的完成，虽然我们在上图中已发货状态直接来到了交易完成，但在实际的订单状态里，我们往往会将一部分物流的状态代入到订单状态中作为订单状态的一部分，比如配送中和已签收两个状态。

在订单状态中加入配送中是为了提醒买家和商家双方对交易进度有更直观的追踪，而将已签收状态加入订单状态则是为了订单状态流的完善，大部分用户在实际收到商品后不会主动点击【交易完成】的按钮，这时为了关闭已经实际完成的订单（减轻订单监控的压力），需要系统去判断哪些订单可以自动变为交易完成状态，系统判断的依据就是签收后超过约定天数（如14天），于是订单状态扩展为下图：

二、信息与角色：不同用户端的订单信息

1. 常规信息

一般来讲，订单的基本信息示意如下：

2. 不同角色的关注点

我们知道线上交易平台的商品分自营商品和外部商家商品两大类：平台商品物流一般又平台负责、商品收益归平台；商家商品的物流一般由商家自行负责、平台需要与商家进行月度结算（下单后平台先收款然后月度结算给商家），根据这种简单的区分，结合两种商品的交易流程，我们可以简单的列出交易的主要参与角色以及每个环节的操作流程，如下图：

在交易的过程中，参与交易的不同角色对订单信息的关注重点各不相同：

1）买家关注点

订单商品和物流情况，即：交易的商品类型（品类）、交易的商品是什么（SKU）、物流信息和物流状态。买家会关注物流送达的情况，并关注自己购买到的商品实际规格是什么，以便签收后对商品进行核对。

2）商家关注点

订单状态、订单商品、收货地址、订单金额。商家需要按照订单状态对订单进行追踪和管理，如待发货状态的订单及时发货、已完成订单账期核对等；还要关注订单商品，一方面及时的核对需要发货商品的规格，另一方面关注商品售卖的统计调整销售策略和库存；

商家需要对订单的发货地址进行关注，部分偏远地区发不了的要及时与用户沟通；商家最关注的就是订单金额，订单金额一方面指的是订单中商品的售卖金额，另一方面指的是商家给到与平台的提成比例。

3）平台关注点

平台需要根据商品归属分发订单，因此关注订单中商品的归属情况；平台发货的订单需要关注发货商品的规格信息，部分商品超过默认规格的还需要拆成多个发货单分别发货；平台的物流则需要关注订单的发货地址；平台的财务部门关注订单的归属和所属商家、订单金额、商家提成比例等信息。

因此根据每个角色对订单关注点的不同，为不同角色展示订单时，可以对信息进行裁剪或终边标识。

三、交易凭证：售后、保价与交易纠纷

在电商平台交易中异常情况时有发生，作为链接货与款的单据，应该详尽的记录和体现交易过程中所出现的正常和异常情况，以便为后续的商家评分、财务结算等流程提供凭证。线上交易中的订单异常包括商品的退回、货款的退回，以及买家对商家的投诉。

售后是线上交易中最常见的一种异常，在进行订单设计时，需要考虑到允许售后发起的条件，这个条件包括了订单状态和商品的性质，一些参与了特殊活动的商品需要同时下单或售后，这种情况下的订单则不能部分退货，但是在实际收到商品后则可能会支持部分退货（商品质量等问题），见下图示意（注意：实际场景中还需要分的更细）：

退款一般是伴随售后退货而发生的，但是也可能是商品价格变动带来的保价行为，很多线上交易平台现在都能够支持保价的操作，保价会对订单的实际交易金额产生影响，但是要注意可以申请保价的订单状态、商品类型、以及与特殊运营活动的互斥规则，因为保价会影响到平台与商家结算的计算，因此保价应该与用户实际支付金额分开，但是需要作为平台结算金额的一个要素项。

交易纠纷与订单的关联，在于纠纷的处理结果对订单的影响，在平台接入的纠纷处理中，可能发生的结果包括为用户退款或发放代金券，这其中退款或发券的操作，需要作为纠纷订单的一个结算项，与商家进行核算时的扣除，因此这也是订单的一个结算金额要素。

订单是一整套交易场景的体现，设计过程中要充分考虑实际的业务场景和订单状态的结合，将订单的实现与相关的上下游场景打通，避免与售后、物流、财务流程脱节。

本文由 @梦溪原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

给作者打赏，鼓励TA抓紧创作！

一、订单的本质

二、交易始末：订单状态的设计

1. 基本状态

2. 状态设计时的要点

二、信息与角色：不同用户端的订单信息

1. 常规信息

2. 不同角色的关注点

三、交易凭证：售后、保价与交易纠纷

Recommend

“后台产品” UX & UI 设计总结（上）- 设计要点概括

谈谈ICO的三个本质

【笔记】游戏BOSS的设计要点

8种引导方式，7个设计要点，让你全面了解新手引导！

缓存的架构设计要点

透过现象看本质——谈谈ML2 plugin这回事儿-lokott

透过现象看本质——谈谈L2 agent 这回事儿-lokott

webpack | 谈谈 webpack 的本质

浅谈在线客服产品功能设计要点

Netty系列之Netty百万级推送服务设计要点

About Joyk