編輯導語：退款模塊的設計優化在一定程度上可以優化用戶體驗，讓流程更加清晰和高效，緩解用戶焦慮，滿足用戶需求。那么，在虛擬商品退款模塊設計中，有哪些事項需要注意？本篇文章里，作者結合實際經驗，總結了一份虛擬商品退款流程優化的避坑指南，一起來看一下。

最近在做公司的退款流程優化項目，這個項目從6月開始調研到現在終于進入研發流程，2個月的時間里我跟客服、財務和技術同事聊了很多，終于把潛在的坑都盤得差不多了。

所以也第一時間跟大家分享。

01

第一個坑：想要把所有問題解決。

退款是一個很正常的消費者訴求，用戶拿到商品，對質量不滿意，在一定條件下，自然希望可以有退款的權利。無論是線下交易還是線上交易，退款的剛需一直都在。

但同時，退款又是一個典型的做到80分就可以的需求。一個產品不會因為退款功能做得很牛逼，就在付費轉化率上具有更大的優勢，這是很難的。

所以，在資源有限的情況下，滿足用戶基本訴求。做到80分，對我來說就可以了。

那用戶的基本訴求是什么呢？那就是因為各種原因想要退款時，發起申請后，能夠盡快拿到應得的退款。錢落入口袋，才算安心。

另一方面，一個新產品剛上線時，研發重點一定是正向流程，即如何讓用戶付款。而關于退款，尤其是虛擬商品的退款，一般都交給客服團隊解決。

那這時候客服的工作量就很大了，對每個用戶的退款訴求，用戶電話呼入，溝通協商，確認退款金額，要到支付賬戶，找技術回收權益，修改待退款的訂單。一旦迎來大促，客服的工作量真的是爆發式增長。

最后一個重要的角色是財務，退款發生時，資金逆向流動，那財務會充當兩個角色，第一是要給用戶打款，第二是要把這中間的賬給記清楚。對虛擬商品來說，有時候錢不單單是公司的，也是版權方或者IP的，比如一個老師的課程，我們要給老師分潤，那一旦這門課產生了退款，錢該怎么算，這都是需要財務去考慮的地方。

所以為什么要做退款流程優化，因為它優化了用戶體驗，節約了客服時間，讓財務流程更清晰和自動化。

但切記，從資源投入角度來說，做到80分，用50%的資源投入，解決80%的退款場景，帶來120%的實際收入，這才是最明智的投資方式。這時候就需要我們去看過去一段時間的退款數據，什么sku、什么系統的退款是主要的，根據這個來決定做到80分的需求范圍。

02

第二個坑：希望產品主導一切。

作為產品經理，如果我沒有接過100個以上用戶的退款訴求，如果我沒有整理過100個用戶以上的退款報表，那我是沒有資格去以自己的邏輯去主導這個需求的。

為什么我做了兩個月的調研，因為我需要不斷地跟客服和財務去聊，聊他們之前手動處理時都是怎么做的，為什么要這么做，了解清楚了這些，才能知道可以將哪些流程產品化。

在做這個需求之前，我作為產品經理，會自然而然地認為，最好的方式就是不需要克服介入，讓系統之前完成跟用戶的交互。例如用戶在app的訂單頁面可以一鍵申請退款，然后錢退到賬戶，整個過程中完全不需要客服的介入。

但這幾乎不現實。對于實物商品來說，需要商品先寄回，評估受損程度來判定能不能退。那對于虛擬商品來說，自然沒有受損這一說，但虛擬商品的權益回收我不建議根據系統邏輯來代替客服的處理原則。

我跟客服聊過，他們現在處理退款的原則，都是在跟大量用戶溝通的基礎上得到的，你去看這些處理原則的時候，會發現根本不是100%的理工男邏輯，例如一門課我聽了50%的課程，就退50%的費用，客服一般不是這樣處理的。

為什么？因為這樣反而增加了他們的成本，如果不想增加他們的成本，那就會增加系統的成本。所以呀，成本！一切都關乎成本！

所以我的處理原則是，完全繼承客服之前的處理邏輯，尊重他們的專業程度，只是把這樣的邏輯代碼化。另一方面，客服真正的痛點是資金原路返回，所以產品經理應該將這個小功能做到100分。

而對財務來說，最核心的訴求是把賬算清楚。一個退款賬單，最核心的大概有這么幾個要素：用戶id、訂單id、訂單金額、應退金額、實退金額、支付時間、退款時間。

任何支持退款的訂單，都應該將這幾個要素記清楚，記準。這幾個核心要素中，最關鍵的又是應退金額和實退金額。

應退金額，代表的是公司理論上應該付出的成本，比如會期還剩一半的時候用戶要退款，那應退金額就是訂單總價的一半。

實退金額，代表的是公司實際退回給用戶的錢，是實際付出成本。有時候客服根據用戶的情緒，多做一些安撫，或者根據用戶的等級做一些臨時操作，都有可能導致根據邏輯算出來的應退金額無法滿足一個退款工單的處理。

為了把賬算清楚，這兩個金額就必須要分開處理。

03

第三個坑：輕易就去動訂單。

如果你不是做訂單系統的產品，然后你去做退款功能了，這時候你可能會說，我在訂單里增加一個退款的屬性好不好，在這個屬性里去記錄退款過程中的各種狀態。

千萬不要！為什么，因為對于大多數公司來說，當有第一筆交易發生時，就很可能會有訂單系統（除非用excel手動記賬）。訂單相關的數據，在各種跟錢相關的報表里都有應用。去改訂單的數據，這才是踩了一個大坑，如果你不是那個做訂單的產品經理，你很可能不會知道自己會少考慮什么情況。

我的做法是：數據解耦、狀態關聯。

數據解耦，說的是退款訂單要單獨管理。打個比方，如果說訂單系統是一個大宇宙，那么退款相關的訂單就是一個獨立的小宇宙，兩個宇宙之間通過狀態的映射來連接。

用戶無論是在平臺申請退款，還是在第三方申請退款，相關的訂單都會進入到退款流。退款流包括權益的流轉、訂單狀態的流轉、資金的流轉等，這些流轉是獨立的，他們的數據不會影響原先訂單系統里的數據。

所以我在后臺新增了一個菜單去管理退款流中的所有訂單，完全不去動原來的訂單系統。

另一方面，對于每一個退款訂單，都會有一個退款狀態，這個狀態描述了一個訂單在退款流中的關鍵節點：

• 發起退款：用戶正式向平臺發起退款，以客服在后臺完成操作為觸發節點。
• 退款到賬中：平臺完成權益回收，觸發資金回退流。
• 退款完成：資金通過原支付渠道回到用戶賬戶，需要有各支付渠道關于退款成功的回執。
• 退款撤銷：退款流中的逆向流程，以客服操作為觸發。
• 退款失?。?/strong>獲取支付渠道退款成功的回執失敗，用戶沒有收到錢。