各位勞動人民節(jié)日快樂！難得的4天小長假，希望各位朋友玩的開心、吃的放心、睡的安心、躺著順心，以最飽滿的熱情恢復元氣，開啟2019的下一個雞血奮斗模式~

「 以下故事情節(jié)及人物均為作者杜撰，若有雷同，純屬巧合：

     小Q：某醫(yī)藥互聯網公司后臺產品經理，著手規(guī)劃重構公司的供應鏈及電商后臺相關系統」

     22:30的地鐵上，小Q加完班趕上末班車回家，相比早晚高峰的擁擠，此時地鐵里相對松散好多，但也不是人人有座。一群20出頭的安檢員們站在門口談笑著討論著下地鐵后去哪里嗨翻下半場，于他們而言，下班了脫下制服，才意味著一天生活的開始。不遠處坐著兩名年輕的程序猿正在激烈討論著白天遇到的一個bug的解決方案，意猶未盡，似乎不是因為趕末班車，還能繼續(xù)干兩個小時；對面的一位中年大哥頭向后靠著車廂閉目養(yǎng)神，面容憔悴，已經花白而稀疏的發(fā)絲凌亂的耷拉在“地中?！鄙?，一看就是長期加班導致的亞健康狀態(tài)；身旁一位30出頭的程序員快速跟老婆孩子視頻聊完幾句后，又從包里拿出電腦開始調試，貌似在為某個緊急項目爭分奪秒......

    也許末班車就是專為這么一幫互聯網人準備的加班福利吧。今年同時段加班的人明顯比去年多了不少。想起自己一位大廠的哥們跟自己聊起的，公司近期要裁員，人人自危，領導要求996，但到點了也沒人走，有人寧愿每天干耗到凌晨，下班了就在公司附近住賓館也不愿提前回家，就怕因為考勤排名靠后成為被裁的對象，結果惡性循環(huán)，加班越來越多，效率反倒越來越低。小Q苦笑著搖搖頭，在資本寒冬籠罩下的互聯網行業(yè)，覆巢之下，焉有完卵？

01 退貨退款整體流程

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

    一、客戶線上發(fā)起申請，平臺審批；

    二、客戶聯系客服，由客服代為從后臺發(fā)起申請。

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

▲  退貨退款場景羅列

02 退貨退款系統流程詳解

    根據退貨退款觸發(fā)的時機不同，小Q將退貨退款流程分為訂單發(fā)貨前、訂單發(fā)貨后、訂單簽收后3大節(jié)點，單獨設計系統流程。

1.訂單發(fā)貨前的退貨退款流程

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

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

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

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

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

            ①取消訂單；

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

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

            ①嘗試取消訂單，若商品未發(fā)貨，則可取消成功。否則取消失敗，退款失?。?/p>

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

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

▲  訂單發(fā)貨前的取消及退款流程

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

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

    系統處理邏輯為：

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

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

    此處需要說明的是，自營平臺訂單，一般在庫房操作WMS系統，退貨入庫狀態(tài)可與上游系統實時互通，故在庫房退貨入庫以后可自動觸發(fā)退款；而商家系統最好由商家明確確認收到實物以后（多了一步商家確認的動作），再觸發(fā)退款。

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

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

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

        訂單簽收以后發(fā)起的退款，與簽收前主要有兩點不同：

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

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

        系統處理流程為：

         （1）用戶或客服發(fā)起退貨申請；

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

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

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

03 訂單、退貨單與退款單

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

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

▲  訂單、退貨單與退款單

根據退貨單的操作狀態(tài)，小Q將退貨單設計為待審核、待入庫、入庫完成、駁回 4個狀態(tài)：

①待審核：在訂單逆向過程中，客戶或客服新發(fā)起退貨申請，系統生成退貨單的初始狀態(tài)；

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

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

④駁回：退貨申請被駁回的狀態(tài)。

▲  退貨單狀態(tài)圖

按照退款節(jié)點，退款單的狀態(tài)設計為待審核、待退款、退款完成、駁回 4個狀態(tài)：

①待審核：退款申請剛提交的初始狀態(tài)；

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

③退款完成：由財務手工或系統自動觸發(fā)退款，退款成功后的狀態(tài)；

④駁回：退款申請被駁回的狀態(tài)。

▲  退款單狀態(tài)圖

04 退款金額計算

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

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

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

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

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

        a.優(yōu)惠按照商品金額比例分攤，按照分攤后的實付金額退款；

        b.退款時需考慮剩余商品是否滿足優(yōu)惠，重算優(yōu)惠后退款。

    為加強理解，舉例說明：

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

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

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

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

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

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

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

②若退B，則剩余A和C，原金額合計140，不再滿足優(yōu)惠條件，需扣除優(yōu)惠，故退款金額=6020=40元。

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

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

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

    此規(guī)則可預防刷優(yōu)惠券的情況，但規(guī)則較復雜，解釋成本和系統實現成本較大。

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

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

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

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

    倚天照?；o數，流水高山心自知。無論企業(yè)還是員工，在喧囂浮躁中，能夠腳踏實地，守得自己心中的一方凈土，不隨波逐流，便是這紛擾社會中的一片桃園，終有一日，會迎得滿園桃花開……