火爆雙十一的電商預售系統(tǒng)簡介
關于電商預售系統(tǒng)文章做了一些分享,希望能夠對你帶來啟發(fā)。
1.預售的概念
預售:指商品還沒有到正式銷售的時間提前進行銷售。
預售的好處包括以下幾點:
- 降低供應鏈成本。提前銷售可以更加準確估計商品的銷量,商家可以更加準確地準備庫存,會減少商品的搬動次數以及倉儲成本。
- 累積人氣和銷售。商品在預售期間可以累計一段時間的人氣,然后在某個時刻銷售額大幅提升,有利于沖刺業(yè)績。
- 新品試探市場。新發(fā)布的商品在未正式發(fā)售前,試探市場的反應,有利于降低制造成本,更加靈活的選擇市場策略。
- 累計訂單。諸如生鮮、時令商品、小眾商品等不易周轉的商品可以采取預售的形式累計訂單再統(tǒng)一進貨和發(fā)貨,降低倉庫成本。
2.預售產品的結構
預售包括三種:預約預售、定金預售、全款預售。
預約預售:指用戶可以預約商品的購買資格或者消息提醒,然后在指定時間購買商品。一般預約商品都有明確的價格,不過現在有些手機在預約時沒有明確的價格,在發(fā)布會公布才會有明確的價格。所以會有一種暫無定價的預約預售。
定金預售:指用戶先支付商品款的一部分,過一段時間后,再支付商品款的剩余部分,付完全款后商家再發(fā)貨。這里的定金,可以是固定的,也可以膨脹,例如:定金10元可以抵20元,類似再做了一個直降促銷。這里會有一種復雜的情況:也就是按照人數來實行階梯價。人數越多,預售價格越低,形成多個階梯。
全款預售:指用戶全額支付商品款,商家在后續(xù)的規(guī)定時間內履單。這里也會有人數階梯價的情況存在。
3.預約預售產品流程
- 預約商品多是新品,為了惠及更多用戶,會有單用戶限購數和搶購總數量來做數量方面的控制。
- 預約商品多是緊俏品,防止黃牛小號批量刷單,會有用戶風險等級的校驗或會員等級的校驗。
- 用戶觸達這塊的形式包括短信、郵件、站內信。
- 活動頁的內容和后臺設置內容要通過預約活動id進行關聯,保持一致,如果不關聯,會出現詳情頁和活動頁不一致的情況。
- 活動頁要允許用戶直接預約。用戶預約需校驗登錄狀態(tài),不可重復預約。
- 預約商品多是新品,沒有銷量、評價,會影響在其搜索頁的排名,所以需要有冷啟動算法支撐搜索排名。
- 用戶在某個時刻搶購,會造成系統(tǒng)瞬時流量,所以要支持排隊秒殺。
- 暫無售價的預約需要價格系統(tǒng)支持這種價格形式,然后在中間期改為明確的價格。
4.定金預售產品流程
①用戶實際支付金額=定價+尾款-膨脹。
②定金預售比較麻煩的是每個節(jié)點下訂單的處理,舉幾個例子:
- 用戶支付定金成功,未付尾款,未取消訂單,訂單需在尾款支付時間后自動關閉。
- 用戶支付定金成功,未付尾款,用戶主動取消訂單,定金不退。
- 用戶定金成單未付款,后續(xù)不支付,不主動取消訂單,訂單需在尾款支付前自動取消掉。
- 用戶定金成單未付款,后續(xù)不支付,主動取消訂單。
- 用戶支付定金成功,付尾款成功后又取消訂單,訂單需取消后退全款。
③人數階梯價:隨著支付定金人數越來越多,尾款會減少。適合邀請好友一起玩。
5.全款預售產品流程
- 全款預售相對來說比較簡單,一般會延遲發(fā)貨,有預計發(fā)貨時間的設置。
- 預售對發(fā)貨時間有延遲,要對商家的DSR特殊處理。
- 預售要收取商家保證金,防止商家收取大量欠款后潛逃。
- 預售、定金、預約應該都是互斥的,同一個sku同時不能存在兩個促銷。
作者:劉鑫,微信公眾號:pm-wolf,1號店產品經理。
本文由 @劉鑫 原創(chuàng)發(fā)布于人人都是產品經理。未經許可,禁止轉載。
題圖來自PEXELS,基于CC0協議
評論
大神,想請教下消費者在同一家店購買了預售商品,同時也購買了正常銷售的商品,是一筆訂單還是拆單呢?
預售商品一般不能加入購物車的,所以不會你說的那種出現在一筆訂單的情況
大神我想問問關于商家與平臺的流程,是平臺發(fā)起活動然后商家再挑選商品進行參與然后平臺再次審核嗎?
看到po主是1號店的大神,不敢放肆,有幾個問題想請教一下:
1.想問一下,1號店的優(yōu)惠規(guī)則是否獨立封裝為服務,還是結構和訂單放在一起?
2.如果you獨立封裝,定金的邏輯是放在哪兒的?訂單還是優(yōu)惠中心?
3.定金的通知怎么設計?是通過定時任務推送,還是說寫流程引擎來實現?
4.因為雙11量較大,所以接口的推送是異步的還是同步的?
5.預售商品的邏輯庫存是放在WMS的嗎?
6.邏輯庫存的buffer值的補貨邏輯是怎么樣的,優(yōu)先保證銷售還是售后換貨?
7.關于定金,是采用兩筆訂單還是等待尾款形成一筆訂單?我看淘寶的是一筆訂單,但是這樣財務的賬目怎么算?
最后一個單獨的,搶購的時候支持優(yōu)惠的發(fā)生嗎?這個是咋優(yōu)化的?因為這樣要通過前端,優(yōu)惠,訂單,商品,wms好幾個接口,性能影響咋樣?
你才是大神,牛逼
我不是開發(fā),我能回答的盡量回答
1.價格是獨立的服務。
2.定金邏輯在價格服務里。
3.定金通知是定時任務,頻率應該是每分鐘一次。
4.你是說短信、站內信推送嗎?這個不清楚
5.庫存是虛擬庫存,都在WMS
6.虛擬庫存應該是沒buffer值,不夠可以再加。
7.訂金和尾款一筆訂單,支付方式要支持分筆支付。
最后一個問題:定金膨脹算一種優(yōu)惠。當然用券是可以的,只是太復雜沒必要。確實會有這些服務,沒關心過性能,不過都ok啦。
0 0這些都是產品定義的啊
其他問題基本都知道你的意思了
就第四個,這個是各個接口之間的接口方案,如果是同步的 估計性能會受影響,異步的通知 ,擔心頻率太大了 數據不一致會導致出現坑,所以想知道是咋整的
再就是最后一個,我是想了解下,你們的優(yōu)惠券在搶購,就是那種0點開始 一波搶完的,是不是能用,因為搶購對性能要求太高了,要調優(yōu)惠,實在是要命。
消息觸發(fā)(短信、站內信、郵件等)也有服務的,是同步的。
性能問題有架構師負責。性能問題實在搞不定了,產品才會有所知曉,改動方案。
同步的 在雙11這么大的并發(fā)量的情況下,0 0 接口性能過得去嗎
哦哦哦 那可能每個公司對于產品和架構的使用不一致,我們之前做這些是因為在工作工程中,很容易由以產品為中心,變成以架構為中心,不論是溝通成本還是做出來的效果可能都會有影響,所以產品盡量做能做的事情。