订单含金量的裂变：市场分化下的企业抉择

半问

订单含金量在下降，订单研发的含金量在上升。

01
产品体系中，订单管理作为交易链路上最核心的模块，其流程的难度和复杂度都比较高，尤其是在经典的电商业务中，订单几乎和系统中所有核心的模块都有交互，在订单设计的初期，经常能听到某种指挥的声音：
复制某App的流程就行。
话虽然没错，但是只在理论上可行；而当下实际的情况是：受到消费大趋势的影响，多数商品在执行低价竞争策略，导致订单的含金量在下降；然而运营又在千方百计的添加营销策略，争取提升订单量转化，这又会导致订单模块的复杂度增加，提高产品研发的含金量。
常识来说：花哨的策略不如低价，低价策略不如仅退款。
从最近的互联网媒体舆论来看，似乎头部电商对低价竞争都有松动，再次将重心转向订单的成交额，价格战终究还是打不动了。

02
订单几乎是产品中所有业务关系的焦点。
相应的结构模型自然也就很复杂，在面对类似订单这种复杂的业务场景下，可以先从模型层面做大的结构规划设计，然后在研发的过程中持续迭代细节，先不管最后落地的是桥，或者是一叶扁舟。
不是废墟，什么山都可以。
设计订单的结构模型，至少要从三个大方向来考虑：平台属性，业务场景，订单主体。
1）平台属性
平台的特点就是可以服务多种类型的卖家和买家，而不是独立的店铺型产品，只服务于商家的自营品类和业务；比如主流的电商平台和各种品牌的小程序店铺，这两种模式下所产生的订单结构有很大的差异：平台型订单需要将交易拆分到各个商家结算，店铺型产品的订单在拆单结算这块则简单许多。
2）业务场景
订单流程中需要兼容的业务交易场景很多，包括普通购买行为，预售和促销活动，团购和分期付款等；交易物品可能涉及实物和虚拟物品以及服务等；支付货币可能包括资金和优惠券以及产品内的积分兑换等，还有当下比较热门的跨境交易。
3）订单主体
以平台型的业务来看，订单的主体结构至少包括三个层级：主订单、子订单、订单项；主订单可以理解为用户下单时的交易记录，子订单是拆分到商家层面的订单，订单项是拆分到商品层面的订单；从场景来说就是把购物车里不同商户的商品一次下单支付，商家收到订单后会分别处理各自的流程，比如仓储管理，发货和退换货，结算等。
从模型层分析，已经很复杂了。
再从产品研发层面看，还涉及用户群体中的买卖方和平台方，资金结算对账和支付渠道对接，平台运营活动和营销策略，电商场景中仓储物流和售后等，所以订单管理的难度可想而知。
复制某App的订单流程简单，粘贴到自己的产品中很难。

03
除了框架层面的模型，最核心的就是资金结构，涉及交易类的业务场景对于误差的容忍都非常低，因此在资金结构设计上需要非常的细致，并且制定好相应的计算逻辑和规则，来确保订单金额在全部结算环节都准确无误。
批量结算单有误差，就不是简单的优化系统能收尾的问题。
资金结构与订单主体和支付形式有直接的关系，当然也会受到对账和结算逻辑的影响，尤其是电商平台的支付，涉及到的细节繁多且复杂。
1）资金拆分
用户在电商平台支付一笔订单时，假设购买三个店铺的商品，在主订单中有支付的总金额，还需要把金额拆分到三个商家的子订单中，商家的子订单金额还要拆分到订单项的具体商品，如果支付中涉及优惠和运费的不同策略，那么优惠额度也需要执行类似的拆分计算逻辑，这样方便用户针对单个商品操作退换货流程。
细分下来，无论是主订单子订单还是商品的订单项，每个层级的订单都需要记录总金额、支付金额、优惠金额、运费金额，还要保证各个层级的订单对账没有误差。
2）支付形式
支付形式有多复杂，建议参考各大电商平台的双十一活动即可，除了核心的资金支付，还会涉及预付定金、优惠券、积分消耗、现金红包、产品货币等，这种过粪的模式也火过几年，后来和硬低价与仅退款对线失败。
营销的精髓：优惠多少不确定，但付款额度提高了。
当这些复杂的支付手段融入订单时，订单资金明细的管理和计算就变得非常复杂，如果出现误差问题，会导致整个订单体系和对账结算都出问题，这并不单纯是技术层面问题，更应该从产品和运营层面思考，是否真的需要这么复杂的支付模式。
对于交易类业务，记录好资金明细和执行每日对账机制，可以及时发现和解决异常问题，避免造成大范围的误差和损失。

04
有订单模型的草图之后，还需要规划好订单的流程，设计核心节点的管理逻辑；因为流程连路长且复杂，所以产品和系统功能上要具备订单流程完整周期的驱动，即订单从开始到完成，或者从完成到彻底回滚。
流程，有正向和逆向以及中断的异常情况。
1）正向流程
从下单支付创建订单开始，到后续在账期内完成订单资金的结算，在流程的中间可能存在部分节点倒退的情况，但是从开始到结束走了一个完整周期；以电商购物场景为例：用户从购物车进行下单，预览订单的支付结算明细，对订单进行支付，商家进行订单确认发货，用户确认收货和评价商品，平台在账期内对订单金额进行分润结算。
2）逆向流程
逆向流程通常是从中间环节向前回滚，完成之后整个订单处于作废结束状态，例如用户在收到货后发现和预期不符，或者不符合卖家的商品描述，则可以发起退回流程；商家端同意且收到退货之后确认入库，并且退回用户支付的订单金额，订单逆向流程走完进入作废状态。
3）异常流程
复杂流程中发生异常导致中断，这在产品中是比较常见的现象，订单被中断的原因有很多，例如用户操作层面，系统技术层面，网络或者第三方渠道突然异常等，这时就需要产品层面的人工操作入口，或者系统的定时任务识别，进而驱动订单的流程执行到下个合理的节点。
以支付这个切入口来说，支付成功前如果异常，需要把订单退回到待支付状态并提醒用户重新支付，支付成功后如果异常，产品或者系统需要自发的完成后续的补偿机制，把订单推到待发货状态。
任何业务场景中，流程的完整性都非常关键。
尤其是订单这种复杂的流程，产品设计上预留运营手工操作的入口，系统的主动识别和自动化的补偿机制，都是必不可少的管理策略。

05
订单的管理流程复杂，相应的状态机也就很复杂，同一个订单在不同的事件驱动下，需要不断的进行状态转换，从而实现整个订单流程的完整周期；比如用户支付，商家发货，取消订单等事件，都会导致订单从一个状态转换到另一个状态。
从常规的订单结构设计来说，单一的状态很难细致的描述订单的周期，需要多个状态进行组合判断；例如订单的流程状态，买卖双方的支付状态，退货过程的售后状态，围绕平台和商家的结算状态等。

• 流程状态机：待支付、已支付、待发货、已发货、已收货、售后中、售后完成、待评价、已评价、已完成、待结算、已结算、已关闭。
• 售后状态机：无售后、申请中、已同意、已拒绝、已退货、已收货、已入库、已退款、已取消、已完成。
• 支付状态机：未支付、已支付、已退款。
• 结算状态机：待结算、结算单已创建、平台已核验、商家已核验、结算单已核验、结算单异常、已打款、已确认、已完成。
  

定义状态机之后，还需要明确状态转换的驱动事件；订单状态转换的基本原理：当前状态在指定事件的驱动下转换到下个状态；例如待支付状态在支付事件驱动下转换到已支付状态，已支付未发货状态在取消订单事件下转换到已取消状态，已发货状态在申请售后事件驱动下转换到售后中状态。
状态机转换是数学模型和逻辑，在产品层面还要明确定义状态机的描述。
订单状态和转换逻辑复杂，但是很多中间状态和明细并不需要向用户层面暴露，只需要展示用户最关注的流程状态即可；对于大多数网购用户来说，关注自己App内订单状态，可能只涉及到支付发货和售后而已。

06
复杂的流程，在产品设计阶段就需要综合考虑多方面的建议，前期业务和技术的介入，避免产品层面出现合理但不合适的设计，过繁或者过简都不利于整体的迭代节奏。
限制业务的天马行空，提醒技术的细节把控，同时要实现业务的核心需求，兼容技术的难点处理。
于订单模块来说，参考其它App的流程和原理自然可以，但是想直接粘贴到自己的产品中，也显然不现实。
原理在理论上是通用的。
但是不同产品不同的业务背景和团队，提需求的人和实现需求的人千差万别，所以同一套理论实践出来的效果也就截然不同。
有段子嘲讽，产品研发拿着跨江大桥的设计蓝图，最终实现的结果就是个小木筏，如果拿着小木筏的设计图，是不是得教用户游泳？
作者：半问  ，公众号：半问。未经作者许可，禁止转载。