當我們搞清楚優惠券分類那些事之后，系統后臺的優惠券創建流程應該怎么設計，來保證后續面對奇形怪狀的業務需求時如何讓產品迭代更加有效率。enjoy~

前言

優惠券在平臺中是一個神奇的東西，一個東西本來賣100元，運營人員雞賊地在后臺把價格改為120元，然后再發一張20元優惠券出來。從理論上以及現實上來看，此時假設同一個用戶面臨以上兩種情況并且無其它影響因素的存在，獲得優惠券后成單概率會更高。

從人性角度來看，我認為優惠券系統體現出來的便是人心本性的綜合表現——

（1）貪婪又節儉

薅羊毛一時爽，是人都想占點便宜，比如近兩年的銀聯6.20活動補貼，消費者們為了早上9點享受超市滿100減去38的優惠活動，大媽大爺們甘愿8點就選好商品在結賬處排隊等候，只因每日的優惠名額是全國限量。

在一線城市的類似活動中，你才能見識到國人的收入消費情況并不如你想象中那么光鮮。消費者在促銷活動中占著了便宜，在自認為智商爆棚的自我優越感中沉浸。然而他們哪有商家精明，成功的商人并不是慈善家，他們只是更懂得如何讓消費者甘愿掏錢出來還開開心心地回家，甚至是感謝商家給的福利。

（2）大方又懶惰

與節儉又矛盾的是，人們在消費時又是大方的，他們懶得去考量比價關于擺在面前的優惠是否是真的優惠，自認為貴的就是好的。本人曾在張大媽平臺發過一個爆價鏈接，給近期準備買kindle的電商部女同事，她竟然覺得無比復雜并直言看不懂，而本身從事電商運營工作的人都已經看不懂下面這段話，那更可以說明廣大人民群眾是懶得去思考。

人是好面子的，于是人們雞賊地為自己懶惰找了一個巧妙的借口“我其實很大方，喜歡就買買買，不在乎價格”。

圖為某導購網站關于優惠流程的介紹

正因促銷手段在人性面前具有如此強悍的針對性，優惠券系統如今早已不是電商平臺特有?；ヂ摼W平臺中，上到虛擬商品如知識付費、下到線下服務如共享單車，凡是涉及到支付場景的平臺基本都會存在對應的優惠券系統。

上一篇處女作我簡單地分享了自己對于優惠券系統的分類認識，這次就接著之前的話題，想聊一聊當我們搞清楚優惠券分類那些事之后，系統后臺的優惠券創建流程應該怎么設計，來保證后續面對奇形怪狀的業務需求時如何讓產品迭代更加有效率。

關于優惠券系統的設計

設計優惠券系統時，不要大而全地整理需求想著一步到位，當然更不要上來打開axure就是干，這個在做任何產品需求時都是通用的。

我認為最合適的節奏應該是把需求理解得基本通透后，再橫向對比市場上對應產品的優劣，最后才是根據業務需求以及目前的平臺實際基礎，把最基本最必要最不可或缺的流程做出來（是否必要流程的檢驗標準就是，這個流程如果不做，整個產品還能不能完整跑下去，如果流程依舊能跑下去那么它就是非必要），之后才開始考慮錦上添花那些（比如廣告分發、數據統計等）。

這就好像我們要給一座山修路，我們自然是先爬到山頂從上往下看，然后回過頭再下山一步一步把梯子搭起來，優先解決人們安全上到山頂的需求，之后才是關注路上植被風景等問題的規劃。當然，技術資源多到用不完的大公司們就當我沒說。

優惠券系統首先要理解的便是琳瑯滿目的各類優惠券到底是怎樣一回事，而之前的文章已經介紹過，感興趣的朋友也可以點擊【優惠券系統細節剖析（一）：關于優惠券分類及對應設計思路】看看，那這次就以自己現在負責平臺的優惠券需求為例來講講。

本人當時設計的添加創建優惠券流程如下，具體分析介紹詳見下文：

1. 優惠券基本信息

• 優惠券名稱：通常每一張優惠券都會有一個名稱，部分平臺為了方便運營人員管理會設置兩個字段，一個是后臺內部看的，另外一個是給C端用戶看。
• 優惠券領取頁面配圖配色：考慮到優惠券在發放傳播過程中對于平臺或商品品牌推廣的需求，可設計允許運營人員在一定程度以內的自定義操作性。以本人當初設計為例，如下圖所示，上方頭圖可在后臺上傳放置固定大小尺寸的平面圖，而為了保證頁面視覺的統一性又不至于增加過多的開發需求，下方可在后臺填寫對應色值并在前端進行相應顯示，當然往往這種設計是需要考慮默認通用圖的樣式的。

• 總發行量：優惠券通常數量設置有限，這個是需要運營人員經過一定的核算成本之后再定下來的，不是拍腦袋隨便填。
• 優惠券有效期：如上一篇文章所屬，有效期通常有兩種，一種是“從A時間點到B時間點”，另一種是“自領取后X天內有效”?？紤]到后者變動因素較大，風險不可控，如果是平臺第一次推出優惠券系統則建議先設計前者，后續若有業務場景需求則再加個需求選項上去即可。需要注意一點的是，關于時間范圍需求需明確具體時間點，并精細到秒，但每次讓運營去填具體秒數估計又會罵街，所以通常需和程序員明確時間點A到B為“xxxx-xx-xx 00:00:00到yyyy-yy-yy 23:59:59”，其中xy由運營人員自行配置。

2. 領取

• 可領取用戶：通常優惠券會限定哪一類用戶才可領取，比如“僅新用戶”可領取，同樣的，系統初期先做一個“全體用戶”可領取即可。這里建議最好把這個“可領取用戶”字段也寫到需求文檔中，即便它當前只能必選“全體用戶”一個選項，因為如此一來程序員也會明白你后續會在這個上面做新的選項出來，那目前他就可以在初期就為后續的拓展預留好接口和字段從而方便后續的迭代。
• 每人限領：指每個人最多能領取多少張同樣的優惠券。這里需要明確判定單個用戶的指標，絕大多數平臺在下單時如果用的第三方授權登錄通常必須綁定手機號才可順利下單，那此時就存在一個問題，即微信授權登錄用戶（未綁定手機）是否能領取優惠券，如果能領取則需要考慮后續賬號合并時的優惠券匯總處理，如果不能領取則需要設計領取時相應的引導綁定手機號流程。

3. 使用門檻

• 使用門檻：指用戶形成訂單時需要達到何種條件才能使用優惠券。無門檻的要萬分慎重，因為這就是白花花的錢，如果平臺有了一定知名度但是不設置風險預防機制（防止有心人惡意攻破后臺機制或者利用運營人員失誤操作而侵占平臺利益）的話，就會很容易發生幾個月前拼夕夕的黑客薅羊毛事件了。
• 面額：面額的話通常直接設置即可。筆者考慮到相關風險問題，決定無論從后臺輸入或者是系統規則中直接限定優惠券金額大小，另外針對無門檻優惠券進行更加嚴格的限制。

需要補充的是，后續若打算推出可平行的另外一些促銷功能，如滿減、會員價等，則需要提前考慮好促銷系統的功能優先級，若碰上一個商品可同時使用多重優惠手段時，則每個級別只能挑一個優惠手段，并按照優先級先后進行依次計算。

以京東為例，50元的商品若參加滿199-100活動，且當你手頭有一張適用的99-50優惠券，假設你購買4件，則此時第一優先促銷手段為“滿199減100”（50*4=200>199，可減100），其次才是驗證第二優先促銷手段“優惠券”（滿減后為100元，大于99元，可用券優惠50元），然而從2018年底開始筆者發現京東開始調整優惠系統邏輯，開始實施平行優惠，也就是剛才的案例中已經可以直接使用199-50元的優惠券了（商品價格同時滿足不同優惠手段均可符合優惠資格）。

反面案例如淘寶近幾年來的雙11活動，預熱支付定金+定金享受翻倍+品牌、跨店鋪等多檔優惠券+零點直降+滿減津貼等亂七八的促銷手段為典型案例，別說消費者了連商家都很難吃透規則。

4. 適用范圍

首先需要注意在商品性質上的明確，比如虛擬商品類（無需發貨）或者充值類商品，同樣來說是需要與技術人員直接明確是否允許參與優惠券系統規則，考慮到該類商品的利潤點較為固定，通常都會從系統層面直接設計讓該類商品不參與優惠以避免后續可能出現的運營失誤。

關于適用商品的選擇，流程上是需要讓運營人員一個一個進行勾選，但是考慮到商品sku過多的話，一張全品類的優惠券設置就足以讓運營人員罵娘，所以按照目前我的設計是讓運營人員可直接勾選一個大范圍（比如全部商品或者某一個類目下的商品），然后再從中去剔除某一小部分不適用于優惠券的商品。

我知道有人看到這里肯定會質問某一些運營場景下的設置也是相當的反人類后臺操作，但正如前文所言，這個后臺設置流程是我根據我們團隊當前的實際情況下所做出來的決策，并且也是得到運營部門的認可才會有這樣的一個結果。做產品沒有辦法照搬照抄，別人的案例你只能作為思路上的參考學習，但真正實施起來請還是以自己團隊的實際情況為準。

總結

老板或者業務部門只會說一句“我要優惠券功能”，但是優惠券所涉及范圍較廣，上到頂層分類設計以及后續拓展，下到優惠流程所涉及到的售后結算等諸多流程，另外還需要考慮如何去輔助財務和運營設置優惠券時相對更準確地進行決策。

今天介紹了創建優惠券時所需要注意的最基本的點，那么后續打算再更新一篇，聊聊優惠券所牽扯到的其他產品線（如數據統計、結算售后等）的相關流程功能應該如何設計調整，使得整個促銷流程更加順暢兼容。

本文由 @梁小栩 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議