售後類型基本可以分為四種情況：僅退款（未收到貨）、退貨退款（已收到貨）、換貨、補寄。這篇文章僅討論退貨退款的情況，我將從申請售後、退貨退款單狀態與操作、退貨分支流程、涉及其他版塊等4個維度來講解。
首先，申請售後時需要選擇申請原因、填寫問題描述、上傳憑證圖片等三項操作，提交之後就會生成一條售後單記錄，然後進入後臺，待工作人員進行操作。
這其中最重要的就是申請原因。因為電商法規定「買家在籤收商品之日起七天內（按照物流籤收後的第二天零時起計算時間，滿168小時為7天）發起申請售後退換貨」，當用戶選擇申請原因為「七天無理由退換貨」時，用戶的主動權將會大得多，只要不是用戶自身的問題，如造成商品損壞影響二次銷售，商家是必須同意的。但是是否支持七天無理由退換貨是跟著商品走的，有些商品支持有些不支持，所以在添加商品時需要選擇。
由於我們公司做不到像淘寶的自有物流系統能及時抓取籤收信息反饋，就給了用戶10天（預計3天物流配送+7天無理由退貨），自發貨10天之後用戶將不能選擇該申請理由。
審核中（修改申請、撤銷申請）、待買家發貨（填寫物流單號、撤銷申請）、待商家收貨（無）、已完成（無）、拒絕中（修改申請、撤銷申請）、已關閉（無）
待審核（通過、拒絕）、待買家發貨（無）、待商家收貨（確認收貨、查看物流）、待商家退款（確認退款、查看物流）、已完成（查看物流）、已拒絕（無）、已關閉（無）
如上圖，用戶端和後臺的退貨單狀態除了「待商家退款「都能一一對上（不像訂單那樣複雜，因為一個售後單只會對應一個商品），而用戶端省略「待商家退款「的目的主要是從用戶考慮，一是簡少用戶的認知成本，二是緩解用戶的焦慮。
而後臺為什麼要有這一狀態是因為對商家來說，收貨是商品部幹的事，退款是財務幹的事，不同部門的權限不一樣，當然如果要做細一點，甚至可以財務有一套審批的流程（審批、打款等操作由財務和出納等角色操作），這裡不做展開。
需要說明一點，當商家點擊通過時應該出現一個確認地址彈窗，也就是商家添加的退貨地址。該彈窗的目的是為了選擇一個退貨地址發送給用戶，同時也提醒商家退貨地址是否更改了。
其實退貨的正向流程很簡單就像上圖一樣不同的操作會變更不一樣的狀態，而複雜的是各種各樣的分支流程，這時就需要系統進行限制。
首先需要明確一點的就是用戶對訂單中某一商品申請售後，系統會凍結整個訂單的金額，而該條售後單未完結之前（處於已完成或已關閉狀態），商家將不能對該筆訂單的金額申請結算。比如用戶的某個訂單內買了A商品2件和B商品，只對A商品的其中一件進行申請，此時整個訂單金額都會進行凍結（為什麼凍結整個訂單而不是僅該商品，在財務一章中會解釋）。
凍結訂單金額和加各種限制都是為了保障用戶和商家的利益。
（1）申請售後時間限制
首先，確認收貨分為用戶主動確認收貨和系統自動確認收貨，而一般自動確認收貨的時間規則我們是這樣定的，自商家發貨日起10天自動確認，比如淘寶是快遞籤收日起7天自動確認，但是淘寶有自己的物流系統，而我們做不到這一點，所以加上3天的物流時間（當然可以根據不同的商品屬性來設置不同時間）。
當確認收貨之後，再開始計算申請售後的時間，一般是15天，過了15天用戶將不能申請售後
（2）超時未處理限制
整個退貨流程需要用戶做的有兩步：
如果用戶不進行操作，一般會給到7*24小時，時間截止後將會自動關閉售後單，用戶只能重新申請。
（3）修改申請次數限制
用戶可以進行修改申請並提交的操作在「審核中」和「拒絕中」都有，但是這裡說的需要做限制是在「拒絕中」這一狀態。比如用戶被拒絕後，重複在7天時間結束之前修改申請並提交，商家也一直拒絕，那就可能會出現該筆訂單金額一直凍結中，商家無法結算。
為了防止用戶的惡意行為所以需要做一個限制，比如用戶最多只能申請3次，第3次被拒絕後只能申請平臺客服介入解決。當然，如果不加次數限制，也可以有時間限制，就是只有在可以申請售後時間內才能修改申請並提交；比如1號確認收貨，16號之前能申請售後，17號時就不能修改申請了，同時售後單自動關閉。
（4）申請售後次數限制
接著上面說的，如果用戶被拒絕後，撤銷了該退貨單，又重新申請，也有可能進入循環中，所以在申請售後這裡也需要做次數限制。
這個次數限制肯定是在申請售後時間這個大前提以內，但這樣做的目的就是防止用戶惡意提交，對商家造成騷擾，當然這個限制可加可不加。
總結一下，在申請售後這裡做的判斷有：首先判斷該訂單該商品有無進行中的售後單（包括換貨），有則不能申請；該商品如果有成功的退貨單，且之前退貨單中的申請數量小於該商品購買數量時可以申請，否則將不能；該商品的處於已關閉狀態的售後單是否小於三條，是則可以申請，大於等於三條時，只能申請平臺客服介入解決。當然這些限制都有一個大前提，該訂單處於售後時間內，超過則都不能申請。
（待審核）超時未處理：用戶提交售後單，如果商家超時未處理，比如時間限制為7*24小時，將自動審核通過，並通知管理後臺的客服人員及時聯繫商家。
待商家收貨/待商家退款）超時未處理：用戶回寄之後，此時商家該進行的操作有2步，確認收貨和確認退款，如果此時商家超時未進行操作，同樣將由管理後臺的客服人員介入，甚至可以給到客服和財務人員直接退款的權限（當然這要考慮公司章程和部門組織架構）。
當然，還可能出現的情況就是，比如用戶發回空包裹或亂填物流單號或發回的商品出現破損之類的，這時就需要商家申請客服介入的功能。
一個退換貨會涉及到的其他版塊有商家、商品、財務、營銷等，這些版塊之間可能會存在一些數據的聯動，所以需要考慮進去。當然這些版塊主要是後臺的數據，用戶端的感知並不大。
一般平臺會對每個商家有一個評分，和一套獎懲制度。
評分的目的可能更多的影響用戶端，評分高的商家下的商品出現在用戶面前的機率更大，不管是搜索結果排名更靠前還是猜你喜歡等流量入口展示。而退換貨肯定會影響評分，比如用戶申請原因選擇為「七天無理由」時可能不計入分數，而選擇為質量問題，或商家服務態度問題而不想要了，這肯定會影響該商家評分的降權。
獎懲制度更多關乎於平臺與商家的聯動，這個就要根據公司不同時間段的業務需求來制定了，比如因質量問題退貨佔比高於多少的商家，需要罰多少錢，或一些特定活動不能參加。
退貨涉及到與商品的聯動有2個維度，該商品的分數和庫存。
上面說的是商家的評分，但是每個商品肯定也會有自己的一套計分規則，這樣搜尋引擎從資料庫裡拉商品出來後才會有一個先後順序的展示。而退貨則會影響降權，這裡面的計算規則很複雜，而且也得根據公司當前的業務目的來制定，這裡不做展開。
用戶下單並支付後就會扣除該商品的庫存，成功退貨後也將還原庫存。當然也得看該商品是否被刪除或者該sku是否已刪除。
訂單中的金額信息與退貨會產生關聯的有運費、金幣抵扣、實際支付金額、結算金額。
（1）運費
首先，得判斷回寄商品的運費該由哪方承擔和是否該退用戶支付的運費，所以就得判斷是用戶自身的原因還是商品的原因（我們平臺還未介入運費險）。
有兩個方案：
個人認為，如果由系統來介入感覺好像對商家更強制一點，對用戶更有保障一點，但是賣家肯定會鑽空子，比如告知用戶不要選擇哪些申請原因，這樣反倒對用戶是一種騷擾，倒不如更開放一點，讓雙方更自由的溝通。
接下來說該多少退用戶支付的運費。先解釋一下，運費是由運費模板計算而來，且又分為按重量計算和按件數計算（先不討論按體積計算，使用的太少）。
比如按重量計算該運費模板為首重2kg，首價10元，續重1kg，續費3元；某一sku重量為0.7kg，那買1~2件需付運費10元，3~4件需付10+3元，5件需付10+3+3元，6件需付10+3+3+3元，這樣算出來的運費就是不規則的。問題就出現了，當我買6件，需付運費19元，那當我申請退貨1件，應該退多少運費，申請3件，又應該退多少。
按照運費模板的計算來退顯然不合理，有一個方案就是按平均數，比如退3件退的運費就是19/6*3元，或者固定退多少元，比如你付了10元運費只退5元，付了20元只退10元，其實都並不是那麼合理，可能我暫時未想到更合理的方案，有方案的大佬歡迎在評論區大家一起交流！
所以基於退運費金額的問題，我更偏向於上一段的第二個方案，就是賣家和用戶在線下自行協商，退多少運費由你們自行商量決定。
最後是回寄運費的問題。如果確實是商品的問題，用戶支付多少回寄運費是不知道的，而系統唯一能計算的就是根據運費模板，但是肯定也存在不準確的地方，比如商家和快遞公司談好後，付的運費比用戶付的要少。所以，最好的方案就是商家和用戶進行協商。
順帶提一句，如果平臺有滿減運費的功能，可能存在的風險就是，比如用戶買2件包郵，申請未收到貨僅退款，那就可能會對商家造成損失。所以退款的時候可以做扣除運費後再退的功能。
（2）金幣抵扣和實際支付金額
用戶可以通過我們平臺的一些途徑獲得金幣，類似京東的京東可以用作購買商品的補貼。用戶在提交訂單的時候就會把金幣按一定比例分攤到各個商品頭上，比如A、B、C三個商品售價分別為20、30、50元且分別購買2件，你有20元金幣，就可分別抵扣4、6、10元，所以當對A商品其中一件申請退貨時，將會退還你現金18元和2元的金幣。
（3）結算金額
是指平臺抽傭後商家能結算的金額，比如商品售價100，平臺抽傭5元，商家能結算95元。當用戶成功退款之後將在可結算金額中扣除這一部分結算金額。
然後說一句，為什麼售後和訂單沒有關係。如果看過之前我寫的訂單系統就知道我之前設計的是售後單和訂單之間的狀態各自獨立，互不幹涉。比如一個訂單中只有一個商品，只對這個商品發起售後時，訂單狀態發生改變，比如叫「退款中」，那這樣還說得過去；但是當一個訂單中存在多個商品或多個購買數量時，如果一部分商品發起了售後而一部分沒有發起，那就不好說了。所以最簡單的方案就是訂單和售後單狀態相互獨立。
所以，訂單的後續操作如確認收貨、評價等和售後狀態沒關係，自動確認收貨時間倒計時與該訂單中是否存在售後單也互不影響。
因為我們平臺暫未涉及優惠券，滿減（如滿200減50）等營銷功能，本篇就不做展開，主要是我還沒做過這些功能，可能對立面的一些細節想得不夠全面，反而對各位造成誤解。
以上就是我對退貨系統的解讀，如果有不合理或者其實有更好方案的地方，歡迎各位大佬指出，同時提出意見！
之前我寫過訂單系統的三篇文章，收到一些反饋，有評論說我寫得太詳細可以精簡一些，也有說我就是應該寫得這麼細別人才看得懂。我也在反思，如果僅僅是為了閱讀量可以把標題寫得唬人一點，為了點讚量可以把內容精簡一些讀起來更順暢一些。但是我寫文章的目的之前也說過，一是為了復個盤，二是為了和大家討論，發現我寫得不合理的地方。其實還有一點是我自己的感觸，才做電商的時候很懵逼也踩過很多坑，我希望儘量把這些踩過的坑都寫出來，希望能給人一點參考作用。
從0到1構建電商平臺之訂單系統（3）：處理訂單
從0到1構建電商平臺之訂單系統（2）：支付訂單
從0到1構建電商平臺之訂單系統（1）：提交訂單
本文由 @橘鑽 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。