3. 可用商品范圍

可用商品范圍主要指用戶所領取到的優惠券可作用于哪一些商品，通常先規定商品類型如僅作用于實物類商品，否則就會有一定風險造成之前拼多多優惠券羊毛事件（優惠券可作用于虛擬充值類商品），接著才是規定可適用商品目錄。

常見可用商品范圍有4種： ?

1. 單品優惠券：僅可用于所指定的單一商品；
2. 指定商品優惠券?：可用于所指定的多個商品；
3. ?類目優惠券：可用于指定的某個一級類目或二級類目下的多個商品，通常會有個別特例商品除外；
4. 全品優惠券：可用于平臺內所有的商品，通常會有個別特例商品除外。?

4. 使用門檻

首先需要把領取門檻和使用門檻區分清楚，前者是“怎么樣才能拿”，后者是“拿了后怎么樣才能用”。使用門檻是指當用戶挑選了可用商品范圍內的商品后，需滿足的某一個條件后才能進行使用。

常見使用門檻主要有2種： ?

1. 滿減券：訂單中符合使用范圍的商品需要滿多少元才可以減去優惠券對應面額的金額；
2. 立減券：也可以叫現金券或無門檻券，即只需要商品屬于使用范圍以內，即可直接使用。

5. 有效期

有效期是指優惠券在時間維度上的使用限制，即領取后必須在什么時間條件下才能使用。

常見有效期有2種：

1. 普通優惠券：?通常優惠券會設定使用時間為某一個時間節點至另一個時間節點，在時間范圍內才可使用指定優惠券；
2. 限時優惠券：規定領取后的某一個時間段內可使用，?如“領取后7天內可用”。

關于多個不同優惠券類型的設計思路

1. 看似種類場景繁多，但底層邏輯都是“4W1H”

上述分類總結僅僅列舉了常見的優惠券場景，實際上不同平臺均會在上述5個維度有自己特定業務場景下的延伸，然而從系統邏輯角度去看這個問題，絕大部分優惠券業務場景下的底層邏輯都逃不出“4W1H”。

如下圖所示，所有優惠券其實就是5個維度下的順序組合。

從領取門檻來看：這個維度下設定相對靈活，只需要在用戶觸發“領取”動作時通過條件判斷是否應該發放。比如新人優惠券，?通常會根據“新人”的定義做相應的系統設計，如“24小時內注冊”則規定“用戶領取時間減去用戶注冊時間，小于或等于24小時，才可順利領取”；而首單優惠券，則是領取時判斷用戶訂單數據是否為0,0則可以領取，否則不可領取。

從領取方式來看：主要根據運營場景需求設計即可，需要注意的是被動領取除非是由運營人員后臺觸發系統發放，否則通常都會讓用戶完成某個平臺所規定的特定條件或者流程后獲得，如注冊后獲得、成功支付下單后獲得，參加抽獎游戲后獲得。

從?商品范圍來看：單品、指定商品、類目、全品優惠券都是創建優惠券時需明確平臺內所有商品的子集，這個子集內的商品就可以使用優惠券，最后剩下的問題僅僅是這個子集到底是多大而已。

從使用門檻來看，滿減券和立減券的使用條件都是可使用券的商品價格加起來必須滿X元才可減Y元，只是在立減券的使用場景下，此時X等于0，立減券的使用門檻也就是“無門檻”。

以有效期來看，限時優惠券與普通優惠券，都是創建優惠券時需明確該優惠券可用時間范圍為A時間點到B時間點，區別僅在于普通優惠券的A、B時間點均為已明確的時間節點。而限時優惠券的A時間點為未知時間節點“優惠券領取時間”，B時間點則為“優惠券領取時間+優惠券可用時間時長”。

2. 任何一種優惠券都是以上5個維度的排列組合

以最常見的電商常規優惠券場景?來舉例，如大家所熟知的京東“滿105減5的全品類優惠券”，便是以下5個維度中不同的方案設置組合而成的結果。

另外又比如瑞幸咖啡的新人優惠券，可用于大師咖啡/零度拿鐵，7天內有效，則是以下的方案設置。

因此，當理清楚優惠券的5個維度，市面上95%的優惠券都能適用于該方案模型。

3. 優惠券后臺設計思路

產品經理在面對業務部門隨時提出的各類優惠券場景需求，如果在規劃優惠券系統的初始階段可以把上述5個維度分為5個子模塊功能進行設計，甚至前瞻性地告知技術人員預留好接口類型，相信可以很大程度上節省后續的迭代開發資源。

?后續比如業務又提出了“新人優惠券”需求，此時我們只需要在“領取門檻”這個子模塊里進行對應的拓展設計，增加“僅新人可領取”的產品需求即可，同時也會最大程度地避免影響擾亂到另外4個子模塊。關于這一塊內容準備下一次文章結合優惠券系統需求文檔的分享再另行展開。

結束語

第一次寫產品認識分享文，原先的提綱列好后下手才發現真寫出來會是一個大坑，而目前僅為了闡述設計思路就已經寫了這么大篇幅，所以寫著寫著就決定調整成多篇來寫，后續會將上述五個子模塊功能設計展開介紹，另外優惠券所涉及的售后流程、結算流程都是不小的坑，有機會也會拿出來細講。

?如果表達不清晰或者有錯誤看法的請大家及時指出，我也會第一時間考究并進行調整修改，以免誤導他人，謝謝各位耐心看到這里。

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

題圖來自Unsplash，基于CC0協議