營銷活動產品設計更多需要加上運營的思維,以吸引用戶,獲得更多流量,而流量的轉化則是商城或者平臺的價值所在。在眾多的營銷活動中,預售系統對用戶來講“邊際效應”較大的促銷方式,對忠實用戶和新用戶有一定的吸引力。
涉及到的用戶角色:
商家:發布預售系統商品,提交預售系統商品的詳情資料。
平臺:添加預售系統商品、設置預售系統規則、審核商家提交的預售系統商品、結算。
買家:瀏覽預售系統商品、支付定金、提交訂單、支付尾款、等待收貨。
具體流程根據各平臺的規則不同而略有不同。而整個環節的關鍵點在訂單的“狀態問題”和“結算問題”以及“庫存問題”。
預售系統訂單的狀態問題:預售系統訂單若分為“定金訂單”和“尾款訂單”,定金訂單需要增加“待付尾款”的狀態,無論程序猿在數據庫中做何種合并,買家付完定金后,生成尾款訂單,前臺總訂單狀態則應為“待付尾款”,此后,總訂單狀態則隨著尾款訂單的狀態改變而改變。
需要說明的是,程序猿在預售系統訂單狀態的調取中,可以在數據庫中增加臨時狀態來代替“邏輯控制”,由于平臺本身的訂單狀態并沒有“待付尾款”,利用邏輯控制就容易造成狀態混亂,筆者在實際案例中,就遇到商家發貨時訂單在前端的顯示沒有問題,而在導出時,狀態就出現了混亂。
預售系統訂單的結算問題:預售系統訂單的結算在數據庫中,相當于將兩條訂單合并為一條訂單來向商家結算,如果操作不當則容易出現“對不上賬”的情況:商家看到訂單已結算,對賬時發現,每筆訂單總有被少結算一部分的金額,該部分金額即是定金的金額,由于程序猿在合并訂單時因為不讀取定金訂單的狀態就忽略了結算定金的金額。
庫存問題:關鍵在于預售系統的庫存怎么設計,是設計一個預算范圍內的加庫存進行預售系統,也就是準備預售系統的商品數量,這種做法對整個后臺的改動較小,但是在后期統計由于虛擬的庫存,要注意統計數據的問題;還有一種就是不限定預售系統量,這樣的話,即使庫存為0也可以繼續銷售,但是對后臺的改動就比較大,開發成本會很高。
后臺:如果預售系統商品是在平臺的商品庫中選擇,就要通過預售系統商品的ID來進行標記選擇,如果預售系統商品是新導入則在后臺設置導入的功能(批量導入),同時設置預售系統商品列表,在預售系統商品列表中隨時可以編輯和管理預售系統商品。后臺操作的關鍵在于預售系統時間的設置,預售系統時間之前、預售系統時間內、預售系統時間后,商品在庫的顯示狀態及定價必須通過運營人員進行準確把握。
預售系統規則:預售系統商品的一般規則是先支付定金,定金一般不予退款,天貓商城的預售系統商品也是如此。設置尾款的支付時間,同時提醒用戶及時支付尾款,若超時不支付,則訂單自動取消,不予退款。
預售系統商品的吸引力在于價格的便宜,相當于另一種形式的團購,因為預售系統同時為商家提供足夠的備貨時間,合適的商品、合適的價格,足以讓預售系統活動達到預期目的。
文章編輯:Micronet微網 最好的微商城系統盡在Micronet微網
如需了解更多預售系統資訊 可報名申請或撥打全國免費電話400-830-8248
文章轉載于:http://www.ebrun.com/20161011/196040.shtml
聲明:本網部份文章為轉載文章,在每篇文章底部有說明,文章的觀點和立場僅代表作者個人立場,不代表微網立場,若是文章轉載中有侵范您的權益,請發郵件到 493149@qq.com或致電13922854199通知刪除,謝謝!