如何設(shè)計電商訂單系統(tǒng)?
在電商體系中,商品中心、訂單中心、庫存系統(tǒng)為最重要的三大核心系統(tǒng),訂單系統(tǒng)(OMS系統(tǒng))連接用戶和商家之間最重要的交易信息系統(tǒng),本次闡述一下電商訂單系統(tǒng)的產(chǎn)品設(shè)計。
一、訂單系統(tǒng)的作用
1.1 對用戶來說
用戶在下單后實時查看訂單發(fā)貨狀態(tài),物流信息狀態(tài)和最后交易糾紛的售后流程等。
1.2 對商家來說
商家管理訂單狀態(tài),實時發(fā)貨,處理售后糾紛處理等,更好更快的滿足用戶需求,提升處理效率等。
1.3 對平臺來說
在平臺運營上,監(jiān)管訂單,處理平臺介入異常訂單信息,處理需求和供給兩端的糾紛,提供業(yè)務(wù)支撐,實現(xiàn)業(yè)務(wù)閉環(huán),提升用戶價值,完善用戶體驗等。
二、訂單系統(tǒng)的特點
2.1 業(yè)務(wù)類型不同,訂單規(guī)則不同
訂單系統(tǒng)搭建需要考慮實際業(yè)務(wù)情況,分商品實物訂單,虛擬訂單等不同業(yè)務(wù)其訂單系統(tǒng)的設(shè)計區(qū)別都是很大,如:實物商品售賣,付費課程售賣和服務(wù)餐飲業(yè)務(wù)其電商設(shè)計都是根據(jù)實際業(yè)務(wù)劃分。
2.2 流程復(fù)雜,分正向逆向流程
前端用戶下單時正常時的正向流程為從商品下單,發(fā)貨,收貨到最后的訂單交易成功;發(fā)生售后異常時的逆向流程:用戶申請退貨,到退款結(jié)算一系列售后流程;其規(guī)則又有很大的不同。
2.3 信息交互復(fù)雜,邏輯性強
從訂單下單產(chǎn)生的訂單經(jīng)過大約20個不同子系統(tǒng)的一系列信息的流轉(zhuǎn),前端展現(xiàn)簡單的頁面展現(xiàn),可能后端會經(jīng)過大量的系統(tǒng)信息校驗和流轉(zhuǎn)。
三、怎么設(shè)計一個訂單系統(tǒng)
從用戶下單總體流程為:用戶下單選擇下單方式(購物車,直接下單)——訂單下單——訂單拆單——生成訂單查看訂單狀態(tài)——交易成功或申請售后逆向流程等等;商家后臺系統(tǒng)更改訂單狀態(tài),對接發(fā)貨,物流,售后和最終的數(shù)據(jù)統(tǒng)計等。
3.1 下單方式:購物車的設(shè)計(篇幅有限,有機會續(xù)寫)
- 基本邏輯:購物車入口邏輯,購物車商品庫存邏輯(鎖定扣減邏輯),購物車的商品分開展示邏輯;
- 價格計算器:優(yōu)惠類型劃分,優(yōu)惠計算邏輯及展示;
- 離線購物車:登錄加購邏輯,未登錄加購邏輯;
- 立即購買:立即購買流程;
- 異常處理:失效商品邏輯及展示,優(yōu)惠失敗邏輯及展示;
- 其他邏輯:湊單邏輯,商品推薦邏輯,對接的系統(tǒng)信息流轉(zhuǎn)邏輯。
3.2 訂單下單:訂單信息展示
- 用戶信息:用戶賬號,用戶等級;
- 訂單基礎(chǔ)信息:父訂單,子訂單,訂單編號,訂單狀態(tài),訂單時間;
- 收貨信息:收貨地址,收貨人姓名,聯(lián)系電話,郵箱;
- 商品信息:SKU信息,規(guī)格,商品數(shù)量,價格,商品圖片,商家,商品鏈接;
- 優(yōu)惠信息:優(yōu)惠券,促銷活動,虛擬幣抵扣金額;
- 支付信息:支付方式,支付單號,支付狀態(tài),支付時間,商品總金額,實付金額,運費,虛擬幣抵扣金額,促銷優(yōu)惠金額,優(yōu)惠券優(yōu)惠金額,總優(yōu)惠金額;
- 物流信息:物流公司,物流狀態(tài),物流單號;
- 其他信息:發(fā)票信息,下單平臺,分銷渠道。
3.3 訂單下單:訂單拆單
下單時拆訂單:父訂單拆子訂單
- 平臺的不同店鋪商家需拆單:因為涉及到商品歸屬權(quán)不同,其財務(wù)結(jié)算,發(fā)貨情況不同所以需要拆單;
- 倉庫不同,需要拆單:一物多倉的情況下,可能按照地域時效選擇倉庫發(fā)貨物流信息不同需要拆單。
支付后拆發(fā)貨單:子訂單拆多個包裹
- 品類特殊包裝要求需要拆單:如易碎品需要特殊包裝,超大物品需要單獨包裝,有些不同品類的商品不能放在一起;
- 物流因素,超過物流運輸限制需要拆單,如超過規(guī)定物流公司重量需要拆單;
- 商品價值:海淘商品消費限額,貴重物品商品價格高需要單獨發(fā)貨,需要拆單。
3.4 訂單下單:訂單的計算
- 訂單實付金額=商品總金額+運費-商品優(yōu)惠總金額
- 商品優(yōu)惠總金額=優(yōu)惠券+促銷活動+積分抵扣+會員抵扣
3.5 生成訂單:訂單狀態(tài)
不同業(yè)務(wù)類型商品訂單狀態(tài)不同,實物商品訂單和虛擬商品訂單狀態(tài)都有所不同,訂單狀態(tài)最重要的是各個時間節(jié)點的數(shù)據(jù)流轉(zhuǎn),這里介紹下實物商品訂單的訂單流轉(zhuǎn)狀態(tài):
待付款:用戶提交訂單,尚未付款,等待用戶支付,由于待付款狀態(tài)會鎖定庫存,所以一般會設(shè)置超時自動取消;
待發(fā)貨:用戶付款之后,等待商家發(fā)貨;
待收貨:商家已發(fā)貨,等待用戶收貨;
交易成功:用戶確認(rèn)收貨后,訂單已完成交易;
已取消:付款之前取消訂單,超時未付款或用戶自動取消訂單都會產(chǎn)生這種訂單狀態(tài);
售后中:用戶在付款后發(fā)貨前申請退款,或商家發(fā)貨后用戶申請退換貨狀態(tài),需要注意的是售后狀態(tài)也有單獨的訂單流轉(zhuǎn)狀態(tài):待審核,待退貨入庫,待退款,待換貨入庫,換貨出庫中,售后成功;
交易失?。寒?dāng)售后完成后的訂單狀態(tài),”已取消“的訂單狀態(tài)可以合并到“交易關(guān)閉”中。
3.6 訂單的售后:訂單逆向流程
訂單的逆向流程可以是用戶主動發(fā)起或者客服發(fā)起,需要注意的是不同節(jié)點申請退換貨,系統(tǒng)的處理方式不同,逆向流程復(fù)雜,還涉及到優(yōu)惠分?jǐn)偡颠€的邏輯,這里不詳細介紹,以下為各個時間節(jié)點的訂單售后流轉(zhuǎn)情況:
待付款取消訂單:用戶提交訂單后,主動取消訂單或超時未支付時候,訂單狀態(tài)為“已取消”;
待發(fā)貨取消訂單:用戶支付訂單后,到“待發(fā)貨”狀態(tài)時,用戶申請取消訂單需要判斷數(shù)據(jù)到哪個環(huán)節(jié)了,訂單未到調(diào)度中心和就在調(diào)度中心未下發(fā)到倉庫管理系統(tǒng)或從調(diào)度中心到了倉庫管理系統(tǒng)(WMS系統(tǒng))但攔截下來了,則可以取消成功;否則取消失敗,訂單繼續(xù)發(fā)貨;
待收貨/交易成功取消訂單:收到貨物后,當(dāng)SKU全退時,原訂單變成“交易關(guān)閉”;當(dāng)發(fā)生訂單部分退貨,退款時候,原訂單保持不變,維持“待收貨”或“交易成功”狀態(tài),同時生成部分售后訂單,剩余的訂單還可以進行售后。
3.7 訂單的數(shù)據(jù)統(tǒng)計
訂單交易維度:
統(tǒng)計周期內(nèi)訂單銷售額(GMV)【最重要】
訂單量:統(tǒng)計周期內(nèi)訂單量
客單價:統(tǒng)計周期內(nèi),已支付的訂單平均金額
下單用戶數(shù)支付用戶數(shù),訂單金額分布,地域分布等等
商品分析維度:
被下單的商品數(shù):統(tǒng)計周期內(nèi),被下單數(shù)>0的上架商品總和
被支付的商品數(shù):統(tǒng)計周期內(nèi),被支付訂單數(shù)>0的上架商品總和
被訪商品數(shù):統(tǒng)計周期內(nèi),被訪問uv數(shù)>0的上架商品總和
商品收藏次數(shù),商品銷售統(tǒng)計,加購件數(shù)等等。
訂單來源維度:
統(tǒng)計每個訂單的來源:如H5,公眾號,APP,小程序,pc端;
記錄每個訂單的產(chǎn)生過程,包括在創(chuàng)建之前的商品瀏覽,加入購物車,提交訂單等關(guān)鍵路徑的數(shù)據(jù)分析;
追蹤訂單來源:包括來源的網(wǎng)站,關(guān)鍵詞,來源網(wǎng)站等等。
四、總結(jié)
訂單系統(tǒng)與各個系統(tǒng)之間信息交互復(fù)雜,要求邏輯思維能力較強,對于產(chǎn)品設(shè)計來說,邏輯比具體的原型頁面更為重要,需要考慮每個節(jié)點具體的前置后置條件,流程設(shè)計是否足夠容易理解、易用。
每個系統(tǒng)產(chǎn)品設(shè)計時候都要根據(jù)實際業(yè)務(wù)情況分階段完成,按照用最小化成本設(shè)計產(chǎn)品,實現(xiàn)業(yè)務(wù)需求,例如實物商品訂單系統(tǒng)中訂單狀態(tài)欄待付款,逆向流程中退換貨中換貨狀態(tài)等等開始也可以先不用設(shè)計,后期根據(jù)業(yè)務(wù)實際情況在進行設(shè)計。
訂單系統(tǒng)具體的界面復(fù)雜,不同業(yè)務(wù)模式下其設(shè)計特點很大差異,多參考不同業(yè)務(wù)類型下的訂單系統(tǒng),門檻低的如淘寶,有贊,拼多多等等電商前后臺訂單系統(tǒng)搭建。
篇幅有限,歡迎大家交流社交語音產(chǎn)品,電商前后臺產(chǎn)品的產(chǎn)品設(shè)計,VX:1332616842;共同交流學(xué)習(xí),謝謝!
本文由 @十甫君 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議。
?
WX少一位…
講的比較全面,干貨滿滿 謝謝大佬!
請問大佬~ 有關(guān)于子訂單的問題,用戶在同一店鋪下單,因為是批發(fā)購買量大一個物流包裹發(fā)不完,需要多個物流包裹,這樣就需要將這個訂單拆為多個子訂單,那么這樣的話發(fā)貨的物流編號對應(yīng)的應(yīng)該是子訂單號。但是如果不需要進行拆單的情況下,物流單號就直接對應(yīng)訂單編號嗎,還是說一個訂單編號必須要有一個子訂單號,物流信息只對應(yīng)子訂單號?
多個包裹也應(yīng)該是同一物流單號吧,為什么要拆單呢,如果如果真的出現(xiàn)了多個物流單號的情況,展示一個應(yīng)該也是沒有問題的吧,兩個報過一定是同步發(fā)出的啊。
兄弟,可以參照有贊的做法,我個人覺得不錯的,就是一個訂單對應(yīng)多個子訂單,發(fā)貨物流是按照子訂單來走,這樣的話,你的問題即可解決了
兩個方案:
1.訂單綁定物流號,按照商品維度綁定,前端用戶展示時 根據(jù)物流號進行綁定,例如3個商品(一個SKU多數(shù)量同理),分別拆成2個(A組)和1個(B組),上傳物流號時傳入A組商品的物流號1,B組傳物流號2,前端做邏輯處理展示,具體方案有很多,可以是點擊訂單查看物流,出現(xiàn)2個物流單里面再展示商品,也可以是A組綁在一組,點擊查看物流展示該組的物流軌跡
2.銷售訂單是給C端用戶使用,商家側(cè)應(yīng)將其轉(zhuǎn)化為包裹單,原理跟上面商品分組類似,只是設(shè)計方案不同罷了,目前主流是包裹單形式。
問一下大佬你們的訂單涉及到商家發(fā)貨么,電子面單如何做~
請問大佬,如果是同一自營倉庫同一時間出單的是不是就沒必要拆分訂單了呢?
肯定需要拆啊,只有拆了才能讓整個流程清晰可見,倉儲管理哪兒才是清晰明了
這個也要視具體情況而定。比如超大件要拆單。比如床品和桌椅板凳。這個就是樓上提到的多個包裹問題。
再比如,包含生鮮食品和非生鮮食品,因為涉及到的退換貨規(guī)則可能是不一樣的。
需要的,上文不是說了拆單的原因之一:物流因素,超過物流運輸限制需要拆單,如超過規(guī)定物流公司重量需要拆單,比如一些跨境電商,要求單個包裹重量是不能超過規(guī)定的