售后类型基本可以分为四种情况：仅退款（未收到货）、退货退款（已收到货）、换货、补寄。这篇文章仅讨论退货退款的情况，我将从申请售后、退货退款单状态与操作、退货分支流程、涉及其他版块等4个维度来讲解。
申请售后
首先，申请售后时需要选择申请原因、填写问题描述、上传凭证图片等三项操作，提交之后就会生成一条售后单记录，然后进入后台，待工作人员进行操作。
这其中最重要的就是申请原因。因为电商法规定“买家在签收商品之日起七天内（按照物流签收后的第二天零时起计算时间，满168小时为7天）发起申请售后退换货”，当用户选择申请原因为“七天无理由退换货”时，用户的主动权将会大得多，只要不是用户自身的问题，如造成商品损坏影响二次销售，商家是必须同意的。但是是否支持七天无理由退换货是跟着商品走的，有些商品支持有些不支持，所以在添加商品时需要选择。
由于我们公司做不到像淘宝的自有物流系统能及时抓取签收信息反馈，就给了用户10天（预计3天物流配送+7天无理由退货），自发货10天之后用户将不能选择该申请理由。
退货退款单状态对应操作1. 用户端状态对应操作
审核中（修改申请、撤销申请）、待买家发货（填写物流单号、撤销申请）、待商家收货（无）、已完成（无）、拒绝中（修改申请、撤销申请）、已关闭（无）
2. 后台状态对应操作
待审核（通过、拒绝）、待买家发货（无）、待商家收货（确认收货、查看物流）、待商家退款（确认退款、查看物流）、已完成（查看物流）、已拒绝（无）、已关闭（无）
如上图，用户端和后台的退货单状态除了“待商家退款“都能一一对上（不像订单那样复杂，因为一个售后单只会对应一个商品），而用户端省略“待商家退款“的目的主要是从用户考虑，一是简少用户的认知成本，二是缓解用户的焦虑。
而后台为什么要有这一状态是因为对商家来说，收货是商品部干的事，退款是财务干的事，不同部门的权限不一样，当然如果要做细一点，甚至可以财务有一套审批的流程（审批、打款等操作由财务和出纳等角色操作），这里不做展开。
需要说明一点，当商家点击通过时应该出现一个确认地址弹窗，也就是商家添加的退货地址。该弹窗的目的是为了选择一个退货地址发送给用户，同时也提醒商家退货地址是否更改了。
退货分支流程
其实退货的正向流程很简单就像上图一样不同的操作会变更不一样的状态，而复杂的是各种各样的分支流程，这时就需要系统进行限制。
首先需要明确一点的就是用户对订单中某一商品申请售后，系统会冻结整个订单的金额，而该条售后单未完结之前（处于已完成或已关闭状态），商家将不能对该笔订单的金额申请结算。比如用户的某个订单内买了A商品2件和B商品，只对A商品的其中一件进行申请，此时整个订单金额都会进行冻结（为什么冻结整个订单而不是仅该商品，在财务一章中会解释）。
冻结订单金额和加各种限制都是为了保障用户和商家的利益。
1. 用户端限制
（1）申请售后时间限制
首先，确认收货分为用户主动确认收货和系统自动确认收货，而一般自动确认收货的时间规则我们是这样定的，自商家发货日起10天自动确认，比如淘宝是快递签收日起7天自动确认，但是淘宝有自己的物流系统，而我们做不到这一点，所以加上3天的物流时间（当然可以根据不同的商品属性来设置不同时间）。
当确认收货之后，再开始计算申请售后的时间，一般是15天，过了15天用户将不能申请售后
（2）超时未处理限制
整个退货流程需要用户做的有两步：
商家通过售后申请后，需要用户回寄商品并填写物流单号；商家拒绝时，需要用户修改申请并提交或撤销申请。
如果用户不进行操作，一般会给到7*24小时，时间截止后将会自动关闭售后单，用户只能重新申请。
（3）修改申请次数限制
用户可以进行修改申请并提交的操作在“审核中”和“拒绝中”都有，但是这里说的需要做限制是在“拒绝中”这一状态。比如用户被拒绝后，重复在7天时间结束之前修改申请并提交，商家也一直拒绝，那就可能会出现该笔订单金额一直冻结中，商家无法结算。
为了防止用户的恶意行为所以需要做一个限制，比如用户最多只能申请3次，第3次被拒绝后只能申请平台客服介入解决。当然，如果不加次数限制，也可以有时间限制，就是只有在可以申请售后时间内才能修改申请并提交；比如1号确认收货，16号之前能申请售后，17号时就不能修改申请了，同时售后单自动关闭。
（4）申请售后次数限制
接着上面说的，如果用户被拒绝后，撤销了该退货单，又重新申请，也有可能进入循环中，所以在申请售后这里也需要做次数限制。
这个次数限制肯定是在申请售后时间这个大前提以内，但这样做的目的就是防止用户恶意提交，对商家造成骚扰，当然这个限制可加可不加。
总结一下，在申请售后这里做的判断有：首先判断该订单该商品有无进行中的售后单（包括换货），有则不能申请；该商品如果有成功的退货单，且之前退货单中的申请数量小于该商品购买数量时可以申请，否则将不能；该商品的处于已关闭状态的售后单是否小于三条，是则可以申请，大于等于三条时，只能申请平台客服介入解决。当然这些限制都有一个大前提，该订单处于售后时间内，超过则都不能申请。
2. 商家端限制
（待审核）超时未处理：用户提交售后单，如果商家超时未处理，比如时间限制为7*24小时，将自动审核通过，并通知管理后台的客服人员及时联系商家。
待商家收货/待商家退款）超时未处理：用户回寄之后，此时商家该进行的操作有2步，确认收货和确认退款，如果此时商家超时未进行操作，同样将由管理后台的客服人员介入，甚至可以给到客服和财务人员直接退款的权限（当然这要考虑公司章程和部门组织架构）。
当然，还可能出现的情况就是，比如用户发回空包裹或乱填物流单号或发回的商品出现破损之类的，这时就需要商家申请客服介入的功能。
涉及其他版块
一个退换货会涉及到的其他版块有商家、商品、财务、营销等，这些版块之间可能会存在一些数据的联动，所以需要考虑进去。当然这些版块主要是后台的数据，用户端的感知并不大。
1. 商家
一般平台会对每个商家有一个评分，和一套奖惩制度。
评分的目的可能更多的影响用户端，评分高的商家下的商品出现在用户面前的几率更大，不管是搜索结果排名更靠前还是猜你喜欢等流量入口展示。而退换货肯定会影响评分，比如用户申请原因选择为“七天无理由”时可能不计入分数，而选择为质量问题，或商家服务态度问题而不想要了，这肯定会影响该商家评分的降权。
奖惩制度更多关乎于平台与商家的联动，这个就要根据公司不同时间段的业务需求来制定了，比如因质量问题退货占比高于多少的商家，需要罚多少钱，或一些特定活动不能参加。
2. 商品
退货涉及到与商品的联动有2个维度，该商品的分数和库存。
上面说的是商家的评分，但是每个商品肯定也会有自己的一套计分规则，这样搜索引擎从数据库里拉商品出来后才会有一个先后顺序的展示。而退货则会影响降权，这里面的计算规则很复杂，而且也得根据公司当前的业务目的来制定，这里不做展开。
用户下单并支付后就会扣除该商品的库存，成功退货后也将还原库存。当然也得看该商品是否被删除或者该sku是否已删除。
3. 财务
订单中的金额信息与退货会产生关联的有运费、金币抵扣、实际支付金额、结算金额。
（1）运费
首先，得判断回寄商品的运费该由哪方承担和是否该退用户支付的运费，所以就得判断是用户自身的原因还是商品的原因（我们平台还未介入运费险）。
有两个方案：
由系统介入，通过申请原因来判断，比如七天无理由退货就是用户承担，商品质量问题就是卖家承担，此时就比较复杂，可能会存在商家先把货款提走后用户再申请退货的情况，这样就会在保证金里扣除运费；是卖家和用户在线下自行协商。
个人认为，如果由系统来介入感觉好像对商家更强制一点，对用户更有保障一点，但是卖家肯定会钻空子，比如告知用户不要选择哪些申请原因，这样反倒对用户是一种骚扰，倒不如更开放一点，让双方更自由的沟通。
接下来说该多少退用户支付的运费。先解释一下，运费是由运费模板计算而来，且又分为按重量计算和按件数计算（先不讨论按体积计算，使用的太少）。
比如按重量计算该运费模板为首重2kg，首价10元，续重1kg，续费3元；某一sku重量为0.7kg，那买1~2件需付运费10元，3~4件需付10+3元，5件需付10+3+3元，6件需付10+3+3+3元，这样算出来的运费就是不规则的。问题就出现了，当我买6件，需付运费19元，那当我申请退货1件，应该退多少运费，申请3件，又应该退多少。
按照运费模板的计算来退显然不合理，有一个方案就是按平均数，比如退3件退的运费就是19/6*3元，或者固定退多少元，比如你付了10元运费只退5元，付了20元只退10元，其实都并不是那么合理，可能我暂时未想到更合理的方案，有方案的大佬欢迎在评论区大家一起交流！
所以基于退运费金额的问题，我更偏向于上一段的第二个方案，就是卖家和用户在线下自行协商，退多少运费由你们自行商量决定。
最后是回寄运费的问题。如果确实是商品的问题，用户支付多少回寄运费是不知道的，而系统唯一能计算的就是根据运费模板，但是肯定也存在不准确的地方，比如商家和快递公司谈好后，付的运费比用户付的要少。所以，最好的方案就是商家和用户进行协商。
顺带提一句，如果平台有满减运费的功能，可能存在的风险就是，比如用户买2件包邮，申请未收到货仅退款，那就可能会对商家造成损失。所以退款的时候可以做扣除运费后再退的功能。
（2）金币抵扣和实际支付金额
用户可以通过我们平台的一些途径获得金币，类似京东的京东可以用作购买商品的补贴。用户在提交订单的时候就会把金币按一定比例分摊到各个商品头上，比如A、B、C三个商品售价分别为20、30、50元且分别购买2件，你有20元金币，就可分别抵扣4、6、10元，所以当对A商品其中一件申请退货时，将会退还你现金18元和2元的金币。
（3）结算金额
是指平台抽佣后商家能结算的金额，比如商品售价100，平台抽佣5元，商家能结算95元。当用户成功退款之后将在可结算金额中扣除这一部分结算金额。
然后说一句，为什么售后和订单没有关系。如果看过之前我写的订单系统就知道我之前设计的是售后单和订单之间的状态各自独立，互不干涉。比如一个订单中只有一个商品，只对这个商品发起售后时，订单状态发生改变，比如叫“退款中”，那这样还说得过去；但是当一个订单中存在多个商品或多个购买数量时，如果一部分商品发起了售后而一部分没有发起，那就不好说了。所以最简单的方案就是订单和售后单状态相互独立。
所以，订单的后续操作如确认收货、评价等和售后状态没关系，自动确认收货时间倒计时与该订单中是否存在售后单也互不影响。
因为我们平台暂未涉及优惠券，满减（如满200减50）等营销功能，本篇就不做展开，主要是我还没做过这些功能，可能对立面的一些细节想得不够全面，反而对各位造成误解。
以上就是我对退货系统的解读，如果有不合理或者其实有更好方案的地方，欢迎各位大佬指出，同时提出意见！
之前我写过订单系统的三篇文章，收到一些反馈，有评论说我写得太详细可以精简一些，也有说我就是应该写得这么细别人才看得懂。我也在反思，如果仅仅是为了阅读量可以把标题写得唬人一点，为了点赞量可以把内容精简一些读起来更顺畅一些。但是我写文章的目的之前也说过，一是为了复个盘，二是为了和大家讨论，发现我写得不合理的地方。其实还有一点是我自己的感触，才做电商的时候很懵逼也踩过很多坑，我希望尽量把这些踩过的坑都写出来，希望能给人一点参考作用。
相关阅读
从0到1构建电商平台之订单系统（3）：处理订单
从0到1构建电商平台之订单系统（2）：支付订单
从0到1构建电商平台之订单系统（1）：提交订单
本文由 @橘钻 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
