為什么？因為這樣反而增加了他們的成本，如果不想增加他們的成本，那就會增加系統(tǒng)的成本 。所以呀，成本！一切都關乎成本！
所以我的處理原則是，完全繼承客服之前的處理邏輯，尊重他們的專業(yè)程度，只是把這樣的邏輯代碼化 。另一方面，客服真正的痛點是資金原路返回，所以產(chǎn)品經(jīng)理應該將這個小功能做到100分 。
而對財務來說，最核心的訴求是把賬算清楚 。一個退款賬單，最核心的大概有這么幾個要素：用戶id、訂單id、訂單金額、應退金額、實退金額、支付時間、退款時間 。
任何支持退款的訂單，都應該將這幾個要素記清楚，記準 。這幾個核心要素中，最關鍵的又是應退金額和實退金額 。
應退金額，代表的是公司理論上應該付出的成本，比如會期還剩一半的時候用戶要退款，那應退金額就是訂單總價的一半 。
實退金額，代表的是公司實際退回給用戶的錢，是實際付出成本 。有時候客服根據(jù)用戶的情緒，多做一些安撫，或者根據(jù)用戶的等級做一些臨時操作，都有可能導致根據(jù)邏輯算出來的應退金額無法滿足一個退款工單的處理 。
為了把賬算清楚，這兩個金額就必須要分開處理 。
03 第三個坑：輕易就去動訂單 。
如果你不是做訂單系統(tǒng)的產(chǎn)品，然后你去做退款功能了，這時候你可能會說，我在訂單里增加一個退款的屬性好不好，在這個屬性里去記錄退款過程中的各種狀態(tài) 。
千萬不要！為什么，因為對于大多數(shù)公司來說，當有第一筆交易發(fā)生時，就很可能會有訂單系統(tǒng)（除非用excel手動記賬） 。訂單相關的數(shù)據(jù)，在各種跟錢相關的報表里都有應用 。去改訂單的數(shù)據(jù)，這才是踩了一個大坑，如果你不是那個做訂單的產(chǎn)品經(jīng)理，你很可能不會知道自己會少考慮什么情況 。
我的做法是：數(shù)據(jù)解耦、狀態(tài)關聯(lián) 。
數(shù)據(jù)解耦，說的是退款訂單要單獨管理 。打個比方，如果說訂單系統(tǒng)是一個大宇宙，那么退款相關的訂單就是一個獨立的小宇宙，兩個宇宙之間通過狀態(tài)的映射來連接 。
用戶無論是在平臺申請退款，還是在第三方申請退款，相關的訂單都會進入到退款流 。退款流包括權益的流轉(zhuǎn)、訂單狀態(tài)的流轉(zhuǎn)、資金的流轉(zhuǎn)等，這些流轉(zhuǎn)是獨立的，他們的數(shù)據(jù)不會影響原先訂單系統(tǒng)里的數(shù)據(jù) 。
所以我在后臺新增了一個菜單去管理退款流中的所有訂單，完全不去動原來的訂單系統(tǒng) 。
另一方面，對于每一個退款訂單，都會有一個退款狀態(tài)，這個狀態(tài)描述了一個訂單在退款流中的關鍵節(jié)點：
發(fā)起退款：用戶正式向平臺發(fā)起退款，以客服在后臺完成操作為觸發(fā)節(jié)點 。退款到賬中：平臺完成權益回收，觸發(fā)資金回退流 。退款完成：資金通過原支付渠道回到用戶賬戶，需要有各支付渠道關于退款成功的回執(zhí) 。退款撤銷：退款流中的逆向流程，以客服操作為觸發(fā) 。退款失敗：獲取支付渠道退款成功的回執(zhí)失敗，用戶沒有收到錢 。
每一個退款狀態(tài)，都會映射一個訂單狀態(tài) 。這樣做的好處一方面是數(shù)據(jù)解耦，對原系統(tǒng)干擾最小，另一方面實現(xiàn)數(shù)據(jù)上的互查 。
04 第四個坑：退款里的逆向流程不能忽視 。
想不到吧，退款這個逆向操作里，也存在逆向流程 。負負得正，最終就是，錢還是在用戶那里 。當然退款的逆向流程，也是從客服那里了解到的 。
確實對于一部分用戶來說，他們申請退款之后，會打電話過來說因為一些原因不想退了 。那這個逆向流程怎么處理 。
我的靈感來自于電商退款設計，我在京東下單后，如果想要退款并且選擇了上門自提，那我能夠修改收貨地址的次數(shù)是有限的（好像是三次），我將這樣的處理方法稱之為：有限條件下的逆向支持 。
推薦閱讀
- 冰墩墩怎么火了
- 磨砂膏有什么用 怎么用 磨砂膏有什么用
- 怎么教寶寶自己穿鞋子
- 男子提肛運動怎么做才正確
- 怎么換王者局內(nèi)稱號 王者榮耀如何更換局內(nèi)稱號
- 王者榮耀戰(zhàn)隊戰(zhàn)力貢獻度怎么獲得
- 怎么把胸練挺拔
- 鳳儀之詔皮膚怎么獲得 鳳儀之詔的皮膚怎么領
- 王者鳳儀之詔領取了有什么用 王者榮耀怎么才能獲得鳳儀之詔
- 王者榮耀橘右京怎么獲取 王者榮耀怎樣獲得橘右京