起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識樸樸（線上超市）促銷系統模擬
促銷系統其實我們作為消費者已經知道了很多套路，尤其是最近幾年天貓雙十一的種種優惠，幾乎沒有什么促銷方案在雙十一中找不到的。所以其實歸納促銷方案并不是重點，雖然如何把種種促銷方案抽象歸納并形象化方便配置也很重要，但是更重要和復雜的還是重疊互斥和結算這一塊。
這篇學習到促銷系統，促銷是平臺讓利提高銷量的重要手段，包括一般的促銷活動（滿減、滿折、滿贈等）和優惠券。 主要相交互的系統是商品系統、庫存系統、訂單系統、crm（會員）系統。
商品系統用于指定活動的商品；庫存系統可以劃分出活動庫存和一般庫存；訂單系統很重要的一點就是在結算這些活動時按什么順序結算以及分攤到各個商品，會影響訂單的最終支付金額和退款時的計算；crm 系統可用于精準營銷指定可以享受活動資格的用戶群體。
促銷系統其實我們作為消費者已經知道了很多套路，尤其是最近幾年天貓雙十一的種種優惠，幾乎沒有什么促銷方案在雙十一中找不到的。所以其實歸納促銷方案并不是重點，雖然如何把種種促銷方案抽象歸納并形象化方便配置也很重要，但是更重要和復雜的還是重疊互斥和結算這一塊。
原型鏈接：https://xd.adobe.com/view/80b51f95-d563-48bd-7f8f-38fea693b065-f684/
一、學習
有一篇文章從比較高的角度總結了促銷類型和計算順序， 這篇文章首先是將促銷類型歸為三種：
- 針對商品單品（特定 SKU 或 SPU）的降價，如商品券，或者直接打折；
- 商品集合的降價。即以人工劃分的商品類別為單位做一些營銷活動，如某品牌系列的滿減，或比如柑橘類水果的活動；
- 訂單整體的降價，比如絕大部分優惠券是適用于整單的打折或降價的。
然后規定了大部分業務場景的結算順序是按照以上順序的 1 2 3 來計算的，在商品小計中先計算單品價格，單品降價后再看是否符合商品小計的活動規則，最后再計算訂單整體。 接著說明了一句很重要的原則： “同類型通過實體進行互斥、不同類型可以相互疊加。”
二、簡單歸納
我認為他對于促銷類型的總結和最后的原則都很合理，也體現了絕大部分業務場景。第三點原則的類型是比較具體的類型，比如滿減是一個類型，滿贈、滿折、滿額換購，都是不同的類型，實體是商品，也就是說一個商品不能參加兩個不同的滿減，或者兩個不同的滿贈，對于同一商品來說如果在同類型的兩個不同活動中。那么這兩個活動一定要是互斥的，而不能疊加。
在創建具體的活動時，我們可以手動來設定不同類型的活動 A 與活動 B 互斥或疊加，但是在總體上應該有一個基礎的、同商品不能同時參加同類型活動的規則，這樣可以使配置和開發時的代碼沒那么多冗余。
這里就要求我們在最開始設定類型時，要想好哪些活動是同一個商品絕不可以同時參與的。這個規則決定了抽象程度，如滿減和滿折如果認為都是降價類的，同商品不能兩次降價，那么劃歸一類不可以同時參與，如果換購和贈品都屬于低價獲取商品類的，也劃歸一類不能同時參與。
如果只是不能滿 50 – 20 后又滿 10 – 5 這樣疊加下去，但是滿減后也可以滿折，那么就滿減、滿折都是不同的類型。當然一般來說劃分的細一點，比較可以適應之后活動的靈活性。但是對于第二點計算順序我還是有些不同的想法。
當然了，訂單整體的降價一定是放在最后的，但是商品單品和商品小計的順序其實可以更靈活一點，通過配置權重來決定展示和結算的順序，畢竟本身權重也是一定要配置的一個要素。
三、配置的基本要素
對于一個促銷活動，也是可以用基本的 5W2H 來分析的。
- WHAT – 是什么類型的促銷活動？活動名稱是什么？促銷的商品有哪些？
- WHY – 需求的目標是什么？這其實應該是促銷人員思考的，在做一個活動時目的是提高銷量，還是清空庫存，還是帶動客單價，來決定他配置一個怎樣的活動。
- WHO – 后臺角度：誰配置的？是否有審核？前臺角度：從 crm 中選擇合適的用戶。
- WHEN – 后臺角度：什么時間配置的？前臺角度：可用時間？
- WHERE – 投放渠道是哪里？小程序、app。
- HOW – 具體的活動規則是什么？如滿減的數額，與其他活動是否互斥？權重多少？
- HOW MUCH – 投入產出比如何？有無數量限制？商品有無限購庫存？用戶端有無限購？
四、關于權重
我認為權重分為兩方面：顯示權重和計算權重，但實際上也可以只配置一個權重。 權重是為了控制包含相同商品的活動與活動之間的關系，活動與活動的關系可認為只有兩種：疊加和互斥。也就是對于同一個商品，活動 A 與 B 是可以疊加還是只能選擇其一。
如果是互斥，那么默認為顧客選擇哪一個就是顯示權重，此時沒有計算的先后可言，因為只能選一個。 如果是可疊加享受，一定是要有個計算的先后邏輯；并且肯定是全部顯示出來，但是哪一個為先呢？這個等下再講。
具體到如何去設計這個邏輯，我的思路是填寫數字而不應該是固定的一些等級，原因是如果同時期，首先配置了活動 A，包含商品 x，那么假若有三個以上的活動同時包含了商品 x，就很難去配置相互之間的關系。既然這個權重只是要在多個共存時確定一個“比較級”，那么只要有數字的比較就可以了，不需要確定的等級，甚至無需對數字作要求，如果喜歡，10000 也可以。
這個權重可以視為這個活動的一個標簽，如果活動過期，即可釋放這個數字。比如原有一組有重復商品的活動 A B C，權重分別為 1 2 3，C 活動過期，3 這個數字得到釋放，新建活動 D 也與 A B 有重復商品，那么此時可以把 D 的權重設置為 3。
同時，在不同活動 A B C 有重復商品時，只需對 A B C 設定數字即可，這一組數字不會影響到另一組 E F G H 的權重。（這里的一組表示包含重復商品的不同活動）也就是說可以對 A B C 賦值權重 1 2 3，也可以對 E F G H 賦值 1 2 3 4，只要 A B C 與 E F G H 沒有相同商品即可。
具體到前臺的計算和顯示上，示意圖如下：
活動和權重
假設有三種產品 X Y Z，各自有圖上所示的活動和權重。表格中的 O P 兩種活動是與 ABC 活動可疊加的，O 與 P 互斥，A B C 之間互斥。此時 O 權重 高于 P，對于 X Y 而言 A1 權重最高，Z 而言 C1 權重最高。
那么此時在購物車的顯示如下圖：
優惠活動示例
用戶可以在 O 這里可以切換成 P，也就是可以切換為同樣能應用于全部 XYZ 的其他優惠活動；同時可以手動單獨切換 X Y Z 的所有可選優惠，如把 Z 單獨從 O 的活動中解放出來單獨設定為 P；或從當前 C1 切換為 C2，那此時還是和 XY 共同屬于 O 活動的。
那么如果 O 與 C2 互斥，P 與 C2 可疊加，這一操作會使得 Z 商品適用 P 和 C2 兩種活動，此時 P 和 C2 到底應該哪一個為先呢？從視覺上看，就是哪一個在上，哪一個在下呢？
我覺得比較合理的是這樣：與計算權重相反，計算權重越高，越在下，從視覺上我覺得這樣更符合習慣，也就是某活動下面列表中的商品我們先計算一下金額，再去看是否符合上面的條件，有一個匯總計算的感覺。
其實權重本身從商品的角度看，可以認為給商品的活動賦予了優先級，如 Z 商品有四種、兩組活動，OP 一組，C1C2 一組，切換時等于是將這個商品的這一活動優先級手動臨時提升到了組內最高，如果切換成其他的活動，那么原來的活動還按原有的權重去計算和比較。
還有一種特殊情況是，商品 Z 同時享受 A1 和 P，A1 的計算權重高于 P，此時界面上看起來就會是這樣的：
同一活動分割顯示
由于 P 在顯示上要高于 A1，所以導致與其他 A1 活動商品分隔開了，這種情況下想清晰看到所有活動商品可能方案就只有點進活動詳情，將已選擇的商品放在最前面來展示比較好。
活動頁面展示
當然實際上這種情況很少見，同一個商品有兩種互斥的營銷活動就比較多了，一般來說運營人員也不會這樣去配置，畢竟對結算、計算成本、用戶理解都會提高復雜度，所以在做后臺的時候，我們應該在合適的時候提醒運營人員該活動與其他活動是否有重復商品，減少犯錯的可能。
五、優惠券
這里把優惠券也劃歸促銷系統，主要是考慮到使用人員和調用的系統基本是一致的。 優惠券各個產品社區已經有很多介紹的文章了，這里也沒什么特殊。劃分類別從領用機制上可分為用戶觸發和系統觸發。
其中系統發放可認為是用戶無需做任何操作，系統出于補償或活動發券，直接發放到用戶賬戶中，活動發券又可以分為主動發放和被動觸發，主動發放是直接發放到用戶賬戶中，被動觸發是當用戶打開 app 或小程序時才發放到用戶賬戶中（比如餓了么）。
用戶觸發可以分為用戶直領和任務發券，用戶直領就是在指定頁面直接領取即可，任務發券則是需要完成一定的操作，比如下單、注冊、拉新才可以領取的券。
字段的話主要也是使用 5W2H 分析得到的各類字段：
- WHAT – 是什么類型的優惠券？優惠券名稱是什么？適用商品有哪些？
- WHY – 這里和促銷活動是一樣的。
- WHO – 這里和促銷活動也是一樣的。
- WHEN – 后臺角度：什么時間配置的？前臺角度：可領取的時間？可用的時間？絕對時間還是相對時間？是否要具體到時間段？
- WHERE – 投放渠道是哪里？小程序、app；使用渠道又是哪里？可以滿足比如小程序發券 app 使用來帶動 app 下載使用量。
- HOW – 具體的券規則是什么？如滿減的數額，與其他活動和券是否互斥？權重多少？觸發機制？用戶領用還是直接發放？
- HOW MUCH – 投入產出比如何？有無數量限制？每天限量還是限制總量？每人在單位時間內可以領用幾張券？
這里維護的是固定業務模式的優惠券和優惠券池，也就是說常見的每日領券、下單返券、客服發券等，可以在這里維護，如果是涉及到關聯券的活動，應在另一平臺（暫稱活動平臺）維護，在活動平臺可以設定具體的比如 H5 頁面內容樣式，頁面有效時間，頁面分享樣式等內容，只需復制優惠券系統的券編號，即可關聯此處設置的優惠券。
如果業務的組合有更多豐富的形式，則可以在設計系統時有更多的解耦，在這里只維護各類基礎的優惠券，完全不涉及業務規則，將一切業務規則轉移到活動平臺來維護。
六、后臺
具體到我模擬的樸樸這一塊，它現在的業務是分布在四個城市，廣州、深圳、福州、廈門，根據我的觀察一般來說活動商品大體一致，只是福廈的降價讓利程度要低于廣深。
由于活動差不多，所以我暫時還是把四個城市做成一個后臺，如果有更精細化的運營（也可能現在就是），是可以分為四個站四個后臺的，可以考慮通過拷貝編號等方式快速將一個站的活動移植到另一個站并進行簡單修改。
這里貼出以滿減為例的幾張原型，包括列表頁，新建活動頁，和搜索選擇商品的頁面。
營銷首頁
有效活動指在配置時已經設定生效并且通過審核的活動，可能正在應用或者還未到生效時間，無效活動則是草稿、待審核、已結束的活動。
新建滿減活動 – 階梯滿減
在配置了商品、時段、城市、渠道等信息以后，系統需要識別出與當前活動有重復商品的活動，運營人員可以選擇與重復活動互斥或者重疊，并標記權重。
新建滿減活動 – 每滿減 – 選擇商品 – 按類目
考慮到商品庫內 SPU 眾多，直接展示商品列表會增加對服務器的壓力和降低響應速度，所以采用按類目、按品牌展示的兩種維度方式，也是因為做活動時通常也是以這兩種維度來考慮的，在這個頁面可以選擇到 1 – 3 級類目和單品商品。同時也可以直接搜索 SPU 進行定位。
新建滿減活動 – 每滿減 – 選擇商品 – 按品牌
由于品牌數量也很多，所以交互上一個頁面僅按照拼音順序列出品牌，并在下一個頁面再結合三級類目展示該品牌具體的商品。
新建滿減活動 – 每滿減 – 選擇商品 – 按品牌 – 品牌商品
之所以是三級類目是因為絕大多數品牌其實不會覆蓋到多個二級類目以上，三級類目不會太多，也方便選擇。
其他的滿折、換購、滿贈等活動字段大同小異，接下來貼兩張優惠券的原型圖。
優惠券.png
需要注意的是已發放的優惠券一般是不允許編輯的，可以對當前優惠券禁用，或者復制信息直接新建，但是已發放的優惠券出于數據統計和用戶體驗的考慮，不允許編輯。
新建優惠券 – 頁面直領
新建優惠券時按照 5W2H 的考量大致劃分了字段信息來區分，這里沒有考慮重疊互斥的問題，因為樸樸當前的業務邏輯是不論什么類型的優惠券，每單僅限 1 張，與所有促銷活動可重疊，計算權重自然是在最后。
如果今后有擴展的話，按照促銷活動的權重設計即可。至于訂單逆流程的計算分攤和退款，其實就是按照順序計算后得到的分攤價格再去退款，優惠券只有整單退款才可以退還，即使退還時已經過期，直接歸入用戶賬戶的已失效優惠券即可，如果是平臺操作問題導致用戶損失優惠券，應當由客服創建補償券補償給客戶。
下一個系統也許會做文中提到的活動平臺吧～
訂單系統：https://www.jianshu.com/p/e8070184de81
客服系統：https://www.jianshu.com/p/0f5f22a61428
運營支撐系統：https://www.jianshu.com/p/d13b2c35f257
本文由 @milk 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
- 目前還沒評論，等你發揮！
