起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識【干貨】電商業務退貨、退款泳道圖與狀態操作框架分享
今天給大家分享一下電商后臺退款邏輯的泳道圖與狀態操作框架，雖然這并非最先進的業務處理邏輯，但還是希望可以給初入電商后臺的產品經理一些啟發。以下流程還可繼續進行優化。
在電商平臺中，訂單、退貨、退款等相關業務流程，是初入電商后臺的產品最難攻克的環節，流程功能基本靠口口相傳，師傅傳徒弟的形式在這里表現的淋漓盡致。當然不乏有一些大牛剛剛出世就顛覆了現有的邏輯。
一、僅退款-業務
電商退款流程中有一項業務為“僅退款”，顧名思義，退錢不退貨。
僅退款環節中，用戶只需要在前臺發起僅退款流程申請，觸發僅退款審核流程后，此時前后臺開始進行審核線路流轉。
在僅退款的泳道圖中，角色方面規劃了三方協商流程，用戶先行與供應商進行協商，協商內容主要是退款申請與退款金額兩方面，供應商也可進行拒絕的操作。用戶與供應商之間的協商發起與拒絕次數不做限定。
為了保證用戶與供應商各方的權益，避免哪一方出現無聊的行為，此時平臺角色其實是作為一種最高判決機構的形式存在的，流程中用戶與供應商均可以發起平臺介入爭議判決的流程。
平臺行駛的判決權利是至高無上的，一旦平臺認為爭議之中過錯方應承擔相應責任時，即可改變當前流程所需的流轉方向，對用戶與供應商之間都可進行退款關閉與退款判決的決定。
退款關閉后，當前訂單將再也無法由任何入口觸發退款發起的環節。
僅退款泳道圖：
二、退貨退款-業務
電商退款流程中另一項業務為“退貨退款”，顧名思義，一手交錢一手交貨。
退貨退款環節中，用戶只需要在前臺發起退貨退款流程申請，觸發審核流程后，此時前后臺開始進行審核線路流轉。
退貨退款與僅退款流的角色、角色職能基本相同，唯一不同的在于流程上較僅退款多了用戶發貨與供應商收貨的流程
審核流程中，供應商在收貨環節中增加了一次拒絕用戶申請的機會，平臺介入機會也從僅退款的1次，增加到了2次。
這源于退貨退款流程中包含兩種元素：退貨退款的申請流程與執行流程。
退貨退款泳道圖：
三、售中退款、售后退款
- 售中退款可分為：未發貨退款（僅退款），已發貨退款（僅退款、退貨退款）
- 售后退款可分為：已發貨退款（僅退款、售后退款）
從銷售角度來看，當前流程是分為售中與售后退款兩種環節；兩種環節中，再次細分為未發貨、已發貨退款形式，僅退款與退貨退款是退款的兩種形式。以及具體操作所對應狀態，請參考下圖：
退貨退款狀態框架：
作者：王榮，微信號公眾號：PM_magic，9年互聯網后臺產品設計經驗，主導電商后臺核心業務搭建，流程、邏輯設計，多系統設計經驗。
本文由 @王榮 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CCO協議
主干流程是有的，但描述過于粗狂，不夠深入。
挺好
你好，為什么售后退款任何操作都不改變訂單狀態，難道不是退款成功后，訂單狀態變為交易關閉嗎
同問，我也是很疑惑。
同問這個問題，我竟然還給自己強行解釋了一波，哈哈~
一般來說，訂單狀態和售后單狀態相互獨立；因為會存在一個訂單中存在多個商品，只退其中一部分或只存在一個商品有多個購買數量，只退其中一部分的情況；如果售后狀態能影響訂單狀態，那多商品這種情況就需要做判斷，反而搞復雜了
想明白了，謝謝作者的回復~
售后退款情況復雜，應客戶與商家進行協商處理，如果貨物破損嚴重，協商全部退款且不退貨，訂單沒有必要關閉，不管全部退款或是部分退款，訂單未產生相應退貨，用戶所購商品已到達用戶手中，又怎能判斷為訂單關閉呢？
未發貨退款時部分退款又怎么處理呢？
未發貨訂單，不存在“部分退款”場景
肯定會存在啊，比如我一個訂單買了10個商品，都還沒發貨的時候，突然某一件不想要了，就退掉一件
強行按照商品梳理拆開某一個訂單，更何況你不付款商家是不會發貨的
退款單未處理完時，商家點發貨時會提示：訂單中部分商品買家已經申請退款，繼續發貨會關閉退款申請，是否要繼續發貨？如果商家仍然發貨了，那退款單狀態為退款關閉，訂單變為待收貨狀態。
如果商家已經退款給買家了，退款單狀態為退款成功。訂單繼續停留在待發貨狀態，商家發其他未退款的商品。發貨后，訂單為待收貨狀態。
贊！一點小問題：
平臺拒絕申請–>退貨關閉，用戶確認收貨–>退貨關閉，這兩種情況都是平臺的判斷結果是平臺行為，那么“退貨關閉”是不是放在平臺泳道比較合理呢？
整體功能流程清晰，學習了，感謝分享！
流程圖多個交叉也可以的？
待發貨的訂單申請退款，平臺最終拒絕退款申請后，之后的流程如何處理？是繼續走商家發貨流程還是直接訂單關閉？
走平臺介入流程，需要人工處理了
正常來說，平臺不會拒絕，因為沒有發貨退款很正常，拒絕會得罪用戶。
但是平臺如果真的拒絕了（比如定制類產品），那就是退款單關閉了，訂單繼續停留在待發貨狀態，商家發貨，這樣很可能得不償失，用戶會給差評啥的。
同時退款審批單是不是也應該有單獨的狀態：待審批、審批中、審批完成（包括同意/不同意）
因為可能不止一道審批；
希望能夠解答一下 ??
所以退款單的狀態一共就是有：待退款，退款中，退款完成，退款關閉四個狀態
那如果涉及到退款審批的話，退款單的狀態是不是應該變為：待退款 、待審批、退款中、退款完成、退款關閉五個狀態呢？
很有含金量的干貨
請問怎樣理解【系統觸發】？
系統所觸發的內容，為退貨退款中的正向流程，比如供應商超時未處理，那么為了用戶體驗著想，縮短供應商的審核周期，系統默認認為供應商同意退款操作（或者理解為供應商放棄使用權利）。
剛才看了作者之前的解釋，才發現這里的“確認收貨”與我的理解不同，是指客戶只有在收到貨物后再能發起退款、退貨流程，我覺得這個環節應該發生在退款流程之前，而不是流程之中，這回造成歧義。
而且我覺得應該存在商家確認商品在于客戶對款的流程。
用戶有兩種退貨退款方式，第一個是售中退款，第二個是售后退款，第一種方式不需要進行確認收貨就可以發起流程，確認收貨只是作為用戶在第一中情況中主動終止退貨退款的一種形式。第二種方式是以確認收貨后發起的退款方式。
運營商確認收貨又退款失敗，這貨要怎么處理？
怎么處理？
有一點疑問，在“僅退款”、“退貨退款”兩個泳道圖的“用戶”泳道中，“填寫申請退款金額、理由”直接與“確認收貨”相連接，個人覺得這個“確認收貨”應該出現在供應商泳道中，情景應該是在供應商收貨確認后再給與用戶退款，缺少相應環節。
這只是說明在用戶填寫協商退款金額時，如果進行確認收貨操作，那么將終止這次的退款流程。
很基礎，是干貨
售中售后狀態看懵了……，學習了
專業的
不錯 學習到了
同問，確認收貨-關閉退款這個流程是什么意思呢
在用戶成功發起申請退貨退款流程后，流程將進行退貨退款流轉，同時，在流程發起后，用戶同樣具備對當前訂單進行收貨的功能。一旦用戶在當前流程中就行確認收貨，也就意味著，用戶已經對貨物不存在爭議了，也許這之間用戶與供應商協商了些什么，這方面我們不去追究。
確認收貨功能，是用戶關閉退款申請的一種方式。
你好，我有幾個問題，請教一下。
1、用戶是在平臺購買的，為什么申請退款要供應商審核呢？不是應該直接到平臺嗎？然后由平臺和供應商溝通。
2、同意退款之后，錢退給平臺還是退給供應商了？正常應該是平臺
3、用戶在平臺購買，但是退款時卻要供應商來審核，如果拒絕了，那用戶體驗會很差，然后再去找平臺，平臺再和供應商溝通，無形中多了一步用戶和供應商之間的聯系。（和1有點像的問題）
4、我理解的只有買的商品有問題，需要售后處理才會有供應商的人員介入。
我的理解是：用戶退貨退款，先告知供應商并進行協商，協商無果后再通知平臺介入，可能跟現在的一些電商售后處理不一樣了
你的理解完全正確，這取決于電商應用的是哪一種模式。
嗯，一般退貨都得先經過供應商同意，因為要審核商品是否完好無缺，但是淘寶有極速退款，就是只要申請退款，錢立馬到賬
這個流程所歸屬的電商模式為供應商入住的店鋪形式，所以用戶是與供應商直接溝通，平臺在一定程度下僅僅作為交易場所存在
嗯，明白了。自營和三方入駐的兩種流程。那前端展現其實要對用戶提醒的清楚。
兩種形式在前端的展現是有絕對性區別的，而且在QA中也會有相應體現。用戶業務通道環節中，也會有明確展示。這都是用戶體驗的功底。
流程扭轉方面，后臺是重中之重。
能否加你好友？？？
問個問題，為啥已經是退款流程了，還要有：確認收獲》關閉退款的流程呢？
因為有可能用戶和供應商達成了退款協議，達成了“不退貨僅退款”的條件，所以這種時候，用戶是可以點擊“確認收貨”的
清楚了，謝謝!