“先試穿再購買”的電商平臺訂單模塊的重構心得

產品老司機手把手教寫文檔,10天線上課程,零基礎掌握產品經理必備7大文檔撰寫法。了解一下>

當原有系統過于冗雜且原有功能不再適用當前需求時,重構系統的需求油然而生。于是筆者就和我們分享了訂單管理模塊重構的心得。

從事電商行業,是一個女裝類自營電商平臺,結合虛擬試衣技術,和線下試穿服務,為用戶提供一種不用出門就可以享受逛店試穿的服務。

用戶首先購買平臺會員,在會員有效期內可以在平臺上將喜歡的衣服加入試衣盒子,盒子滿5件時可以在不付任何費用的情況下寄給用戶,用戶拿到盒子后,試穿這些衣服,再決定是否購買,然后將不買的衣服裝入盒子再寄回平臺,往返包郵。

這篇文章產生的背景,這篇文章是在做訂單管理模塊重構的時候產生的,好像所有系統建立的第一個版本都是暫時符合現在版本的APP,然后需求越來越多,不停的往原來的系統上加功能。

有一天終于發現加不了了,老系統由于可擴展性太弱,承受不了奇奇怪怪的功能。

于是開始想辦法一個模塊一個模塊地梳理,開始著手重構的事情。

但是此時重構已經工作量巨大,任何一個功能都已經在線上運行,一個都不能砍,耗時巨長。

所以我認為,重構的事情越早進行越好,做不到第一個版本就規劃得很清楚的時候,功能越少,越沒有歷史遺留問題的時候,做重構的事情越好。所以就借訂單部分重構的檔口,來小結下訂單管理相關的問題。

重構必要性:

  1. 當前將單一原始單拆分不同狀態的產品形態已經無法覆蓋所有交易類型的訂單處理。
  2. 將訂單拆分為不同類型,不同類型分別定義后臺狀態,方便不同業務部門有針對性的處理訂單。
  3. 訂單拆分將可擴展性增強,隨著業務形態多樣化,可以在不同類型的訂單及其狀態上優化,如“7天無理由”需求可能涉及的“售后”類型的訂單問題。

重構步驟:

  1. 原始訂單拆分為不同類型的訂單
  2. 分別梳理不同類型訂單的流程和相應狀態
  3. 類比常規電商各節點把控的關鍵信息,并根據業務特殊性將其移植嫁接

先來梳理下常規電商的狀態流轉:

1. 待付款:

用戶選好商品下單,但未付款的狀態。

預判到用戶下一步可能是付款行為,所以在下單同時鎖定庫存,但由于用戶未付款,我們不知道用戶是否會買下,所以倉庫只是暫時替用戶留貨,但不會扣減,當用戶付款后,貨才會真正成為用戶的貨。

但是由于用戶有可能下單但遲遲未付款,被占用的貨不能賣給其他用戶,造成了損失,所以待付款訂單會有實效性,只為用戶保留一小段時間。

這段時間的長短根據不同平臺有不同的考量,比如外賣平臺由于時效性更高,可能只保留15分鐘的訂單;對于服裝電商對時效性要求也是很高,所以通常都會給出24小時的鎖定時間,24小時后再不付款就自動取消訂單了。

2. 待發貨:用戶付款后,商品未發貨的狀態。付款后,庫存扣減,倉庫備貨。

3. 待收貨:倉庫包好商品并交到快遞小哥手中,訂單開始更新物流信息。

4. 待評價:用戶確認收貨后,錢款打給賣家,用戶可以評價訂單。

5. 售后:用戶付款后,不管貨有沒有發出,用戶都可以將錢款退回,此時的退款或退貨申請均作為售后狀態,創建相應的售后工單,會有對應的售后服務人員跟進。

值得注意的是用戶在每個訂單狀態下的退款和退貨行為:

首先,下單未付款狀態下,用戶可以直接取消訂單,訂單終態是“已取消”,不會再流轉至后續的訂單狀態中;

在付款后,未發貨的狀態下,用戶申請退款可以直接退,倉庫攔截出庫成功就可以直接退款,訂單終態也是“已取消”或者叫“已關閉”;

在發貨后,用戶再取消訂單會直接走售后流程,創建退換貨單,推到倉庫,倉庫根據退換貨單給退回的貨品審核并做入庫處理,再給用戶替換出新貨。

以上是常規電商的訂單狀態的梳理,下面來看看我們平臺的訂單中,哪些流程可以直接抄,哪些流程具有自己的特點。

首先,我們的盒子,是一去一來(平臺 → 用戶 → 平臺)是一個正常的流程,因為我們提供的服務是讓用戶挑選5件衣服,打包成一個盒子,然后寄回家中試穿,試好后再決定是否購買,然后再把不喜歡的衣服退回來,而且往返運費全免。

經過一定的調研和統計,最終用戶5件衣服全買的概率是很小的,留貨量在2、3件的用戶居多。

也就是說,退貨的行為是一個常規的行為,退貨發生的概率可以達到九成,盒子的一個來回也可能不涉及交易,而交易訂單也有可能不與盒子關聯(比如購買會員服務或其他增值服務等)。

所以我暫且把盒子訂單和交易訂單分開,此文主要詳細說盒子訂單。我方的盒子訂單正向流程如下圖所示:

一、待發貨狀態

在一般電商中,用戶選貨后進入“確認訂單”的頁面,目的是為了讓用戶檢查所選SKU是否有誤,以及給用戶一個最終決定的過程,因為他的下一步是去付款,要謹慎為好。當用戶確認訂單后,生成交易單,同時鎖定庫存,用戶在一個時間段內支付后庫存扣減,取消訂單或超時未支付則鎖定庫存釋放。

與一般電商相同的是,訂單創建后,要占用實際的庫存,所以看起來確認訂單同時鎖庫存的操作是相同的。

但是,訂單創建后用戶不需要支付任何費用(因為本質是試穿,到貨才可能產生交易),不生成支付單,這是相比于一般電商不同的地方,就是我們在這一步沒有“從支付單創建到支付/不支付”的過程,也就是鎖定庫存的過程。

因此,我們可以不做鎖定庫存的操作。

但是這會遇到的問題是:用戶在選貨到創建訂單那一步,可能會發生選到的SKU被別人選走導致缺貨的情況,這樣就要返回重新選擇,再重新生成新的訂單,體驗不太友好。

所以在沒有支付訂單的情況下,我們是否需要在生成原始訂單前、在選款結束到訂單最終確認前做庫存鎖定操作?

鎖的話鎖定多久?會不會讓別的想要這件SKU的用戶想選的時候可用庫存已經沒了,而猶豫半天的用戶最終又沒要,為這部分用戶鎖定庫存造成了資源的浪費?

考慮到我們初期的庫存很淺,每個SKU最多5件,用戶有很大的概率會在確認訂單時,剛選的SKU被另一個用戶秒下單而缺貨,發生次數多了用戶一定會覺得我們做的是假電商(騙我進來看看又不讓我買那種)。

對于已經進入確認訂單步驟的用戶來說,我們會先檢驗庫存,保證了他們決定下單的SKU一定有貨;對于還未進入確認訂單步驟的用戶來說,沒貨了盡早告訴他們,讓他們心里有數,不會進到確認訂單的步驟,節約時間成本,也不會有太大的負面情緒。

所以我們決定還是為用戶鎖定庫存,在選好SKU后進入確認訂單的頁面同時,我們就為用戶鎖定了庫存。

如果用戶最終確認了訂單后,訂單創建,庫存扣減;用戶如果在確認訂單的步驟中放棄了,訂單創建失敗,鎖定庫存釋放。

訂單創建后,推送至倉庫ERP系統,倉庫確認,并將訂單揀貨通知下發至WMS,由相應的揀貨人員揀貨、包裝、稱重等一系列流程后,最終出庫,交給快遞小哥手中,訂單狀態變為“已發貨”。

二、已取消狀態

在商品發貨前可以取消訂單。訂單創建后創建相應的發貨單,并推送至倉庫WMS,可能已直接發貨,狀態未及時更新,在一般電商中,如果直接給用戶退款,而倉庫已經直接發貨,有可能造成貨款兩失,所以應該先暫停訂單出庫,在倉庫調度中查詢訂單是否推送至倉庫。

若尚未推送,則停止推送;若已經推送,則應該到WMS攔截發貨,暫停出庫流程;若攔截失敗,則應該拒絕“取消訂單”申請,因為訂單已經實際出庫了。

在我們電商的待發貨狀態取消訂單,由于用戶尚未支付,取消訂單也不會發生貨款兩失的情況,所以只要是在商品沒有實際出庫的情況下,我們都是可以直接暫停的,此時庫存會相應的加回來。

以上是訂單出庫之前的狀態,接下來會涉及到的是訂單在路上和反向的過程。

三、已發貨狀態

訂單在快遞小哥手中時會顯示這個狀態,并且根據發貨物流單號獲取物流的動態信息。

一般的電商中,這個狀態下用戶可以確認收貨,若在物流狀態更新為“已簽收”后的一段時間內,比如9天未確認收貨,訂單會自動確認收貨。

我們平臺的訂單不會給用戶主動確認收貨,因為對于用戶來說,他們只是叫了幾件衣服到家試穿,購買行為是后置的。

如果用戶遲遲未購買也未寄回,會造成資源大大的浪費,而且服裝容易過季,超過半個月再返架,返架前還需要運送、審核、清洗等一系列流程,此時的服裝不一定在售了。

所以我們會給用戶一個比較短的時間試穿,并且這個時間以物流信息“已簽收”為準。

但是由于我們接了第三方物流查詢接口,獲取的物流動態做不到實時更新,而且非常有可能是快遞小哥送到了但是用戶沒時間取貨,那如果直接按照物流“已簽收”狀態開始倒計時,用戶也不太能接受。

所以我們定的時間是“從物流更新為“已簽收”的次日凌晨0點開始的72小時”為用戶可以試穿的時間,超過這個時間若未將衣服買下或退回,則訂單逾期,要有相應的記錄,給我們做用戶分層和風控中心做參考信息。

因此,逾期的訂單只要一旦逾期了,就會一直跟著這筆訂單,未必對用戶可見,一方面對那些真的有特殊原因不小心逾期了(比如說,工作日家里沒人,只能預約到周末,但是到了周末就超時了),此時如果用戶看到自己的逾期不良記錄可能會產生消極的情緒;另一方面對于那些惡意買家,給他看到逾期也不會改變什么,所以逾期的記錄只要內部工作人員可見即可。

從本質上來說,一般電商的“確認收貨”基本等于我們的“購買”,因為同樣是確認把錢款付給賣家,一般電商是支付平臺把錢打給賣家,我們是實際收到用戶的款項。

四、已付款狀態

如上所說,我們的購買行為是后置的,用戶只有自己實際拿到貨時才決定是否購買,所以此時交易訂單創建同時不需要鎖定庫存,這是跟一般電商不太一樣的地方。

我們原來是不想做“交易訂單”這件事的,因為當時希望的是用戶盡快地進入付款的流程,多一步操作搞不好就不買了,這是老板提出的論調,我很理解老板的擔心,但這一步存在一定有它的理由:

一般電商需要這一步除了要鎖定庫存外,還要鎖定商品價格、優惠信息,這兩個信息時效性很高,即便我們這步不用鎖庫存,但也要鎖定價格、優惠信息,很有可能用戶下單寄出時是這個價格,到手后要付款了是一個價,實際支付的時候又是另一個價,支付系統也不知道收哪個。

而且我們有些優惠信息時效性更高,可能1分鐘后不真的付款,不創建交易單來鎖定的話,萬一由于網絡原因支付失敗了,返回再重新進入交易流程,優惠信息沒了,豈不是很不開心,后臺開發人員在系統設計時也會創建交易訂單,只是是否對用戶可見。

而且,一般電商都有創建交易單的操作,用戶也已經被市場教育得很認可了,沒有必要再做改變。

接下來,就進入了訂單的反向的流程。如前文提到的,這樣區分是向倉庫方面靠攏,倉庫的各方面業務都比較完善,比如反向流程可能不僅僅是退貨,后續還會有換貨,所有的套路都很完善,所以就撿成熟的方案用起來。下圖是反向訂單流程:

五、待寄回

在我們的平臺中,用戶付好款后(或一件都看不上的),可以直接在APP中預約快遞,只需要填寫上門取件地址和時間,就會有快遞小哥上門取件,取件后,用戶可以繼續叫盒子,保證用戶一次只能叫一個盒子,但是再會員有效期內可以叫多次。

在預約快遞,到快遞小哥實際攬件的狀態為“待寄回”狀態。從這里開始,訂單開始走反向流程,即一般電商中的退換貨/售后流程。

用戶將不需要買的商品勾選好后,預約快遞,選擇取件時間和地址,退貨單創建,同時創建物流單。退貨單創建同時推送至倉庫ERP系統,倉庫操作員根據退貨單號、物流單號、應退商品等信息進行驗貨、清洗以及入庫操作,平臺根據ERP對商品的審核狀態將訂單置為“已完成”。

在退貨單創建前,也就是成功預約快遞之前,都是可以購買商品的,并且可以分多次購買,因為發現女生的購物習慣很不確定,5件衣服中經常會有個一兩件衣服想買但是又不太舍得買,但是放了幾天后想想還是買下吧,有點像淘寶退貨,申請退貨后還是支持用戶取消申請的。

此時一個盒子訂單就可能與多個交易相關聯,這也是把盒子訂單和交易訂單分開的原因,業務的可擴展性增強。

六、寄回中

快遞小哥取件后,到快遞被倉庫簽收的過程為“寄回中”。

七、待審核/異常/已完成

倉庫簽收退回貨品,到驗貨完成之前,訂單狀態為“待審核”。

商品從用戶手中退回的時候不一定全為完好無損的,可能是奇形怪狀的,有的可能沾有口紅印子,有的起球嚴重。

完好無損的貨品是經過清洗、熨燙以及再次包裝的操作后可以直接入庫變為可銷售庫存;奇形怪狀的貨品經過審核后確定無法還原后,不能入庫變為可銷售狀態,只能進入次品倉。

當然相信大部分用戶都是正常用戶,退回的商品基本都是良品,少數用戶會退回次品,也很少有平臺會跟消費者扯皮,通常都是自認倒霉,只是完善的電商平臺會有自己的風控系統,某個用戶退回的次品過多,協商未果,就認為這個用戶信用不好,或是拉黑等等,他們以后的購物也會受到影響。

當然不管是良品還是次品,我們都需要得到一個統計的結果,退貨單中每一件商品都是良品時,訂單自動完成;有次品出現時,訂單會先到“異常”狀態,由客服去協商了解情況后,手動將訂單完成,并填寫備注。

訂單的各個狀態間的流轉就是以上了,總的來說自己摸索著做還是有些難度,但是工作了這兩年現在才算是有了點步入專業的感覺,不是說做出來的系統有多么專業,而是說在摸chao索xi的過程中做到了仔細思考,為什么別人這么設計,這一步為什么不能直接移植過來?要做出哪些改變?這樣設計是最優解決方案嗎?是否還有更完善的方案等等?這才是產品經理應該做到的工作吧。希望以后多做出這些總結,然后跟大家一起成bao長fu!

 

本文由 @Emma 原創發布于人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基于CC0協議。

給作者打賞,鼓勵TA抓緊創作!
評論
歡迎留言討論~!
虎扑足球手机虎扑网 河北十一选五开走势 大乐透甘肃十一选五 陕西快乐10分开奖 安徽快3在线开奖直 5分赛车计划软件 鑫科材料股票行情 幸运飞艇6码技巧图片 海南麻将打牌小技巧 陕西快乐十分几点开机 中国平安股票分析论文 安徽11选5任3最大遗漏 qq四川麻将手机版 山东麻将怎么打 股票配资怎么辨别实盘虚拟盘(假盘) 分分11选5最新下载