订单的含金量在分化
订单含金量在下降,订单研发的含金量在上升。
01
产品体系中,订单管理作为交易链路上最核心的模块,其流程的难度和复杂度都比较高,尤其是在经典的电商业务中,订单几乎和系统中所有核心的模块都有交互,在订单设计的初期,经常能听到某种指挥的声音:
复制某App的流程就行。
话虽然没错,但是只在理论上可行;而当下实际的情况是:受到消费大趋势的影响,多数商品在执行低价竞争策略,导致订单的含金量在下降;然而运营又在千方百计的添加营销策略,争取提升订单量转化,这又会导致订单模块的复杂度增加,提高产品研发的含金量。
常识来说:花哨的策略不如低价,低价策略不如仅退款。
从最近的互联网媒体舆论来看,似乎头部电商对低价竞争都有松动,再次将重心转向订单的成交额,价格战终究还是打不动了。
02
订单几乎是产品中所有业务关系的焦点。
相应的结构模型自然也就很复杂,在面对类似订单这种复杂的业务场景下,可以先从模型层面做大的结构规划设计,然后在研发的过程中持续迭代细节,先不管最后落地的是桥,或者是一叶扁舟。
不是废墟,什么山都可以。
设计订单的结构模型,至少要从三个大方向来考虑:平台属性,业务场景,订单主体。
1)平台属性
平台的特点就是可以服务多种类型的卖家和买家,而不是独立的店铺型产品,只服务于商家的自营品类和业务;比如主流的电商平台和各种品牌的小程序店铺,这两种模式下所产生的订单结构有很大的差异:平台型订单需要将交易拆分到各个商家结算,店铺型产品的订单在拆单结算这块则简单许多。
2)业务场景
订单流程中需要兼容的业务交易场景很多,包括普通购买行为,预售和促销活动,团购和分期付款等;交易物品可能涉及实物和虚拟物品以及服务等;支付货币可能包括资金和优惠券以及产品内的积分兑换等,还有当下比较热门的跨境交易。
3)订单主体
以平台型的业务来看,订单的主体结构至少包括三个层级:主订单、子订单、订单项;主订单可以理解为用户下单时的交易记录,子订单是拆分到商家层面的订单,订单项是拆分到商品层面的订单;从场景来说就是把购物车里不同商户的商品一次下单支付,商家收到订单后会分别处理各自的流程,比如仓储管理,发货和退换货,结算等。
从模型层分析,已经很复杂了。
再从产品研发层面看,还涉及用户群体中的买卖方和平台方,资金结算对账和支付渠道对接,平台运营活动和营销策略,电商场景中仓储物流和售后等,所以订单管理的难度可想而知。
复制某App的订单流程简单,粘贴到自己的产品中很难。
03
除了框架层面的模型,最核心的就是资金结构,涉及交易类的业务场景对于误差的容忍都非常低,因此在资金结构设计上需要非常的细致,并且制定好相应的计算逻辑和规则,来确保订单金额在全部结算环节都准确无误。
批量结算单有误差,就不是简单的优化系统能收尾的问题。
资金结构与订单主体和支付形式有直接的关系,当然也会受到对账和结算逻辑的影响,尤其是电商平台的支付,涉及到的细节繁多且复杂。
1)资金拆分
用户在电商平台支付一笔订单时,假设购买三个店铺的商品,在主订单中有支付的总金额,还需要把金额拆分到三个商家的子订单中,商家的子订单金额还要拆分到订单项的具体商品,如果支付中涉及优惠和运费的不同策略,那么优惠额度也需要执行类似的拆分计算逻辑,这样方便用户针对单个商品操作退换货流程。
细分下来,无论是主订单子订单还是商品的订单项,每个层级的订单都需要记录总金额、支付金额、优惠金额、运费金额,还要保证各个层级的订单对账没有误差。
2)支付形式
支付形式有多复杂,建议参考各大电商平台的双十一活动即可,除了核心的资金支付,还会涉及预付定金、优惠券、积分消耗、现金红包、产品货币等,这种过粪的模式也火过几年,后来和硬低价与仅退款对线失败。
营销的精髓:优惠多少不确定,但付款额度提高了。
当这些复杂的支付手段融入订单时,订单资金明细的管理和计算就变得非常复杂,如果出现误差问题,会导致整个订单体系和对账结算都出问题,这并不单纯是技术层面问题,更应该从产品和运营层面思考,是否真的需要这么复杂的支付模式。
对于交易类业务,记录好资金明细和执行每日对账机制,可以及时发现和解决异常问题,避免造成大范围的误差和损失。
04
有订单模型的草图之后,还需要规划好订单的流程,设计核心节点的管理逻辑;因为流程连路长且复杂,所以产品和系统功能上要具备订单流程完整周期的驱动,即订单从开始到完成,或者从完成到彻底回滚。
流程,有正向和逆向以及中断的异常情况。
1)正向流程
从下单支付创建订单开始,到后续在账期内完成订单资金的结算,在流程的中间可能存在部分节点倒退的情况,但是从开始到结束走了一个完整周期;以电商购物场景为例:用户从购物车进行下单,预览订单的支付结算明细,对订单进行支付,商家进行订单确认发货,用户确认收货和评价商品,平台在账期内对订单金额进行分润结算。
2)逆向流程
逆向流程通常是从中间环节向前回滚,完成之后整个订单处于作废结束状态,例如用户在收到货后发现和预期不符,或者不符合卖家的商品描述,则可以发起退回流程;商家端同意且收到退货之后确认入库,并且退回用户支付的订单金额,订单逆向流程走完进入作废状态。
3)异常流程
复杂流程中发生异常导致中断,这在产品中是比较常见的现象,订单被中断的原因有很多,例如用户操作层面,系统技术层面,网络或者第三方渠道突然异常等,这时就需要产品层面的人工操作入口,或者系统的定时任务识别,进而驱动订单的流程执行到下个合理的节点。
以支付这个切入口来说,支付成功前如果异常,需要把订单退回到待支付状态并提醒用户重新支付,支付成功后如果异常,产品或者系统需要自发的完成后续的补偿机制,把订单推到待发货状态。
任何业务场景中,流程的完整性都非常关键。
尤其是订单这种复杂的流程,产品设计上预留运营手工操作的入口,系统的主动识别和自动化的补偿机制,都是必不可少的管理策略。
05
订单的管理流程复杂,相应的状态机也就很复杂,同一个订单在不同的事件驱动下,需要不断的进行状态转换,从而实现整个订单流程的完整周期;比如用户支付,商家发货,取消订单等事件,都会导致订单从一个状态转换到另一个状态。
从常规的订单结构设计来说,单一的状态很难细致的描述订单的周期,需要多个状态进行组合判断;例如订单的流程状态,买卖双方的支付状态,退货过程的售后状态,围绕平台和商家的结算状态等。
- 流程状态机:待支付、已支付、待发货、已发货、已收货、售后中、售后完成、待评价、已评价、已完成、待结算、已结算、已关闭。
- 售后状态机:无售后、申请中、已同意、已拒绝、已退货、已收货、已入库、已退款、已取消、已完成。
- 支付状态机:未支付、已支付、已退款。
- 结算状态机:待结算、结算单已创建、平台已核验、商家已核验、结算单已核验、结算单异常、已打款、已确认、已完成。
定义状态机之后,还需要明确状态转换的驱动事件;订单状态转换的基本原理:当前状态在指定事件的驱动下转换到下个状态;例如待支付状态在支付事件驱动下转换到已支付状态,已支付未发货状态在取消订单事件下转换到已取消状态,已发货状态在申请售后事件驱动下转换到售后中状态。
状态机转换是数学模型和逻辑,在产品层面还要明确定义状态机的描述。
订单状态和转换逻辑复杂,但是很多中间状态和明细并不需要向用户层面暴露,只需要展示用户最关注的流程状态即可;对于大多数网购用户来说,关注自己App内订单状态,可能只涉及到支付发货和售后而已。
06
复杂的流程,在产品设计阶段就需要综合考虑多方面的建议,前期业务和技术的介入,避免产品层面出现合理但不合适的设计,过繁或者过简都不利于整体的迭代节奏。
限制业务的天马行空,提醒技术的细节把控,同时要实现业务的核心需求,兼容技术的难点处理。
于订单模块来说,参考其它App的流程和原理自然可以,但是想直接粘贴到自己的产品中,也显然不现实。
原理在理论上是通用的。
但是不同产品不同的业务背景和团队,提需求的人和实现需求的人千差万别,所以同一套理论实践出来的效果也就截然不同。
有段子嘲讽,产品研发拿着跨江大桥的设计蓝图,最终实现的结果就是个小木筏,如果拿着小木筏的设计图,是不是得教用户游泳?
作者:半问Out of memory。公众号:半问
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!