虚拟商品退款的产品设计中，有哪些坑你需要了解
最近在做公司的退款流程优化项目，这个项目从6月开始调研到现在终于进入研发流程，2个月的时间里我跟客服、财务和技术同事聊了很多，终于把潜在的坑都盘得差不多了。
所以也第一时间跟大家分享。
一
第一个坑：想要把所有问题解决
退款是一个很正常的消费者诉求，用户拿到商品，对质量不满意，在一定条件下，自然希望可以有退款的权利。无论是线下交易还是线上交易，退款的刚需一直都在。
但同时，退款又是一个典型的做到80分就可以的需求。一个产品不会因为退款功能做得很牛逼，就在付费转化率上具有更大的优势，这是很难的。
所以，在资源有限的情况下，满足用户基本诉求。做到80分，对我来说就可以了。
那用户的基本诉求是什么呢？那就是因为各种原因想要退款时，发起申请后，能够尽快拿到应得的退款。钱落入口袋，才算安心。
另一方面，一个新产品刚上线时，研发重点一定是正向流程，即如何让用户付款。而关于退款，尤其是虚拟商品的退款，一般都交给客服团队解决。
那这时候客服的工作量就很大了，对每个用户的退款诉求，用户电话呼入，沟通协商，确认退款金额，要到支付账户，找技术回收权益，修改待退款的订单。一旦迎来大促，客服的工作量真的是爆发式增长。
最后一个重要的角色是财务，退款发生时，资金逆向流动，那财务会充当两个角色，第一是要给用户打款，第二是要把这中间的账给记清楚。对虚拟商品来说，有时候钱不单单是公司的，也是版权方或者IP的，比如一个老师的课程，我们要给老师分润，那一旦这门课产生了退款，钱该怎么算，这都是需要财务去考虑的地方。
所以为什么要做退款流程优化，因为它优化了用户体验，节约了客服时间，让财务流程更清晰和自动化。
但切记，从资源投入角度来说，做到80分，用50%的资源投入，解决80%的退款场景，带来120%的实际收入，这才是最明智的投资方式。这时候就需要我们去看过去一段时间的退款数据，什么sku、什么系统的退款是主要的，根据这个来决定做到80分的需求范围。
二
第二个坑：希望产品主导一切
作为产品经理，如果我没有接过100个以上用户的退款诉求，如果我没有整理过100个用户以上的退款报表，那我是没有资格去以自己的逻辑去主导这个需求的。
为什么我做了两个月的调研，因为我需要不断地跟客服和财务去聊，聊他们之前手动处理时都是怎么做的，为什么要这么做，了解清楚了这些，才能知道可以将哪些流程产品化。
在做这个需求之前，我作为产品经理，会自然而然地认为，最好的方式就是不需要克服介入，让系统之前完成跟用户的交互。例如用户在app的订单页面可以一键申请退款，然后钱退到账户，整个过程中完全不需要客服的介入。
但这几乎不现实。对于实物商品来说，需要商品先寄回，评估受损程度来判定能不能退。那对于虚拟商品来说，自然没有受损这一说，但虚拟商品的权益回收我不建议根据系统逻辑来代替客服的处理原则。
我跟客服聊过，他们现在处理退款的原则，都是在跟大量用户沟通的基础上得到的，你去看这些处理原则的时候，会发现根本不是100%的理工男逻辑，例如一门课我听了50%的课程，就退50%的费用，客服一般不是这样处理的。
为什么？因为这样反而增加了他们的成本，如果不想增加他们的成本，那就会增加系统的成本。所以呀，成本！一切都关乎成本！
所以我的处理原则是，完全继承客服之前的处理逻辑，尊重他们的专业程度，只是把这样的逻辑代码化。另一方面，客服真正的痛点是资金原路返回，所以产品经理应该将这个小功能做到100分。
而对财务来说，最核心的诉求是把账算清楚。一个退款账单，最核心的大概有这么几个要素：用户id、订单id、订单金额、应退金额、实退金额、支付时间、退款时间。
任何支持退款的订单，都应该将这几个要素记清楚，记准。这几个核心要素中，最关键的又是应退金额和实退金额。
应退金额，代表的是公司理论上应该付出的成本，比如会期还剩一半的时候用户要退款，那应退金额就是订单总价的一半。
实退金额，代表的是公司实际退回给用户的钱，是实际付出成本。有时候客服根据用户的情绪，多做一些安抚，或者根据用户的等级做一些临时操作，都有可能导致根据逻辑算出来的应退金额无法满足一个退款工单的处理。
为了把账算清楚，这两个金额就必须要分开处理。
三
第三个坑：轻易就去动订单
如果你不是做订单系统的产品，然后你去做退款功能了，这时候你可能会说，我在订单里增加一个退款的属性好不好，在这个属性里去记录退款过程中的各种状态。
千万不要！为什么，因为对于大多数公司来说，当有第一笔交易发生时，就很可能会有订单系统（除非用excel手动记账）。订单相关的数据，在各种跟钱相关的报表里都有应用。去改订单的数据，这才是踩了一个大坑，如果你不是那个做订单的产品经理，你很可能不会知道自己会少考虑什么情况。
我的做法是：数据解耦、状态关联。
数据解耦，说的是退款订单要单独管理。打个比方，如果说订单系统是一个大宇宙，那么退款相关的订单就是一个独立的小宇宙，两个宇宙之间通过状态的映射来连接。
用户无论是在平台申请退款，还是在第三方申请退款，相关的订单都会进入到退款流。退款流包括权益的流转、订单状态的流转、资金的流转等，这些流转是独立的，他们的数据不会影响原先订单系统里的数据。
所以我在后台新增了一个菜单去管理退款流中的所有订单，完全不去动原来的订单系统。
另一方面，对于每一个退款订单，都会有一个退款状态，这个状态描述了一个订单在退款流中的关键节点：
发起退款：用户正式向平台发起退款，以客服在后台完成操作为触发节点。
退款到账中：平台完成权益回收，触发资金回退流。
退款完成：资金通过原支付渠道回到用户账户，需要有各支付渠道关于退款成功的回执。
退款撤销：退款流中的逆向流程，以客服操作为触发。
退款失败：获取支付渠道退款成功的回执失败，用户没有收到钱。
每一个退款状态，都会映射一个订单状态。这样做的好处一方面是数据解耦，对原系统干扰最小，另一方面实现数据上的互查。
四
第四个坑：退款里的逆向流程不能忽视
想不到吧，退款这个逆向操作里，也存在逆向流程。负负得正，最终就是，钱还是在用户那里。当然退款的逆向流程，也是从客服那里了解到的。
确实对于一部分用户来说，他们申请退款之后，会打电话过来说因为一些原因不想退了。那这个逆向流程怎么处理。
我的灵感来自于电商退款设计，我在京东下单后，如果想要退款并且选择了上门自提，那我能够修改收货地址的次数是有限的（好像是三次），我将这样的处理方法称之为：有限条件下的逆向支持。
即，我支持用户走逆向流程，但从成本考虑需要有一定的限制，并且这个限制条件是提前让用户知道的。如果用户在这个限制条件之外，那只能先退款再重新购买了，尽管我们知道这样用户第二次购买的概率会比较低，但从总体成本考虑这样也是划算的。
所以呀，还是那句话，做到80分，考虑所有可能，但永远考虑成本。
怎么做的呢，我设计了一个缓冲期。当用户发起退款后，在缓冲期内用户可以发起拦截，过了缓冲期就不行了。当然，缓冲期内拦截后，用户理论上可以再次申请退款（技术上是0边际成本的，只要把可支持退款的订单状态范围扩大就行），但是从客服成本考虑，我一期还是先把这个口子收拢了。
另一方面，这个缓冲期支持后台配置，根据平日和大促两种节奏，制定不同的退款缓冲期。
五
第五个坑：苹果用户购买虚拟商品时的退款
最后一个坑，也是最头疼的设计，就是苹果用户购买虚拟商品时的退款。这里先介绍苹果用户退虚拟商品的三个阶段吧。
第一个阶段：用户找苹果退款后，苹果公司不会有任何消息给我们。当然苹果也不会轻易同意一个用户的退款，他们有自己的判断准则。但是这对于所有卖虚拟商品的平台来说，不确定性就很大了。如果用户从苹果退款了，但苹果不告诉我们，那这里面会有多大的黑产空间，简直不可想象。
第二个阶段：用户找苹果退款后，苹果公司会有一个消息告诉我们，有用户退款了。这个消息包括：用户id、产品id、第三方交易id、订单id、退款时间、退款状态。这对于我们来说就已经是一大进步了，至少收到这个消息后，我们可以对用户在站内的权益做回收，相关的订单做状态流转处理。
第三个阶段：未来，用户发起退款后，苹果会首先找平台要用户在平台相关的下单记录和使用情况，以此作为依据决定是否要给用户退款。这样能进一步地压缩黑产操作的可能性，希望这一天早点来到。
好了，接着说下现在的第二个阶段，用户在苹果退款了，苹果也给我们发消息了，那应该如何处理。
这里又涉及到两种情况：
1、用户在苹果购买的是商品；
2、用户在苹果购买的是虚拟货币充值，比如我司的智慧币、得到的得到贝。
如果是第一种情况，那处理逻辑很简单。找到退款的那个订单id，完成权益回收，并且将退款状态修改为退款完成，应退金额和实退金额都是苹果实际返回给用户的金额。
第二种情况比较麻烦，最麻烦的地方在于找到充值订单和商品购买订单的关联关系。
举个例子吧，用户在苹果充了100个智慧币，然后用100个智慧币在平台购买了1门课程。如果用户在苹果退了100智慧币的充值订单，那理论上平台应该也把这门课回收。
但最有意思的是，用户用100智慧币购买1门课程的时候，购买这个课程的订单和100智慧币的充值订单不太好完全关联。就好像我从银行取了100块钱现金，然后我去隔壁烧烤店吃了一顿100的烧烤，我能知道我花的是哪一张RMB么，很难。
因此思来想去，我决定在这一步还是由人工介入，根据充值订单的时间，和用户在这个时间之后的其他订单，以及每个订单的支付方式，来判断这种关联关系。
只要这种关联关系判断好了，剩下来的就是回收权益，然后可能会有虚拟资产的平衡（因为会有关联订单的总价大于或小于退回的虚拟资产这两种情况）
六
虚拟商品的退款流程设计，当我走完一遍之后，差不多能盘出来的主要的坑就是这些了。
当然有很多东西还没有讲清楚：比如会期、课程、训练营等不同的产品，权益该如何回收；比如涉及到分销时，账又该怎么算等问题。可以肯定的是，这篇文章所说的内容，没有覆盖虚拟商品退款时所关联的所有场景。
但我有两点很深刻的体会：
当我跟客服、财务去聊的时候，我发现其实他们也不指望所有需要手工操作的地方，都能够自动化，但一定有一个主要的痛点需要去解决。比如找用户要支付账号时，面临的不信任，比如退款时间和支付时间不在一个月份时，月度报表结算问题。
其次，在我看来，一线的财务和客服经验完全是我的盲区，我可以尽力去理解，但很难去干预。所以，我选择尊重专业人士在专业领域的专业经验，用产品经理能做到的事情，去做好支持。
这一篇有点干，有点硬，感谢你看到了这里。