眾所周知，跨過成長期，B2C就是血拼使用者體驗，除了價效比，使用者介面，支付便利，到貨速度與質量，包裝等正向體驗外，還有RMA這個反向體驗的集大成者。相比正向體驗的易於感知和易於改進，RMA則複雜的多，絕大部分賣貨導向的B2C很難把SOP做細：雖然事實上，RMA不流暢造成的老客戶流失幾近4成。
我想，網購的使用者大都經歷過如下場景：
1，剛剛提交的訂單尺碼弄錯了，要修改訂單，客服回答，訂單已經確認了，沒法改了，要麼取消訂單重下。於是，算了，懶得搞了。
2，參加促銷活動的訂單，客服電話通知缺貨，建議訂單全部退款。可是，這個訂單參加的活動很優惠，取消太虧了；於是客服又建議換貨，不過只能換價格一樣的商品，下單缺貨本來就是商家的錯，還這麼多條條框框，真不爽。
3，糾結了半天還是決定退款算了，結果客服非要退到銀行卡（信用卡還不行），還得告知是XX支行，暈，好煩。最後等了5天，錢才退回來，中間還催了2次。
4，貨到付款買了2件衣服，結果發現其中一件有汙漬，要求退貨，結果客服說不行，必須2件衣服一起退，退就退了吧，結果10天也沒收到錢，打400電話去催，客服的回覆是：快遞公司還沒回款，財務制度規定回了款才能退款。NND，你和快遞公司的事，幹我啥事啊。
同樣，B2C運營和客服的同事也經常為下列事宜頭疼不已：
1，財務退款流程太長，5天到賬算是短的，COD（易觀百科：COD）的10天都很正常。財務堅持收支兩條線，不能坐支（也就是原路退款），雖然這樣能節約0.5-0.7%，或者每筆1-2元的財務費用。
2，RMA庫沒有清晰的庫存，退回來的商品與訂單也無法一一對應，有多少可以重新上架，有多少可以折讓銷售，還有多少需要銷燬，統統一筆糊塗賬，更要命的是，聽說倉庫有人在靠RMA庫發小財。
3，從使用者體驗出發，當然是只要貨沒出倉，就應該允許改單。可惜，WMS（易觀百科：WMS）和訂單處理系統不是資料實時交換的，做不到。
顯然，一個合格的RMA，至少應該做到如下幾點：
1，正庫商品有明確的出庫狀態和分類庫存，如可用庫存，訂單庫存，財務庫存，佔用庫存。
2，所有子系統（訂單處理，RMA，財務等）的資料均實時交換，確保最快的反應速度。
3，只要貨未出倉，就允許改單，無論是換貨或退貨，最終都是一個包裹出庫。
4，如果是換貨，無論比原金額高，還是原金額低，或者相等，系統都應該能支援。
5，RMA庫有清晰的庫存，與訂單號一一對應的原始記錄。
6，系統自動核對外部系統（如支付寶，財付通，快遞COD）的退款記錄（主要通過訂單號作為主鍵），降低人工核對的工作量和財務人員的道德風險。
7，每個RMA的case有唯一的ID，並通過不同的單據（如異常處理單，RMA申請單，RMA處理單，退款單等）依次流轉，系統能夠準確記錄每張單據的處理人和處理時間，以便通過KPI考核確保跨部門的退款流程能夠3個工作日內到賬。
當然，上門退換貨，半退拒收，交換出庫這種高難度動作，沒有自有物流團隊是玩不起來的。對目前的大多數B2C不適用，不在討論之列。
按照這個要求，結構化的去看RMA的應用場景，其實一個標準的樹狀圖：
之後，每種情況還需要分成四種場景：全退，全換，半退，半換。好的RMA，理論上說，是應該支援這全部24種情況的。從系統設計上說，就是流程要儘可能標準化，同一個表單在系統的判斷邏輯下支援更多甚至全部場景，並且可記錄，可追溯。由於和其他系統對接，開發量相當大，在大的電商公司如新蛋，RMA系統甚至都有一個單獨的team在開發。
逐一解釋24種場景實在是太羅嗦了，直接上圖吧，做過B2C專案或者運營的同學仔細看是完全可以看得懂的。
最後，只補充一句，RMA並不神祕，雖然複雜但並不算很難。不過，如果不放在公司戰略層面作為核心使用者體驗來對待，就很難得到足夠的資源去持續優化。筆者曾聽很多朋友抱怨公司的RMA不好用，但同樣很少聽到有在積極改進，point就在這裡。