B端產品的冷啟動需要依靠大客戶，并不斷優化系統，擴大客戶范圍。那么 ，該如何高效處理用戶訴求與問題，并使用合理的運營推廣策略。本文總結了幾點用戶運營策略，希望對你有所幫助。

B端產品的冷啟動多是依靠個別大客戶，在為大客戶做好基本功能之后，隨之而來的挑戰是不斷優化系統，擴大用戶范圍。

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

一、宣導手冊

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

宣導手冊要點：

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

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

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

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

圖文并茂。一圖勝千文，但圖片也不要放太多，比如一個訂單有5個狀態，那么放5張圖就差不多了，沒必要多個字段少個字段也單獨貼圖，容易把用戶搞暈；關鍵節點、最終操作成功的界面一定要讓用戶看得很清楚（我經常聽到用戶說的一句話就是“你看到那個界面就對了”）。

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

二、搞好關系

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

• 與客戶搞好關系。客戶代表的往往是公司的領導層，與他們搞好關系能使產品推廣順風順水?？扇绻约杭墑e不高，對方不怎么會關注到自己，怎么辦？解決辦法就是體現自己的專業性：產品能帶給對方企業的價值、對方要付出的代價、產品的細節等等，我們都了然于胸，能隨時告知對方想了解的信息，對方自然會被你刮目相看。
• 與用戶搞好關系。用戶代表的往往是公司的執行員工，與他們搞好關系能獲悉產品后續真實的改進方向。B端產品會收到很多定制化的需求，可很多定制化的需求其實是對方領導想要的，此時如果不聽一聽實際用戶的心聲，做出來的東西很可能會讓用戶很痛苦。

學會提問：

• 放低姿態。我們跟用戶打交道的時候，用戶往往會將我們當作一個專業人士，或是上級派下來的調研人員，這就會導致用戶只會說些“你想聽的話，或者是他認為上級想聽的話”。因此，在提問之前，我們要放低姿態，與對方拉近距離之后，再做提問；
• 發散性問題。多問沒有標準答案的5W1H問題，而不是判斷、選擇式的問題，比如：問“你覺得A功能帶給你哪些價值？”，而不是“你會不會用A功能？”；問“相比于隊伍的落后員工，你覺得他們和優秀員工的差距在哪里？”，而不是“你作為優秀員工，有哪些工作技巧？”。
• 放空心態。切忌不可帶著預期結果去溝通，這樣只會引導用戶給出你想要的答案。得到用戶真實心聲之后，可能結果并不是你所希望的那樣，這反而是好事——避免公司資源浪費，有利于及時調整方向。

三、問題處理機制

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：用戶驗證通過后，開發人員關閉問題

四、興奮型需求

當用戶已經使用你的產品，逐漸改變他們原來的工作方式時，可能會發現使用數據總是不溫不火，與預期有一些出入。原因往往是多方面的：功能宣導還沒到位，用戶對產品價值還不認可；用戶對新產品的不熟悉、不信任；被領導強制要求使用，內心會有所抵觸；系統僅僅是將線下作業搬到線上，沒有對業務流程做很大的優化；員工更喜歡直觀的線下作業等等。

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

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

多去看看競品，以及多去玩一玩其他類型的產品。很多優秀的設計光靠自己腦子想是想不到的，我們需要通過他人作品獲得靈感，這樣在發現新需求的時候，我們能最快的想到設計方案。比如：做業務系統時，設計數據產品的功能，用戶會很感激你幫他省下的手工統計報表的時間；考慮中后臺產品的用戶體驗，用戶會覺得這是最懂他的系統；

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

愿讀到篇尾的你，成為引領業務的B端產品經理。