O2O业务预付订单交易流程设计

0 评论 1505 浏览 11 收藏 17 分钟

本文作者分享了完整的O2O预付订单的交易流程。因为用户、商家、平台运营人员、派单系统的参与,流程中有很多分支所以较为复杂。笔者将项目上遇到的情况整理、分享出来,希望对读者有所帮助。

做O2O相关业务,本质上是平台作为中介,将能够提供服务的商家(也就是劳动者)组织起来,然后吸引用户来购买商家的服务。商家付出了劳动也付出了时间,对于商家而言这段时间是有机会成本的。如果不给某个用户提供服务,商家可以用这段时间去服务别的用户,或者做别的事情。

现实当中常常发生临近服务时间用户取消订单,或者是商家到达制定地点却联系不上用户的情况。这时商家手上没有任务,而且一时半会儿也接不到新的订单,那么就会产生空档期。

大家使用过打车软件就会知道,用户下完单(并且司机接单)后超过一定时间,如果出于自身的原因要取消订单,用户是要给予司机一定补偿的。

其他O2O业务也存在类似打车业务的场景。

临近服务前或者已到了服务时间,用户取消订单,就应当对商家进行补偿。这种情况的过错方在用户,赔偿金理应由用户出。

那么用户怎么支付赔偿金呢?

考虑到少量用户存在诚信问题,会以各种方式拒绝/逃避赔付,从而打破O2O的订购-交付-实际完成付款的商业流程和契约(商家按时到达制定地点也是服务交付的一部分,也应当获得收益),那么不少情况下就有必要在下单阶段就要求用户预付款。有了预付款,就可以用来支付前面所说的赔偿金。

O2O预付订单的交易流程与普通用户常见的B2C、C2C实物电商不同。前者因为更多的业务场景和支付方式,某些方面甚至还要更复杂。

下面就以上门洗碗业务为例(先不必在意业务是否合理),来设计一个交易流程。为了覆盖足够多的业务场景,以便这个设计具有更高的通用性,这里我们预设:

  1. .对于这项服务,用户既可以选择预付也可以选择服务后付款;
  2. 用户可以线上付款也可以线下付款;
  3. 平台的运营工具包含了会员余额(充X送Y)和代金券(运营/客服发放,可以抵扣现金)。

一、整体流程

一次完整的服务从开始到结束包括用户下单并预付、平台派单&商家接单、商家提供服务、商家和用户确认最终账单并操作出账、用户最终完成付款和售后。

另外需要说的是,这里的账单指的是商品信息和费用信息,交易指的是用户的支付情况,而订单则是账单+交易。

因为交易明细信息(包括服务时长、服务费用、支付方式)在下单时都不是最终态,在后续过程中可能会调整,所以需要将账单和订单区分开来,而交易又有一套独立于账单和订单的流转过程。

在整个流程中,订单包含这些状态:

  • 待预付:生成预付账单还未进行预付时的状态
  • 处理中:用户选择了预付并跳转到收银台进行操作时的状态,如果用户在收银台未完成付款就返回,则订单状态再次变成“待预付”
  • 待确认:系统在派单中时的状态
  • 已完成:完成服务后,订单最终完成付款了结
  • 已取消:订单被取消后的状态

账单有这些状态:

  • 待处理:生成账单后的初始状态
  • 处理中:用户点击跳转到收银台进行支付时,状态=处理中。如果用户未完成付款,而是从收银台点击返回,那么状态变回“待处理”
  • 已完成:当账单被成功支付后,账单状态为“已完成”
  • 已关闭:当账单没有被支付或作废,则账单状态为“已关闭”

交易有这些状态:

  • 未支付:订单生成后初始状态为“未支付”
  • 已预付:当订单完成预付则该状态变为“已预付”(非强制预付的订单无此状态)
  • 已出账:未支付&已预付的账单由商家更新并出帐,交易状态变成“已出账”状态
  • 已支付:服务结束后订单被成功支付,状态为“已支付”(当商家确认现金支付时,不使用“已支付”,而是变为“已确认”)
  • 已确认:商家在商家端点击确认收到现金,交易状态=“已确认”
  • 已退款:订单发生过支付(预付),但是后续订单被取消,则交易状态为已退款
  • 已作废:订单未发生过支付,订单被取消后,交易状态为已作废

二、用户端下单流程

用户下单时首先需要选择服务项目、服务时间、服务人员和服务地点,以及这笔订单是否要使用代金券或者是会员余额。用户确认并操作下一步时会生成预付账单信息。系统根据策略判断该笔订单是否需要强制预付款,策略可以根据业务情况自行制定,这里举例:

  • 产品线维度:部分产品线必须预付,其余的无需
  • 时间维度:一天当中的某些时段需要预付
  • 用户维度:多次取消订单用户、芝麻信用分较低用户必须预付
  • 天气:遭遇恶劣天气时需预付
  • 经营情况:平台单量大/库存占用率高时需预付

如果用户无需预付,则提交后直接进入系统派单流程;如果需要预付则调起收银台进行付款。付款过程中会占用库存(因为指定了服务人员和服务时间),所以需要限制付款时间,一旦超时未完成付款,则系统自动取消订单。用户完成预付后同样进入派单流程。

另外需要注意,如果用户在一笔订单中同时使用多种支付方式,处理逻辑需要进行设计以避免优惠和运营规则出现冲突或者崩溃。

比如:

  1. 如果允许用户同时使用会员卡和优惠券,那么是所有优惠券都可以和会员卡同时使用,还是仅限部分类型的券;
  2. 出于更好的用户体验,系统自动帮助用户绑定一张券,那么优先绑定什么券(大额优先还是近期失效的优先?折扣券优先还是代金券优先?等等)。

三、商家端推送账单、保单、结算流程

商家到达制定地点、做好服务准备后,需要在商家端确认“开始服务”,此后商家和用户都无法在APP上取消订单。

等到商家完成服务,根据实际情况对服务时长(以及是否使用其自带的工具材料)进行调整,然后发给用户确认,用户确认无误后最终完成付款。基于这样的业务流程,需要将订单结算拆分为推送账单和报单两个部分。

  • 推送账单:是指商家按照实际服务情况填写好消耗的时长和物料,并将服务明细推送给用户。好比是去饭店吃法,在付款前饭店先给一个已上菜名称、价格的列表和汇总金额。如果账单有误,用户看完后可以要求商家调整。因此,推送账单的页面存在两种情况(首次推送前的形态,及推送过后返回来修改的形态)。
  • 报单:是指商家将账单提交给系统,并依据此账单完成结算。

在商家收款过程中,流程设计人员要明确的是:

  1. 会员卡、现金、其他线上支付方式在什么情况下可以选用?下面举例的流程中,只有当用户是会员并且会员卡余额充足时才可以使用。当然,从运营的角度,在培训时得向商家强调必须事先与用户确认,才能操作收款;从产品角度,商家完成收款之前在界面上也应该进行提示。
  2. 用户是否在商家收款前就完成了线上支付,也就是预付?如果没有预付,则需要用户现金支付或者在用户端进行线上支付。
  3. 用户已在线上预付的金额比实际金额多或少该如何处理?一般是多退少补。预付过少时需要再次支付;预付过多时需要考虑扣款的优先级,一般是代金券>会员余额>第三方支付,多余的部分原路退回。
  4. 商家正常完成收款时,在商家端如何给予引导?可以参考下面流程图中的情形。
  5. 在异常情况下,这笔订单已经完成最终结算了,此时商家继续操作报单、收款应该如何处理?一般而言,需要在前端进行报错提示,可参考流程图中的情形。

四、用户完成支付流程

商家推送账单后,如果仍然有部分金额或者全额需要支付,则用户可以支付现金、使用会员卡余额支付(如果有卡且余额足够),或者是通过第三方支付进行结算。前两个选项都无需用户在APP端操作,第三类则需要。

而在后端请求支付接口前必须先校验账单/订单的状态,如果订单已经完成支付或者是已取消,则支付流程中断。这些都是基本常见的考量,不赘述。

五、关于订单被取消的处理

一个订单可能因为各种原因被取消,具体包括但不限于下面表格中列出的情况。其中,1类的情形过失方为用户;2类情形的过失方为商家;3类情形过失方为平台。

如果是商家或者平台的过失,则用户不应当承受不利后果。所以对于已预付的订单被取消,则应该对用户进行原路退款、全额退款。

在一些情况下,甚至还应当给用户发券进行补偿。举例:

  1. 长期忠实高价值用户因订单取消而发起投诉;
  2. 无可派商家,或者是系统多次派单都无法满足用户的需求;
  3. 临近服务时间,临时取消订单,给用户带来不便;
  4. 优惠券/代金券因过期而无法原样退回。

因商家自身原因取消订单,应记录到商家的考核评价体系中。多次取消订单的商家,可以减少派单甚至不派单,也可以根据业务情况进行罚款、扣押金、增加培训、解约等。

如果是因用户的过失而导致取消订单,则会存在全额罚款、部分罚款和全额退款三种处理方式。

  • 未预付的订单:平台无法对用户进行罚款,这种情况下商家时间和收入上的损失由平台进行补偿。但是平台会记录用户的失信行为,用户后期再次使用平台服务就需要预付了。
  • 预付订单:根据用户取消订单的时机来决定应当采取哪种处理方式。举例,距离服务时间T<24小时,全罚;24小时≤T<48小时,罚用户在线支付总额的一半;T≥48小时,全额退款。

对于出现的退款,需要对退款的路径、各种退款方式的优先级、退款中卡券的处理做出相应的规则。

  • 退款路径:原路退回,用户使用什么方式付款,退款时就回到相应的账户中。
  • 退款方式优先级举例:第三方支付>会员卡>代金券/优惠券。这样设定,是因为第三方支付无特权,其余两种有特权,既然用户失信则应对特权进行限制;会员卡是用户通过充值获得的,而代金券/优惠券是平台运营给予的,用户获取后者的成本远低于前者,所以会员卡的优先级比券高。当然,为了避免用户做出错误决定并导致其投诉,需要在用户使用前就提示这种业务场景。
  • 卡券异常情况处理:卡券如果按照原样返回会过期的情况,根据业务确定是否延期;2.因为卡券的存在,按照比例规则计算时可能会出现退款金额>在线支付金额的情况,此时应该加一条兜底规则,避免过多的退款。

六、关于售后

如果商家服务完离开后用户发现质量问题并向平台投诉,则在一些情况下平台运营会介入并了解情况,确认问题存在后会先行用代金券赔付给用户,而后再对商家进行惩罚。该流程是整个服务的一部分,但是不涉及预付,此处一笔带过。

本文由 @霹雳 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!