首页
/
每日頭條
/
科技
/
電商訂單管理系統設計思路
電商訂單管理系統設計思路
更新时间:2024-11-16 06:33:22

傳統電商依托于線上流量産生消費者,新零售則是通過網上商城、小程序以及其他應用程序相結合形成網店,同時與線下實體門店和現代物流進行深度整合,最終形成了新的銷售模式。


訂單管理系統上下遊對接系統繁雜,包括:商品中心、客戶中心、營銷中心、支付中心、庫存中心、财務系統等。


通過訂單中心,可以實現線上定單、線下定單、外部定單的統一管理。并完成訂單收錄,實現訂單合并和分拆,門店/倉庫匹配等。


本文從 “訂單管理”實際運用場景出發,深度解析新零售訂單的設計思路。


訂單管理系統總體框架


訂單管理以信息、資金、物流為基礎,貫穿于整個訂單生成到完結的運作過程。


信息是指在訂單中由各種系統組合而成的交易信息,同時又通過完整的交易鍊,從商品交易到付款,再到結算。以成本、效率、體驗為維度,通過線上線下的深度融合,為用戶提供最佳的服務,而配送方式和支付方式是服務的基礎。


同一時間的訂單中包含着多種信息,因為有了這些數據,訂單才真正形成。根據訂單類型對訂單來源進行識别、标記處理,以提高訂單查詢效率,幫助運營統計不同維度的成交。


資金指用戶通過交易形成的資金流,通過賬戶餘額,或其他支付渠道,形成未結算/已結算資金的。


物流代表形成訂單後商家對用戶形成的服務實體,同時結合渠道、類型、服務、信息,從而形成一個完整的訂單系統。


訂單管理系統主要流程


新零售是線上 線下相結合的方式,在數據方面必須同步,包括了商品的售價、商品的庫存、商品的SKU,同時會員信息也要保持同步,已經在線上注冊的會員,在線下同樣也能享受到會員帶來的權益,另外無論是線上訂單還是線下訂單都需要統一放在訂單中心進行管理。


一、線上訂單處理

網上訂單涉及系統模塊較多,包括:商品、顧客、訂單、支付、結算、庫存等系統,還存在客服、 WMS等系統。


訂單管理過程環節更多,包括售中、售後、客戶維權、投訴等環節。


線上訂單的方式包括三種:

ü後台處理:找到對應的銷售訂單進行處理(發貨、提交總部改派、退款/退貨);


ü收銀機處理:收到網店的銷售訂單後,收銀機出現預警提示,找到銷售訂單模塊進行處理;


ü商家端APP:為了提高商家處理訂單的效率,在商家端APP同樣配備了銷售訂單處理功能。

電商訂單管理系統設計思路(訂單管理系統設計)1


二、線下門店訂單

正向下單流程:基于線下門店購物場景


到門店選擇商品——收銀台結賬——通過收銀機掃碼進入訂單——計算優惠信息——選擇付款方式——成交形成訂單信息——商品出庫處理。


電商訂單管理系統設計思路(訂單管理系統設計)2

反向取消訂單流程:可以通過流程取消訂單,以覆蓋更多的特殊消費場景。


收銀機選擇退款,退貨,換貨等方式來處理,


門店在處理線下訂單時直接通過人工收銀機或自助收銀機進行處理,收銀機的功能包括:


ü掃碼識别會員身份(或手機号碼識别)、識别商品信息、辦理會員;


ü處理線上銷售訂單和門店訂單;


ü掃碼核銷到店自提訂單、電子卡券、虛拟商品等;


ü會員儲值(儲值餘額/儲值卡);


ü基本收銀功能(交班、收銀、查詢);


ü活動促銷打折(限時折扣、滿減送、打包價、加購價、第二件半價、贈品)跟營銷系統相關。


訂單管理系統模塊


顧客管理:根據顧客信息匹配會員權益,同時檢測虛拟資産信息,如紅包、卡券、積分等;活動管理:獲取促銷信息,通過實例判斷用戶現有的優惠券是否滿足減免條件,以此計算優惠信息;


商品管理:查詢網店/門店商品,包括 SKU,價格,規格等信息;


訂單管理:通過顧客中心,市場中心,商品中心,顧客中心等計算出支付訂單的最終數量,生成訂單後系統進行拆分邏輯,包括優惠信息拆分,訂單拆分,最後進入 WMS和财務系統;


資産管理:顧客完成下單後形成未結清/已結清的資金,并對各門店/倉庫進行資金核對;


财務管理:當各門店産生銷售訂單時,财務系統将其拆分,并将銷售訂單拆分,将訂單拆分,将訂單拆分到 WMS和财務系統。


報表管理:對用戶生成的一系列數據進行彙總處理,從頁面浏覽,到訂單成交,通過數據分析,幫助商家做出判斷,從而做出更加明智的決策。


1)經過數據收集和分析,分析出商品推廣量、商品深度、商品淘汰率、商品暢銷度、季節商品等多項指标,指導商家調整商品結構。


2)對不同倉庫/門店的商品、品類的銷售排行和付款情況進行分析,針對重點指标和異常指标進行趨勢分析,幫助商品挖掘出新的增長點,查找出異常原因。


3)利用顧客信息資料了解顧客需要,分析顧客特點,評估顧客價值,為顧客制定相應的營銷戰略和資源配置計劃,發現潛在顧客,以進一步擴大業務,促進企業的快速發展。

‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

訂單管理系統原型


一、下單流程

買家在商城選擇要購買商品,下單,商家收到訂單生成通知後在後台确認付款,或買家在前端确認付款:


後台訂單詳情頁:


電商訂單管理系統設計思路(訂單管理系統設計)3


前端訂單詳情頁:


電商訂單管理系統設計思路(訂單管理系統設計)4


☛當買家下單未付款時,商家可以在“訂單管理-待支付訂單”進行訂單改價操作。


後台 “修改價格”功能:


電商訂單管理系統設計思路(訂單管理系統設計)5


前端改後顯示新價格:


電商訂單管理系統設計思路(訂單管理系統設計)6


☛買家付款後,商家收到訂單付款通知并備貨後進行處理。


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)7


☛商家查看确保信息無誤,則可回到待發貨列表中或在訂單詳情中點擊【确認發貨】。


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)8


☛商家發貨之後,訂單變成“待收貨狀态”


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)9


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)10


☛等待商品到達買家手中,買家确認收貨或因買家不确認收貨,商家可以在後台确認收貨。


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)11


☛确認收貨之後訂單狀态會變為“已完成”狀态


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)12


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)13


在“已完成”狀态下,買家可對商品進行評價,商家在扣台查看評價的商品信息及會員信息、評價等級、評價時間。


☛買家在商城選擇購買商品,提交訂單且未付款并取消,訂單變為“已關閉”狀态,商家可查看相應訂單。


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)14



二、退貨退款流程

Ø“已收貨”狀态下的退貨退款流程

☛買家收到貨後申請退貨退款時,前端申請流程如下。


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)15


☛商家可查看到買家申請售後的訂單,點擊查看詳情。


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)16


處理退貨申請,通常有三種處理結果:


ü一駁回

ü二通過申請(需要客戶寄回退件)

ü三同意退款(無需客戶寄回商品)--該處理結果的前提條件是買家寄回退件,商家收到退件,确認商品後,方可退款給買家。


駁回:退款退貨信息有誤,商家駁回讓買家重新申請。


前端審核詳情顯示已駁回,如下界面


電商訂單管理系統設計思路(訂單管理系統設計)17


☛商家通過申請後,買家會收到審核通過的通知,“退款中”的訂單狀态變成“待退貨”狀态,可查看詳情填寫退貨的快遞單。


商家後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)18


前端審核後界面:


電商訂單管理系統設計思路(訂單管理系統設計)19


☛商家收到買家寄回的退件,确認無誤後可在退貨申請處同意退款或者手動退款


後端界面:


電商訂單管理系統設計思路(訂單管理系統設計)20

電商訂單管理系統設計思路(訂單管理系統設計)21


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)22


手動退款後台訂單處理結果顯示界面:


電商訂單管理系統設計思路(訂單管理系統設計)23


☛商家同意退款後,常見退款通道規則:


買家如果選擇微信支付方式則會退款到買家的微信零錢或銀行卡中,


買家選擇的是餘額抵扣則退款的金額會到買家的商城用戶餘額中,


買家選擇的是其它方式的支付(比如支付寶支付),退款金額則會到買家的微信錢包中(需商戶平台中的确保餘額),


買家選擇的是積分抵扣的話,則退款的金額就會到買家的商城積分中。


☛商家如果選擇的處理結果為“手動退款”,則需要商家與買家進行線下溝通進行其他方式的退款,則此申請的售後訂單會完成退款處理。


如果商家收到貨後,商品因買家個人原因有損壞,可選擇“駁回”,需要寫明原因,确認後,買家會收到駁回通知。則由雙方協議


Ø“待收貨”狀态下的退貨退款流程

☛當賣家已發貨且買家未收到貨時,提交申請後。


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)24


☛商家查看買家申請售後訂單,理退款申請。


1)買家申請售後時選擇“僅退款不退貨”處理方式


買方和賣方協議好退款不退貨即為商家已聯系快遞員并攔截派送,物件會被派回到賣家那邊。則後台處理退款申請需按“同意退款,無需客戶寄回商品”為處理結果


電商訂單管理系統設計思路(訂單管理系統設計)25

前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)26


2) 買家申請售後時選擇“退款退貨”處理方式有兩種情形:


一若賣家無法攔截快遞,則會跟買方協議讓買方拒收商品,物件即會被派送回賣方。


二買方收到貨物卻未點擊确認收貨按鈕,則後台處理退款申請需要按“通過申請,需要客戶寄回商品”為處理結果。


電商訂單管理系統設計思路(訂單管理系統設計)27


☛商家收到買家寄回的退件,确認無誤後可在退貨申請處同意退款或者手動退款,


如下以同意退款為例


電商訂單管理系統設計思路(訂單管理系統設計)28


商家同意退款後,前端訂單顯示“已退款”


電商訂單管理系統設計思路(訂單管理系統設計)29


Ø僅退款流程

☛如買家支付訂單且未發貨的狀态下,可申請退款。選擇“僅退款不退貨”,一般沒有填寫/選擇退款理由,無法提交成功。


前端界面:


電商訂單管理系統設計思路(訂單管理系統設計)30


☛提交申請後,商家查看相應訂單,處理退款申請。


後台界面:


電商訂單管理系統設計思路(訂單管理系統設計)31

電商訂單管理系統設計思路(訂單管理系統設計)32


四、換貨流程(針對已完成訂單)


☛買家若已确認收到貨,買家申請售後進行換貨,提交申請後,訂單會顯示“退款中”狀态


前端界面


電商訂單管理系統設計思路(訂單管理系統設計)33


☛商家可看買家換貨訂單,處理退款申請。


電商訂單管理系統設計思路(訂單管理系統設計)34

電商訂單管理系統設計思路(訂單管理系統設計)35


處理結果有三種:


ü一駁回,

ü二通過申請(需客戶寄回商品),

ü三确認發貨(無需客戶寄回商品)


處理換貨訂單,首先需要買家先寄回商品,商家收到貨後确認無誤方可發換貨商品給買家。


處理換貨申請,選擇通過買家的換貨申請,收件地址選擇默認,也可自定義地址。


☛買家的換貨申請審核通過後會收到審核通過的通知,可在已完成訂單、待退款訂單中查看訂單審核詳情。


前台界面:


電商訂單管理系統設計思路(訂單管理系統設計)36

電商訂單管理系統設計思路(訂單管理系統設計)37


☛商家收到買家寄回的商品,确認無誤後在換貨訂單确認發貨,即直接發送換貨的商品。


買家訂單狀态為“待買家收貨”界面


電商訂單管理系統設計思路(訂單管理系統設計)38



,

Comments
Welcome to tft每日頭條 comments! Please keep conversations courteous and on-topic. To fosterproductive and respectful conversations, you may see comments from our Community Managers.
Sign up to post
Sort by
Show More Comments
推荐阅读
手機屏幕哪家好一點
手機屏幕哪家好一點
我們一直都說,所謂的性價比,其實無非就是在各個環節摳來摳去,最後将成本省了下來。一款手機如果顯得很便宜,那麼肯定是有便宜的道理,不是這裡節約了用料,就是那裡采用了廉價的配件。畢竟廠商也不是做慈善的,一款産品總是要賺錢的,隻是賺多賺少而已。就...
2024-11-16
電腦聯網之後網速很慢
電腦聯網之後網速很慢
電腦聯網之後網速很慢?如果電腦配置過度,即便網速再好,也同樣會出現打開網頁很慢的情況,因此假如網速測試很快,但打開網頁很慢的話,建議查看下電腦配置如何,一般而言,雙核配置以上電腦打開網頁均會十分流暢,但對于那種老爺機,依然沿用老賽揚單核+5...
2024-11-16
想做軟件開發需要哪些知識
想做軟件開發需要哪些知識
想做軟件開發需要哪些知識?開發APP是一個系統的過程,往往需要做一些前期的準備工作,這些準備工作會在很大程度上決定後續APP開發是否會順利,準備工作包括以下内容北京木奇移動技術有限公司,專業的軟件外包開發公司,歡迎交流合作,現在小編就來說說...
2024-11-16
何謂aeb自動刹車系統
何謂aeb自動刹車系統
【環球網科技報道記者樊俊卿】近年來,自動駕駛日漸走進普羅大衆視野。也許在不遠的未來,無人駕駛汽車将完全改變當前我們通勤的方式。為了盡早實現這一願景,全球多家汽車制造商與科技企業在這一技術上投入了大量的資源,推動着這一技術的快速發展。但你可能...
2024-11-16
陸金所風向标
陸金所風向标
圖片來源@視覺中國文丨十字财經,作者丨李意安經曆了近兩年時間的打磨,陸金所的“去O”計劃終于進入了最後沖刺階段。2018年二季度,“去O”正式立項。陸金所組建了一個近40人的技術小分隊專注于“去O”進程。“眼下已經完成了将近95%,預計到今...
2024-11-16
Copyright 2023-2024 - www.tftnews.com All Rights Reserved