接《訂單系統總結》章節，上面所講的都是訂單的正向流程中的履單，逆向流程并沒有介紹，今天我們就主要說說訂單逆向流程這些事。

由于歷史原因，官網并未做訂單逆向流程，每天所有的退款都需要客服人員手動錄入系統處理，不但效率低，還容易出錯。因此這次做訂單系統規劃時（也考慮了逆向流程），主要從以下幾點介紹：

1. 訂單狀態機

逆向流程節點及其狀態確定，見圖：

總結：訂單狀態的確定，我們當時規劃的時候和研發同時開了三次會，最終確定；經過就不多說了。主要說下訂單狀態確定思路吧。

我們當時是先畫了一個訂單的主線流程圖，然后在訂單的主線流程圖每個節點開始考慮都會存在哪些狀態；最終前臺確定了這六個狀態，但后臺的訂單狀態可遠遠不止這些；基本上要比前臺的狀態多了一倍還要多；當然會有這么多狀態，也是因為交互的系統比較多導致；一般初期的電商系統這幾個狀態也夠用。

2. 退款場景

從狀態機中不難看出，退款發生的場景主要有以下幾類

1. 未付款時，取消訂單；系統自動取消訂單一般會根據自身公司實際情況來決定；我們當時是因為有占存的概念，因此暫定是30分鐘
2. 已付款待發貨申請：因為公司的倉庫都是自己的，可以控制；因此可以根據實際情況來做攔單，同時客服審核后可直接退款
3. 已付款且已發貨申請：這塊一般公司會根據自己的規則決定是否先行退款還是是收到退貨后再退，一般業務會根據實際情況處理售后。在此，既要考慮用戶體驗，又要考慮商品退貨風險

3. 退款業務流程

其實，做后臺系統，需求調研的時候，他們也說不出個一二三，除非經驗比較深的，或許能提出一些信息點；很多時候是需要產品經理主動給出一條思路進行引導的；經過和相關部門的溝通，最終確定了業務流程，具體如圖：

用戶操作流程圖：

總結：根據不同的訂單狀態，顯示不同的退款類型入口。

一般對于退款申請，未發貨的訂單申請退款都可以整單申請退，邏輯上相對要簡單一些；如果是退款退貨，相對來說比較復雜

• A. 無各種優惠的時候 ，選擇某一商品申請退款，申請后按業務流程處理即可；
• B. 訂單有優惠的時候，選擇某一商品申請退款，則牽涉到退款金額的計算。

如：兩件商品A（20元）、B（80元），訂單共100元；提示滿90包郵；現在用戶申請退A商品，就牽涉到退款金額計算；是按比例退款，還是是按實際售價退；所有的金額計算要和相關業務部門溝通，根據實際情況來確定退款金額計算規則后執行。

4. 后臺系統交互

經過和其他系統的產品經理溝通，最終的交互圖也確定了下來。當然出具的這些流程圖需要根據公司的實際情況來設計規劃，提供的只是些可借鑒的圖

5.原型圖和PRD

根據上述的流程圖大致清楚了列表及其功能點。也就可以逐步出具原型圖和PRD了。

原型和頁面不做過多介紹，其實都是按照上述的流程圖確定頁面和功能點后，按照實際需要來出具原型視圖，畢竟對于業務來說，這些他們最直觀了解產品的初衷。

客服退款審核列表

客服退款審核詳情

財務退款詳情

總結

1. 用戶填寫的退款申請，是需要區分是退款還是是退貨的。

• 未發貨的退款—可以直接進行系統退款的
• 而退貨，是需要查詢退貨登記中是否已簽收的
• 只有已經簽收的財務才會去退款，當然，客服也可以根據實際情況來決定是否要提前給用戶退款

2. 如果公司無多個系統，退款也就不會有多個系統復雜交互；做產品最終還是要根據公司實際情況考慮，而上面的流程，僅是我工作總結得一部分。

不洗勿噴，有不正確的地方，還請同行們指證。

作者：簡之箐，微信公眾號：簡之箐，5年互聯網產品經理，曾擔任醫藥產品經理和電商產品經理，經歷主導過電商平臺的系統整合規劃。

本文由 @簡之箐 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議