文章的結尾總結怎麼寫
對於相對複雜的B端產品操作，使用者的入駐、熟悉過程存在較高的學習難度，我們可以透過什麼方法來降低使用者的使用門檻呢？本文總結了3類場景+8種方法，希望能給你帶來一些幫助。
對於相對複雜的B端產品操作，使用者的入駐、熟悉過程存在較高的學習難度，我們作為產品設計者可以透過哪些方法來降低使用者的使用門檻呢？本文透過總結了3類場景+8種方法，希望我們在拓展功能邊界的同時，注重使用者使用效果，更好的發揮產品作用。
不知道從何時開始，很多B端產品的銷售團隊以產品功能多，業務邏輯複雜當成了宣傳亮點，以大而全為競爭優勢，極力渲染自己的產品能夠解決業務場景中的“一體化痛點”。
誠然，這種推廣模式對於B端使用者的決策者而言，會有一定的吸引力，但作為產品團隊，我們始終不能忽略一個關鍵問題：
新使用者、初期成長型使用者怎樣能快速掌握你的產品？怎樣能快速透過你的產品而達到他的目的？
全文概覽：
產品初裝費的無奈
降低客戶入駐門檻的3類場景分析
降低使用者學習成本的8種方法
寫在最後的總結
今天的文章很長，建議先收藏~
01 產品初裝費的無奈
我遇到有些SaaS平臺在收費內容中包含了“產品初裝費”，當然也有平臺會採用一些優惠活動減免這部分“初裝費”。
這裡的“初裝費”並不是我們日常理解的系統安裝、維護、實施的費用。
而是給使用者開通了新的賬號，由平臺服務人員幫助使用者完成一系列必需的複雜操作，並維護好初始資料。
舉例說明：比如某個產品（平臺）提供了較為成熟的配置化審批流程自定義功能，包含了圖形化的配置、不同的條件分支、不同的業務種類、不同的資料許可權及流轉過程，以及抄送、會籤/或籤、資料許可權配置等等。（聽起來就蠻複雜的）
現在我的企業要使用此平臺完成各項業務流轉，企業本身一定有個性化的業務審批流程，企業操作人員大機率不知道怎樣在平臺中建立適合自己的審批流，便可以把審批流程的場景線下描述清楚，由平臺的服務人員代為配置。配置完成後企業直接使用即可。
這個過程似乎很貼心，而且將更多的產品服務融入其中，更有甚者藉此宣稱為“更有溫度、更貼心的增值服務”。而在我看來，
僅從產品設計和應用的層面來分析，這項“初裝費”的服務在一定程度上也是不得已而為之。
畢竟產品的設計、操作、初始化規則太複雜了，對於新使用者增加了大量的學習成本，如果一切均由使用者自行操作，可能會有大量使用者望而卻步，從而影響了平臺的推廣進度。尤其當你的使用者日常對網際網路軟體、網際網路操作並不熟練時，這樣一套“功能強大”的平臺，一定會把他拒之門外。（
這也是我一直想探索的【平臺思維】與【使用者思維】的差別與矛盾
）
而且我們現在討論的依然是使用者進入之後，怎樣快速上手。如果再向前思考一步，還有什麼辦法能夠
最佳化“使用者進入”的過程？
即在使用者正式使用之前，有哪些辦法能夠降低其入駐門檻？
尤其是A企業已經使用過同類的產品，我們要把企業“撬過來”的時候，有哪些可嘗試的功能來支撐？
所以今天的分享，我會整體分為兩部分：一方面探索產品層面使用者入駐的簡化過程；另一方面才是入駐之後，如何讓使用者對產品儘快由陌生到熟悉。
此過程我也處於初步探索階段，希望能夠為有同樣困惑的夥伴們帶來一點幫助，
同時如果你有更好的設計方案，歡迎和我分享，我們一起彙集智慧做出更好的產品。
02 降低客戶的“入駐門檻”
首先我把平臺的新客戶分為三類，再針對每類的特點進行分析。
1. 全新型客戶
全新型客戶是我們最常見也最好理解的，對於“全新”的客戶來說，我們的設計可以圍繞
【入駐操作效率】
來最佳化。
舉一個容易理解的例子，銀行很多業務涉及到監管要求和風控等因素，需要線下辦理。隨著網際網路時代的到來，銀行也一直在探索更多線上化的可能性。但是不同的銀行對於同一類業務，開通的流程也有很多差別。
科技力量強的銀行，可能有些企業服務支援全線上辦理，透過web端進行資料填寫、安全認證，即可完成開通；
但還有很多銀行採取“先線上提交資料預約，再拿著紙質材料到網點線下辦理”的方式，平心而論，
如果你是企業，在其他因素都對等的情況下你會怎麼選？
我也遇到過一些小銀行的客戶經理說，因為入駐流程的不便捷，導致他們某些業務很難推廣。
而且，即便是全流程線上處理，不同的入駐模式對於客戶也有不同的體驗。
我們以需要稽核企業資質的場景為例，下面就有兩種不同的模式：
使用者註冊——>填寫企業認證資料——>平臺方稽核——>企業登入——>檢視平臺全量功能
使用者註冊——>自動登入並進入平臺——>檢視平臺部分功能（彈出待認證提示）——>填寫企業認證材料——>平臺方稽核——>檢視平臺全量功能
以上兩種模式，你會更傾向於哪個？或者你認為哪個企業的入駐門檻更低？
當然，其中可能包含不同業務模式，平臺對入駐企業的“真實性”、“安全性”等方面有不同的要求。第二種也可能會存在更多的垃圾資料，但是如果僅從“入駐門檻”的角度分析，第二種無疑是更低的。
而且現在越來越多的B端產品，尤其是SaaS類產品更傾向於採用第二種“開放註冊”的模式。（
當然，這種方式也容易被競爭對手瞭解更多，但這就是另一個話題了
）
再深入考慮一步，同樣的入駐流程，使用者註冊或企業認證時填寫的資料多與少，勢必也會影響入駐轉化率，這也是為什麼現在越來越多的產品（尤其是C端），可能只需要一個手機號+驗證碼就可以註冊成功了。B端認證時所收集的資料，除去企業的基本資質資訊之外，
每多一個附加資訊，就會增大一部分入駐的難度。
2. 半新型客戶
半新型客戶指這些客戶和我們產品存在一定的關聯關係，比如我們的產品是對某些存在合作關係的產品，在業務場景上的拓展，因此合作方現有的客戶也可以成為我們的客戶。
而對於這類客戶，從體驗上講，我們總不能讓他再來註冊一遍吧？因此，我們的設計可以圍繞
【系統自動遷移】
的思路進行最佳化。
所以此時我們需要設計出一套可以從合作方平臺平滑自動遷移客戶資訊的方案，讓這些存量的客戶可以直接登入我們的產品，無需進行其他任何操作。
如果我們平臺所需的部分資訊合作方無法提供，那我們再考慮如何透過補錄，或者簡化註冊的流程來解決。
補錄指的是使用者可以正常登入平臺，但如果開展某項業務操作之前，需要有提示去進行資訊補錄；
簡化註冊指的是使用者無法正常登入平臺，但假設註冊需要10項資料，平臺能透過合作方獲取8項，那就再提供另外2項的資訊，從而讓入駐流程更簡單。
當然，系統間的資料遷移過程也是比較複雜的，尤其對於同一個客戶，在不同的平臺均有業務操作，而客戶資訊如果在某個平臺發生變更之後，
多個平臺間如何進行資料同步從而保證客戶的操作連貫性，也是一個非常值得單獨探討的場景。
其中還會牽扯出很多種情況，包含功能架構層面、處理邏輯層面、技術架構層面等等，今天就不展開分析了，後續我會單獨整理一篇關於“資料遷移”的場景總結。
3. 競爭對手的客戶
最後，對於“競爭對手”的老客戶來說，我們的設計可以圍繞
【打通技術壁壘】
的可能性來探索。
記得兩年前讀《幕後產品》這本書時，網易雲音樂當時對於是否支援“匯入歌單”功能進行了激烈的討論，最終這個功能為產品帶來了非常顯著的效果，讓其他音樂平臺的使用者帶著他們的歌單順利遷移到了網易音樂。其中具體的場景和功能我記不清了，我也沒有使用過網易的“匯入歌單”，但這個思路就是針對競爭對手中的老客戶非常有效的降低入駐門檻的體現。
以大家熟知的OA協同產品來舉例，假設A公司以前使用釘釘，現在你們新推出了一個產品，其中包含了其中的功能以及其他的客戶增值功能，那麼有什麼辦法能夠讓A公司更容易接受這一步的產品遷移呢？
我們知道，
一旦客戶在某個平臺沉澱了三年及以上的業務資料，那麼這些資料價值是非常大的，我們很難讓對方放棄這些價值。
《俞軍的產品方法論》一書中提到一個公式，我認為非常具有指引性：
使用者價值=新體驗-舊體驗-替換成本
相信我們都能重視新產品的新體驗，也一定是因為新體驗的優勢才有機會讓客戶拋棄舊體驗。但我們千萬不要忽略【替換成本】，而資料價值在替換成本中佔有最重要的地位。
所以我們的方案更加清晰了——
支援舊平臺的業務資料匯入
（這裡的匯入並不一定指檔案匯入，我們不要被固有觀念影響）
當然也有可能客戶希望新舊平臺一起用，那我們的方案可能要修改為支援新舊平臺對於部分業務的資料同步/共享。
而因為這裡的新舊平臺不存在合作關係，所以無論是資料同步還是匯入，都只能透過我們的產品來探索方案。這也是為何我把這個場景的關鍵定義為
【打通技術壁壘】
。
如果舊平臺有OpenAPI，那我們勢必要對接上；
如果沒有OpenAPI，但是有資料匯出功能，則需要使用者先進行匯出，我們再支援這一類資料模板的匯入。
但是如果我們是一個平臺級的產品，目標使用者所涉及的舊系統參差不齊，在模板匯入上也很難做到標準化，這時我們可以優先支援幾類常見的模板，後續再迭代更多的模板。或者設計出一款能夠自動識別多種模板的匯入功能。
假設舊系統的資料無法匯出，那就只能透過其他途徑線下收集這些資料，再由使用者批次匯入了。一旦實際情況走到這一步，面對著具體的替換成本，這個客戶我們大機率很難“撬動”。
以上三類，是常見的降低客戶入駐門檻的思路，不知道讀到這裡的你有沒有一些收穫呢？下面我們來看另一方面，對於新使用者，如何降低他們的學習成本。
03 降低使用者的“學習成本”
1. 在新功能首次使用時，貼心的提示很重要
首先，使用者首次登入之後的整體佈局、功能、重點操作的入口介紹很重要。
我們常見的平臺類產品，首次登入的介紹功能比較同質化，多數以“浮動”、“突出”、“指引”為主。但是，這些靜態的標註，以及通用化的標註，對使用者來說真的有用嗎？
代入使用者思維來試想：我們有多少次是透過這些提示來認識平臺的？
但是如果沒有這一步，似乎也會少點什麼。所以我們應該思考的是，如何讓這一步新使用者指引更能
貼合用戶的【入門水準】
。
其次，使用者首次在正式使用某個功能時，功能的操作流程，溫馨提示等共性介紹也很重要，具體內容請看下一條。
2. 操作指引真的能完成指引嗎？
現在常見的操作指引，更多像是【頁面介紹】，告訴你這頁重點的操作在哪。如果不做指引，使用者多花幾秒的時間也能看個大概。
但是這個業務應該怎麼做？有什麼前後順序要求，需要提供哪些資料，能夠生成哪些結果，能夠為我帶來什麼，這些問題使用者從哪裡知曉呢？
所以真正有效的操作指引應該是怎樣的？
我的觀點是：
至少要有一個單獨的功能帶著使用者把功能的效果簡單直接的介紹清楚，並半自動的帶領使用者進行關鍵節點學習，透過簡單的點選、資料變化，把MVP流程快速“跑通”一遍。
這裡有點像我們玩遊戲時的【新手教程】，邊講邊練。
寫到這裡我也突然好奇，為什麼B端產品中，很少有真正的【新手教程】？是因為不重視？還是因為體驗要求