編輯導語：我們可以在各種平台上看到付費會員機制，比如視頻平台的會員、微博會員等等，這些會員可以給用戶帶來一些附加的福利以及利益；并且會員卡的後台管理設計要有多種考慮，從用戶角度出發；本文作者分享了關于會員機制的後台管理設計，我們一起來看一下。
大家好，今天給大家帶來了新的幹貨，前面講過了“财務流水”和“财務對賬”的相關設計；這一篇趁熱打鐵，抽“财務流水”其中的一個“交易項目”——“付費會員業務”（嚴謹，後面稱“會員卡業務”）來講一講。
“會員卡業務”聽上去好像都是C端玩的東西，其實不然，“會員卡業務”不僅和用戶的權益息息相關，因為涉及到收入，所以這塊業務也和财務密切相關。
“會員卡業務”聽起來簡單，但是實際入手設計的時候要考慮到的點還是特别多的，一不小心就有可能給後面的工作挖了一個坑，今天給大家梳理一下這塊産品設計。
好了，閑話少說，我們直接進入主題吧。
一、業務背景業務背景其實很常見了，簡單來說就是“付費會員卡業務”，類似于市面上視頻會員、音樂會員等等，按照時間的長短去買，買了之後就可以在指定時間内享受特權，這其中所涉及到的有C端用戶的操作以及C端與後台的交互等等。
對于C端用戶而言，隻有簡單的三步，打開APP、下單、支付就可以享受會員權益了；而對于後台就相對複雜一點了，要記錄操作，還要改動數據，大家會問，這有什麼難的？前面幾步确實沒什麼難度，但是涉及到業務閉環中的“退款”的時候，就需要稍加設置避免踩雷了，下面給大家細講如下。
二、會員卡購買支付流程購買流程與後台數據交互相對簡單，直接給大家描述要點加圖示了。
1）【記錄用戶購買記錄】：相當于是用戶操作日志。
2）【記錄會員卡購買記錄】：單獨記錄會員卡的購買記錄，這裡注意，為什麼要單獨記錄會員卡的購買記錄呢？
舉個例子：如果用戶使用了優惠券，使支付訂單金額為“0”，那麼就不會跳轉至第三方的支付軟件支付了，從自己APP内即可完成支付；同樣道理，第三方支付平台亦不會有流水産生，而這條記錄，也不宜記錄至“财務流水”中，所以就單獨拿出一個表記錄用戶的會員卡購買記錄，也用于用戶在C端查看賬單使用。
注：記錄會員卡購買記錄的時候，建議将本次購買記錄的會員起止時間也記錄上，這是個關鍵點，下面講到退款的時候會提到。
3）【後台改變用戶屬性】：根據用戶購買的會員産品，改變用戶對應的屬性。
4）【設置會員到期時間】：根據用戶購買的會員卡時間，設置用戶的會員到期時間。
5）【記錄收入流水】：根據訂單詳情，記錄收入流水。
注：這裡提到了多個表，大家看上去功能可能會有所重複（“用戶購買記錄”、“會員卡購買記錄”、“收入流水”），沒錯，部分數據是有重複的，這裡建議大家根據實際業務需要調整；如果問有那麼多數據重複為什麼不放到一張表裡，因為實際業務需求的需要以及多表合用帶來的冗餘數據和調整困難以及查詢問題各家技術解決方案不同，這裡就不做具體技術讨論了。
給大家用序列圖描述一下流程吧，實在找不出更好類型的圖表來描述了。
這一步需要的後台操作其實很少，基本上就是生成了一些數據而已，便于各個業務部門通過數據來做分析，都是些表格配合查詢條件的界面，我就不放出來了。
三、會員卡申請退款流程說起筆者會員卡退款的流程設計，真的是很充滿戲劇性，因為當時系統還不是很完善，退會員卡的這個事情就一直被擱置着，還是走的線下實現——客服登記表格，同步給産品，然後再交給開發直接改數據，是不是很Low？也就當時數據量小的時候可以這樣應付一下；結果沒過多久，因為筆者所在企業地區業務調整，要面臨大面積的退會員卡業務了，這時候才着手設計退會員卡的業務流程，可以說是倉促上陣了；雖然倉促，但是設計過程還是有條不紊的，該有的流程都有了，該預想到的問題也準備了解決方案，最終保障了我們能夠平穩處理這次“事件”。
這也算是單獨給大家交代了一下“退會員卡業務”的業務背景了吧Hah，雖然是一次倉促的設計，但是沒吃過豬肉還沒見過豬跑嗎？不就是把錢退回到用戶錢包裡嗎，這有什麼難的？盡管筆者對這塊業務在規劃的時候有所準備，但還是踩了不少雷，和我的程序員夥伴共同努力，才如期交付了産品，下面把經驗彙總一下，分享給大家。
在講這塊業務流程的時候，要給大家一些提示，有些曆史大家沒有經曆過應該也聽說過吧，早期的話費充會員然後申請退款、寬帶充會員申請退款，現在的APP STORE申請退款等等；這些業務如果說有一個共性的話，那麼都是如果退款是需要用戶主動去提訴求的；而受理用戶訴求的崗位是“用戶服務部門”，也就是我們常說的“客服”。
然後呢，我們就明确了業務的發起以及業務在系統的入口。
1）【生成會員退款申請】：這個操作是由“客服”在後台操作生成，我們這裡僅就“會員卡退款”業務展開讨論；這項業務在創建退款申請的時候也是存在兩項注意點的，這兩點是不太常見的業務場景，但也是實際業務中需要注意的。
恰巧筆者這兩種情況都遇到了：
注：【生成會員退款申請】這一項中，退回方式也是我們要注意的事項，下面會講到退款有“原路退回”和“特殊”，這裡原路退回可以理解；但是還存在特殊情況，例如支付渠道沒有退款接口，超過支付平台要求的退款時間等等，因為存在特殊的情況；所以建議在客服操作申請的時候就加以判斷，讓客服第一時間知道該申請何種方式的退款，從而向用戶要全需要操作的信息。
具體見下面解釋：
我們以用戶用支付寶購買會員為例，沒記錯的話退款應該是走這個接口（trade.refund 統一收單交易退款接口），這個接口明确說明了：“當交易發生之後一段時間内，由于買家或者賣家的原因需要退款時，賣家可以通過退款接口将支付款退還給買家，支付寶将在收到退款請求并且驗證成功之後，按照退款規則将支付款按原路退到買家帳号上；交易超過約定時間（簽約時設置的可退款時間）的訂單無法進行退款 支付寶退款支持單筆交易分多次退款，多次退款需要提交原支付訂單的商戶訂單号和設置不同的退款單号。一筆退款失敗後重新提交，要采用原來的退款單号。總退款金額不能超過用戶實際支付金額”；意思就是在交易産生後的一定時間内，是可以走退款接口申請退款的，退款回原路返回，并且同一筆訂單可以申請多次退款。
為什麼支付寶要要求在一定時間内，因為人家也是有結算賬期的，不能讓收入挂在那一年半載的等着你來操作退款吧；像這種能夠正常退的，我們可以原路退回還不麻煩，但是像特殊渠道或者是超時的，就要通過特殊方法執行了。
特殊方法怎麼走呢？就是需要“客服”人工向用戶要企業所支持的退款渠道的賬号了，這樣手動錄入一條退款申請；而支付的時候如果是支付寶，後面可以設計走批量轉賬的接口完成支付，這是“特殊”的流程。
2）【後台改變用戶屬性暫停用戶會員權益】：“客服”操作了退款申請後，即需要凍結用戶的會員權益，這裡要注意的是如果支持按天退款，那麼記錄中需要将用戶要退的天數記錄下來。
因為一旦被拒絕，就要按照申請退款的天數再加回會員天數，加回的時候，還要同步設置對應會員卡購買記錄中記錄的會員有效時間；這一點很隐蔽，是為了考慮多次申請退款時避免會員卡狀态和會員卡購買記錄匹配不起來。
3）【同意與打款-原路退回/特殊】：這裡是兩個步驟，審批環節主要是根據客服提交的情況進行審批，主要講一下退款操作，原路退回不多贅述了。
如果是特殊退款，例如登記用戶支付寶賬号的退款，可以通過支付寶批量轉賬的接口實現退款（alipay.fund.trans.uni.transfer 單筆轉賬接口），如果是其他沒有接口的支付渠道就不建議了；一是資金安全問題，二是實在沒必要再為此單獨設計流程了（然後就是打款失敗的場景我們也暫時不考慮了，隻需要保留一個修改打款信息的功能，并返回審核即可）；同意之後，推送消息給到用戶。
支付寶API截圖：
4）【記錄用戶退款記錄】、【記錄會員卡退款記錄】、【記錄支出流水】，這幾項合并來說下吧，和“購買流程”類似，主要是記錄功能，不多贅述了。
5）【不同意-恢複用戶會員權益并消息通知】：如果退款申請被拒絕，這裡要注意的是需要恢複用戶申請之前的剩餘會員天數，而不是恢複成之前的會員截止時間，然後再來一條消息推送或者短信就最好了。
本以為三言兩語就能講清楚，看來是高估了自己的語言功底；本以為三筆兩筆就能畫清楚，看來是高估了自己的畫圖能力。
省略了部分流程，本意想盡可能的把業務給大家描述清楚，奈何水平有限，大家湊合看下吧：
沒有給大家放财務相關的流水界面，隻保存了部分大體流程上的界面；因為文章是基礎常規的會員卡後台業務來梳理的，根據梳理從原有的原型上做了輕微的調整，剩餘一些頁面留給大家遐想。
五、結語這個項目已經過去很久了，為了給大家盡量寫全面一些，筆者又重新梳理了一遍業務需求，盡量把需要注意的點都寫給大家。
在這個框架下，很多細節的地方要根據實際不同的業務需求做調整了（例如是否支持會員卡的部分退款、是否已過期的會員卡退款等等）。
其實無論C端的會員卡玩法如何設計，後台的會員卡實現方式和方法都很相似；整理好邏輯思路，确定好細節需求，相信無論什麼樣的會員玩法都難不倒你的，也希望這篇文章能夠幫助到大家吧。
最後，ToB，加油！
本文由 @橙子哥哥 原創發布于人人都是産品經理，未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
,更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
