虚拟商品退款的产品设计中有哪些坑你需要理解

最近在做公司的退款流程优化项目，这个项目从6月开始调研到现在终于进入研发流程，2个月的韶光里我跟客服、财务和技能同事聊了很多，终于把潜在的坑都盘得差不多了。

以是也第一韶光跟大家分享。

01 第一个坑：想要把所有问题办理。

退款是一个很正常的消费者诉求，用户拿到商品，对质量不满意，在一定条件下，自然希望可以有退款的权利。
无论是线下交易还是线上交易，退款的刚需一贯都在。

但同时，退款又是一个范例的做到80分就可以的需求。
一个产品不会由于退款功能做得很牛逼，就在付费转化率上具有更大的上风，这是很难的。

以是，在资源有限的情形下，知足用户基本诉求。
做到80分，对我来说就可以了。

那用户的基本诉求是什么呢？那便是由于各种缘故原由想要退款时，发起申请后，能够尽快拿到应得的退款。
钱落入口袋，才算安心。

另一方面，一个新产品刚上线时，研发重点一定是正向流程，即如何让用户付款。
而关于退款，尤其是虚拟商品的退款，一样平常都交给客服团队办理。

那这时候客服的事情量就很大了，对每个用户的退款诉求，用户电话呼入，沟通协商，确认退款金额，要到支付账户，找技能回收权柄，修正待退款的订单。
一旦迎来大匆匆，客服的事情量真的是爆发式增长。

末了一个主要的角色是财务，退款发生时，资金逆向流动，那财务会充当两个角色，第一是要给用户打款，第二是要把这中间的账给记清楚。
对虚拟商品来说，有时候钱不单单是公司的，也是版权方或者IP的，比如一个老师的课程，我们要给老师分润，那一旦这门课产生了退款，钱该怎么算，这都是须要财务去考虑的地方。

所以为什么要做退款流程优化，由于它优化了用户体验，节约了客服韶光，让财务流程更清晰和自动化。

但牢记，从资源投入角度来说，做到80分，用50%的资源投入，办理80%的退款场景，带来120%的实际收入，这才是最明智的投资办法。
这时候就须要我们去看过去一段韶光的退款数据，什么sku、什么系统的退款是紧张的，根据这个来决定做到80分的需求范围。

02 第二个坑：希望产品主导统统。

作为产品经理，如果我没有接过100个以上用户的退款诉求，如果我没有整理过100个用户以上的退款报表，那我是没有资格去以自己的逻辑去主导这个需求的。

为什么我做了两个月的调研，由于我须要不断地跟客服和财务去聊，聊他们之前手动处理时都是怎么做的，为什么要这么做，理解清楚了这些，才能知道可以将哪些流程产品化。

在做这个需求之前，我作为产品经理，会自然而然地认为，最好的办法便是不须要战胜参与，让系统之前完成跟用户的交互。
例如用户在app的订单页面可以一键申请退款，然后钱退到账户，全体过程中完备不须要客服的参与。

但这险些不现实。
对付实物商品来说，须要商品先寄回，评估受损程度来剖断能不能退。
那对付虚拟商品来说，自然没有受损这一说，但虚拟商品的权柄回收我不建议根据系统逻辑来代替客服的处理原则。

我跟客服聊过，他们现在处理退款的原则，都是在跟大量用户沟通的根本上得到的，你去看这些处理原则的时候，会创造根本不是100%的理工男逻辑，例如一门课我听了50%的课程，就退50%的用度，客服一样平常不是这样处理的。

为什么？由于这样反而增加了他们的本钱，如果不想增加他们的本钱，那就会增加系统的本钱。
以是呀，本钱！
统统都关乎本钱！

以是我的处理原则是，完备继续客服之前的处理逻辑，尊重他们的专业程度，只是把这样的逻辑代码化。
另一方面，客服真正的痛点是资金原路返回，以是产品经理该当将这个小功能做到100分。

而对财务来说，最核心的诉求是把账算清楚。
一个退款账单，最核心的大概有这么几个要素：用户id、订单id、订单金额、应退金额、实退金额、支付韶光、退款韶光。

任何支持退款的订单，都该当将这几个要素记清楚，记准。
这几个核心要素中，最关键的又是应退金额和实退金额。

应退金额，代表的是公司理论上该当付出的本钱，比如会期还剩一半的时候用户要退款，那应退金额便是订单总价的一半。

实退金额，代表的是公司实际退回给用户的钱，是实际付出本钱。
有时候客服根据用户的感情，多做一些安抚，或者根据用户的等级做一些临时操作，都有可能导致根据逻辑算出来的应退金额无法知足一个退款工单的处理。

为了把账算清楚，这两个金额就必须要分开处理。

03 第三个坑：轻易就去动订单。

如果你不是做订单系统的产品，然后你去做退款功能了，这时候你可能会说，我在订单里增加一个退款的属性好不好，在这个属性里去记录退款过程中的各种状态。

千万不要！
为什么，由于对付大多数公司来说，当有第一笔交易发生时，就很可能会有订单系统（除非用excel手动记账）。
订单干系的数据，在各种跟钱干系的报表里都有运用。
去改订单的数据，这才是踩了一个大坑，如果你不是那个做订单的产品经理，你很可能不会知道自己会少考虑什么情形。

我的做法是：数据解耦、状态关联。

数据解耦，说的是退款订单要单独管理。
打个比方，如果说订单系统是一个大宇宙，那么退款干系的订单便是一个独立的小宇宙，两个宇宙之间通过状态的映射来连接。

用户无论是在平台申请退款，还是在第三方申请退款，干系的订单都会进入到退款流。
退款流包括权柄的流转、订单状态的流转、资金的流转等，这些流转是独立的，他们的数据不会影响原来订单系统里的数据。

以是我在后台新增了一个菜单去管理退款流中的所有订单，完备不去动原来的订单系统。

另一方面，对付每一个退款订单，都会有一个退款状态，这个状态描述了一个订单在退款流中的关键节点：

发起退款：用户正式向平台发起退款，以客服在后台完成操作为触发节点。
退款到账中：平台完成权柄回收，触发资金回退流。
退款完成：资金通过原支付渠道回到用户账户，须要有各支付渠道关于退款成功的回执。
退款撤销：退款流中的逆向流程，以客服操作为触发。
退款失落败：获取支付渠道退款成功的回执失落败，用户没有收到钱。

每一个退款状态，都会映射一个订单状态。
这样做的好处一方面是数据解耦，对原系统滋扰最小，另一方面实现数据上的互查。

04 第四个坑：退款里的逆向流程不能忽略。

想不到吧，退款这个逆向操作里，也存在逆向流程。
负负得正，终极便是，钱还是在用户那里。
当然退款的逆向流程，也是从客服那里理解到的。

确实对付一部分用户来说，他们申请退款之后，会打电话过来说由于一些缘故原由不想退了。
那这个逆向流程怎么处理。

我的灵感来自于电商退款设计，我在京东下单后，如果想要退款并且选择了上门自提，那我能够修正收货地址的次数是有限的（彷佛是三次），我将这样的处理方法称之为：有限条件下的逆向支持。

即，我支持用户走逆向流程，但从本钱考虑须要有一定的限定，并且这个限定条件是提前让用户知道的。
如果用户在这个限定条件之外，那只能先退款再重新购买了，只管我们知道这样用户第二次购买的概率会比较低，但从总体本钱考虑这样也是划算的。

以是呀，还是那句话，做到80分，考虑所有可能，但永久考虑本钱。

怎么做的呢，我设计了一个缓冲期。
当用户发起退款后，在缓冲期内用户可以发起拦截，过了缓冲期就弗成了。
当然，缓冲期内拦截后，用户理论上可以再次申请退款（技能上是0边际本钱的，只要把可支持退款的订单状态范围扩大就行），但是从客服本钱考虑，我一期还是先把这个口子收拢了。

另一方面，这个缓冲期支持后台配置，根据平日和大匆匆两种节奏，制订不同的退款缓冲期。

05 第五个坑：苹果用户购买虚拟商品时的退款。

末了一个坑，也是最头疼的设计，便是苹果用户购买虚拟商品时的退款。
这里先先容苹果用户退虚拟商品的三个阶段吧。

第一个阶段：用户找苹果退款后，苹果公司不会有任何给我们。
当然苹果也不会轻易赞许一个用户的退款，他们有自己的判断准则。
但是这对付所有卖虚拟商品的平台来说，不愿定性就很大了。
如果用户从苹果退款了，但苹果不见告我们，那这里面会有多大的黑产空间，切实其实不可想象。

第二个阶段：用户找苹果退款后，苹果公司会有一个见告我们，有用户退款了。
这个包括：用户id、产品id、第三方交易id、订单id、退款韶光、退款状态。
这对付我们来说就已经是一大进步了，至少收到这个后，我们可以对用户在站内的权柄做回收，干系的订单做状态流转处理。

第三个阶段：未来，用户发起退款后，苹果会首先找平台要用户在平台干系的下单记录和利用情形，以此作为依据决定是否要给用户退款。
这样能进一步地压缩黑产操作的可能性，希望这一天早点来到。

好了，接着说下现在的第二个阶段，用户在苹果退款了，苹果也给我们发了，那该当如何处理。

这里又涉及到两种情形：

用户在苹果购买的是商品；用户在苹果购买的是虚拟货币充值，比如我司的聪慧币、得到的得到贝。

如果是第一种情形，那边那里理逻辑很大略。
找到退款的那个订单id，完成权柄回收，并且将退款状态修正为退款完成，应退金额和实退金额都是苹果实际返回给用户的金额。

第二种情形比较麻烦，最麻烦的地方在于找到充值订单和商品购买订单的关联关系。

举个例子吧，用户在苹果充了100个聪慧币，然后用100个聪慧币在平台购买了1门课程。
如果用户在苹果退了100聪慧币的充值订单，那理论上平台该当也把这门课回收。

但最故意思的是，用户用100聪慧币购买1门课程的时候，购买这个课程的订单和100聪慧币的充值订单不太好完备关联。
就彷佛我从银行取了100块钱现金，然后我去隔壁烧烤店吃了一顿100的烧烤，我能知道我花的是哪一张RMB么，很难。

因此思来想去，我决定在这一步还是由人工参与，根据充值订单的韶光，和用户在这个韶光之后的其他订单，以及每个订单的支付办法，来判断这种关联关系。

只要这种关联关系判断好了，剩下来的便是回收权柄，然后可能会有虚拟资产的平衡（由于会有关联订单的总价大于或小于退回的虚拟资产这两种情形）。

06

虚拟商品的退款流程设计，当我走完一遍之后，差不多能盘出来的紧张的坑便是这些了。

当然有很多东西还没有讲清楚：比如会期、课程、演习营平分歧的产品，权柄该如何回收；比如涉及到分销时，账又该怎么算等问题。
可以肯定的是，这篇文章所说的内容，没有覆盖虚拟商品退款时所关联的所有场景。

但我有两点很深刻的体会。

当我跟客服、财务去聊的时候，我创造实在他们也不指望所有须要手工操作的地方，都能够自动化，但一定有一个紧张的痛点须要去办理。
比如找用户要支付账号时，面临的不信赖，比如退款韶光和支付韶光不在一个月份时，月度报表结算问题。

其次，在我看来，一线的财务和客服履历完备是我的盲区，我可以尽力去理解，但很难去干预。
以是，我选择尊重专业人士在专业领域的专业履历，用产品经理能做到的事情，去做好支持。

这一篇有点干，有点硬，感谢你看到了这里。

#专栏作家#

大力哥呀；微信"大众年夜众号：大力哥求职，大家都是产品经理专栏作家。
正年轻的产品经理，关注新零售、用户体系，善于问题抽象及拆解。

本文原创发布于大家都是产品经理。
未经容许，禁止转载

题图来自Unsplash，基于CC0协议