起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識電商產品退貨退款的那些事
接《訂單系統總結》章節，上面所講的都是訂單的正向流程中的履單，逆向流程并沒有介紹，今天我們就主要說說訂單逆向流程這些事。
由于歷史原因，官網并未做訂單逆向流程，每天所有的退款都需要客服人員手動錄入系統處理，不但效率低，還容易出錯。因此這次做訂單系統規劃時（也考慮了逆向流程），主要從以下幾點介紹：
1. 訂單狀態機
逆向流程節點及其狀態確定，見圖：
總結：訂單狀態的確定，我們當時規劃的時候和研發同時開了三次會，最終確定；經過就不多說了。主要說下訂單狀態確定思路吧。
我們當時是先畫了一個訂單的主線流程圖，然后在訂單的主線流程圖每個節點開始考慮都會存在哪些狀態；最終前臺確定了這六個狀態，但后臺的訂單狀態可遠遠不止這些；基本上要比前臺的狀態多了一倍還要多；當然會有這么多狀態，也是因為交互的系統比較多導致；一般初期的電商系統這幾個狀態也夠用。
2. 退款場景
從狀態機中不難看出，退款發生的場景主要有以下幾類
- 未付款時，取消訂單；系統自動取消訂單一般會根據自身公司實際情況來決定；我們當時是因為有占存的概念，因此暫定是30分鐘
- 已付款待發貨申請：因為公司的倉庫都是自己的，可以控制；因此可以根據實際情況來做攔單，同時客服審核后可直接退款
- 已付款且已發貨申請：這塊一般公司會根據自己的規則決定是否先行退款還是是收到退貨后再退，一般業務會根據實際情況處理售后。在此，既要考慮用戶體驗，又要考慮商品退貨風險
3. 退款業務流程
其實，做后臺系統，需求調研的時候，他們也說不出個一二三，除非經驗比較深的，或許能提出一些信息點；很多時候是需要產品經理主動給出一條思路進行引導的；經過和相關部門的溝通，最終確定了業務流程，具體如圖：
用戶操作流程圖：
總結：根據不同的訂單狀態，顯示不同的退款類型入口。
一般對于退款申請，未發貨的訂單申請退款都可以整單申請退，邏輯上相對要簡單一些；如果是退款退貨，相對來說比較復雜
- A. 無各種優惠的時候 ，選擇某一商品申請退款，申請后按業務流程處理即可；
- B. 訂單有優惠的時候，選擇某一商品申請退款，則牽涉到退款金額的計算。
如：兩件商品A（20元）、B（80元），訂單共100元；提示滿90包郵；現在用戶申請退A商品，就牽涉到退款金額計算；是按比例退款，還是是按實際售價退；所有的金額計算要和相關業務部門溝通，根據實際情況來確定退款金額計算規則后執行。
4. 后臺系統交互
經過和其他系統的產品經理溝通，最終的交互圖也確定了下來。當然出具的這些流程圖需要根據公司的實際情況來設計規劃，提供的只是些可借鑒的圖
5.原型圖和PRD
根據上述的流程圖大致清楚了列表及其功能點。也就可以逐步出具原型圖和PRD了。
原型和頁面不做過多介紹，其實都是按照上述的流程圖確定頁面和功能點后，按照實際需要來出具原型視圖，畢竟對于業務來說，這些他們最直觀了解產品的初衷。
客服退款審核列表
客服退款審核詳情
財務退款詳情
總結
1. 用戶填寫的退款申請，是需要區分是退款還是是退貨的。
- 未發貨的退款—可以直接進行系統退款的
- 而退貨，是需要查詢退貨登記中是否已簽收的
- 只有已經簽收的財務才會去退款，當然，客服也可以根據實際情況來決定是否要提前給用戶退款
2. 如果公司無多個系統，退款也就不會有多個系統復雜交互；做產品最終還是要根據公司實際情況考慮，而上面的流程，僅是我工作總結得一部分。
不洗勿噴，有不正確的地方，還請同行們指證。
作者：簡之箐，微信公眾號：簡之箐，5年互聯網產品經理，曾擔任醫藥產品經理和電商產品經理，經歷主導過電商平臺的系統整合規劃。
本文由 @簡之箐 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自PEXELS，基于CC0協議
專欄作家
木北的產品成長路，微信公眾號：木北的產品成長路，人人都是產品經理專欄作家，互聯網產品經理，曾擔任醫藥產品經理和電商產品經理，經歷主導過電商平臺的系統整合規劃。
本文原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
一個訂單中同一個商品購買多個，部分數量退貨退款，這種如何處理呢，目前淘寶和京東貌似都沒做同一商品讓用戶自行填寫部分數量的退貨功能
商品發貨了，然后買家拒收，寄回來的郵費由買家承擔，應如何設置呢
你說的是什么樣的場景下發貨拒收的呢？如果是用戶下單成功后商家發貨拒收，就需要在自己的系統退款規則中去設置，是否是買家承擔運費，來扣減運費后進行退款；主要還是要看是在什么環節，什么場景下做的退款，根據實際的場景再去分析如何設置的問題！
第一張圖建議不要 用黃色背景色白色字體，這種搭配是看不清的
部分退貨部分退款怎么辦
不是有訂單狀態、退款單狀態嗎？只是有關聯關系。
可以參考我的文章
請問如果是 審核不通過 下一步操作應該是什么
有個問題想問你一下，如果一筆訂單多個商品，有一個商品在待發貨狀態下申請退款，被拒絕了，拒絕理由是已發貨；當用戶收到了貨之后，是否有入口發起退款退貨入口
根據公司的實際業務場景來決定要不要留退款退貨入口。一個是發貨中的退款，一個是售后問題；
你的實退金額是默認的還是可以更改的，如果是因為你的商品質量問題，那退回的商品的運費誰來承擔？我覺得你的后臺應該增加一個是否退運費的功能
運費能不能退和公司業務流程、制度有關。可以根據公司的實際情況來決定要不要增加運費修改的功能
流程圖搞的好復雜
有個問題，退款需要財務審批，那退款的狀態是不是應該就是：待退款、待審批、退款中、退款完成（已退款）、退款關閉 共5個狀態呢？
同時財務審批的時候審批單應該會需要的狀態是：待審批、審批中、審批完成（同意/不同意）呢？
希望解答下，這樣子是否合理？謝謝 ??
對，可以這樣設定哦?。。?/p>
請問待審批和審批中有什么區別呢？
審批如果是多級審批，可以有審批中這個狀態；如果不是，可以沒有這個狀態的。具體的你要根據自己公司的實際業務需要來決定。
好的謝謝，才看見 ??
是的，作者回答的比較正確，如果有多級審批人，是會有審批中這個狀態的。
產品小白遇到過的問題，敬請不吝賜教 ??
1，判斷庫存有無是否應該由平臺配合運營半自動化進行，且應該在買家下單之前，直接在付款之前就將交易友好中斷，
2，關于已付款待發貨狀態下退款是否需要進行審核，而是直接退款；
3，多件訂單且有運費情況下單件退貨運費是否分拆，且如果涉及到優惠券和積分是否需要分拆退還；
1. 判斷庫存買家下單會做判斷，因為有些平臺是全渠道營銷，倉庫實際庫存和系統庫存的更新時間差問題導致發貨時發現庫存不足
2. 對于已付款待發貨狀態下的退款可以根據實際業務場景不做審核，直接退款
3. 多件訂單且有運費情況下單件退貨運費會根據實際的業務來進行分拆，優惠券和積分可以分拆退還，以可以不退還的；具體要看公司業務。
拆單，部份發貨，分潤，手續費，大額，時間差異這些都要考慮
對，這些都是需要考慮的。這些點會根據公司的實際情況按公司計算實際的退款金額
1、上面好像沒有售后換貨流程。
2、上面的流程售后好像都是以訂單為單位進行售后，如果訂單內部分商品售后、多次售后，這些情況都是這么處理的。
能稍微也介紹下么，謝謝。
是的。售后的這塊沒有做過多介紹。因為每個公司的業務流程都不一樣，處理方式也會有一些差別。
至于你說的售后可以從以下幾點考慮
1. 破損補寄：客服登記補貨原因后生成工單，庫房補寄處理
2. 換貨：
錯發—兩種處理方式；
不需要將錯發貨品寄回庫房，直接客服登記生成工單，庫房補寄
用戶將錯發貨品寄回，填寫寄回快遞單號；庫房收到貨后做換貨退回入庫，庫房補寄
用戶買錯要求退貨，將換貨貨品寄回，庫房補寄，將寄回貨品做退回入庫
3. 漏發
庫房訂單貨品漏發，客服登記生成工單，庫房補寄
4. 分批發貨
一筆訂單多個貨品，部分貨品有貨，部分需要用戶等；可先將有貨貨品先行發出；無貨商品來貨后庫存更新，庫房再次發貨等
總結：售后大致這些，當然還會存在其他的情況，這里不做過多說明。如果想要更細致的了解，后期會專門出具相關文章說明。
說明：其實關于售后，最主要還是要看公司的實際業務流程，來策劃實際的售后系統功能。
狀態機很清晰，可是我現在還不分不清狀態機和流程的實際區別 ??
多看，多想，多畫，多總結，慢慢就清晰了。一個新的事物都是逐步從不清晰到清晰的
個人感覺流程就是把狀態機中描繪的東西更加細化一點，更加具體一點，具體是怎樣去操作這些步驟的~@簡之箐 是這樣嗎？
文章總體寫的方向是對的，但是有幾個地方可以進階討論下：（我就想到啥說啥了）
1.大部分中小型電商系統會將RMA放在OMS或者ERP中，而不是單獨處理，實際上RMA的處理方案是非常復雜的；
2.關于退款的金額計算方面，是比較復雜的，一般會有兩種，分攤法和反算法，前者易于理解，后者更為精，并且要考慮單個訂單多次退貨的情況；
3.訂單的處理，建議不要將退貨放在訂單狀態上，如果這樣設計，會導致在業務獨立，擴充的時候產生無法擴充的囧狀，實際訂單會發生這么集中單據，1.(前臺)訂單；2.拆單訂單(如果有拆單)；3.物流單(一般貴WMS管理)；4.售后單，建議分開處理，然后建立單據中心（這是目前金蝶和天貓的做法），來進行對外封裝。
4.退貨的情況實際上非常復雜，尤其是在做跨境或者海外的情況，會有物流中丟包，實際上這也涉及到退貨（這塊比較復雜，實際上會有多發，少發，錯發，丟件，物流退稅等很多情況），對于這塊的處理，需要同時兼顧，訂單，WMS庫存，財務賬目和ERP的整體數據。
5.另外，退貨不建議直接跟財務交互，不過文中的實際業務，看起來WMS，是沒有從ERP中獨立出來的（不知道為啥，一般電商WMS非常重要），而是RMA與WMS交互，WMS和財務或者ERP交互，這樣保證WMS與財務系統，物、錢是一直的。
6.WMS中對于退貨，實際上也是比較難處理的，因為有一些東西的價值太小，實際回收商品的金額 可能還不如一個物流的錢高（當然，這是免物流退貨的情況），所以要考慮虛擬退貨的情況；
7.WMS中對于售后這塊的處理是做逆向單，但是逆向單同時要兼顧換貨單，這塊也比較復雜；
8.另一個，不屬于本文的探討范圍，實際也可以發散考慮的，退貨翻新的問題，或者重新上架，這塊從業務上說屬于售后服務業務，但是系統處理上屬于WMS和SCM的處理范圍，要考慮RMA，WMS，SCM，ERP，訂單商品的整個交互。
分析的真好。學習了，非常感謝?。?！
第一點：分開處理是因為業務需要，現在的業務處理退款單，財務需要多個系統切換查詢，因此統一將退款單據集中最終放到財務系統處理；
第二點：退款金額的計算確實比較繁雜，需要細化
第三點：退貨狀態和訂單狀態是分開的，會生成不同的單據，可能是狀態機未表現清晰
第四點：您上面提到的少發，漏發錯發等情況，由于時間倉促，所以未做過多的描述。這塊是計劃放在售后系統中細說
第五點：我們的倉儲是和WMS系統再一起的，歷史原因，公司系統比較繁雜您提到的這些現在基本上都在ERP中，導致ERP現在運作很慢，因此在逐步往出遷
第六點：您說的這種情況，我們現在確實存在，但是目前都僅僅只是做了一個記錄統計，實際的流程并未形成閉環
第七點：非常贊同您的觀點，確實是比較復雜
第八點：退貨翻新 這應該和電商行業屬性有關，可能更集中在數碼類，電器類等；對于藥品，不存在翻新問題。
很開心能收到您的分享，學習了。非常感謝！?。?/p>
真厲害，方便留微信嗎？以后得多像您學習?。?！
沒有接觸過電商，將所有縮寫查了一遍，好厲害
?? 被各種虐出來的 不過現在想想那幾年還是值得的
非常不錯
謝謝！??！有更好方案的，歡迎指證。
對與退貨退款，庫存這塊具體是怎么處理呢？
有退貨的，收到貨物后會做退貨入庫，商品可銷售庫存增加；
嗯嗯，我在這方面還是個新人，以后多多交流~
RMA通知WMS生成逆向收貨單，倉庫收到之后做逆向入庫單，收貨和入庫匹配，增加售后好料或者壞料區庫存，然后看需不需要翻新，如果需要進SCM，翻新之后重新上架。
順便看了你上面的回復，很受教，多謝。
看過你寫的好幾篇文章了，有不少都是我目前也正遇到的問題，感謝！
??
結論呢？