B端產品的冷啟動多是依靠個別大客戶，在為大客戶做好基本功能之后，并不斷優化系統，擴大客戶范圍。那么 ，該如何高效處理用戶訴求與問題，并使用合理的運營推廣策略，隨之而來的挑戰是不斷優化系統，擴大用戶范圍。

這個過程中，如何讓用戶快速知道產品的功能？如何獲取用戶最真實的訴求？如何高效處理用戶問題？如何提高用戶的使用率？如果讀者還沒有很好的答案，本文可以為你提供一些非常實用的干貨

一、B端產品和C端產品有那些區別

1、面向對象層面

C端產品面對的用戶通常是消費者、個人用戶，產品所經手的用戶量級通常很大，所以toC產品更注重用戶體驗，界面設計。

B端產品面對的用戶通常是企業、商家，產品的用戶量級通常較小，但更注重業務邏輯，所以toB通常為了辦事更高效來設計。

2、盈利模式層面

C端產品則更注重快速落實公司商業模式，通常會短時間內開發出MVP投放市場來測試產品的契合度，最終是以大量級的用戶來達到盈利目的。

比如說：游戲類，主要直售皮膚/皮膚碎片/各種充值活動/點券奪寶的終極獎勵/廣告等來盈利，該盈利模式要基于有大量的用戶;

B端產品往往是解決客戶具有共性的痛點，因為問題的解決客戶出現付費意愿;

這些痛點可能是開源：增加推廣渠道、增加銷售渠道(TB的電商)、增加知識來源;抑或節流：

降低生產成本、降低溝通成本、提升管理效率如OA/PMP 等;減少外部成本，如商旅服務、政務服務等;

3、產品場景和產品形態方面

C端產品的使用對象則更偏向于某一類人群，解決的多為生活場景，比如在家休閑或者外出游玩，輕松愉悅，約束很少，所以往往是APP、小程序形態比較多。如叮咚買菜、健康碼、乘車碼、親子社區等;

B端產品的受眾對象往往是組織單位，解決的場景多為工作問題，比如公司、學校、政府、特殊群體等，因為對應的多是公司辦公場景下的使用，所以往往產品的主力端口為PC端，移動端為補充性端口;如CRM，銷幫幫進銷存等;

4、產品使用角色和客戶耐受性

C端產品使用角色大多為單角色，如陌陌解決個人交友問題、京東到家解決個人商品購買問題、消消樂解決個人生活趣味的問題;基于此C端用戶更傾向于感性使用，更具有個性化，用戶樂于體驗不同的產品，追求產品帶給用戶的感受，也會分享表達自身的感受和情感，尋求認可和共鳴;耐受性較低，隨時可能會流失;

B端用戶一般情況下默認是理性的，甚至是具有一定專業性的，比如某些財會人員，倉儲人員，銷售人員等，追求在功能完備的基礎上效率至上，高效準確的完成任務，工作過程中也會受到老板的關注和監督，因為工作關系到整個公司的運作。基于此B端的客戶往往行為更為理性，耐受性很強(更換B端產品對于客戶方的使用習慣、額外經濟成本也很大，這也是B端客戶粘度較高的原因);

5、產品結構和設計的差異

C端產品是為了解決用戶的某個核心需求而設計的，再加一些輔助的賬戶、登錄注冊等周邊功能，大多邏輯相對比較簡單，開發周期會相對較短;但產品設計上要關注人文和人性，迎合目標用戶的需求，需要明確感知用戶的需求，做好產品體驗，所以對于同理心，交互要求較高;具有較好創意的C端產品可能在問世后短時間內用戶獲得爆發性的增長;

B端產品在不同行業不同業務之間的處理差異很大，一般都會涉及多個組織部門之間的協作，要求分工明確，責任歸屬也要清晰，所以在產品設計上往往會設計組織架構，操作權限和數據權限，保障產品能夠表達出業務流程;在業務完備的基礎上，還能夠提高操作效率，降低操作成本和學習成本; 產品層級多、邏輯復雜，開發周期也較長，少則半年多則數年。B端產品一般逐步打開市場，不會有爆發性的增長;

6、關于產品決策的差異

C端產品的決策者一般很簡單，使用者本身，決策周期也很快，如一個C端的用戶可以很快決策出是否要在餓了嗎上點餐、是否要選擇用滴滴出行叫車、是否要在某個美妝社區里點擊鏈接買一只口紅等;

B端產品的決策者相對要復雜，往往不是某一個人，而是需要在應用中進行協作的一群人，如直接決定購買行為的關鍵人，話語權最高的老板或高管， 話語權一般，有較強的否決權的企業IT管理者; 還有話語權低，但集體行為會對決策有直接影響企業員工，這些員工可能還來自不同部門、有著不同職級，每個人的訴求都有差異。基于此產品體驗不好或功能無法覆蓋實際場景時，使用者集體的罷用對產品便是致命的打擊;

7、持續運營優化的策略

C端產品，因為面對大量用戶，不斷留存、活躍、轉化、傳播是終極目標，這就要求運營人員要持續關注相關數據，DAU,MAU，GMV等核心指標，分析數據找出差異原因，預測趨勢，并反饋到產品端不端的迭代優化，形成良好的市場推廣閉環;

B端產品，往往是由公司的“客戶成功團隊”或“售后部”持續跟進獨立用戶的使用過程及效果，并將問題反饋到產品端不斷進行功能性升級維護，B端產品是逐步打磨的過程，雖然解決的是問題共性，但不同客戶也會提現出差異，產品對應的業務場景也在持續變化中，所以不斷升級的終極目的是抽離共性、彌合差異，提高產品的適應度，超越競爭對手擴大市場份額。

二、B端產品做好宣導手冊

一份結構清晰，說明詳實的宣導手冊是必不可少的。B端產品以完成業務工作為主，角色權限多，往往流程又長又復雜，對應的功能操作流也會很長，對于一名新用戶（很有可能只是一個學歷認知都不高的打工人）來說，學習成本很高，一份好的宣導手冊可以給新用戶心理安慰，也能幫助企業降低了人員培訓成本。

宣導手冊要點：

線下培訓。在時間精力允許的情況下，產品經理應該親自給用戶做一次功能培訓，一方面可以近距離接觸實際用戶，另一方面可以在培訓的時候觀察用戶的反應，從他們的眼中判斷產品的價值。

PS：培訓前最好多了解用戶的作業場景，避免用戶覺得你不專業而質疑產品。

用云文檔。傳統我們都會以PPT、pdf文檔交付給客戶，可隨著用戶需求越來越多，產品迭代越來越頻繁，打包、發送文件就會很耗時間，因此，用云文檔來提供宣導手冊就方便許多。這里要注意的是，B端產品的功能手冊不能隨意放在外網，需做加密或權限處理，否則容易造成知識產權泄漏。

結構清晰。首先，通過角色權限限定用戶可以看到的功能范圍，避免用戶被與其無關的功能分散注意力；其次，每個功能模塊以單獨一部分進行功能說明；最后，為了避免太長的功能操作流讓用戶產生放棄心理，每個功能再分為第一步、第二步……

圖文并茂。一圖勝千文，但圖片也不要放太多，比如一個訂單有5個狀態，那么放5張圖就差不多了，沒必要多個字段少個字段也單獨貼圖，容易把用戶搞暈；

關鍵節點、最終操作成功的界面一定要讓用戶看得很清楚（我經常聽到用戶說的一句話就是“你看到那個界面就對了”）。

說明詳實。關鍵功能步驟要用線條、框框標出，并在邊上加以文字說明；文字盡量簡練，文字太多用戶看了就覺得很復雜。

三、B端產品需要搞好關系

和客戶搞好關系的道理大家都很明白，可關系是個虛的東西，一起吃肉喝酒并不能證明好的關系。大部分客戶、用戶都是只是因為“工作”才與我們產生交集，產品經理還是需要通過自身硬實力來與客戶群體搞好關系。

1、與客戶搞好關系

客戶代表的往往是公司的領導層，與他們搞好關系能使產品推廣順風順水。可如果自己級別不高，對方不怎么會關注到自己，怎么辦？解決辦法就是體現自己的專業性：產品能帶給對方企業的價值、對方要付出的代價、產品的細節等等，我們都了然于胸，能隨時告知對方想了解的信息，對方自然會被你刮目相看。

2、與用戶搞好關系

用戶代表的往往是公司的執行員工，與他們搞好關系能獲悉產品后續真實的改進方向。B端產品會收到很多定制化的需求，可很多定制化的需求其實是對方領導想要的，此時如果不聽一聽實際用戶的心聲，做出來的東西很可能會讓用戶很痛苦。

學會提問：

1、放低姿態

我們跟用戶打交道的時候，用戶往往會將我們當作一個專業人士，或是上級派下來的調研人員，這就會導致用戶只會說些“你想聽的話，或者是他認為上級想聽的話”。因此，在提問之前，我們要放低姿態，與對方拉近距離之后，再做提問；

2、發散性問題

多問沒有標準答案的5W1H問題，而不是判斷、選擇式的問題，比如：問“你覺得A功能帶給你哪些價值？”，而不是“你會不會用A功能？”；問“相比于隊伍的落后員工，你覺得他們和優秀員工的差距在哪里？”，而不是“你作為優秀員工，有哪些工作技巧？”。

3、放空心態

切忌不可帶著預期結果去溝通，這樣只會引導用戶給出你想要的答案。得到用戶真實心聲之后，可能結果并不是你所希望的那樣，這反而是好事——避免公司資源浪費，有利于及時調整方向。

四、B端產品的問題處理機制

B端產品運營的最終目的是不斷優化現有業務流程，從而為公司降本增效。因此，不論產品有沒有瑕疵，我們始終做迭代優化的路上，所以，一個標準的問題處理機制非常必要，它能為產品經理、運營人員、開發人員、終端用戶省去很多時間和精力。

問題處理機制應說明問題的處理步驟，規范處理過程中誰，在什么時間，干什么，完成的標準是怎樣。

舉個例子：

一款產品的用戶2000人（2個營業部，每個營業部1000人），運營2人（每個營業部1人），產品1人，測試1人，開發5人。

如果把相關人拉個群，一旦某次版本有問題，問題的處理狀況可能是：所有人都在反饋同一個問題，用戶消息太多將真正的問題描述淹沒，用戶反饋的并不是系統問題只是不會操作……更糟糕的是，其他沒反饋的用戶看到群里問題這么多，就會以為產品不行，從而對產品失去了信任。

通過一個好的問題處理機制，各方都會輕松很多。

1. step1：用戶發現問題，第一時間向營業部運營人員上報問題

2. step2：運營人員收到問題后，做初步判斷和問題除重，及時通知產品經理和開發團隊

3. step3：產品經理收到問題后，確認是需求問題還是系統bug，如是需求問題走需求版本流程，如是版本bug，評估bug影響范圍，并交給開發團隊處理

4. step4：開發人員收到問題后，對于影響范圍巨大的要在2小時內處理完畢；影響范圍較大的要在當天處理完畢；影響范圍較小的可以放在下個版本迭代中優化；

5. step5：問題修復后，測試需做回歸測試，并通知各方進行驗證

6. step6：用戶驗證通過后，開發人員關閉問題

五、B端產品的興奮型需求

當用戶已經使用你的產品，逐漸改變他們原來的工作方式時，可能會發現使用數據總是不溫不火，與預期有一些出入。

原因往往是多方面的：功能宣導還沒到位，用戶對產品價值還不認可；用戶對新產品的不熟悉、不信任；被領導強制要求使用，內心會有所抵觸；系統僅僅是將線下作業搬到線上，沒有對業務流程做很大的優化；員工更喜歡直觀的線下作業等等。

一個行之有效的辦法就是為用戶提供超出預期的興奮型需求。那么，該如何做出興奮型需求呢？

做好上文提到的搞好關系。了解用戶真實的聲音，看他們把時間都花在哪里了，工作哪一部分最讓他們痛苦。然后，我們再以產品的方式幫助他們解決，讓他們既賺錢又不那么累。

多去看看競品，以及多去玩一玩其他類型的產品。很多優秀的設計光靠自己腦子想是想不到的，我們需要通過他人作品獲得靈感，這樣在發現新需求的時候，我們能最快的想到設計方案。

比如：做業務系統時，設計數據產品的功能，用戶會很感激你幫他省下的手工統計報表的時間；考慮中后臺產品的用戶體驗，用戶會覺得這是最懂他的系統；

小步快跑。我們以為那個功能用戶會興奮，實際用戶內心毫無波瀾。所以，此類功能最好先用MVP做驗證，再通過大版本開發。

本文鏈接：http://www.sztqnet.com/article/1325.html