從0到1構建電商平臺之訂單系統(1):提交訂單
筆者復盤了電商平臺從0到1的搭建過程,梳理并分析了具體的流程設計,涉及商家系統、商品系統、訂單系統、售后系統、會員系統、營銷系統、財務系統、數據系統等,與大家分享。
最近我經歷了一次電商平臺從0到1的搭建,準備把項目以文章的方式寫出來(除去可能會涉及到公司內部業務流程的地方)。
寫文章的目的,一是為了復盤,重新梳理思路,二是為了寫出來與大家共同學習和討論,設計得不合理的地方(技術的角度或者流程功能的角度)還請大家指出。
電商平臺主要會涉及商家系統、商品系統、訂單系統、售后系統、會員系統、營銷系統、財務系統、數據系統等。我會把訂單系統的文章拆分成三篇,本篇是第一篇。
雖然每個公司的具體需求與業務場景不一樣,我們平臺的功能需求可能其他平臺不盡相同,但整個訂單的產生到結束的,主要有以下3個流程:
本篇文章主要是提交訂單這一步,當用戶停留在客戶端的提交訂單這一步時,會涉及到哪些字段,各字段會有哪些影響,后端的一系列判斷流程
一、字段信息
在該頁面需要提交的字段信息如下圖所示:
二、用戶操作
用戶一系列操作對各項數據的影響:
1. 選擇收貨地址
用戶選擇的收貨地址中的地區會涉及到運費的計算(每個商家有自己的n套運費計算模板,添加商品時會選擇對應的運費模板,不同地區的運費計算會根據商品重量或件數進行計算,相應的介紹在商家系統一文中闡述)
2. 選擇是否抵扣
我們平臺業務上暫未涉及優惠券,但會通過一些渠道獲得相應的金幣,而這些金幣是可以用來抵扣訂單金額的,但是抵扣有多種方式。
比如有多個商品時,從上往下依次抵扣,平均抵扣,但相對最合理的是按商品價值比例進行抵扣,比如有3款商品,分別為20元,30元,50元,而你的金幣正好抵扣10元,按2元,3元,5元抵扣。
需要注意的是,當你的商品總價100元,運費為10元,而金幣可抵扣105元,此時是先抵扣運費再抵扣商品,還是當先把商品金額抵扣完后是否抵扣運費,這就要看平臺的規則或不同的業務場景相應的規則了;
畢竟要涉及到退貨退款,如果用戶是選擇7天無理由退貨,是不會退用戶運費的,此時如果先抵扣運費再抵扣商品,用戶只會損失金幣,而先抵扣商品不抵扣運費,用戶損失的是現金,對用戶的體驗是不一樣的。
3. 選擇是否朋友代付
代付是一套比較復雜的業務場景,會涉及到微信的分享,獲取微信的openid之類的流程,具體在另外的文章中我會寫出來。
4. 選擇是否匿名購買
當用戶選擇是后,用戶對該商品的評價可以根據一定的顯示規則來隱藏昵稱
5. 填寫訂單備注
需要注意的一點是,訂單備注是跟著商家走的,也就是跟著訂單走的(因為會涉及到以商家為維度拆單),所以需要每個商家有一個輸入框。
三、判斷流程
點擊提交訂單按鈕后,此時后臺會進行一系列的判斷。
1. 風控驗證
判斷此次下單是否惡意可以通過一些維度,比如該賬號或ip是否一段時間內重復下單多次,是否有過惡意下單記錄等,這里不做展開。
2. 驗證商品狀態
如果當用戶停留在提交訂單頁面期間,商家下架了該商品,處于已下架狀態,或者用戶選擇的該sku已售罄;所以需要在提交訂單頁面驗證一次。
3. 驗證sku庫存
比如用戶在選擇sku時,購買數量為2件,庫存也剩2件,但此時有另外的用戶搶先購買了1件;所以需要在提交訂單頁面判斷一次庫存是否大于該用戶的購買數量(因為在提交訂單后就會鎖定庫存,所以并不會出現在支付頁面顯示商品庫存不足的情況)。
4. 驗證sku信息是否更改
當用戶停留在提交訂單頁面期間,商家更改了商品的sku信息(比如直接刪掉或修改了金額)并成功上架,此時應提示用戶“商品信息已更改,請重新下單”,并原路返回頁面。
下一篇:“支付訂單”
本文由 @張璨 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
好厲害,可以加大佬微信嘛
zhangcanking
講得很詳細,很有用,謝謝
??
?? ??
寫的很棒,期待后續的文章。
謝謝,哈哈