整理了一下我們APP中優惠券模塊的設計方案，只談產品層面如何設計功能，不談運營層面如何運作券碼，兼顧技術層面。初次分享定義為1.0，以后會多次迭代。

基于我們產品是B2C自營電商的底層架構，所以我設計的優惠券方案至少支持以下使用場景：滿減券、打折券、包郵券、商品券、滿贈券、全場通用券等等。

一直以來接觸的是淘寶店鋪的產品體系，根據自己以前的電商運營經驗和對優惠券的理解，最終抽象得出一套通用性的優惠券設計方案。

優惠券本質

優惠券的本質是經濟學中的價格歧視。形式上給予消費者心理一定的折扣，然后促成訂單。本質上商家向不同的接受者提供相同的商品或相同質量的服務，但是在接受者之間實行不同的銷售價格。

優惠券的表象

對于顧客來說，優惠券就是買東西的時候用它來省錢。

對于初級PM來說，優惠券可能就是滿減券、打折券、滿贈券這3種類型。那從技術層面來說，RD至少需要構建3個類，并且無法兼顧優惠碼。并且后續很難去兼顧運營提出的新優惠券類型。

其次淘寶給店鋪提供了3種優惠券：訂單券、商品券、包郵券，這是平臺的策略。我們是獨立B2C，不需要做得這樣細。京東也類似。

優惠券的類

從面向對象的技術角度來說，優惠券可以抽象成類，本質上是類的實例化。

優惠券的價值

是優惠，不是現金。

請注意電商領域通俗意義上的優惠券是指下單可以優惠金額的券，使用即作廢。不是那種可以充值到賬戶的現金券，也不是可以使用多張的折扣券。

為什么做優惠券？

簡單來說，就是拉新促活。

怎么做優惠券？

先說大概步驟：

新建

即你想要什么樣的優惠券，包含優惠券的面值，有效期，類型，門檻，使用限制，標簽……

新建是指新建了一批優惠券，可能限定了總張數，也可能不限定。本質上就是構建優惠券這個類的屬性，具體如下：

• 優惠券名稱：方便運營標記，可以顯示給用戶看。
• 有效期：即可以使用該券的起始時間。一般有兩種：①運營人員設定，比如2017-01-05~2017-02-05②從領券之日起x天，比如注冊送券一般有效期7天。延展來講餓了么滴滴還限定了時段，比如僅早上8:00~10:00可用。
• 應用范圍：指什么范圍可以使用券，一般是全場、某店鋪、某店鋪某品類。甚至還有限定某店鋪某商品，注意這個更應該歸于應用范圍屬性，而不是使用條件，比較容易混淆。
• 使用條件：即該訂單需要滿足的條件，比如滿x元、滿x件、無條件。延展來講可能是該訂單需滿足、該訂單中商品需滿足、該訂單的發貨地需滿足……請注意最終落在該訂單層面優惠，減免金額。
• 優惠結果：即該訂單用券后享受的優惠。比如減x元、打x折、免運費、贈禮物、免稅費、返優惠券……
• 優惠疊加：比如原本是滿100元減20元，疊加后就是滿100元減20元，滿200減40元，上不封頂。
• 承擔部門：該批次優惠券的費用由哪個部門承擔。
• 是否顯示到前端：設置了之后，商品詳情&領券中心&購物車都會顯示。一般是第一種券類。本質上應該置于發放層面，不過考慮到總不能運營每設置一批優惠券就得新建一次，發放一次。就把它歸屬于優惠券的屬性。
• 是否限定級別：比如普通用戶無法領取，高級用戶才可以領取。
• 排除某類商品：在應用范圍的基礎上排除某些特殊商品、某個商品。

需要單獨說明的是：

• 為了兼顧優惠碼，所以盡量不要去限制該批次優惠券的數量。這一點和淘寶店鋪優惠券的區別很大。為此其實新增了2種優惠券類。最終有3個優惠券類（class）：①限制總張數，限制每人領取張數②不限制總張數，限制每人領取張數③不限制總張數，不限制每人領取張數。
• 第一種類最終生成的實體是X張，第二和第三類是1張，但是可以使用多次。后者比較適合和第三方平臺合作推廣，比如和什么值得買。像當年uber發放出去的兌換碼應該采用的是第三種券的定義。
• 每張優惠券，只能關聯一條使用條件和一條優惠結果，技術實現層面上來說可以關聯多條，但是這樣會導致業務太復雜。

審核

優惠券其實是讓利提升銷量，所以需要業務部門申請預算并提交財務審核。不過我們APP體量還小，這一步暫時省略。后續可以補充。

發放

審核通過的優惠券需要向目標用戶進行發放。發放是個泛概念，分為用戶主動領取&系統自動發放。

新建優惠券的時候，已經提供了一個顯示到前端的屬性，稱之為領券。

比如給每一個批次的優惠券生成鏈接，發給用戶讓他們去領。

另外：注冊自動返券，下單自動返券，邀請成功自動返券，屬于系統自動發放的類型。

發放這一步是很偏運營的事兒，產品配合好即可。

領取

當用戶領取成功之后，我的優惠券列表新增一條記錄。此時這張券的狀態是未使用，下單的時候如果使用了它，則為已使用狀態。

使用

優惠券的使用和訂單流程強關聯，一種是先用券后生成訂單，還有一種是先生成訂單再用券。我們APP采用的是前者，遵循用戶被淘寶京東培養出來的認知習慣。

選擇優惠券之后生成訂單，此時該張優惠券和該訂單進行綁定，同時狀態變成”已使用”。

注意每個訂單最多使用一張優惠券，一張優惠券只能使用一次。理論上來說一個訂單可以使用多張券，一張優惠券可以使用多次比如uber有那種使用x次的晚高峰券，只是這樣會讓業務變得很復雜，產品設計和技術實現都會變得很復雜。除非業務必須，否則不推薦這樣做。

回收

過期未使用的優惠券需要進行回收和作廢。

統計

無論是生成優惠券的記錄、還是每一張被領取的記錄，以及每張使用的記錄，都需要記錄日志供查詢。

優惠券是否退還

理論上來說優惠券一般不退，優惠券1.0版本中不支持將未付款而取消的訂單綁定的優惠券進行返還，如果以后有時間可能會優化一下。此時會多一個使用中或者鎖定的中間狀態。

退款的時候優惠的金額怎么處理

如果不處理，那用戶下單100+50-20優惠，如果全部退款則是退款150，很明顯對商家造成營收上面的損失。

如果處理則按照”哪里優惠回哪里”的規則來處理：

• 如果是指定某件商品/某類商品的優惠券，那優惠金額肯定由該商品承擔的。當退該商品，需減去優惠券金額。
• 如果是指定某些（分類、商戶、活動等），那優惠金額分攤到符合資格的商品上。
• 如果是全店鋪通用，那優惠金額分攤到每一個購買商品上。

分攤金額的算法有兩種：

• 按照符合優惠券的商品金額進行均攤
• 按照訂單剩余部分是否符合優惠券

舉例：顧客購買了A商品1件90元，B商品1件30元，使用了一張優惠券滿100元減20元。如果顧客想退款A商品：

• 按照算法1，提交退款的最多金額為90*(90+30-20)/(90+30)=75元。
• 按照算法2，因為商品B＜100元，則提交退款的最多金額為90-20=70元。

實際情況中方案A和B的金額，有高有低。如果由于特殊原因需要給用戶多退，客服可在后臺修改。

我們APP采用的是第一種，對用戶比較公平，體驗比較好。

和其他營銷功能的兼容性

營銷功能我一般分為3大類：對商品的打折、對訂單的優惠券、對全場的活動。

1. 打折，針對于商品，可以設置某一商品、可以是某一品類、也可以是全店……
2. 優惠券，針對于訂單，可以設置減x元訂單金額、減運費、減稅費……
3. 活動，針對于全店&訂單，一般設置為全場滿x元減x元，滿x元打x折，滿x元包郵，滿x元贈禮物……

當確認訂單的時候，滿足打折、優惠券、活動規則。誰先誰后，最終導致的付款金額是完全不一樣的。

我們設計的整套營銷功能的計算規則如下，供大家參考。

優惠券和活動的本質

當然說到底，優惠券和活動本質是一樣的。只是促銷的外部表現，但是內部規則是通用的。對于初級PM來說，可能不太能夠理解這句話，但是一定要嘗試從產品層面理解，也可從技術層面理解。

總結

本質上對于PM來說，新接手一個從未做過的功能，都是根據自己用其他產品中的該功能認知以及自己的理解、以及產品經驗來做的。問題是這樣太具象了，需要抽象出核心的模塊。

很多講優惠券的文章太側重運營層面了，問題是這樣實現出來的功能其實只是徒有表象，稍微運營有點新需求就無法擴展了。這其實是這個PM對優惠券的技術本質理解還不夠深刻。

說道最后，其實本質上就是優惠券的類如何設計，其他的都是依附于上面的方法，以及其他類的方法。

作者：吳寶峰，個人公眾號langzisay。業務型產品經理，3年社交+4年電商的工作經驗。

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