01 退貨退款整體流程

最近加班，主要在趕工處理售後系統退款和退貨需求。按照公司業務場景，小Q總結了退款退貨的觸發場景主要分為兩類：

一、客戶線上發起申請，平台審批；

二、客戶聯系客服，由客服代為從後台發起申請。

同時，由于公司業務同時存在自營平台和三方POP商家兩種業務模式，以及在線支付和貨到付款兩種支付方式的訂單，小Q總結并梳理出整體業務場景藍圖：

▲ 退貨退款場景羅列

02 退貨退款系統流程詳解

根據退貨退款觸發的時機不同，小Q将退貨退款流程分為訂單發貨前、訂單發貨後、訂單簽收後3大節點，單獨設計系統流程。

1.訂單發貨前的退貨退款流程

用戶下單以後，在實物訂單未出庫之前，用戶尚未拿到實物商品，訂單也還處于正向履約流程中，還不涉及到逆向物流場景。在此場景下發起的退貨退款，在系統層面操作為：

一、取消訂單；二、退款。

根據訂單所處的履約節點，系統處理邏輯再細分為3個子節點：

（1）訂單未支付：特指貨到付款訂單已提交，和在線支付訂單已提交未付款的場景。 此時由于尚未支付，所以隻需要取消訂單即可，不涉及退款；

（2）訂單已付款，但尚未下發庫房/商家：此時訂單還在中台訂單履約系統中，實物尚在庫房未動。在系統層面的處理為：

①取消訂單；

②在線支付的訂單，由系統或者人工生成退款單，審核通過後将訂單實付金額原路退回用戶支付賬戶（貨到付款的訂單未付款，無需退款）。

（3）訂單已下發庫房：此時訂單已産生波次進行發貨生産了，所以退款之前需确保實物商品尚未真實發出，将商品還貨上架。為防止系統信息流轉過程中存在滞後性，故在取消訂單前，最好核實一下庫房/商家實物的真實情況。在系統層面的處理為：

①嘗試取消訂單，若商品未發貨，則可取消成功。否則取消失敗，退款失敗；

②庫房将已取消訂單攔截并還貨上架；

③在線支付訂單，生成退款單，審核通過後原路退款至用戶支付賬戶。

▲ 訂單發貨前的取消及退款流程

2.訂單拒收的退貨退款流程

訂單發貨以後，實物已經在運輸途中，但用戶尚未簽收，此時，若用戶拒絕簽收，則産生了拒收。貨到付款的訂單，拒收時并未收費，也無需退款。

系統處理邏輯為：

（1）客服核實拒收原因，若用戶還想繼續要，則聯系物流公司對包裹進行再投，正常簽收訂單。此過程仍為訂單正向流程，未涉及售後流程。

（2）若協商同意退貨，則由客服發起一個退貨申請下發至庫房（自營業務）或者商家端（三方POP商家業務），等待包裹被物流送回以後，核實确認無誤後，将在線支付訂單原路退款，貨到付款訂單因尚未收款，無需退款。

此處需要說明的是，自營平台訂單，一般在庫房操作WMS系統，退貨入庫狀态可與上遊系統實時互通，故在庫房退貨入庫以後可自動觸發退款；而商家系統最好由商家明确确認收到實物以後（多了一步商家确認的動作），再觸發退款。

平台退款以後，與商家進行結算訂單應收時需排除已退款訂單。

▲ 訂單拒收退貨及退款流程

3.訂單簽收後的退貨退款流程

訂單簽收以後發起的退款，與簽收前主要有兩點不同：

（1）貨到付款訂單此時已收款，所以涉及到訂單退款；

（2）簽收前的退貨都是整單維度，簽收後可支持部分退貨。

系統處理流程為：

（1）用戶或客服發起退貨申請；

（2）平台或商家審核退貨申請，同意後，用戶将包裹寄回。若為自營平台訂單，隻需要平台審核通過即可寄回包裹；若為商家訂單，還需商家審核同意。

（3）庫房/商家收到寄回包裹後，生成退款單，按照約定路徑将貨款退回用戶賬戶。原則上要求按原路返回，但部分為現金支付的貨到付款訂單，或者其它情況，可以協商其它線上退回路徑。

▲ 訂單簽收後的退貨退款流程

03 訂單、退貨單與退款單

由于1張訂單可能會産生多次退貨，每次退貨會生成1張退貨單。同時，1張訂單也有可能觸發多次退款。所以，小Q将退貨單、退款單單獨設計，與訂單庫獨立存在、相輔相成。

退貨單和退款單是怎樣的關系呢？ 小Q調研完一圈下來發現，并不是每一張退貨單都會生成退款單，更不是每一張退款單都會有退貨單，就像并不是每一滴牛奶都叫xx蘇一樣，嘿嘿~例如貨到付款的訂單退貨，就隻會有退貨單，不需要退款單；有些情況下，客服會針對某些訂單隻為客戶退款，而無需退貨，例如承諾超時賠付等。所以，退貨單和退款單隻有在常規退貨退款場景下才是一對一的關系，在特定的場景下并不具備強關聯關系。

▲ 訂單、退貨單與退款單

根據退貨單的操作狀态，小Q将退貨單設計為待審核、待入庫、入庫完成、駁回 4個狀态：

①待審核：在訂單逆向過程中，客戶或客服新發起退貨申請，系統生成退貨單的初始狀态；

②待入庫：退貨單審核通過，同意退貨的狀态。此時，等待客戶包裹寄回；

③入庫完成：包裹寄回倉庫，庫房已完成入庫；

④駁回：退貨申請被駁回的狀态。

▲ 退貨單狀态圖

按照退款節點，退款單的狀态設計為待審核、待退款、退款完成、駁回 4個狀态：

①待審核：退款申請剛提交的初始狀态；

②待退款：退款單由财務審核通過，同意退款；

③退款完成：由财務手工或系統自動觸發退款，退款成功後的狀态；

④駁回：退款申請被駁回的狀态。

▲ 退款單狀态圖

04 退款金額計算

訂單簽收前的取消和拒收引起的退款，都是整單退貨（全退）。而簽收以後的退貨，經常由于部分商品問題，所以會存在部分退貨（半退）。如果在訂單下單時使用了優惠券、抵扣金、積分等，也需要考慮退回用戶賬戶。

全退情況的退款處理比較簡單，小Q給出的解決方案為：①按訂單實付總金額退款；②未過期的優惠券、積分等優惠信息原路返回。

半退情況下的退款處理相對複雜，小Q向阿輝、老A等電商老鐵們逐個請教和讨論後，總結如下：

①若無組合優惠信息，按商品實付金額退款；

②若使用了組合優惠信息（如整單滿減券），有兩種主流處理方式：

a.優惠按照商品金額比例分攤，按照分攤後的實付金額退款；

b.退款時需考慮剩餘商品是否滿足優惠，重算優惠後退款。

為加強理解，舉例說明：

a.優惠按照商品金額比例分攤，按照分攤後的實付金額退款。(參考：淘寶)

舉例：某用戶購買商品A\B\C各1個，使用了滿150減20的優惠券，按比例分攤後的實付金額如下:

如上，若退A，則退款90元；退B，則退款54元；退C，則退款46元。

此規則簡單易實現，但存在湊單刷優惠券的風險。存在用戶為了湊單使用優惠券，簽收後又将其它不需要的SKU退貨的情況。一般規避方案為：①用戶責任導緻的退貨運費由用戶承擔；②惡意刷優惠券退貨的行為，将用戶做降級處理、或加入黑名單。

b.退款時重新計算優惠，若剩餘SKU繼續滿足優惠，則按原價退款；否則扣除優惠後再退款，若扣退款金額尚不夠優惠，則不能單獨退此商品。參考：京東

舉例1：某用戶購買商品A\B\C各1個，使用了滿150減20的優惠券，實付金額如下：

①若退C，則剩餘A和B，原金額合計160，仍然滿足優惠條件，故退款40元；

②若退B，則剩餘A和C，原金額合計140，不再滿足優惠條件，需扣除優惠，故退款金額=60–20=40元。

舉例2：某用戶購買商品A\B各1個，使用了滿100減50的優惠券，實付金額如下：

①若退A，剩餘B（原金額為40），不再滿足優惠條件，需扣除優惠，可退款金額=60-50=10元

②若退B，則剩餘A（原金額為60），不再滿足優惠條件，需扣除優惠，但因B的原金額（40）小于已優惠金額（50），故不允許單獨退B。

此規則可預防刷優惠券的情況，但規則較複雜，解釋成本和系統實現成本較大。

以上兩種方案，小Q更傾向于方案a。因為在醫藥行業，藥品一經售出，原則上不退不換，所以本來退貨就是個低概率事件，加上用藥的特殊性，為了套優惠券而湊單再退貨的概率就更低了。系統設計時也遵循大道至簡原則，平台在發放促銷優惠時，隻要保證整體上成本能cover住，系統也就無需設計的過于複雜了。

對于以項目驅動的加班，小Q從不排斥。項目趕工期間，為了在計劃時間内有成果産出，無數次自願加班，趕最後一班地鐵到家後繼續挑燈夜戰；也曾經連續奮戰24小時，到賓館短暫休息後又自覺奔赴項目現場，隻會擔心新上線項目有所閃失；更有連續一個月奮戰到淩晨三點，隻為在别人下班期間騰出時間做系統聯調。那些日子很苦，但回憶起來都是甜，心之所向，自驅而動，無怨也無悔。

當996的矛盾在網絡上升級到ICU高度的時候，已然成了企業和員工之間的階級矛盾，正反方各執己見、争鋒相對。對于996，小Q有自己的理解，相比從上往下灌輸的政策和自下而上應對的對策，小Q更加崇尚有意義的自驅式價值觀，而不希望制度淪為一種自欺欺人惺惺作态式的企業與員工博弈的戲台。

縱觀曆史，一切以反人性為出發點的制度都是阻礙曆史前行的絆腳石，終将被曆史所淘汰。 9也好，6也罷，上下班時間本該隻是自我價值實現的一條記錄，淩晨4點的街頭也不應該成為朋友圈炫耀的資本。當然，價值的體現因人而異，有人為了名，有人為了利，有人為了自我提升，也有人為了自我實現。最理想的做法是企業了解每位員工訴求，給予他們想要的，激發每個人的潛能，不斷提升員工做事的效率和投入度。

作者：木筆作畫 産品一俗生，耕于供應鍊，偶有綿薄書，奮筆同君閱。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!