電商産品中，最核心的模塊莫過于訂單。一筆訂單從創建到結束，涉及到複雜的邏輯跳轉和衆多異常處理。本文就結合電商實戰經驗及淘寶訂單設計案例教大家如何基于購物場景來設計電商産品的訂單基礎流程。

說到電商類産品，我們都不會陌生，做為普通人也應該知道電商産品是完成人們購買商品的平台。但作為産品經理，需要用模塊化的視覺來看電商産品。我們可以根據用戶使用場景簡單的将電商産品拆分成浏覽商品、下單交易，訂單跟蹤三個模塊。在每個模塊的設計中都需要基于場景來進行功能及邏輯設計，在經曆過十幾年的電商發展曆史，用戶早已被教育的傻白甜。最快速的找到想到的商品，最簡單的下單購買，最便捷的交易處理，這些才是用戶需要的。如果從上面的三個模塊來看

• 浏覽商品模塊– 設計怎樣的商品頁面展示，分類，搜索，推薦，排名等方式，才能更快度的讓用戶找到自己想要的商品。基于平台又需要考慮如何平衡商品的權重，讓其盡可能維持一個可持續的生态。
• 下單交易模塊– 設計怎樣的規則能快速識别用戶對某一商品感興趣了，又怎麼設計能快速刺激用戶進行下單，在用戶下單時又怎樣盡可能簡單連貫的讓用戶完成支付行為。
• 訂單跟蹤模塊– 設計怎樣的訂單跟蹤及提醒操作才能讓用戶放心的把訂單交給系統，設計怎樣的便捷操作才能讓用戶在遇到問題是快速解決。

正如本文主題所示，這篇文章不是要跟大家講明白電商産品的設計規則，我也不可能在一篇文章中把淘寶十幾年的東西給大家講明白。但我們可以專注來看下訂單交易的基礎部分，訂單模塊邏輯設計。也就是上面說的第三個模塊問題訂單跟蹤模塊。我将結合自身經驗和淘寶設計規則，基于用戶場景的帶入來給大家分享訂單交易模塊的設計規則。主要有三個部分

1. 基于用戶場景的訂單交易需求
2. 從訂單狀态開始構建整體訂單邏輯框架
3. 不能忽視的訂單異常處理

基于用戶場景的訂單交易需求

在設計訂單跟蹤模塊前，我們要先看看現在的用戶怎麼在網上下單的。如上所說，現在的人們都被電商行業教育的越來越懶的，搞的很多創業公司一開始就要設計較完整的交易閉環，耗費大量人力和時間。那用戶的“懶”的場景體現在哪些方面呢？

1. 我要購買時，就給我一步支付了吧。不要兩步，懶得我隻要一步。
2. 購買成功後，我就不管了。快遞要到時記得告訴我就好，那個快遞小哥，放我家門口就好，不點收貨了。
3. 不買了，退錢。不要問我為什麼，你們去跟商家解釋吧，把錢退給我就行。

還有很多“懶”的場景，用戶之所以能這麼懶，是因為他們有懶的資本，而這些的資本都是通過不斷完善的交易流程和産品功能體現的，是産品背後幫助用戶和商家之間規避了很多風險，隐藏了很多需要用戶思考和操作的步驟。那麼在産品層面需要考慮哪些關鍵流程來滿足用戶的“懶”呢？基于上述場景我們可以歸納産品要體現出的場景包括：

1. 能對買家實現連貫下單支付操作，不要給用戶猶豫和思考的空間，他隻需要點點點，你隻需要彈彈彈，直到支付訂單完成。
2. 能在有人購買訂單後給商家快捷的發貨操作。商家也隻需要根據你的彈彈彈來進行點點點即可，直到發貨成功。
3. 系統要能實時跟進訂單進度，适時給用戶和商家提醒訂單狀态和物流狀态。系統要能像管家一樣幫助用戶跟蹤交易，确認收貨。
4. 當用戶發大小姐脾氣取消訂單時，你要知道他發脾氣的原因，也要實時幫助她處理好訂單，也要及時通知和安撫好商家。
5. 當用戶需要你出來幫助時，你要能讓她快速找到你，且及時處理問題。

ok，以上隻是訂單交易過程中可能發生的場景，産品需要從這些場景中抽象出産品需要解決的問題，進而設計功能模塊和邏輯框架。當然，我們也要帶着産品自己的體系去設計功能，畢竟用戶是需要在體系裡被教育的，不過是教育他們更好的使用産品獲得更好的體驗罷了。那我們從場景中進行抽象訂單交易過程需要解決的問題包括

1. 設計最小訂單交易閉環，幫助用戶完成基本交易
2. 設計每個交易狀态下的系統觸發機制，幫助用戶自動完成基本交易
3. 設計每個交易狀态下的異常處理，幫助用戶解決更多異常交易場景的問題

接下來我們就開始從訂單交易框架搭建開始詳細講下如何設計電商交易流程

構建整體訂單邏輯框架

訂單交易最基礎的部分是交易流程，從設計最小閉環開始，逐漸往最小閉環裡補充交易流程。但如何設計最小閉環呢，這裡我們要先介紹訂單交易裡兩個最核心的元素根據場景來定義狀态。核心的部分在于

1、訂單狀态

2、訂單操作

訂單狀态

訂單狀态是定義訂單将按照哪幾個步驟進行的依據，就像我們人的生命周期一樣，有嬰兒期、少年期、中年期、老年期。訂單狀态具有幾個特點

1. 順序性：訂單狀态需要按照一定的規則，從前之後順序發生，不能跳躍，不能逆向。
2. 特殊性：訂單狀态包容異常情況，在順序的過程中都可能因為一些操作随時進入異常态。
3. 可擴展性：訂單狀态可以随着業務場景的需要添加，但一般不會删減。這樣會影響曆史數據。

訂單操作

訂單操作是基于訂單狀态下，可給用戶觸發的對該訂單的操作。訂單狀态一般都由訂單操作觸發才會發生改變。比如買家點擊收貨按鈕後，觸發訂單由待收貨狀态變成了已完成狀态。訂單狀态一般設計為買家和商家共用，但訂單操作一般是獨立設計的。所以在訂單操作設計上就需要考慮對訂單功能的用戶群體包括哪些。常見的用戶群體包括買家、商家、平台管理員。

一些特殊交易平台的訂單還包括其他角色，比如夠格産品上有代售功能，就包括的紅人角色。在這裡因為管理員是超級權限，基本啥都能幹，還可能還會設置等級。所以我們就不做為讨論範圍。接着再考慮給對應角色開放什麼權限前，先确認改狀态下可以有哪些權限，然後再根據角色身份進行分布。

1. 劃分用戶角色
2. 定義該狀态下所有訂單操作
3. 根據角色設置訂單操作

下面我們就基于訂單狀态來讨論下買家和商家對應的訂單操作。

在訂單狀态上，基于訂單交易場景下，完成最小閉關搭建，一般常見的訂單交易最小閉環流程如下

待支付 – 待發貨 – 待收貨 – 訂單完成 四種狀态流轉。

1. 待支付：雖然系統設計上盡量讓用戶一步完成支付了，但未支付的狀态還是要保留，因為你永遠不知道用戶啥時候就沒支付。
2. 待發貨：支付完成的訂單，此時買家處于等待狀态，後面基本不需要做什麼操作。會通知商家進行發貨。
3. 待收貨：商家已發貨訂單，此時設計最關鍵的功能便是物流跟蹤。
4. 訂單完成：當買家點擊收貨後，這筆訂單才算完全交易完成。

在基于四種訂單狀态，我們從商家、買家兩種用戶角色上進行劃分。比如待收貨狀态，一般包括“确認收貨”“取消訂單”“查看物流”操作。确認收貨是相對買家的權益保護，隻能開放給買家。取消訂單按道理商家也可以開放，但一般出于對訂單保護，尤其在賣家已經發貨的狀态下。不會開放給商家，隻會開放給買家。查看物流是雙方都可以進行的操作。所以我們可以安排如下：

商家：查看物流

買家：确認收貨，取消訂單，查看物流

按照這個思路，我們就可以得出待支付、待發貨、待收貨、訂單完成狀态下的訂單操作。從而得出最小閉環的訂單流程。後面可以基于這個最小閉環完善訂單流程。一般常見的操作包括:

• 在狀态時間軸上設置系統定時器功能，替代人工操作更改訂單狀态。如自發貨算起，15天後自動收貨。
• 出于業務需要，添加新的訂單狀态。比如拼團功能需要有待成團狀态。
• 出于業務需要，添加新的訂單操作，比如商家可能無貨了，還沒修改庫存。當有人下單時需要給賣家取消訂單操作。需要在待支付那裡商家端添加取消訂單操作。

下面是淘寶的訂單狀态和買家對應的訂單操作。

不能忽視的訂單異常狀态

如果按照正常的訂單狀态走下去，當然是ok的。但并不符合實際情況，在實際場景中，每一筆訂單都有可能因為外界原因導緻訂單異常。一般異常的主要情況包括

1. 商家因為某些原因無法發貨
2. 買家因為某些原因要求退款/貨
3. 買家因為某些原因取消訂單

…

在産品層面上，需要對這類異常訂單進行處理。因為異常會發生在任何訂單狀态下，所以需要在對應訂單狀态下考慮異常的可能性，然後根據可能性分别提供給不同用戶角色對應訂單操作按鈕。對異常處理的結果有分兩種：

• 一種是取消異常回歸到正常狀态下
• 一種是處理異常交易結束

異常訂單需要添加兩種狀态，一種是處理中狀态，一種是處理結束狀态。比如“申請退款中”是處理中狀态，“交易關閉”是處理結束狀态。在淘寶中，給用戶看到的狀态隻有兩類，一是正常交易狀态，一是異常處理結束狀态，其産品系統後台将所有異常處理中的狀态都封裝了。

最後我們再來看下淘寶所有的訂單狀态和買家對應的訂單操作。

最後，我們再來複盤下如何基于場景來構建訂單體系結構。首先我們要分析用戶場景，找到需要訂單系統滿足的需求和提供的能力。其次我們需要定義訂單流程的最小閉環滿足這個需求，在最小閉環中又要借助 定義狀态、設置操作的設計思路來搭建最小閉環。然後我們需要在最小閉環的基礎上，基于業務需求，同樣采用狀态到操作的設計流程補充完善訂單流程。最後，我們要考慮異常處理的狀态和操作，最終完善訂單流程完整閉環。

作者：水度力子，一年咨詢顧問，兩年産品經驗。曾就職世界500強外企，兩年創業經曆。産品，運營，咨詢分析。

本文由 @水度力子 原創發布于人人都是産品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議

,