訂單系統是後台系統中較為重要的一部分,它記錄了所有的交易,以下就來總結一下訂單管理後台系統的設計。
一、訂單系統主要流程
首先,訂單從創建到完成的整個流程,基本可以分為未付款、已付款待發貨、已發貨和已收貨四個階段。 而在這整個流程中,涉及到的其他模塊主要有支付和庫存。 以下就先介紹一下訂單在各個階段需要考慮的點:
下圖為整個訂單的簡易運轉流程:
說明:在實際操作訂單中,可能還會有滿減、滿贈、優惠券、活動活動、積分等情況,所以訂單信息一般不會只包含了商品總額,大多數情況下,訂單金額=商品金額 +運費-優惠-積分抵扣。 所以,在用戶申請退款/退貨時應退金額計算就會麻煩一些,究竟如何進行扣除和退款,每個企業都有自己的一套規則,只要按照規則計算即可。
二、後台頁面設計
上面概述了訂單運轉的流程,現在來說一下後台頁面的設計。 訂單系統後台主要是對訂單進行監控和管理的。
1、從內容上來說,主要包括商品信息、支付信息、物流信息等,如下圖所示:
- 上圖只是簡單的整理了一張C端線上用戶創建的訂單所需的信息,但在實際公司業務中,可能還會涉及到向經銷商直接供貨的情況,可能是線上,也可能是 線下,但即使是線下,訂單也是需要進入到系統的,因此在設計時,需要實現了解業務操作的細節;
- 如果是線下訂單,需要考慮訂單的創建人可能會是哪些角色,不同角色創建的訂單流程也會有所不同;
- 權限問題;
2、從結構上來說,訂單頁面其實也就是個列表頁,主要可分為搜索區、列表區和操作區。
(1)搜索區域:
在訂單列表中,因為涉及到的信息和狀態比較多,所以為了提高工作效率,需要將常用的重要的條件作為篩選項,以便於快速查找。
一般情況下,搜索區域主要包括:訂單編號、訂單狀態、付款狀態、退款狀態、交易時間、支付渠道、平台、區域等,根據業務範圍而定,當然,顯示哪些條件,還要看權限等級 。
(2)列表區域:
前面已經介紹了訂單詳情,包含的信息較多,所以後台列表中不可能直接顯示訂單相關的所有字段,此時就需要有所取捨,選擇比較重要的字段比如訂單編號、支付流水號、訂單狀態 、退款狀態等信息、以及操作欄。 而剩餘的其他信息,可以通過下級頁面來顯示。
(3)操作區域:
對於訂單的操作,基本上就是一些處理、確認、審核的工作。
三、其他補充
訂單系統作為後台系統中的關鍵模塊,可大可小,主要還是要根據業務的不同而定。
- 比如說,文中講到的只是比較簡單的流程,而實際上,在訂單的處理中,還需要考慮很多情況:
訂單是否需要拆分:比如OTA中的訂單系統,一張訂單可能會被拆分為酒店子訂單和各種單項子訂單,而這些子訂單有可能是由不同的人去處理,而且有的時候 是需要支持客服人員可以在訂單中繼續增加子訂單的,電商平台也一樣,通常都會包含一個主訂單號和多個子訂單號,這時就需要考慮在退貨/退款時是否支持根據子訂單 的維度退款; - 訂單的取消:除了用戶,內部人員在哪些情況下可以主動取消訂單,而該種情況下取消訂單,流程該如何操作,又該給用戶怎樣的反饋;
- 產品/商品來源:在用戶下單前,是否已有庫存,當然,在一般的電商系統中,基本上都是已經有庫存才可以售賣的,但比如在OTA這樣的訂單系統中,產品即 服務,是具有不確定性的,所以在生成訂單的時候,同時要根據其子訂單生成對應的供應商訂單,用戶下單後,企業再去向供應商下單預訂,其實就比較類似於代售 的情況;
- 訂單生成規則:一般情況下,商品的來源和渠道各不相同,很多時候為了便於區分,可能就需要在訂單的生成規則裡加入一些特殊的字符進行標識;
- 活動訂單:當平台在做活動時,商品的價格一般都會出現大的波動,那麼就需要考慮此時下的訂單是否需要單獨管理;
由於訂單系統的設計與業務範圍和流程聯繫比較緊密,因此文中僅對主要流程做了總結,不足之處歡迎補充!
相關閱讀
本文由 @姜蕁 原創發佈於人人都是產品經理。 未經許可,禁止轉載。
題圖來自 Unsplash,基於 CC0 協議