結合商品流轉的電商系列介紹了一些了，商品已經采購入庫、價格稅率設置好了、活動及相關模闆也已經準備完畢，下面就應該上架銷售了，現在接着聊下訂單的生成。此篇是電商後台系列的第9篇，也作為2019年的最後一篇。

訂單從産生到最終的關閉需要經曆很多的環節，訂單也是電商系統的核心數據，有銷售才有收入，所有的工作都是圍繞着訂單開展的，為訂單服務的。

本篇主要聊下從訂單創建到訂單支付完成這部分，介紹下涉及的系統的各個環節，回顧總結下這些簡單的内容，供大家娛樂。

訂單生成流程

上面這個流程相信接觸到電商或經常購物的人都特别熟悉，特别簡單，在設計開發時要我個人覺得要從以下三方面考慮。

首先，我們要清楚從搜索選擇商品到加入購物車，然後提交訂單，再到用戶支付完成。就這麼幾步，你在淘寶、京東等任何一定電商網站也要遵循這個過程，所以這個過程比拼的是用戶體驗以及系統的穩定與性能。

其次，從産品運營的角度來講，應該要考慮到用戶在進入到哪個環節了，應該如何留住用戶，最終讓用戶下單并支付。所以在産品與運營要兼顧考慮，不能脫離開。

最後，訂單生成流程中用戶的浏覽、點擊等行為都需要保存，每個過程要進行數據埋點，後台最終要計算出其頁面PV、UV、以及訂單轉化率等指标，用于後續持續改進的依據。

下面結合自己的認識來說下各個環節，有不對的歡迎大家留言指正。

購買渠道

這裡說的渠道，可以理解為下單來源即用戶從哪挑選商品并下單購買的，先看下下圖。

用戶下單的來源可以分為内部（公司開發的相關産品）與外部（與第三方平台的對接）兩種。

外部渠道，需要我們與第三方平台進行對接（目前都有第三方開放平台），将生成的訂單導入到我們内部平台，然後進行履單。

這裡涉及商品對接及庫存（此部分是要求實時共享還是劃撥渠道庫存的方式，需要根據業務要求而确定，系統的實現是不一樣的）、單據對接（轉單、訂單狀态的更新等、查詢），一般的平台都有開放平台，功能和架構都比較成熟，隻要按業務進行調整設計應該就可以。

涉及支付結算、活動優惠的計算等，這些都與财務系統FMS息息相關，但是在産生訂單的時候要将關鍵信息記錄完整，要求可追溯而且要不可變（有調整要走逆向流程或系統補償方案），代收和傭金的結算流程要結合合同與财務流程進行設計。

對于大的電商公司如果有一定的技術積累，外部渠道隻是為了擴大影響力，用于引流和增加銷售額，真正的收入還應該是内部渠道。

内部渠道，這是公司的主營業務銷售渠道，涉及公司一些技術産品開發，而且這些應用産品就是公司的名片。

目前，零售公司都在實行線上 線下的方式，以用戶為中心進行社區化的經營，本質上就是為了賣貨。線上以APP 小程序為主，網站目前應該以引流和宣傳為主了，移動端的産品是核心産品。

線下就是便利店模式，但現在如何經營好門店是衆多零售企業在追尋的，線上銷售無邊界，線下銷售有經營半徑，所以對于産品的建設也不同。

APP 小程序要求有效的利用移動設備的界面，更注重的産品的展示和整個購物流程的流暢性，但便利店應該以商品貨架的規劃、用戶的親身體驗以及服務為主，服務應該更重要。

聊到這裡小結下，渠道就是根據公司的戰略來開發公司的技術産品，也是商品在哪個平台上進行銷售的渠道。下面正式來說下訂單産生時每個環節的一點理解。

商品搜索

用戶下單前首先要查詢需要的商品，商品有庫存并且已經上架銷售了，如何在前端APP上讓用戶快速的查看到是需要詳細規劃與設計的。

搜索需要用到搜索引擎，要設置關鍵字，對于商品名稱等要進行分詞，這部分是要通過搭建搜索平台來實現。

此外，商品展示時有導航，要有分類，要根據不同的樓層展示不同的商品，比如有促銷的可以單獨做活動頁、可以歸集在一個樓層裡。

搜索具體咋做沒接觸過，但現在在APP或小程序上我個人感覺都通過分類或導航去找商品的，在淘寶或京東這種品類多的網站還是需要輸入關鍵詞查找商品的。所以對于SKU不多企業，搜索可以稍弱化點，更多的采用引導方式去尋找商品（不知道我的這種想法是否正确的，目前我很多時候是閉門造車哈哈）。

選擇商品

商品查到了，如何選擇商品呢？

這也需要我們的系統提供必要的信息。

1. 商品詳情頁，此部分在前面介紹商品系統時說過，首先每個商品要根據上傳的圖片，商品的模闆生成商品詳細信息。由于網上購物是看不到實物的，所以隻能通過圖片或小視頻來顯示，這是最直接有效的信息傳遞方式。其次，要有規格參數的描述，如材質、大小等特性要突出;最後就是關于商品的服務條款，如保修、質量及使用說明等。
2. 用戶評論，目前商品的好評率是用戶非常關注的，因為零售企業售賣的不僅是商品，更重要的是服務，但服務的好與壞是通過用戶來反饋的。評論要從商家服務水平、商品質量、商品使用情況等不同維度進行。用戶評論是與客服相關的，所以要有專門的人針對商品評論進行及時回饋與問題的解決，盡可能的真實的顯示用戶評論，降低差評，給用戶真實的信息。
3. 價格，在商品價稅管理中介紹過商品的售價如何制定，依賴于哪些指标，最主要的是毛利率以及競争對手的價格。低價不一定是好的選擇，價格是要與商品品質及服務關聯的。價格要醒目的展示給用戶，要有對比，讓用戶感覺到優惠力度，價格的變動有嚴格的審核流程且要及時生效，避免用戶投訴。
4. 促銷活動，沒有哪個網站不搞促銷的，促銷的玩法前段時間整理過一篇，大家可以參照《促銷活動一覽表》。

經曆了上面的一系列操作，此時就可以加入購物車了。

購物流程

購物流程直接影響用戶體驗的。

首先，雖然都是選品>加入購物車>提交訂單>支付結算，但不同的商品我們應該有所區别，比如秒殺商品就可以直接生成訂單，不需要加入購物車。

其次，在購物流程中，我們應該更側重于營銷引導即讓用戶根據添加到購物車的商品給予相關推薦。因為用戶走到這個流程，購買的願望已經很強了，如果能夠給出一些更好的建議或優惠，可以更好促進訂單的達成，提高轉率。

第三，在購物車中每次的商品的增與減都需要實時的獲取商品的價格信息、庫存信息以及優惠活動信息。這些金額的計算，促銷活動的獲取、訂單優惠重新計算對系統要求是非常高的，響應慢了用戶體驗不好，數據獲取不準确會造成用戶的投訴，都會導緻訂單的流失。

第四，在系統設計時要考慮系統耦合度及功能的擴展性。如果這部分耦合度太高，會增加後續項目的難度，要合理劃分功能。同時要注重時序性；有的服務先調、有的後調這些都要綜合考慮。

購物流程組對産品、技術要求都很高，代碼的好壞隻有自己知道，說與做要做到知行合一，這部分也考驗一個人的技術水平和抗壓能力。因為與用戶有關的功能出現問題要能夠及時去解決，并對已有錯誤數據要快速修複。

一直參與的是後端系統的業務與系統設計，對前端的這部分的流程也在學習和梳理中，但此部分是我覺得最核心的如購物車的數據如何保存，用戶的SessionId如何保存，活動如何防止超賣等等。

訂單結算

1）結算頁

首先是支付方式的選擇，支付方式有很多種，目前很少有現金支付了，即便是貨到付款也是支付寶、微信或刷卡了。

這裡說的支付方式有以下幾種：支付寶、微信、銀行卡、優惠券、積分、禮品卡或紅包等。不同的支付方式需要調用不同的支付接口，這時沒有提交訂單還沒有到支付的環節。

2）優惠的重新計算

這裡主要就是進行訂單級别的優惠計算，是否有滿減等優惠等。此部分也是購物流程的一部分。

3）運費計算

這個需要調用前期商品的運費模闆進行計算，是否免郵還要結合會員等級等信息。

4）訂單的提交

隻有提交了才産生用戶訂單。對于訂單有哪些信息需要記錄？

• 訂單的頭信息，即訂單号等基本信息，用戶的基本信息，訂單的來源，訂單的生成時間，訂單級的活動信息記錄。
• 訂單的行信息即商品信息，商品的購買數量、商品編碼、商品原價、售價、優惠價以及商品級的促銷活動信息。

如果是外部渠道的訂單，還需要記錄外部訂單号、合作平台标識等

在此階段，訂單應該處于第一個狀态即待支付狀态，此時訂單雖然創建，但是仍可以取消。

訂單創建後就占有商品庫存了，此時要給用戶支付的時間，這個也要區分場景。普通訂單可以30分鐘内支付，秒殺訂單需要立即支付，限時搶購訂單可以設置1分鐘或5分鐘内支付，否則訂單就需要系統自動取消，釋放庫存。

用戶主動取消訂單，在”待支付”狀态一般沒有限制，取消後即可釋放庫存。

還有一個問題，需要在此說明，即此時的訂單保存在哪裡？肯定是數據庫，要确定的是訂單此時保存在前端訂單庫中，還不需要向後台ERP系統傳遞，前端主庫與後端訂單号之間需要有一個拉單服務。

早在十幾年前自己負責過這個拉單服務的開發，這麼多年好似隻是技術的不斷升級，業務方式沒有太大變化。主要是仍是采用多線程方式及時快速的将前端産生訂單拉到後端生産庫用以後序的作業。

最後，訂單創建完成後，需要用戶支付。此時支付多少錢、如何支付、支付需要對接哪些支付平台這個也是需要進行詳細設計的。涉及到錢的就沒有小事，這點對于我們技術産品尤為重要。

舉個例子：

如果我們在做跨境電商，用戶用人民币支付，但是支付寶國際需要轉化為港币，那麼在調用支付寶國際時就需要将彙率記錄下來，并進行人民币與港币的轉換。如果此部分彙率獲取的不對或記錄錯誤，直接影響到交易的金額，對後續的财務結算等都會産生影響。

在支付過程中，由于調用第三方的支付接口，支付成功與否的狀态回傳可能會有延時，所以此時需要對回傳狀态要嘗試多次，同時我們要将訂單進行狀态鎖定，防止用戶重複支付。

如果用戶支付成功，那麼這時要記錄哪些信息呢？

支付流水号、第三方交易号碼、支付時間、支付狀态、支付金額等，此部分信息第一是為了保證信息的完整性，第二是用于與第三方進行對賬即财務系統中的應收對賬部分，第三是用于用戶的退換貨等後續退款等。

此部分信息要在不影響支付流程的效率前提下，盡可能的詳細記錄，可以采用異步方式進行，但不能少記或不記，在涉及金額的信息我認為數據的冗餘是必要的，多比少好。

至此，訂單支付成功了，訂單的狀态應該是“待發貨”狀态。訂單會經過拉單、拆單等操作向下流轉，後續會接着總結。

總結

關于訂單的部分，目前是想根據訂單的狀态去梳理下，目前要輸出一篇好文章可能要幾天或一周，有點慢，所以純文字的會快點。這也是在本篇中沒有畫相關的流程圖的原因，而且對于節點多的每個環節都畫好比較費時，畫的不細參考意義不大（後續會再針對一個個環節進行細化）。所以便采用文字描述的方式和你唠，唠的隻是我個人的一些理解，涉及細節需要共同探讨與設計。

自加入“人人都是産口經理”平台的幾個月來輸出的文章頻率有點高，質量可能有些粗糙，2020年會控制節奏，深耕細作。最後，感謝您的閱讀與關注！

#相關文章#

1.《通過商品流轉了解系統模塊組成》

2.《電商系統之供應商管理》

3.《電商系統之合同管理》

4.《電商後台：商品管理系統》

5.《電商後台之價稅管理》

6.《電商後台：采購管理模塊》

7.《電商後台：商品上架前的最後準備》

8.《電商系統：倉儲軟件功能的簡單設計》

作者：倔強的大蘿蔔；公衆号：倔強的大蘿蔔

本文由 @倔強的大蘿蔔 原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

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

查看全部