編輯導(dǎo)語：我們可以在各種平臺上看到付費會員機制，比如視頻平臺的會員、微博會員等等，這些會員可以給用戶帶來一些附加的福利以及利益；并且會員卡的后臺管理設(shè)計要有多種考慮，從用戶角度出發(fā)；本文作者分享了關(guān)于會員機制的后臺管理設(shè)計，我們一起來看一下。

大家好，今天給大家?guī)砹诵碌母韶?，前面講過了“財務(wù)流水”和“財務(wù)對賬”的相關(guān)設(shè)計；這一篇趁熱打鐵，抽“財務(wù)流水”其中的一個“交易項目”——“付費會員業(yè)務(wù)”（嚴(yán)謹(jǐn)，后面稱“會員卡業(yè)務(wù)”）來講一講。

“會員卡業(yè)務(wù)”聽上去好像都是C端玩的東西，其實不然，“會員卡業(yè)務(wù)”不僅和用戶的權(quán)益息息相關(guān)，因為涉及到收入，所以這塊業(yè)務(wù)也和財務(wù)密切相關(guān)。

“會員卡業(yè)務(wù)”聽起來簡單，但是實際入手設(shè)計的時候要考慮到的點還是特別多的，一不小心就有可能給后面的工作挖了一個坑，今天給大家梳理一下這塊產(chǎn)品設(shè)計。

好了，閑話少說，我們直接進入主題吧。

一、業(yè)務(wù)背景

業(yè)務(wù)背景其實很常見了，簡單來說就是“付費會員卡業(yè)務(wù)”，類似于市面上視頻會員、音樂會員等等，按照時間的長短去買，買了之后就可以在指定時間內(nèi)享受特權(quán)，這其中所涉及到的有C端用戶的操作以及C端與后臺的交互等等。

對于C端用戶而言，只有簡單的三步，打開APP、下單、支付就可以享受會員權(quán)益了；而對于后臺就相對復(fù)雜一點了，要記錄操作，還要改動數(shù)據(jù)，大家會問，這有什么難的？前面幾步確實沒什么難度，但是涉及到業(yè)務(wù)閉環(huán)中的“退款”的時候，就需要稍加設(shè)置避免踩雷了，下面給大家細(xì)講如下。

二、會員卡購買支付流程

1. 業(yè)務(wù)流程

購買流程與后臺數(shù)據(jù)交互相對簡單，直接給大家描述要點加圖示了。

• C端動作：用戶下單——支付——獲取會員權(quán)益
• 后臺作業(yè)：【記錄用戶購買記錄】、【記錄會員卡購買記錄】、【后臺改變用戶屬性】、【設(shè)置會員到期時間】、【記錄收入流水】

2. 【后臺作業(yè)】項目釋義

1）【記錄用戶購買記錄】：相當(dāng)于是用戶操作日志。

2）【記錄會員卡購買記錄】：單獨記錄會員卡的購買記錄，這里注意，為什么要單獨記錄會員卡的購買記錄呢？

舉個例子：如果用戶使用了優(yōu)惠券，使支付訂單金額為“0”，那么就不會跳轉(zhuǎn)至第三方的支付軟件支付了，從自己APP內(nèi)即可完成支付；同樣道理，第三方支付平臺亦不會有流水產(chǎn)生，而這條記錄，也不宜記錄至“財務(wù)流水”中，所以就單獨拿出一個表記錄用戶的會員卡購買記錄，也用于用戶在C端查看賬單使用。

注：記錄會員卡購買記錄的時候，建議將本次購買記錄的會員起止時間也記錄上，這是個關(guān)鍵點，下面講到退款的時候會提到。

3）【后臺改變用戶屬性】：根據(jù)用戶購買的會員產(chǎn)品，改變用戶對應(yīng)的屬性。

4）【設(shè)置會員到期時間】：根據(jù)用戶購買的會員卡時間，設(shè)置用戶的會員到期時間。

5）【記錄收入流水】：根據(jù)訂單詳情，記錄收入流水。

注：這里提到了多個表，大家看上去功能可能會有所重復(fù)（“用戶購買記錄”、“會員卡購買記錄”、“收入流水”），沒錯，部分?jǐn)?shù)據(jù)是有重復(fù)的，這里建議大家根據(jù)實際業(yè)務(wù)需要調(diào)整；如果問有那么多數(shù)據(jù)重復(fù)為什么不放到一張表里，因為實際業(yè)務(wù)需求的需要以及多表合用帶來的冗余數(shù)據(jù)和調(diào)整困難以及查詢問題各家技術(shù)解決方案不同，這里就不做具體技術(shù)討論了。

3. 流程圖

給大家用序列圖描述一下流程吧，實在找不出更好類型的圖表來描述了。

這一步需要的后臺操作其實很少，基本上就是生成了一些數(shù)據(jù)而已，便于各個業(yè)務(wù)部門通過數(shù)據(jù)來做分析，都是些表格配合查詢條件的界面，我就不放出來了。

三、會員卡申請退款流程

說起筆者會員卡退款的流程設(shè)計，真的是很充滿戲劇性，因為當(dāng)時系統(tǒng)還不是很完善，退會員卡的這個事情就一直被擱置著，還是走的線下實現(xiàn)——客服登記表格，同步給產(chǎn)品，然后再交給開發(fā)直接改數(shù)據(jù)，是不是很Low？也就當(dāng)時數(shù)據(jù)量小的時候可以這樣應(yīng)付一下；結(jié)果沒過多久，因為筆者所在企業(yè)地區(qū)業(yè)務(wù)調(diào)整，要面臨大面積的退會員卡業(yè)務(wù)了，這時候才著手設(shè)計退會員卡的業(yè)務(wù)流程，可以說是倉促上陣了；雖然倉促，但是設(shè)計過程還是有條不紊的，該有的流程都有了，該預(yù)想到的問題也準(zhǔn)備了解決方案，最終保障了我們能夠平穩(wěn)處理這次“事件”。

這也算是單獨給大家交代了一下“退會員卡業(yè)務(wù)”的業(yè)務(wù)背景了吧Hah，雖然是一次倉促的設(shè)計，但是沒吃過豬肉還沒見過豬跑嗎？不就是把錢退回到用戶錢包里嗎，這有什么難的？盡管筆者對這塊業(yè)務(wù)在規(guī)劃的時候有所準(zhǔn)備，但還是踩了不少雷，和我的程序員伙伴共同努力，才如期交付了產(chǎn)品，下面把經(jīng)驗匯總一下，分享給大家。

1. 業(yè)務(wù)流程

在講這塊業(yè)務(wù)流程的時候，要給大家一些提示，有些歷史大家沒有經(jīng)歷過應(yīng)該也聽說過吧，早期的話費充會員然后申請退款、寬帶充會員申請退款，現(xiàn)在的APP STORE申請退款等等；這些業(yè)務(wù)如果說有一個共性的話，那么都是如果退款是需要用戶主動去提訴求的；而受理用戶訴求的崗位是“用戶服務(wù)部門”，也就是我們常說的“客服”。

然后呢，我們就明確了業(yè)務(wù)的發(fā)起以及業(yè)務(wù)在系統(tǒng)的入口。

• C端動作：線上/電話提出訴求；
• 企業(yè)客服：查找用戶信息——登記/操作退款申請；
• 企業(yè)審核：審核訴求，同意or不同意；
• 后臺作業(yè)：【生成會員退款申請】、【后臺改變用戶屬性暫停用戶會員權(quán)益】、【同意與打款-原路退回/特殊】、【記錄用戶退款記錄】（對應(yīng)“記錄用戶購買記錄”）、【記錄會員卡退款記錄】（對應(yīng)“記錄會員卡購買記錄”，且需要改變“會員卡購買記錄”的退款狀態(tài)）、【記錄支出流水】（對應(yīng)“記錄收入流水”）、【不同意-恢復(fù)用戶會員權(quán)益并消息通知】。

2. 【后臺作業(yè)】項目釋義

1）【生成會員退款申請】：這個操作是由“客服”在后臺操作生成，我們這里僅就“會員卡退款”業(yè)務(wù)展開討論；這項業(yè)務(wù)在創(chuàng)建退款申請的時候也是存在兩項注意點的，這兩點是不太常見的業(yè)務(wù)場景，但也是實際業(yè)務(wù)中需要注意的。

恰巧筆者這兩種情況都遇到了：

• 是否允許超過期限的會員卡購買申請退款，參考APP STORE購買的產(chǎn)品超過會員使用期限后仍然可以支持申訴退款；
• 是否支持按剩余天數(shù)操作退款申請，可以理解為是否支持退款金額手動設(shè)置，不超過原支付金額即可。

注：【生成會員退款申請】這一項中，退回方式也是我們要注意的事項，下面會講到退款有“原路退回”和“特殊”，這里原路退回可以理解；但是還存在特殊情況，例如支付渠道沒有退款接口，超過支付平臺要求的退款時間等等，因為存在特殊的情況；所以建議在客服操作申請的時候就加以判斷，讓客服第一時間知道該申請何種方式的退款，從而向用戶要全需要操作的信息。

具體見下面解釋：

我們以用戶用支付寶購買會員為例，沒記錯的話退款應(yīng)該是走這個接口（trade.refund 統(tǒng)一收單交易退款接口），這個接口明確說明了：“當(dāng)交易發(fā)生之后一段時間內(nèi)，由于買家或者賣家的原因需要退款時，賣家可以通過退款接口將支付款退還給買家，支付寶將在收到退款請求并且驗證成功之后，按照退款規(guī)則將支付款按原路退到買家?guī)ぬ柹?；交易超過約定時間（簽約時設(shè)置的可退款時間）的訂單無法進行退款 支付寶退款支持單筆交易分多次退款，多次退款需要提交原支付訂單的商戶訂單號和設(shè)置不同的退款單號。一筆退款失敗后重新提交，要采用原來的退款單號?？偼丝罱痤~不能超過用戶實際支付金額”；意思就是在交易產(chǎn)生后的一定時間內(nèi)，是可以走退款接口申請退款的，退款回原路返回，并且同一筆訂單可以申請多次退款。

為什么支付寶要要求在一定時間內(nèi)，因為人家也是有結(jié)算賬期的，不能讓收入掛在那一年半載的等著你來操作退款吧；像這種能夠正常退的，我們可以原路退回還不麻煩，但是像特殊渠道或者是超時的，就要通過特殊方法執(zhí)行了。

特殊方法怎么走呢？就是需要“客服”人工向用戶要企業(yè)所支持的退款渠道的賬號了，這樣手動錄入一條退款申請；而支付的時候如果是支付寶，后面可以設(shè)計走批量轉(zhuǎn)賬的接口完成支付，這是“特殊”的流程。

2）【后臺改變用戶屬性暫停用戶會員權(quán)益】：“客服”操作了退款申請后，即需要凍結(jié)用戶的會員權(quán)益，這里要注意的是如果支持按天退款，那么記錄中需要將用戶要退的天數(shù)記錄下來。

因為一旦被拒絕，就要按照申請退款的天數(shù)再加回會員天數(shù)，加回的時候，還要同步設(shè)置對應(yīng)會員卡購買記錄中記錄的會員有效時間；這一點很隱蔽，是為了考慮多次申請退款時避免會員卡狀態(tài)和會員卡購買記錄匹配不起來。

3）【同意與打款-原路退回/特殊】：這里是兩個步驟，審批環(huán)節(jié)主要是根據(jù)客服提交的情況進行審批，主要講一下退款操作，原路退回不多贅述了。

如果是特殊退款，例如登記用戶支付寶賬號的退款，可以通過支付寶批量轉(zhuǎn)賬的接口實現(xiàn)退款（alipay.fund.trans.uni.transfer 單筆轉(zhuǎn)賬接口），如果是其他沒有接口的支付渠道就不建議了；一是資金安全問題，二是實在沒必要再為此單獨設(shè)計流程了（然后就是打款失敗的場景我們也暫時不考慮了，只需要保留一個修改打款信息的功能，并返回審核即可）；同意之后，推送消息給到用戶。

支付寶API截圖：

4）【記錄用戶退款記錄】、【記錄會員卡退款記錄】、【記錄支出流水】，這幾項合并來說下吧，和“購買流程”類似，主要是記錄功能，不多贅述了。

5）【不同意-恢復(fù)用戶會員權(quán)益并消息通知】：如果退款申請被拒絕，這里要注意的是需要恢復(fù)用戶申請之前的剩余會員天數(shù)，而不是恢復(fù)成之前的會員截止時間，然后再來一條消息推送或者短信就最好了。

3. 流程圖

本以為三言兩語就能講清楚，看來是高估了自己的語言功底；本以為三筆兩筆就能畫清楚，看來是高估了自己的畫圖能力。

省略了部分流程，本意想盡可能的把業(yè)務(wù)給大家描述清楚，奈何水平有限，大家湊合看下吧：

四、設(shè)計界面

1. 申請退款入口

2. 選擇退款類型

3. 申請退款

4. 審核退款

5. 財務(wù)退款

6. 設(shè)計界面總結(jié)

沒有給大家放財務(wù)相關(guān)的流水界面，只保存了部分大體流程上的界面；因為文章是基礎(chǔ)常規(guī)的會員卡后臺業(yè)務(wù)來梳理的，根據(jù)梳理從原有的原型上做了輕微的調(diào)整，剩余一些頁面留給大家遐想。

五、結(jié)語

這個項目已經(jīng)過去很久了，為了給大家盡量寫全面一些，筆者又重新梳理了一遍業(yè)務(wù)需求，盡量把需要注意的點都寫給大家。

在這個框架下，很多細(xì)節(jié)的地方要根據(jù)實際不同的業(yè)務(wù)需求做調(diào)整了（例如是否支持會員卡的部分退款、是否已過期的會員卡退款等等）。

其實無論C端的會員卡玩法如何設(shè)計，后臺的會員卡實現(xiàn)方式和方法都很相似；整理好邏輯思路，確定好細(xì)節(jié)需求，相信無論什么樣的會員玩法都難不倒你的，也希望這篇文章能夠幫助到大家吧。

最后，ToB，加油！

本文由 @橙子哥哥 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議