編輯導讀：轉贈金額是產品中的一個常見功能，指將賬戶已有的金額贈予給他人。因爲涉及到金額，所以它的設計需要非常嚴謹，否則一旦產品上線後出現問題，會產生很大的風險。本文作者總結覆盤了他在產品設計中遇到的問題，與你分享。

最近在工作中設計了轉贈金額的功能，一個小小的功能，在實際產品設計中產生了很多問題，且這些問題都不容小覷，因爲涉及到金額，一旦產品上線後出現問題，會產生很大的風險。所以我把在產品設計中遇到的問題進行了總結，分享給讀者，希望在設計類似產品功能時，可以幫助大家做參考。

01 什麼是轉贈金額及使用場景

轉贈字面的意思是贈予，表示將已有的東西贈予別人，別人收取後，不需要退換，贈予人也不會追要。標題中定義的“轉贈金額”，實際就是將賬戶已有的金額贈予給他人。比如：你賬戶裏有1000元，你可以將這1000元以內的金額轉贈給多個人，每人可收取相等或不等的金額。具有這種轉贈行爲的就叫做轉贈金額。

轉贈金額的使用場景有多種，本文內容按照我在實際工作中應用轉贈金額的場景來講。

我們設計的“轉贈金額”功能，主要是針對企業用戶，企業用戶在企業中一次性申請金額，用於在我方平臺購買產品。如果用戶賬戶的金額在後續使用過程中使用不完或不想使用時，平臺是不支持提現功能的。對於我們來說，用戶在充值金額的時候，這筆錢就已經扣除並支付到我們的公司賬戶了。而在充值到用戶不想使用的期間，這筆錢很有可能就已經被公司因爲某種原因花掉了，用戶後續提現，其實就相當於退費。就算是企業平時的經營非常良好，如果某一時間段，大批量用戶同時申請提現，也會導致公司出現現金流虧損的情況。

所以我們決定不支持提現功能。如果用戶在平臺充值金額後，用不完或不想使用了，那麼可以通過轉贈的方式，將金額轉贈給企業或部門人員。對於我們來說，如果用戶真的暫時沒有需求使用當前產品，通過轉贈金額的方式既可以減少用戶流失，也可以讓用戶和用戶之間產生互動，通過這種轉贈行爲促進用戶活躍度，是一個更好的選擇。

02 轉贈金額需要考慮的問題

“轉贈金額”其實是個小小的功能，但因爲涉及到金額髮放、領取。其風險是很多的。例如早期的微信轉賬功能，我們在使用微信轉賬時不能保證每次都操作無誤，轉賬時可能會出現輸入的金額錯誤，或者轉賬時轉錯人。而要求對方退款時，對方不肯退換。導致了我們自己承受損失。這就是在涉及錢財過程中的風險問題。而後期微信新增了在轉賬一定金額後，驗證收款方信息的功能，用來提高轉賬的安全性。

所以在我們涉及到金錢的實際產品設計中需要考慮到方方面面。確保每個點都要考慮到，減少風險的發生。

一般轉贈金額時的操作一共分成3步：轉贈人填寫轉贈的規則、分享給領取人、領取人進行領取。

根據這個操作的流程我們就可以根據每一個步驟來分析轉贈金額功能都需要考慮的一些問題。

轉贈人填寫轉贈的規則：

轉贈人填寫轉贈的規則：轉贈規則是轉贈人在給想好給用戶轉贈前需要設定的規則。用戶可以根據設定的具體規則進行領取。主要包含的參數有，轉贈金額和轉贈個數。

轉贈金額是轉贈人準備轉贈給其他用戶的金額，一般我們在準本贈予給其他人物品的時候，首先是在送出之前就想好要轉贈的東西是什麼。所以我們要先定義好轉贈的金額。

轉贈個數就是你準備將金額轉贈給幾個人，幾個人可以進行領取。便於我們一次性操作實現多人領取。舉個例子，如果你準備給多個人轉贈金額，如果沒有轉贈個數的話，就需要你進行多次操作，填寫金額轉贈給A用戶。A用戶領取後，你需要再次填寫金額轉贈給B用戶…這樣反覆操作，即麻煩又浪費時間。

用轉贈金額乘以轉贈個數就是我們最終要發送的金額。例如：轉贈金額填寫10元，轉贈個數填寫1個。那麼我們最終發送的金額就是10元，有1個人可以領取。如果轉贈個數填寫5個，那麼就是50元。通過這樣一個規則設定，也能計算清楚，一共需要發送的金額是多少，和預算是否吻合。或者相差多少。設定好規則後我們就可以發送給領取人，讓系統按照這個規則進行批量發送了。

但是在這種規則下，產品經理還需要延伸考慮的問題是，根據實際應用場景，按照轉贈金額乘以轉贈個數來轉贈的話，希望每個人可以分到多少金額，是平均分還是隨機分配。

分享給領取人：

在轉贈人填寫好轉贈規則時，分享給領取人時，中間還缺少一步，就是我們需要考慮，用戶當前賬戶的餘額是否滿足用戶填寫的轉贈規則。也就是說，我要給你轉1000元，那麼得看我有沒有這1000元，如果我只有100元，那麼我肯定就無法給你轉這個錢。

領取人進行領取：

前面轉贈人確認好規則了，錢也放進去了。分享給其他用戶後，就是領取人進行領取這個轉贈金額了。這時候就容易出現一些問題。

例如：是否需要限制領取人？我轉贈給別人的金額，我自己能否領取？

我在填寫轉贈規則的時候輸入了紅包個數爲3，那麼同一個領取人能否連續領取3次？

轉贈的金額是否有時效性限制，比如說我給某個用戶轉贈金額後，他一直沒有領取怎麼辦？

還有如果轉贈人規則填寫錯誤能否允許撤回重新發送？

用戶領取成功後，領取到的這個金額能否再次轉贈給其他人？

如果領取人在領取金額時發現金額已被領取完或已過期怎麼辦？

03 領取策略

上面分析了在轉贈金額中容易產生的問題，我將這些問題分成了用戶體驗問題和安全風險問題，下面我根據這兩類來分析下針對這些問題我是如何考慮的。

3.1 涉及到用戶體驗的問題

3.1.1 轉贈金額錯誤是否允許撤回

撤回功能是指給某個人發送消息或郵件、紅包，可以在一定時間內撤回，撤回後，對方將看不到已發送的內容。

如果不支持撤回，那麼當用戶發送消息、郵件後發現自己對發送的內容不滿意想要修改時，或發現消息發錯人時，則沒有機會悔退一步，導致出現不可預估的後果。

而針對轉贈金額我們是沒有做撤回的功能，一方面如果支持轉贈金額撤回，那麼轉贈人在發現金額輸入錯誤，個數錯誤或分享錯人對的時候，可以使用撤回功能及時撤回，避免了一些風險。而另一方面如果我們做了撤回的功能，那麼站在領取人的層面考慮是十分不友好的。收到了轉贈的金額，還沒開心多久就被轉贈人撤回了，心情一定是十分不高興的。舉個例子：有一天你發現你購買的彩票中了大獎，你一定會特別高興，但是你在找彩票的時候又發現彩票不見了，那麼你的心情一定是比沒有中獎還要失落。所以我們在不能只考慮這個功能給我們帶來的價值，同時也要考慮這個轉贈功能給我們帶來的負擔。

像目前微信平臺，發送文字、語音等消息內容都是支持撤回的。是因爲接收消息的用戶對此類消息的感覺並不強烈，如果消息被撤回了，對他們來說也沒有什麼影響。所以衡量利弊的時候，更願意給發送者撤回這個功能。而對比轉贈金額來說，領取金額的用戶收到了錢相當於又被要回去了，那麼領取人帶給我們的負擔要高於給予轉贈人撤回功能的。所以我們不支持轉贈金額做撤回功能。

3.1.2 領取權限的規則制定

權限一般指的是系統設置的安全規則或者安全策略，領取權限就是指用戶A轉贈金額後，都有誰可以領取，誰不能領取。產品經理需要將用戶領取的操作過程中可能會出現的問題進行總結歸納，並制定出解決方案。在領取權限的規則制定中，我們需要考慮的問題主要有：領取人是否需要限制、轉贈人自己能否領取、同一個人能否多次領取、領取別人的轉贈金額，是否能再次轉贈？關於功能的提示。

如果我們不考慮這個領取權限的規則，那麼在金額轉贈的過程中就會涉及到安全問題，轉贈的金額誰都能領取。比如，想轉贈給用戶B的金額，被用戶C領取了。或者B領取金額後還能重複領取。我們要制定的規則主要是想避免這種情況的發生。

下面我根據這幾個需要考慮的問題來分別分析如何根據這些問題制定相應的規則。

領取人是否需要限制：主要是指轉贈人分享金額後，誰能領取的問題。考慮這個問題的原因是因爲可能會出現，有其他人看見轉贈金額分享的鏈接，點擊進去並領取了相應的金額。我們最終的辦法是沒有做領取人限制這個功能，主要考慮的是在真實使用場景中轉贈人會自己控制分享這個範圍，比如只在公司內部部門羣裏發。這樣實際風險程度已經降低，同時我們採用的辦法是領取人在領取金額時輸入一些驗證信息的方式解決了這個問題。

轉贈人自己能否領取：這個問題的風險程度較低，但也是我們也需要考慮的問題。我的考慮是轉贈人轉贈給其他同事的金額是用於讓大家都可以自己在平臺獨立購買產品。那麼轉贈人自己本身已經可以購買。則無需二次領取自己轉贈出去的金額。

同一個人能否領取多次：這個是需要產品經理給開發確定規則的問題，我們在實際產品設計中的規則是同一個人不允許多次領取。轉贈人（負責人）制定領取規則肯定是按照幾個人領取，每個人的領取金額來制定的，如果一個人可以領取多次，則打破了這個規則。

領取別人的轉贈金額，是否能再次轉贈：這個考慮因產品而異。像想有的產品是領取優惠劵的概念，領取後就有不允許再次轉贈的情況。我們的產品應用中，主要目的是能夠讓團隊、部門人去自主購買。將轉贈金額定義爲了賬戶餘額，領取的金額和充值的金額都在一個賬戶餘額中，可以進行再次轉贈。

關於功能的提示：轉贈金額有能領取的情況，就存在不能領取的情況。其中不能領取的情況就包含了金額被領取完。我們需要考慮金額領取完時，系統給出怎樣的提示。比如給出提示：“當前金額已被領完”。如果已經領取完的金額我們不給出相應提示，那麼用戶反覆點擊領取按鈕，會以爲是系統出現了bug。

同時還要結合上面我們設定的規則，考慮給出用戶相應的提示。例如：轉贈人自己領取自己分享的金額需要提示：不能領取自己的轉贈金額二維碼已失效提示：當前二維碼已失效已經領取過轉贈金額，再次領取時，頁面提示：您已成功領取金額，不能重複領取

3.2 涉及到安全風險的問題

因爲我們的功能是轉贈金額，因爲涉及到了金額，所以就要考慮安全的問題，如果在領取過程中我們不去考慮這個權限規則，那麼就會導致轉贈人填寫完金額分享給用戶後誰都能領取，舉個例子：轉贈人把轉贈金額的分享鏈接發送給用戶A，用戶A可以領取，用戶A轉發給用戶B，用戶B也能領取。這樣在轉贈過程中大大提高的風險。我將安全風險的問題主要分爲金額領取的安全性和金額分享的時效性。那麼下面主要根據這兩個點來分別考慮。

3.2.1 金額領取的安全性

金額領取的安全性是本文中重點講解的點。它的解決方法主要有兩個：轉贈人指定領取人和利用驗證轉贈人信息的方式。

轉贈人指定領取人：相對比金額領取的風險，這種辦法就比較安全。上面講到了一個問題就包含，轉贈的金額是否誰都有權限領取。如果用這種方法，讓轉贈人在填寫轉贈規則時，選擇相應的領取用戶，就可以只讓這些人領取。

這種方案的安全性會提高，但是選擇領取人這個步驟，需要結合目前產品本身的功能來看，產品中是否支持選擇領取人，或者通過填寫用戶的一些驗證信息，手機號等。不過這個功能增加了轉贈人的填寫步驟。

還可以考慮的方法，是否需要在產品中建立一個團隊的概念，如果產品的用戶信息的真實性可以保證。那麼可以讓轉贈人在轉贈時，選擇領取權限爲當前企業或當前部門。

驗證轉贈人信息：我們在實際產品應用中就是選擇了驗證轉贈人的信息。主要的步驟是，轉贈人分享後，領取人點擊分享鏈接進入領取頁面後，需要填寫轉贈人的手機號等信息進行驗證，因爲平臺內的手機號是唯一的。增加此步驟是防止誤領，提高領取的安全性。

如果想做的更加安全的話，還可以生成隨機驗證碼。告訴指定領取人，領取人以此驗證碼來驗證。

3.2.2 金額分享的時效性

金額分享的時效性也是我們需要考慮的風險因素。如果轉贈的金額沒有領取完會怎麼樣，這個金額在哪裏，難道要一直被凍結嗎？所以我們定義了一個分享的時效性，如果在24小時內（可以根據自己產品定義），金額沒有領取完，那麼金額會退還回原賬戶。

04 總結

本文中主要分析了涉及金額交易會產生的風險及做爲產品經理需要考慮的問題，如果我們在日常產品設計中考慮不到某個點，或漏掉某個點，很容易在實際產品應用中產生大問題。

本文由 @張悄悄 原創發佈於人人都是產品經理，未經許可，禁止轉載。

題圖來自 unsplash，基於CC0協議

相關文章