電商所有模塊中，訂單系統(tǒng)作為最為核心的模塊，決定了整個流程能不能順暢的執(zhí)行，起著承上啟下的作用。相信很多PM都不陌生，到了一家電商公司，總會覺得公司現(xiàn)有的流程有不少問題，因?yàn)閱栴}來自四面八方，一下子摸不著到底是哪里出了問題，PM就跟補(bǔ)丁師傅一樣，遇到一個補(bǔ)一個。

其實(shí)很多日常開發(fā)和測試提得需求都是表面需求，而這些表面上呈現(xiàn)出的各種問題，都是源自于流程上的不完整或者流程上某個環(huán)節(jié)上的缺失導(dǎo)致的。訂單系統(tǒng)作為一個承上啟下的模塊，流程上出了問題，它肯定脫不了干系。

訂單系統(tǒng)分為用戶端和商家端，今天我們從商家端簡單分析一下訂單系統(tǒng)該如何設(shè)計和完善，才能不斷適應(yīng)公司的業(yè)務(wù)發(fā)展，減少因?yàn)榱鞒虒?dǎo)致的不必要的返工和“補(bǔ)丁”。

為什么說訂單系統(tǒng)是承上啟下的作用，上游是什么，下游又是什么？

這里我們先把問題放在這，后面講到再作解釋。

訂單系統(tǒng)

設(shè)計訂單系統(tǒng)需要考慮幾個模塊，只有所有模塊都考慮清晰了，才能保證訂單系統(tǒng)的穩(wěn)定性和可擴(kuò)展性。

1. 訂單字段

其實(shí)呈現(xiàn)在界面上的訂單信息，都是由各種訂單字段組合而成。訂單字段齊全從某個程度上代表著訂單流程的完整。

訂單字段包括幾個部分，其中金額信息因?yàn)樘厥庑?，?dú)立出來講，實(shí)質(zhì)上金額信息屬于商品信息。

商品信息：商品信息屬于訂單系統(tǒng)的上游端，所有訂單都是從商品演進(jìn)而來，從商品到訂單，訂單系統(tǒng)必須搜集相關(guān)的商品信息，包括店鋪信息，商品id，商品規(guī)格，商品數(shù)量，商品價格。獲取到的商品信息將在訂單詳情頁內(nèi)展示，形成訂單信息后供倉庫方便揀貨，包裝。

用戶信息：用戶信息包括購買用戶的ID，收貨人，收貨地址，聯(lián)系方式。有些平臺的用戶成長體系是基于用戶對平臺的活躍度來計算的，例如京東，它有會員等級及積分卡等類似的成長標(biāo)識，此時獲取到的用戶信息除了普通的信息字段外，還需要獲取該用戶的等級，該次購買后所獲得的積分，以及該用戶所在等級能在該訂單上扣除的優(yōu)惠等信息，具體怎么操作取決于公司的業(yè)務(wù)方向。

金額信息：因?yàn)榻痤~信息的特殊性，所以獨(dú)立出來講，理論上金額信息應(yīng)歸屬商品信息。金額信息的特殊性在于其不止一種金額，其涉及到商品金額，優(yōu)惠金額，支付金額。而優(yōu)惠金額中涉及到的信息較復(fù)雜，像有自營和第三方入駐的電商平臺，都會有商家優(yōu)惠和跨店優(yōu)惠，而這些優(yōu)惠又分不同類型，例如現(xiàn)金扣減，消費(fèi)券扣減，積分獲取，禮品卡扣減，或者以上幾種的組合使用。想要涉及好這一塊內(nèi)容，需要根據(jù)目前自己公司的業(yè)務(wù)情況，列出所支持的優(yōu)惠類型，再枚舉出各種組合下的優(yōu)惠類型，才能保證流程的完整性。

時間信息：記錄各個卡點(diǎn)下的時間，一是記錄，二也是方便售后驗(yàn)證和客戶分析。訂單時間是根據(jù)訂單狀態(tài)改變而改變的，比如：我們常見的用戶。

下單未付款：即展示訂單創(chuàng)建時間、下單時間；
待發(fā)貨狀態(tài)：展示訂單創(chuàng)建時間、下單時間、支付時間；
待收貨狀態(tài)：展示訂單創(chuàng)建時間、下單時間、支付時間、發(fā)貨時間；
交易完成狀態(tài)：展示訂單創(chuàng)建時間、下單時間、下單時間、支付時間、發(fā)貨時間、完成時間；
待退款狀態(tài)：展示退款訂單創(chuàng)建時間、申請退款時間；
交易關(guān)閉-用戶取消：展示訂單創(chuàng)建時間、下單時間、用戶取消時間；
交易關(guān)閉-僅退款：訂單創(chuàng)建時間、下單時間、支付時間、退款申請時間、退款成功時間；
交易關(guān)閉-退貨退款（包含部分僅退款）：訂單創(chuàng)建時間、下單時間、支付時間、交易完成時間、退款申請時間、退款時間。
時間信息看起來不重要，其實(shí)是訂單系統(tǒng)一個重要的組成部分，原因大家可以思考一下。

訂單信息：訂單信息在訂單系統(tǒng)最為核心，訂單信息最重要的又是訂單狀態(tài)。很多公司都有訂單狀態(tài)機(jī)的說法，那到底什么是訂單狀態(tài)機(jī)？

我個人的理解是：在訂單中，通過各種購物情景，觸發(fā)訂單狀態(tài)，將訂單的流轉(zhuǎn)可視化，是訂單狀態(tài)機(jī)的一種具體呈現(xiàn)形式，而它實(shí)質(zhì)就是在描述訂單狀態(tài)的轉(zhuǎn)換。

電商購物中，訂單狀態(tài)分別有以下幾種：【待付款】、【待發(fā)貨】、【待收貨】、【待評價】、【交易完成】、【用戶取消】、【僅退款】、【退貨退款】。而我們一般會將后三種統(tǒng)一放在訂單售后獨(dú)立呈現(xiàn)，去方便平時商家操作的便捷性。

2. 訂單流程

訂單流程是指從訂單產(chǎn)生到完成整個流轉(zhuǎn)的過程，其中包括正想流程和逆向流程。正向流程就是一個正常的網(wǎng)購步驟：訂單生成–>支付訂單–>賣家發(fā)貨–>確認(rèn)收貨–>交易成功。

而逆向流程則是各種退款流程。

（1）正向流程

整個訂單設(shè)計的流程其實(shí)是非常多的，接下來我們將從比較具體的描述一下各個環(huán)節(jié)下的實(shí)際情況。

訂單生成：用戶下單后，系統(tǒng)需要生成訂單，此時需要先獲取下單中涉及的商品信息，然后獲取該商品所涉及到的優(yōu)惠信息，如果商品不參與優(yōu)惠信息，則無此環(huán)節(jié)。

接著獲取該賬戶的會員權(quán)益（這里其實(shí)需要注意的是：優(yōu)惠信息與會員權(quán)益是有區(qū)別的，就好比商品滿減是優(yōu)惠信息，新人立減是會員權(quán)益，一個是針對商品，另一個是針對賬戶）。

庫存扣減是指可銷售庫存數(shù)量-1，嚴(yán)格來講庫存扣減目前分為兩種：

一種是下單減庫存；
另一種是付款減庫存。
個人覺得中小創(chuàng)業(yè)者也許競爭者不比淘寶中的賣家，在電商這個存量市場，需要精細(xì)化的運(yùn)營才能存活下來，如此說保證用戶體驗(yàn)才是根本。所以我這里的觀點(diǎn)是生成訂單扣減庫存，這種做法會避免用戶支付成功商家卻沒貨的情況。然后計算運(yùn)費(fèi)，訂單生成成功。

支付訂單：用戶支付完訂單后，需要獲取訂單的支付信息，包括支付流水號、支付時間等。支付完訂單接著就是等商家發(fā)貨，但在發(fā)貨過程中，往往還有一種情況存在，很正常卻也比較復(fù)雜，就是訂單拆單。

訂單拆單分兩種：一種是用戶挑選的商品來自于不同渠道（自營與商家，商家與商家），此時就需要拆分訂單，并分開結(jié)算，這里還涉及父子訂單的說法，這里不再贅述。
另一種是在SKU層面上拆分訂單：不同倉庫，不同運(yùn)輸要求的SKU，包裹重量體積限制等因素都需要將訂單拆分。比如：商品A只在甲倉庫有，商品B又只在乙倉庫有，此時會將商品A與商品B拆分成兩個訂單?；蛘哂行┢髽I(yè)的做法是將商品A/B調(diào)撥到另外一個倉庫統(tǒng)一發(fā)貨，也方便了用戶。
訂單拆單看起來簡單，其實(shí)里面涉及到底層的系統(tǒng)支持，如你需要對每一個倉庫的貨品進(jìn)行相對準(zhǔn)確的盤點(diǎn)，且做到實(shí)時同步（涉及到倉庫精細(xì)化管理），對商品進(jìn)行準(zhǔn)確分類與擺放，對商品信息記錄準(zhǔn)確無誤等。

這其中哪一模塊都是一個浩大的工程，PM一般進(jìn)入一家公司都會在原有（半成品）的基礎(chǔ)上進(jìn)行優(yōu)化，大家不妨多思考一下底層業(yè)務(wù)，只有在底層做好精細(xì)化管理，才能支持線上豐富的用戶需求。

商家發(fā)貨：商家發(fā)貨過程也有一個標(biāo)準(zhǔn)化的流程，上面也有講到，訂單拆分時會涉及到倉庫間調(diào)撥，然后倉庫會對商品進(jìn)行打單、揀貨、包裝、交接快遞配送。這套標(biāo)準(zhǔn)化流程如果優(yōu)化好，也是一個大工程，這里不再贅述，建議大家看看庫存與倉庫管理方面的書籍，詳細(xì)了解。

確認(rèn)收貨：商家發(fā)貨后，就是等快遞配送了，訂單系統(tǒng)需要接入一些常用快遞企業(yè)的接口，方便用戶與商家在站內(nèi)查詢快遞信息。

交易成功：收到貨后，不是一個服務(wù)的結(jié)束，相反是一個服務(wù)的開始。訂單系統(tǒng)需要在快遞被簽收后提醒用戶對商品做評價，這里要注意，確認(rèn)收到貨不代表交易成功，交易成功是指在收到貨X天的狀態(tài)，此時訂單不在售后的支持時間范圍內(nèi)。到此，一個訂單的正向流程就算走完了。

目前我也沒有研究過，不過我的經(jīng)驗(yàn)告訴我訂單系統(tǒng)對售后訂單的處理并不比正產(chǎn)訂單少，身為電商PM，我們的工作就是去優(yōu)化這些流程，提高用戶粘性。本身售后訂單的出現(xiàn)，在某種程度上已經(jīng)傷害到了用戶，如果流程還一團(tuán)糟的話，我們根本沒有機(jī)會等到用戶的復(fù)購。

（2）逆向流程

一個電商的基本逆向流程如上圖所示，訂單的逆向流程復(fù)雜就在于它幾乎允許在正向流程的任何環(huán)節(jié)出現(xiàn)。有人會問：用戶未收到貨為什么還能退款？

其實(shí)我們換位思考，也很容易理解。假想你是用戶，買了一雙鞋子，付了款發(fā)了貨，正在美滋滋的等待收快遞，然后剛好路過一家鞋店看到剛買的同款鞋子大促銷，于是你就拿起手機(jī)點(diǎn)擊退款，買下了這雙促銷的鞋子。

這種場景其實(shí)是很普通也很正常的用戶日常，所以我們的訂單系統(tǒng)就必須得支持用戶各種豐富的場景需求，也十分考驗(yàn)PM的業(yè)務(wù)滲透能力，好在電商的先行者淘寶已經(jīng)做了很多基礎(chǔ)建設(shè)和用戶教育，我們直接可以拿來套用，不過還是要根據(jù)各個公司的業(yè)務(wù)情況進(jìn)行修改。

取消訂單：用戶提交訂單時，在跳轉(zhuǎn)至支付前直接退出，此時用戶原則上屬于取消訂單，因?yàn)檫€未付款，則比較簡單，只需要將原本提交訂單時扣減的庫存補(bǔ)回即可。

支付失?。河脩暨M(jìn)行支付時退出，或者取消支付，我們將其列為支付失敗狀態(tài)，此時處理同上，將扣減的庫存補(bǔ)回可銷售庫存即可。

付款后退款：用戶支付成功后，商家還未發(fā)貨，支持用戶申請退款，此時如果倉庫與客服是分離的，則需要先檢查倉庫是否已經(jīng)發(fā)貨，若已發(fā)貨則應(yīng)與客戶溝通是否可以收到貨后再進(jìn)行退款，如果倉庫還未發(fā)貨，則可直接同意用戶退款。或者企業(yè)接入菜鳥物流，實(shí)行截件功能，不過這種操作還不成熟，成本會比較大，不適合中小創(chuàng)業(yè)型公司。

缺貨退款：用戶支付成功后，商家發(fā)貨時發(fā)現(xiàn)倉庫缺貨（如果提交訂單扣減庫存，則會減少缺貨情況，為什么是減少而不是避免？因?yàn)閭}庫管理商品時沒辦法做到100%精準(zhǔn)，所以信息有時候會不準(zhǔn)確，導(dǎo)致線上的可銷售庫存顯示有庫存而倉庫已經(jīng)售空的狀態(tài)），則需要與用戶協(xié)商是否退款。

這個流程訂單系統(tǒng)可以做到流程化、自動化，連接消息中心和倉庫管理系統(tǒng)去實(shí)現(xiàn)，難點(diǎn)在于消息的實(shí)時性。我就遇到過在淘寶買過一件上衣，一天過去了，商家跟我說沒貨了，我當(dāng)時殺人的心都有了。

待收貨退款：這個問題目前還沒有特別完美的解決方法，商家發(fā)了貨之后，用戶還未收到貨，此時貨在路上。

我曾經(jīng)在一些交流群里提出過這個問題，大家的看法都不一樣，大體上分為兩種做法：

一種是用戶收到貨后重新寄回；
另一種是用戶直接拒收包裹，包裹直接退回原地址。
我個人傾向于第一種，第一種比較靈活，因?yàn)橛脩粑词盏截浘屯丝畹脑蛞话闩c商品質(zhì)量關(guān)系不大，所以如果允許用戶直接拒收退回，相當(dāng)于商家需要承擔(dān)回退運(yùn)費(fèi)，而本身可能與商家并無太大關(guān)系。

另外一個原因就是，有些商家發(fā)貨地址與退貨地址不在同個地方，不支持直接退回。盡管如此，在到處強(qiáng)調(diào)用戶體驗(yàn)的今天，增加用戶的售后成本也是在消耗用戶對平臺的耐心，大家不妨去思考一下，有沒有更好的解決方法。

用戶拒收：同上。

退貨退款：用戶收到貨后，想要申請售后，則此時需要提供讓用戶輸入售后原因，包括上傳憑證的功能，如果與商家協(xié)商無果，還需要增加平臺客服的入口，方便用戶進(jìn)行申訴。而協(xié)商結(jié)果/申訴成功后直接觸發(fā)自動退款機(jī)制，退款后觸發(fā)消息通知，同時觸發(fā)交易關(guān)閉狀態(tài)，整個售后過程才算結(jié)束。

我上面有好幾處都提到與消息中心的對接，消息的觸發(fā)等，其實(shí)這也算是訂單系統(tǒng)設(shè)計的一部分內(nèi)容，稱之為訂單推送。當(dāng)訂單狀態(tài)機(jī)發(fā)生變化時，需要將對應(yīng)的變化情況告知給相關(guān)人員以便了解當(dāng)前訂單的情況，這也是訂單推送的作用。

3. 訂單推送

訂單推送的觸發(fā)依賴于狀態(tài)機(jī)的改變，涉及到的信息包括：

推送對象（用戶、商家、倉庫）；
推送方式（站內(nèi)消息、push、短信、微信）；
推送節(jié)點(diǎn)（狀態(tài)機(jī)）。
本文主講訂單系統(tǒng)的核心模塊設(shè)計邏輯，訂單推送的具體設(shè)計就不再此處贅述。

結(jié)言

一個訂單系統(tǒng)的設(shè)計絕非這么簡單，它需要一批又一批的人去維護(hù)、去優(yōu)化，根據(jù)公司的業(yè)務(wù)情況做出改變和兼容。

大家平時在做產(chǎn)品設(shè)計的時候可以多深入了解一下公司的具體業(yè)務(wù)場景，這樣才能做出適用自己企業(yè)的訂單系統(tǒng)，自己也才能成長，而不是一直套用別人的邏輯結(jié)果。

本文來源于成都網(wǎng)站建設(shè)公司與成都網(wǎng)站設(shè)計制作公司-創(chuàng)新互聯(lián)成都公司！

新聞標(biāo)題：全方位解析：電商訂單系統(tǒng)頁面設(shè)計
標(biāo)題網(wǎng)址：http://jinyejixie.com/news34/325084.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、品牌網(wǎng)站建設(shè)、網(wǎng)站設(shè)計公司、域名注冊、網(wǎng)站營銷、響應(yīng)式網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)