起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識虛擬商品退款的產品設計中，有哪些坑你需要了解
編輯導語：退款模塊的設計優化在一定程度上可以優化用戶體驗，讓流程更加清晰和高效，緩解用戶焦慮，滿足用戶需求。那么，在虛擬商品退款模塊設計中，有哪些事項需要注意？本篇文章里，作者結合實際經驗，總結了一份虛擬商品退款流程優化的避坑指南，一起來看一下。
最近在做公司的退款流程優化項目，這個項目從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協議
專欄作家
大力哥呀，微信公眾號：大力哥，人人都是產品經理專欄作家。一個90后產品經理，已經寫了6年的公眾號，通過輸出獲得了許多意料外的成長。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
目前正在做ota渠道的極速退款項目，我們現在已經設定了緩沖期來解決一些事情，但是這次緩沖期要全部拿到，釋放出來的規則都要進行處理，這篇文章還是受教了。
蘋果交易的時候會產生33％的手續費，相當于用戶支付500元，最后平臺只收到300多，那用戶去蘋果官方退款之后，這次手續費會退還給平臺，還是平臺倒貼33％的手續費呢？
寫的挺好的。目前我們蘋果退款已經到第三個階段了。
哇，你們已經在使用蘋果第三階段的api了么
有幫助到！！感謝分享?。?/p>
針對這個方面，建議看一下微信支付 or 支付寶開放平臺的相關案例設計?？赡軙o您參考
感謝
感謝
感謝
感謝
一門課我聽了50%的課程，就退50%的費用，客服一般是怎樣處理的？
復雜一點的是根據播放進度來，這個要看埋點的準確程度；懶一點是根據已經購買的時間來做階梯處理，比如0-3天一個處理原則，4-7天一個處理原則。后者是客服長期跟客戶協商出來的一個契約。