B端產品成功的關鍵——運營推廣

B端產品的冷啟動需要依靠大客戶，並不斷優化系統，擴大客戶範圍。那麽，該如何高效處理用戶訴求與問題，並使用合理的運營推廣策略。本文總結了幾點用戶運營策略，希望對妳有所幫助。B端產品的冷啟動多是依靠個別大客戶，在為大客戶做好基本功能之後，隨之而來的挑戰是不斷優化系統，擴大用戶範圍。這個過程中，如何讓用戶快速知道產品的功能？如何獲取用戶最真實的訴求？如何高效處理用戶問題？如何提高用戶的使用率？如果讀者還沒有很好的答案，本文可以為妳提供壹些非常實用的幹貨。壹、宣導手冊壹份結構清晰，說明詳實的宣導手冊是必不可少的。B端產品以完成業務工作為主，角色權限多，往往流程又長又復雜，對應的功能操作流也會很長，對於壹名新用戶（很有可能只是壹個學歷認知都不高的打工人）來說，學習成本很高，壹份好的宣導手冊可以給新用戶心理安慰，也能幫助企業降低了人員培訓成本。宣導手冊要點：線下培訓。在時間精力允許的情況下，產品經理應該親自給用戶做壹次功能培訓，壹方面可以近距離接觸實際用戶，另壹方面可以在培訓的時候觀察用戶的反應，從他們的眼中判斷產品的價值。PS：培訓前最好多了解用戶的作業場景，避免用戶覺得妳不專業而質疑產品。用雲文檔。傳統我們都會以PPT、pdf文檔交付給客戶，可隨著用戶需求越來越多，產品叠代越來越頻繁，打包、發送文件就會很耗時間，因此，用雲文檔來提供宣導手冊就方便許多。這裏要註意的是，B端產品的功能手冊不能隨意放在外網，需做加密或權限處理，否則容易造成知識產權泄漏。結構清晰。首先，通過角色權限限定用戶可以看到的功能範圍，避免用戶被與其無關的功能分散註意力；其次，每個功能模塊以單獨壹部分進行功能說明；最後，為了避免太長的功能操作流讓用戶產生放棄心理，每個功能再分為第壹步、第二步圖文並茂。壹圖勝千文，但圖片也不要放太多，比如壹個訂單有5個狀態，那麽放5張圖就差不多了，沒必要多個字段少個字段也單獨貼圖，容易把用戶搞暈；關鍵節點、最終操作成功的界面壹定要讓用戶看得很清楚（我經常聽到用戶說的壹句話就是“妳看到那個界面就對了”）。說明詳實。關鍵功能步驟要用線條、框框標出，並在邊上加以文字說明；文字盡量簡練，文字太多用戶看了就覺得很復雜。二、搞好關系和客戶搞好關系的道理大家都很明白，可關系是個虛的東西，壹起吃肉喝酒並不能證明好的關系。大部分客戶、用戶都是只是因為“工作”才與我們產生交集，產品經理還是需要通過自身硬實力來與客戶群體搞好關系。與客戶搞好關系。客戶代表的往往是公司的領導層，與他們搞好關系能使產品推廣順風順水。可如果自己級別不高，對方不怎麽會關註到自己，怎麽辦？解決辦法就是體現自己的專業性：產品能帶給對方企業的價值、對方要付出的代價、產品的細節等等，我們都了然於胸，能隨時告知對方想了解的信息，對方自然會被妳刮目相看。與用戶搞好關系。用戶代表的往往是公司的執行員工，與他們搞好關系能獲悉產品後續真實的改進方向。B端產品會收到很多定制化的需求，可很多定制化的需求其實是對方領導想要的，此時如果不聽壹聽實際用戶的心聲，做出來的東西很可能會讓用戶很痛苦。學會提問：放低姿態。我們跟用戶打交道的時候，用戶往往會將我們當作壹個專業人士，或是上級派下來的調研人員，這就會導致用戶只會說些“妳想聽的話，或者是他認為上級想聽的話”。因此，在提問之前，我們要放低姿態，與對方拉近距離之後，再做提問；發散性問題。多問沒有標準答案的5W1H問題，而不是判斷、選擇式的問題，比如：問“妳覺得A功能帶給妳哪些價值？”，而不是“妳會不會用A功能？”；問“相比於隊伍的落後員工，妳覺得他們和優秀員工的差距在哪裏？”，而不是“妳作為優秀員工，有哪些工作技巧？”。放空心態。切忌不可帶著預期結果去溝通，這樣只會引導用戶給出妳想要的答案。得到用戶真實心聲之後，可能結果並不是妳所希望的那樣，這反而是好事——避免公司資源浪費，有利於及時調整方向。三、問題處理機制B端產品運營的最終目的是不斷優化現有業務流程，從而為公司降本增效。因此，不論產品有沒有瑕疵，我們始終做叠代優化的路上，所以，壹個標準的問題處理機制非常必要，它能為產品經理、運營人員、開發人員、終端用戶省去很多時間和精力。問題處理機制應說明問題的處理步驟，規範處理過程中誰，在什麽時間，幹什麽，完成的標準是怎樣。舉個例子：壹款產品的用戶2000人（2個營業部，每個營業部1000人），運營2人（每個營業部1人），產品1人，測試1人，開發5人。如果把相關人拉個群，壹旦某次版本有問題，問題的處理狀況可能是：所有人都在反饋同壹個問題，用戶消息太多將真正的問題描述淹沒，用戶反饋的並不是系統問題只是不會操作更糟糕的是，其他沒反饋的用戶看到群裏問題這麽多，就會以為產品不行，從而對產品失去了信任。通過壹個好的問題處理機制，各方都會輕松很多。step1：用戶發現問題，第壹時間向營業部運營人員上報問題step2：運營人員收到問題後，做初步判斷和問題除重，及時通知產品經理和開發團隊step3：產品經理收到問題後，確認是需求問題還是系統bug，如是需求問題走需求版本流程，如是版本bug，評估bug影響範圍，並交給開發團隊處理step4：開發人員收到問題後，對於影響範圍巨大的要在2小時內處理完畢；影響範圍較大的要在當天處理完畢；影響範圍較小的可以放在下個版本叠代中優化；step5：問題修復後，測試需做回歸測試，並通知各方進行驗證step6：用戶驗證通過後，開發人員關閉問題四、興奮型需求當用戶已經使用妳的產品，逐漸改變他們原來的工作方式時，可能會發現使用數據總是不溫不火，與預期有壹些出入。原因往往是多方面的：功能宣導還沒到位，用戶對產品價值還不認可；用戶對新產品的不熟悉、不信任；被領導強制要求使用，內心會有所抵觸；系統僅僅是將線下作業搬到線上，沒有對業務流程做很大的優化；員工更喜歡直觀的線下作業等等。壹個行之有效的辦法就是為用戶提供超出預期的興奮型需求。那麽，該如何做出興奮型需求呢？做好上文提到的搞好關系。了解用戶真實的聲音，看他們把時間都花在哪裏了，工作哪壹部分最讓他們痛苦。然後，我們再以產品的方式幫助他們解決，讓他們既賺錢又不那麽累。多去看看競品，以及多去玩壹玩其他類型的產品。很多優秀的設計光靠自己腦子想是想不到的，我們需要通過他人作品獲得靈感，這樣在發現新需求的時候，我們能最快的想到設計方案。比如：做業務系統時，設計數據產品的功能，用戶會很感激妳幫他省下的手工統計報表的時間；考慮中後臺產品的用戶體驗，用戶會覺得這是最懂他的系統；小步快跑。我們以為那個功能用戶會興奮，實際用戶內心毫無波瀾。所以，此類功能最好先用MVP做驗證，再通過大版本開發。願讀到篇尾的妳，成為引領業務的B端產品經理。