本帖最后由 热传网 于 2024-11-5 11:05 编辑
做O2O相关业务，本质上是平台作为中介，将能够提供服务的商家（也就是劳动者）组织起来，然后吸引用户来购买商家的服务。商家付出了劳动也付出了时间，对于商家而言这段时间是有机会成本的。如果不给某个用户提供服务，商家可以用这段时间去服务别的用户，或者做别的事情。
大家使用过打车软件就会知道，用户下完单（并且司机接单）后超过一定时间，如果出于自身的原因要取消订单，用户是要给予司机一定补偿的。
其他O2O业务也存在类似打车业务的场景。
临近服务前或者已到了服务时间，用户取消订单，就应当对商家进行补偿。这种情况的过错方在用户，赔偿金理应由用户出。
那么用户怎么支付赔偿金呢？
考虑到少量用户存在诚信问题，会以各种方式拒绝/逃避赔付，从而打破O2O的订购-交付-实际完成付款的商业流程和契约（商家按时到达制定地点也是服务交付的一部分，也应当获得收益），那么不少情况下就有必要在下单阶段就要求用户预付款。有了预付款，就可以用来支付前面所说的赔偿金。
O2O预付订单的交易流程与普通用户常见的B2C、C2C实物电商不同。前者因为更多的业务场景和支付方式，某些方面甚至还要更复杂。
下面就以上门洗碗业务为例（先不必在意业务是否合理），来设计一个交易流程。为了覆盖足够多的业务场景，以便这个设计具有更高的通用性，这里我们预设：
- .对于这项服务，用户既可以选择预付也可以选择服务后付款；
- 用户可以线上付款也可以线下付款；
- 平台的运营工具包含了会员余额（充X送Y）和代金券（运营/客服发放，可以抵扣现金）。
一、整体流程
一次完整的服务从开始到结束包括用户下单并预付、平台派单&商家接单、商家提供服务、商家和用户确认最终账单并操作出账、用户最终完成付款和售后。
另外需要说的是，这里的账单指的是商品信息和费用信息，交易指的是用户的支付情况，而订单则是账单+交易。
因为交易明细信息（包括服务时长、服务费用、支付方式）在下单时都不是最终态，在后续过程中可能会调整，所以需要将账单和订单区分开来，而交易又有一套独立于账单和订单的流转过程。
在整个流程中，订单包含这些状态：
- 待预付：生成预付账单还未进行预付时的状态
- 处理中：用户选择了预付并跳转到收银台进行操作时的状态，如果用户在收银台未完成付款就返回，则订单状态再次变成“待预付”
- 待确认：系统在派单中时的状态
- 已完成：完成服务后，订单最终完成付款了结
- 已取消：订单被取消后的状态
账单有这些状态：
- 待处理：生成账单后的初始状态
- 处理中：用户点击跳转到收银台进行支付时，状态=处理中。如果用户未完成付款，而是从收银台点击返回，那么状态变回“待处理”
- 已完成：当账单被成功支付后，账单状态为“已完成”
- 已关闭：当账单没有被支付或作废，则账单状态为“已关闭”
交易有这些状态：
- 未支付：订单生成后初始状态为“未支付”
- 已预付：当订单完成预付则该状态变为“已预付”（非强制预付的订单无此状态）
- 已出账：未支付&已预付的账单由商家更新并出帐，交易状态变成“已出账”状态
- 已支付：服务结束后订单被成功支付，状态为“已支付”（当商家确认现金支付时，不使用“已支付”，而是变为“已确认”）
- 已确认：商家在商家端点击确认收到现金，交易状态=“已确认”
- 已退款：订单发生过支付（预付），但是后续订单被取消，则交易状态为已退款
- 已作废：订单未发生过支付，订单被取消后，交易状态为已作废
二、用户端下单流程
用户下单时首先需要选择服务项目、服务时间、服务人员和服务地点，以及这笔订单是否要使用代金券或者是会员余额。用户确认并操作下一步时会生成预付账单信息。系统根据策略判断该笔订单是否需要强制预付款，策略可以根据业务情况自行制定，这里举例：
- 产品线维度：部分产品线必须预付，其余的无需
- 时间维度：一天当中的某些时段需要预付
- 用户维度：多次取消订单用户、芝麻信用分较低用户必须预付
- 天气：遭遇恶劣天气时需预付
- 经营情况：平台单量大/库存占用率高时需预付
如果用户无需预付，则提交后直接进入系统派单流程；如果需要预付则调起收银台进行付款。付款过程中会占用库存（因为指定了服务人员和服务时间），所以需要限制付款时间，一旦超时未完成付款，则系统自动取消订单。用户完成预付后同样进入派单流程。
另外需要注意，如果用户在一笔订单中同时使用多种支付方式，处理逻辑需要进行设计以避免优惠和运营规则出现冲突或者崩溃。
比如：
- 如果允许用户同时使用会员卡和优惠券，那么是所有优惠券都可以和会员卡同时使用，还是仅限部分类型的券；
- 出于更好的用户体验，系统自动帮助用户绑定一张券，那么优先绑定什么券（大额优先还是近期失效的优先？折扣券优先还是代金券优先？等等）。
三、商家端推送账单、保单、结算流程
商家到达制定地点、做好服务准备后，需要在商家端确认“开始服务”，此后商家和用户都无法在APP上取消订单。
等到商家完成服务，根据实际情况对服务时长（以及是否使用其自带的工具材料）进行调整，然后发给用户确认，用户确认无误后最终完成付款。基于这样的业务流程，需要将订单结算拆分为推送账单和报单两个部分。
- 推送账单：是指商家按照实际服务情况填写好消耗的时长和物料，并将服务明细推送给用户。好比是去饭店吃法，在付款前饭店先给一个已上菜名称、价格的列表和汇总金额。如果账单有误，用户看完后可以要求商家调整。因此，推送账单的页面存在两种情况（首次推送前的形态，及推送过后返回来修改的形态）。
- 报单：是指商家将账单提交给系统，并依据此账单完成结算。
在商家收款过程中，流程设计人员要明确的是：
- 会员卡、现金、其他线上支付方式在什么情况下可以选用？下面举例的流程中，只有当用户是会员并且会员卡余额充足时才可以使用。当然，从运营的角度，在培训时得向商家强调必须事先与用户确认，才能操作收款；从产品角度，商家完成收款之前在界面上也应该进行提示。
- 用户是否在商家收款前就完成了线上支付，也就是预付？如果没有预付，则需要用户现金支付或者在用户端进行线上支付。
- 用户已在线上预付的金额比实际金额多或少该如何处理？一般是多退少补。预付过少时需要再次支付；预付过多时需要考虑扣款的优先级，一般是代金券>会员余额>第三方支付，多余的部分原路退回。
- 商家正常完成收款时，在商家端如何给予引导？可以参考下面流程图中的情形。
- 在异常情况下，这笔订单已经完成最终结算了，此时商家继续操作报单、收款应该如何处理？一般而言，需要在前端进行报错提示，可参考流程图中的情形。
四、用户完成支付流程
商家推送账单后，如果仍然有部分金额或者全额需要支付，则用户可以支付现金、使用会员卡余额支付（如果有卡且余额足够），或者是通过第三方支付进行结算。前两个选项都无需用户在APP端操作，第三类则需要。
而在后端请求支付接口前必须先校验账单/订单的状态，如果订单已经完成支付或者是已取消，则支付流程中断。这些都是基本常见的考量，不赘述。
五、关于订单被取消的处理
一个订单可能因为各种原因被取消，具体包括但不限于下面表格中列出的情况。其中，1类的情形过失方为用户；2类情形的过失方为商家；3类情形过失方为平台。
如果是商家或者平台的过失，则用户不应当承受不利后果。所以对于已预付的订单被取消，则应该对用户进行原路退款、全额退款。
在一些情况下，甚至还应当给用户发券进行补偿。举例：
- 长期忠实高价值用户因订单取消而发起投诉；
- 无可派商家，或者是系统多次派单都无法满足用户的需求；
- 临近服务时间，临时取消订单，给用户带来不便；
- 优惠券/代金券因过期而无法原样退回。
因商家自身原因取消订单，应记录到商家的考核评价体系中。多次取消订单的商家，可以减少派单甚至不派单，也可以根据业务情况进行罚款、扣押金、增加培训、解约等。
如果是因用户的过失而导致取消订单，则会存在全额罚款、部分罚款和全额退款三种处理方式。
- 未预付的订单：平台无法对用户进行罚款，这种情况下商家时间和收入上的损失由平台进行补偿。但是平台会记录用户的失信行为，用户后期再次使用平台服务就需要预付了。
- 预付订单：根据用户取消订单的时机来决定应当采取哪种处理方式。举例，距离服务时间T<24小时，全罚；24小时≤T<48小时，罚用户在线支付总额的一半；T≥48小时，全额退款。
对于出现的退款，需要对退款的路径、各种退款方式的优先级、退款中卡券的处理做出相应的规则。
- 退款路径：原路退回，用户使用什么方式付款，退款时就回到相应的账户中。
- 退款方式优先级举例：第三方支付>会员卡>代金券/优惠券。这样设定，是因为第三方支付无特权，其余两种有特权，既然用户失信则应对特权进行限制；会员卡是用户通过充值获得的，而代金券/优惠券是平台运营给予的，用户获取后者的成本远低于前者，所以会员卡的优先级比券高。当然，为了避免用户做出错误决定并导致其投诉，需要在用户使用前就提示这种业务场景。
- 卡券异常情况处理：卡券如果按照原样返回会过期的情况，根据业务确定是否延期；2.因为卡券的存在，按照比例规则计算时可能会出现退款金额>在线支付金额的情况，此时应该加一条兜底规则，避免过多的退款。
六、关于售后
如果商家服务完离开后用户发现质量问题并向平台投诉，则在一些情况下平台运营会介入并了解情况，确认问题存在后会先行用代金券赔付给用户，而后再对商家进行惩罚。该流程是整个服务的一部分，但是不涉及预付，此处一笔带过。
本文来源 @霹雳 。未经作者许可，禁止转载。 | 
发表于 2024-11-4 15:44:26
