从0到1精通退款处理:提升成功率、退款时效

1 评论 2501 浏览 25 收藏 11 分钟

在电商平台或支付平台中,退款这一功能是十分常见的,那么在产品设计维度上,退款处理应该如何设计?本文作者便结合教育O2O的退款场景,对退款处理及相应的功能设计、难点等内容做了分析解读,一起来看看吧。

背景

作为一个出金操作,当我们发起批量大额退款时,怎么避免超额退款?退款提示失败,就是真的失败吗,可以继续发起退款申请吗?

虽然国内的支付产品都比较成熟,支付退款成功率基本能达到99%+,但是作为电商平台,或其他业务平台接入时,在业务平台内依然需要较多细节校验和处理,还是有很多值得注意的坑。

可以从这篇文章获得什么:

0-1搞定退款,减少踩坑,考虑退款处理时间、成功率这些功能性指标;也聊聊如何提升退款时效;以及教育O2O的退款场景,了解业务。

一、业务场景

平台面向家长销售线下O2O课程,常见退款场景如下:

发起退款:

  1. 报名期间,家长如反悔希望退款,可以随时申请退款;
  2. 报名结束后,如存在人数不足以开课成班情况,运营会通知并联系家长是否需要退费,或者调班,如果退费,可直接在后台操作,不需要麻烦家长操作;
  3. 开课后,一般一个课程有多个课时,中途如有学生生病请假、中途退课等原因可以随时申请退款;
  4. 学期末,运营方会同意核算学生请假情况,统一进行批量退款。

退款处理:

平台接收退款申请后,一般有几种方案:免审退款,审核退款(退全部课时费、退部分课时费)。

二、流程

1. 业务流程

基于业务场景可以整理出几种退款方式:用户申请免审退款、用户主动退款(需要审核)、运营主动退款,其中:

1. 审核节点,即红色子流程可设置开关,支持业务按需配置审核流程。

2. “1-用户主动流程(免审)”是最简单的流程,常见于报名期间,用户发起后,即可以免审全额退款。

3. “2-用户主动流程(非免审)”相较于“1-用户主动流程(免审)”,其实是增加了学校处理流程,会由学校确认本次退款的金额,是部分退,还是全部退。

4. “3-运营主动流程”则是由运营在后台发起,如无需审核,直接执行退款。

通过以上流程,可以抽象出几个子流程:退款申请、退款处理、退款审核、执行退款;以下将基于子流程展开谈谈每个子流程的处理细节。

2. 退款申请(单笔)

常见问题:

1. 怎么避免重复发起退款?

如用户前台发起后,运营在后台以重复原因发起退款;

需要锁定订单,一个订单仅允许一个退款中记录,避免重复退款。

2. 如何减少运营工作量?

前期流程:微信沟通,发送请假申请信息(文字、图片)-运营处理退款。

存在问题就是,多个家长联系后,运营每次处理都需要凭记忆从手机找到相关材料,再备注传附件,有时没有备注后续纠纷难处理。

需要退款原因支持家长主动备注、上传图片,减少运营工作量(小点,但是有很大提效)。

流程设计:

3. 退款申请(批量)

常见问题:

1. 如何保障退款准确性,降低错误?

常见的退款错误有:批次退款金额、笔数不对,重复退款,课程服务机构变更。

退款过程中,需要统计每个批次退款金额、笔数,保证每个节点人员快速总数是否合理;同时锁定订单,避免多端重复发起退款;如提交过程中,遇到课程服务机构变更,需要补充校验提醒。

2. 如何提升退款时效性?

一个学校课程一般由多个机构服务,对于运营来说,如果一个批次提交多个机构、学校,需要学校+机构确认后,方可退款;如A机构未确认,会影响B机构退款时效。

基于这样的运营背景,则需要按学校、机构拆分批次,提升退款时效。

流程设计:

4. 执行退款

提交到外部支付渠道前,需要校验是否超额、是否重复退款;提交到外部后,需要对外部通道返回结果进行处理,常见错误如:

  1. 请求频繁:定时任务,重新请求。/手动发起请求。
  2. 用户账户已注销:用户联系后,调整退款去向。
  3. 账户余额不足:调整微信自动提现余额,保障次日退款;或等待入金;或调整外部渠道退款方式。

5. 退款状态

三、功能设计

1. 退款申请-单笔前台

以淘宝举例,用户按子订单退款发起退款申请,对于是否允许批量发起退款,需要结合业务场景判断,一般是单件退款,饿了么有个半日达超市服务,支持用户批量退款。

另用户售后政策可参考淘宝,如售后时间,是否退运费等。

https://www.taobao.com/market/global/xfzbzbzzx.php

2. 退款申请-后台批量

一般参考有赞、支付宝、微信支付的批量退款,直接输入支付订单号、退款金额即可,支付订单号需要前往订单管理获取。

但是需要考虑业务使用人员对互联网产品的熟悉程度,系统会过滤出可退款订单(未全额退、未锁定订单),并提供筛选,帮助运营人员快速进行批量退款订单获取。

当然这个方式冗余较多业务信息,一般不是中台的处理方案,而会放到业务系统处理,这个具体看业务和团队的协调。

注意导入模板的设计,顶部增加说明,末列增加退款金额、备注列。

3. 退款失败处理

4. 退款结果查询

后台-退款记录:

后台-退款记录详情:

四、难点

1. 由于清结算需求,退款需关联课时,历史数据处理难度大

多个订单对应一个课程(重复报名)情况:一节课,存在如有学生oid重复,学生课时标记为停课,暂不结算;学期末统一退款、结算。

订单余额多于课时余额:支持自定义金额退款;学期末统一退款、结算。

订单余额少于课时余额:增加校验规则,不允许订单超额退款、超额结算。

2. 服务机构变更,导致退款流程变更

一般来说商家上架商品,产生的商品购买都会和这个商家结算分账,不会出现变更。

但对于线下服务场景来说,用户一次性购买10节课,服务过程中可能出现调班、学校需要更换服务机构等情况;导致子订单服务机构会产生变更,故相较于常规电商退款,需要进一步校验服务机构变更、提醒。

五、如何提升提效

  1. 发起退款:支持单笔退款、批量退款、不成班一键退款。
  2. 退款审核:批量审核、全部审核、审核倒计时。
  3. 退款失败处理:系统自动处理。

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

题图来自 Unsplash,基于 CC0 协议

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 太棒了!!!学到了

    来自浙江 回复