虛擬To B支付設計研究（二）：設計思考篇

產品經理入行寶典，12週特訓，22名產品大牛全程帶班，200+名企內推，100%保障就業！了解詳情

這是虛擬to B支付專題研究的第二篇：虛擬to B支付設計思考。本篇是在第一篇《基礎知識科普篇》基礎上，對虛擬to B支付相關設計知識進行更深入研究，更側重於設計思考。

本篇研究方法：對比法

社會科學中運用較廣的方法。對比法旨在將有一定關聯的現象和概念，進行比較對照，判斷異同、分析緣由。

對於認知陌生領域，好處在於 通過與已知熟悉事物的對比 ，從熟悉事物遷移到陌生事物，更形像地認識陌生新事物。

因此，本篇會通過與To C對比，更好地理解To B支付設計特別之處。

一、什麼是虛擬To B支付

虛擬To B支付是“B端用戶購買組織所需的虛擬商品時進行的支付”。上一篇文章對此有過詳細定義《虛擬To B支付設計研究-基本知識科普篇》

對此再回顧幾個要點，喚起大家的回憶：

虛擬To C支付，可以聯想平時遊戲充值、開通包月的場景，比如QQ音樂充值會員；虛擬To B支付，可以聯想其他公司買騰訊服務的場景，比如企業郵箱購買。
區分To B還是To C支付在於“誰”支付，只要是B端賬號支付，都是To B支付。
“B”因為是組織，使用B賬戶的，可能是多個人。
目前To B支付（B資金轉出去）的方式有：網銀、櫃檯公章、新興在線支付。它們各有利弊。

二、虛擬to B支付設計差異點

1、提供用戶更穩健的操作

虛擬To B支付牽扯的通常是大宗商品，這類商品最大的特點是： 交易金額高，交易頻率低。 可能一年才買一次，但是一次就花個成百上千萬。比如某某企業購買騰訊雲業務。

因此，對於虛擬To B支付來說，操作過程會更加求穩。因此在設計時需要注意幾個要點：

1.1 操作流程更“穩”

一般虛擬To C支付的場景多為 衝動型消費 ，衝動型消費的特點是，用戶的購買意願很容易消減，為了抓住這一點的稍縱即逝的消費意願，越快讓它支付完越好。

因此“快”會是非常重要的考慮因素。參考米大師web，舉一個例子，我們在包月付費時，我們會想辦法來縮短用戶的支付路徑，想辦法讓用戶越快給完錢越好。比如我們一般是把後台下單邏輯隱藏，因此前端是不出現的，前端可以直接 一步完成： 選商品→支付流程。

BUT ，在虛擬to B支付場景中，操作步驟不一定最快，但是一定是最穩健： 該有的操作一步也不能少，有時候為了穩健，還需要用戶多次安全確認 。

我們通常會用指示器把操作步驟顯示出來。讓用戶每一步都能確認，避免犯錯。

1.2 資金流向時刻反饋

在虛擬To C場景中，由於是 小額資金 交易，銀行對資金的處理速度很快，能及時反饋結果。從用戶側下單支付（下單支付頁），到後台反饋銀行結果（結果頁），用時都很快。

BUT ，虛擬To B支付則不同，由於是 大額資金 交易，銀行需要進行核實，這個過程有時候需要進行很傳統的操作，比如：人工打電話核實、登錄網銀U盾操作核實。因此從用戶側下單支付，到後台反饋銀行結果，有時候需要一定時間。

動輒成百上千萬的資金，用戶需要對自己給出去的錢有極致的操控感，需要實時獲知自己的資金流向。因此需要在用戶每個操作時都給出實時的資金反饋。我們在設計時會著重註意 實時反饋。

舉一個例子，如果資金延遲到賬，我們會展示一個時間軸，時刻反饋資金的處理情況。（類似於電商中的物流時間流同步）

1.3 退款作為一個重要的功能設計

在虛擬To C支付中，因為到賬及時率高，加上用戶衝動消費（買了也不貴的心理），退款是一個非常低頻的操作，在產品設計上通常“有即可”，或者有問題找到求助方法即可。

舉一個例子，騰訊服務的付費，在業務中我們不提供一個專門的退款功能，但是會在客服中提供發生問題求助的法子。

BUT ，虛擬To B支付則不同，由於是大額資金交易，加上前面提到了，從下單到訂單完成，中間會有時間差。因此，資金是允許在成交之前，隨時退訂。

因此，退款功能需要做到一個突出重要，用戶能夠發現的位置：

PS： 對於虛擬To B支付，有一個特別點，允許 部分退款 。

2. 兼顧更加多樣複雜角色的前端

都說To B產品是很複雜的，對於虛擬To B支付來說，這個複雜點在於：兼具的角色很多，因為一個B端賬號的背後，可能是多個用戶在使用。

有可能就是，老闆、財務總監、職員都共用一個B端賬號，他們之間的使用差異是很大的，因此設計時需要兼顧這些角色的差異性。

1.1 歷史操作信息作為一個重要的功能設計

虛擬To C支付中，操作者通常是唯一的。一個賬號背後可能就是一個自然人（排除共用賬號的特殊情況）。因此自己進行了什麼支付操作，還是有一定印象。

但是虛擬To B支付則不一定，操作者不一定是唯一的。老闆、財務總監、職員都可能進行過一定操作，如果不記錄，就會導致資金操作亂套。因此，我們會提供一個歷史操作信息的記錄，來方便不同角色登入時，可以清楚上一次操作者的操作。

1.2 簡明易懂的內容設計

虛擬To B支付通常涉及到一定的專業背景知識（比如財務等專有名詞）。但是每個角色的知識背景是不一樣的（比如老闆、財務總監、職員），財務背景的用戶可以在較低學習成本的情況下使用，但是沒有財務背景的（比如老闆），則需要設計時兼顧這部分人的需要，在涉及一定專業背景知識的場景中，我們可以通過一定的內容設計，把背景知識的內容轉換為一般通俗易懂的內容。

3. 做好為產品限制擦屁股的準備

整個行業內，虛擬To C支付已經做得相對完善了，但是虛擬To B支付則處於剛剛起步的階段。不少技術、政策限制導致的問題，需要通過合理的設計來“潤滑”用戶的心理：

銀行系統對於大單處理的效率會是一個很大的技術限制，輕則可以幾小時到賬，重則幾天，有時候甚至1週才能處理完成。這個時候需要通過一定設計來安撫用戶。
有時候受政策影響也會導致用戶一定的不順暢，需要苦口婆心地向用戶解釋。比如支付方式中的線下支付，就是針對一些大單，必須線下使用公章才能用戶能線上操作。

小結

目前虛擬To C支付已經做得相對完善了，虛擬To B支付則處於剛剛起步的階段。正正如此，這一部分還有不少的機會點挖掘。

雖然米大師企業版上線已經走出去，但是要走得更遠，還需要我們繼續做精、做細，把產品體驗做到極致。不斷思考和總結。