自己從0到1探索電商系統搭建——訂單業務的正向邏輯梳理
在電商系統中,“訂單”是基本存在的環節之一,構建訂單的意義之一,就是讓客戶看到交易全流程并心中有數。那么,怎么構建訂單呢?這篇文章里,作者分享了構建訂單的四個邏輯,一起來看看吧,或許會對同樣做電商系統或訂單系統的你,有所幫助。
訂單在線下客戶即時購物場景是不存在的,比如小區樓下街邊的水果攤,賣家和買家在交易時,都在一個交易場景中,我和商家直接說好價格,一手交錢,一手交貨,就結束了整個交易過程,連售后都沒有,一張單子都不需要。
在電商里,其實也可以不需要訂單,我們每次線上交易,就是一錘子買賣,我連購物記錄都不需要生成,客戶只要登陸看到想要的東西和便宜價格,直接付錢,然后沒有訂單環節,直接就顯示支付完成,就結束了,客戶收到一個派送中3天不達必賠的短信就行??蛻舾静魂P心我幾點發貨,等收貨就行,只不過沒有派送流程可視化的用戶體驗而已。
我相信肯定是有這樣的客戶的,但是,畢竟是少數,不成規模,電商做的是全世界用戶的生意(交易需要升華,野蠻人得打領帶了)。
所以,訂單的第一個基本意義就是讓客戶看到交易全流程做到心中有數。
構建訂單的第一個邏輯——告訴客戶他一定能買到
在我APP剛起家的時候,為了流程透明,客戶點擊購買的時候,我得讓客戶知道他能否買到這個商品,有貨不是最重要的,讓客戶自己知道是不是他一定能買到這很重要。
這牽扯到很多環節……
當客戶點擊購買按鈕——開啟購物環節檢查。
- 環節一 :客戶APP的登錄信息還有效么?找不到客戶信息我怎么知道誰買的,檢查客戶的的狀態。
- 環節二 :商品的狀態,是否在售,是否有貨,有就鎖定。
- 環節三 :配送地址是否完善且在配送覆蓋范圍,必須在配送能力范圍。
信息一瞬間都確定了,就可以生成訂單,客戶看到訂單并付款成功一定買到所選商品。
PS:如果訂單失敗,就兩種原因,我們的檢查環節出問題了,或者是客戶付款失敗。
能不能讓客戶先收到貨,只要客戶在我們規定的周期內付款,就可以呢?
目前不行,我們沒有能力確??蛻舨慌苈?,或者跑路可以追回損失。因此我需要即時到賬,及時回籠資金來投入到建設中。
如果客戶購買了很多好東西,想分期支付,我支持分期嗎?
心里是支持的,畢竟賣出去不容易,但是,初創企業有資格和支付公司洽談分期業務嘛?肯定是沒有的。而且利息問題好復雜的,還有等額免息、抽成比例等等,想達成合作還沒到業務體量。
構建訂單的第二個邏輯——讓客戶看到訂單全貌
1. 商品購買頁面
當訂單生成的時候,訂單應該包含哪些信息?如果訂單喚起支付頁面,客戶付錢關閉了支付頁面,訂單應該何去何從?到底是人性的扭曲,還是客戶的淪喪。請走進今天的節目《瘋狂的訂單》。
2. 訂單包含哪些信息?
商品信息:客戶看到自己買了啥,什么規格,買了多少,單價多少。
必備信息:商品名稱,商品規格,商品數量,商品單價。
物流信息:客戶看到自己寄給誰,寄到哪,怎么聯系。
必備信息:收件人,收貨地址,收件人電話號碼。
配送信息(非必須):客戶看到發貨快遞,打包發貨時間,預計送達時間,快遞運費。
非必備信息:快遞公司,發貨時間,能否免運費,送達時間。
PS:盡量減少非必要信息騷擾客戶,讓客戶知道一定買到一定送到即可,但是,可以加。
支付信息:客戶看到自己用啥付的,啥時候付的,付了多少。
必備信息:支付渠道,支付時間,實付金額。
生成信息:客戶看到自己下單時間,下單狀態。
必備信息:下單時間,訂單狀態。
案例:
構建訂單的第三個邏輯——訂單的拆分與組合
這是一個關乎到成本的問題,因為成本的構成很復雜,不同因素導致成本都會不一樣。
- 因素一:商品的規格差別很大,有按包,片,塊,盒,箱,桶,條,件等。
- 因素二:商品的體積差別很大,有小如綠豆,中如茶幾,有大如冰箱,彩電。
- 因素二:商品的價格差別很大,有只需幾塊的,有需要幾千的,有需要幾萬甚至幾十萬的。
- 因素三:商品的重量差別很大,有輕不到10g的,有超過5公斤的,有高達幾十斤上百斤的。
- 因素四:商品的存放差別很大,有所有貨都在一個地區倉庫的,有不同貨在不同地區倉庫的。
- 因素五:用戶的地址差別很大,發達地區的用戶,用的倉庫基本相同,不發達地區,倉庫基本不同。
- 因素六:商品的材質差別很大,有易碎易潮濕易腐蝕的,有忌干忌熱忌凍的,性質不同。
要想企業獲得競爭力,就要不斷優化成本,來獲得利潤空間,因為永遠有人用低價干你。
但是,初創企業是沒有太多用戶,更別提海量用戶數據了,那么我們應該如何布置倉位來讓運輸成本最小化呢?就需要借鑒其他成熟的企業的調研報告數據,不同品類的用戶畫像,不同地區的倉庫特點及成本,不同快遞公司的合作模式和起量單價。
目前,各家快遞公司競爭激烈,3天送達是標配,重量和體積的計價方式大同小異,價格誤差不超過1-2塊,再根據數據參考和自身特點,預估消費人群分布,了各類貨物的銷售量占比,我們在全國浙江(南方),陜西(西北),河南(中部)布置了幾個不同倉庫輻射全國,又根據商品的材質和特性,決定了拆單的維度 :1.用戶地理位置。2.商品材質。3. 包裝成本。
偏遠地區不發貨,企業前期需要低價專注于拿下60%的中南部地區核心消費人群。
因為中南部地區陸運濕度,溫度較高,會把材質要求高的(紙制,金屬等),包裝精細,體積大的,客單價高的商品,布置在陜西偏南部的倉。
材質要求低(石頭質地),包裝成本低,體積重量中等,客單價中低的放在浙江倉。
中型貨物,材質中等(木頭,藤蔓等),重量不超過10公斤的,包裝中等,放在河南倉。
未來根據大量實際成交數據來計算調整倉儲,物流,和貨物存放配比。
客戶的下單習慣——合單支付與父子訂單
如果客戶在APP購物車里面選擇了超過兩件的商品,這幾個商品可能在同一個倉庫,也可能在全國不同的倉庫,而且商品的發貨時間和順序也不確定。
情況一:客戶是全國有很多住所,客戶不固定住在一個城市,而且經常買東西送給全國很多朋友。帶來的變化就是客戶有不同的IP,不同的收貨地址??蛻裘總€商品都下一單。
情況二:客戶固定在一個城市活動,只有一個收貨地址,但是,每個商品都下一單。
情況三:客戶固定在一個城市活動,只有一個收貨地址,所有商品全都一單支付。
合單:
客戶下了多個訂單,但是每個訂單的收貨地址都是同一個,商品也都在同一個倉庫,會把屬于這個客戶的商品在后臺合成為一個訂單,一次物流打包發貨,確保客戶同時收到且降低費率。
客戶可能看到,商品發貨地,發貨時間,快遞公司都一樣。
拆單:
當客戶一次支付多個商品,訂單根據客戶的收貨地址和購買商品特征及最近倉庫所在不同地區,拆分成兩個或多個子訂單,保證每個訂單的成本都是最優解。
這里有一個很重要的用戶體驗問題,叫峰終定律,就是顧客的滿意和失望是兩個極端,要么很滿意,要么很失望。沒有中間態。
所以,確??蛻粢欢ㄙI到很重要。有的商城是庫存不足的情況下也能下單,然后等客戶支付完成,然后拆單發現最優倉沒貨,遍歷全國倉都沒貨,有貨的都發了,沒貨的通過客服告訴客戶,庫存不足,減少購買數量,增加等待或者取消缺貨商品。雖然能保證最大轉化,但是客戶體驗非常不爽。暫時不考慮缺貨情況。
保證無感拆單,讓客戶只需要看到每個貨物的進度就行。
當一個大訂單被拆分成好幾個小訂單的時候,客戶會明顯發現,每個商品的發貨地都不一樣,發貨時間不一樣,快遞公司也不一樣。
當拆單結束之后,所有貨物就該進行發貨了。
這時候訂單就進入了下一個階段,會被推送倉儲物流環節,進行包裹單的生成。
構建訂單的第四個邏輯——訂單的狀態
這時候整個訂單從前臺客戶下單到進入倉儲物流環節的流程就結束了。
那么訂單的正向生命周期非常詳細的情況:
- 待支付:客戶下單,彈出支付頁面的時候,他給關了,沒有付款,或者他沒錢了,沒付款,這個時候訂單已經生成,為了讓他快點付款,我們設計了3分鐘的倒計時,如果客戶再次付款并成功,訂單將由待支付——>待發貨。如果客戶不付款訂單由待支付——>已取消。
- 待發貨:訂單收到貨款,但是貨物還沒有開始挑出來進行包裝和打包。
- 待收貨:貨物已經打包完畢并裝上運貨車輛,開出了倉庫。
- 待結束:貨物已經被客戶拿到并簽收了快遞,但是,客戶可能還沒拆開檢查是否滿意,或者客戶已經拆開使用了,我們需要給客戶一定時間來確??蛻舨贿M行售后流程。
- 已完成:客戶已經拿到貨物滿意并且超過了我們的訂單服務時效,訂單會自動結束轉為評價。
- 已取消:客戶可能下單后沒有付款,或者付款超時,或者付款但是貨物還沒有發出的時候,就聯系客服不想買了,我們沒有實際發貨,并成功退款。
- 已關閉:貨物已經發出,客戶才反悔不想買了,或者客戶簽收且不滿意貨物想退貨,寄回貨物,我們檢查后并確定貨物沒有損失的情況下,退款且關閉了訂單。
- 已失效:訂單服務結束并且已經超過二年的訂單,標記為失效訂單,不可追溯,也不展示了。
APP前臺無需給客戶展示這么多的狀態,只需四個狀態,待支付,待發貨,待收貨,已完成。
下一次我將分析下訂單的逆向流程。隨著業務的不斷增長,我們的業務線上和線下是如何迭代的。每一步都需要圍繞著商業的發展和業務的盈利,生存是第一要義。
如果客戶不滿意我的貨物要退貨,我該怎么辦?我們一定要有售后么?
我們如果沒有售后,連售后按鈕都沒有,客戶該何去何從?
我該讓客服致電客戶能僅退貨嗎?必須要退款么?
我們是怎么檢查退回貨物是否符合二次銷售標準,這個標準我們怎么界定,依據是什么?
如果客戶執意要退貨,APP上的退貨邏輯是怎樣的?整個前后臺的退貨邏輯是怎么樣的?
如果客戶退貨是因為我們發錯貨了,客戶一定沒責任么?如何讓客戶分攤一部分黑鍋呢(原則上肯定不能)?線上和線下的業務我們該怎么處理?
如果客戶想僅退款,我們該怎么處理?
如果客戶……
本文由 @芒果手握 原創發布于人人都是產品經理,未經許可,禁止轉載。
題圖來自 Unsplash,基于CC0協議。
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
有一點不明白,關于合單,合并訂單后針對于用戶側是無感知的,訂單號還是用戶發起訂單后的訂單號。那么合并的訂單號是指的主子訂單么?和原訂單間是怎么關聯的?
受教了,點贊
贊。