我們常談到的互聯網運營，多數是針對C端的，B端由于其特殊性很少被人提及。
很偶然的機會，我有幸經歷了一個互聯網支付項目從0到1的過程，今天跟大家分享的用戶運營（鑒于To B產品的用戶群體大部分是企業，用戶運營在本文中更多的是指商戶運營，但兩者也有共通之處）經驗和心得，也都是泥沼中摸爬滾打總結的。
用戶溝通，讓他們感受到尊重和爽
B端用戶偏理性的屬性，在產品推廣前期，讓獲客比想象中的難。獲客之后，我們需要跟用戶進行大量的溝通工作，且不同階段溝通的要點也不一樣的，比如：
前期：這個時候的用戶通過網站了解到我們的產品，表示出了興趣，并進行注冊。但因為信息不對稱的存在，用戶依然會表現出疑慮和不穩定性，所以該階段的溝通側重挖掘用戶真實的訴求，突出自身產品的差異性和優勢，抓住用戶的心。
中期：用戶已經認可我們的產品，就要安排雙方進行技術上的調試。所以該階段如何協調技術資源，如何快速響應技術問題，如何抹平用戶對產品功能不完善的情緒就很重要了。
后期：用戶產品上線后，存在的各類交易問題、系統問題、功能缺陷問題，也需要我們耗時耗力的溝通解決。
所有的溝通，我們都是通過QQ、微信或電話進行的。溝通中很多技巧都是建立在雙方平等，尤其是對用戶的尊敬上，比如口氣平和，多用敬語（您、很抱歉……）。通過創造輕松愉悅的交流氣氛，能夠讓用戶得到認可和獲得歸屬感，我們產品的價值才得以實現。
用專業的知識，說服用戶
B端產品有一個很大的特點就是其專業性和復雜度較高，一般人都不太熟悉甚至完全沒有概念。用戶在使用我們產品的時候，我們更多的是扮演專（磚）家的角色。
因為面向企業用戶，所以有兩類人需要從我們這里獲得專業的信息：一類企業決策者（老板或則管理者），負責拍腦袋；一類技術人員，負責實現產品技術對接。
我們做的支付SDK產品，在面對這兩類人的時候也需要表現出不同的專業性。
對于決策者而言，他們關心的是：你們的費率為什么這樣定價、如何進行資金清結算、每種支付產品有什么區別、業務的支付場景是否合規等業務層面問題。這需要運營通過不斷的專業學習，形成支付行業的知識積累。
對于技術人員而言，他們關心的是：數據傳輸的安全性是怎么保障的，簽名方式是怎么實現的，前端和后端如何實現接入等技術細節問題。這個有專門技術團隊解答，運營也需要簡單的了解自家產品的內部技術實現方式。
所以，一旦用戶有問題，千萬不要急著回答，想清楚這個問題到底是誰提的，問的是什么，疑惑在哪里，他需要怎樣的回答來說服自己相信這就是自己要的那款產品。
答案和解決方案一定要正確要專業，這也是突出公司和產品形象的機會。
如果不小心給錯解決方案，也不需要太焦慮，謙虛地承認了錯誤并重新提供更加專業的方案，也會贏得用戶的認可。
通過學習專業知識，來輔助運營工作的開展
時響應和反饋
諾曼在《未來產品的設計》里面講到：
賓館因為環境嘈雜且坐電梯的人較多，自己即聽不見電梯門開關的聲音，也看不到指示燈，導致坐錯了好幾次樓層。
這正是反饋機制不完善，帶來的后果。反饋告訴我們現在處于什么狀態，應該怎么做，沒有反饋會讓人感覺到焦慮和失去把控。
企業用戶一方面是理性的，他有耐心等待一個解決問題的答復；另一方面等待是需要時間成本的，用戶也希望有一個時間期限。
不要一味地說，等一下，我們在處理這類模糊沒有意義的話，除非你可以在短時間內給出答復，否則用戶漫長的等待得不到真實的解決，就會變的焦慮和失控。
正確的回答應該是：運營根據實際情況，評估出處理問題的時限。比如：告訴用戶我們已經在處理，預計10分鐘后可以正常使用／問題會在12點前會等到解決……這樣的好處就是用戶有一個預期，他能夠感覺事情處于自己的控制下，在情感上感到放松。
如果臨近或超過時限沒有給商戶反饋怎么辦？那就態度謙虛的道個歉，提前或及時(在商戶反問我們之前)的通知到用戶變化（原因），然后告知后面的方案。
這里的原則就是，我們應該主動去反饋，而不是讓用戶苦苦等待和煩惱。
用戶要求的不一定要做
傾聽用戶訴求，進行需求分析，這活一般都是產品經理干的，但事實上與用戶接觸最多的還是運營，他們才能獲取一手的信息。
從某種層面來看，運營完全可以充當用戶需求分析的角色，就看運營人有沒有這樣的自我定位。
我們自己的產品在很多時候，都會碰到商戶提出的各種要求。比如：收銀臺頁面要定制化，logo能不能修改，數據傳輸要更多的加密方式，請求和響應參數需要自定義，需要各種語言的demo……
用戶的要求不等于真實的需求，就像在諾基亞時代，用戶說我們要打字更快的鍵盤，結果鍵盤倒是設計成符合人體工學的了，可還是被iPhone打敗了。
運營怎么平衡產品和商戶之間的需求，就是一門很重要的藝術了。平衡的前提，就是一定要了解我們產品目前在公司的戰略地位，高層重視程度，資源投入的比重，以及目前產品適用的人群占比。
如果產品本身戰略地位低，意味著資源少，那么商戶的需求就要考慮到重點。如果目前產品已經滿足80%的商戶需求，那么其他合理的需求就應該納入到后期的產品規劃中去，不合理的自然剔除掉。
但有時候迫于某些所謂的內部大客戶，我們會優先去滿足他們的要求，這樣就會無形中占用過多的資源，打亂產品開發的陣腳。
比如：
我們之前的SDK考慮到90%以上的用戶需要接入難度低，技術硬件要求低的需求，故只支持APP內簽名，缺點就是安全級別比較低。
這時候有內部技術實力較強的大客戶，提出了異議，需要加強簽名安全，我們便立馬進行產品修改，最后客戶還是橫挑鼻子豎挑眼，放棄使用我們的產品。
雖然說此類需求是符合我們未來產品的趨勢，但前期因為一個客戶的要求而消耗的成本也不小。當然這是老板拍的決定，大家只能硬著頭皮上。
針對不同的目標用戶，如果產品本身確實存在不完善的功能，也要及時反饋給產品，并告訴用戶等待我們的新功能。學會適當的畫餅，要讓用戶看到希望和預期，但也要考慮到用戶的承受期限。
關注20%的核心價值用戶
長尾理論，說需求曲線的狹長尾部分布著大量的產品和用戶，這里是一座機會的寶庫。中國第三方支付發展也確實符合這種理論，銀行不愿意涉及的小企業給了第三方支付公司發展的空間。
但我們不要忽略了：哪怕是長尾，也逃不開二八定律。就像現在的支付寶和財付通就已經占據了市場70-80%的份額，獲取了絕大部分的利潤。
運營的工作非常雜亂，而且時間有限，要實現高ROI，就要服務好20%的核心價值用戶。我們產品剛推廣初期，用戶量少，故把每一個用戶都當成小心肝一樣呵護。
尤其是商務或內部同事隨手扔一個大客戶過來，我們也得接過來好好伺候著。大部分的結果是，好不容易把產品接入了，卻一點交易量都沒有。
隨著業務量的增長，就需要建立用戶篩選和分級策略。運營應該快速的判斷這個用戶：
是不是我的目標用戶。
是否認可我們的產品和服務。
對價格是否敏感。
是否容易抱怨。
預期會帶來多大的回報。
合作過程是否順利。
同時根據一些簡單具體的規則，比如企業注冊資本、背景實力、盈利模式、交易規模、用戶數等，來識別核心用戶，把更多的資源傾斜在他們身上。
要警惕非核心用戶，尤其是一些干擾用戶，他們可能有無窮的要求和刁難，會不斷消耗公司的資源，這類用戶必要時要敢于放棄。
當然，產品的每個階段，對于用戶的分類標準都是不一樣的，重要的是在實踐中不斷的迭代和優化。
數據驅動運營
在越來越重視數據的互聯網時代，數據化運營的工作越早開展越好，但不同階段側重點會不一樣：
初期，支付產品沒有用戶或用戶極少的時候，我們更多的是關注品牌傳播、網站流量、拉新數據等。
等到用戶量級上去以后，我們開始重視用戶業務層面數據，比如交易數據、交易成功率、失敗率、渠道分布等。
再過一個量級，用戶的活躍度、沉默流失數據也開始關注。
我們最早的數據也就是以日報的形式發出，有系統發的簡報，數據組的報告，但他們的數據更偏向說明數據本身，業務方面的分析太少。
這個時候運營就需要在已有數據報告的基礎上進行優化，加入更多的業務分析，比如網站流量下滑是推廣的力度減少，還是品牌傳播的疲軟，還是競爭對手的崛起，商戶交易的減少是流失還是沉默，是業務出了問題還是項目問題等。
其中的一個交易數據模版，學會版本管理
這里需要說明一點，做運營的一定要掌握很強的數據分析工具嗎？我的理解是，在公司有專門的數據組存在時，運營只需要具備數據敏感性和思維即可，讓更加專業的數據組處理海量的數據。
專業的人做專業的事，他們可以在幾分鐘內處理完你可能需要幾個小時處理的數據。
有了數據和分析，我們就要呈現給相關團隊看，可以用Excel表格，Word或PPT展現，工具不重要，重要的是展現的內容要有價值。
有價值可以參考：領導和同事時間都很寶貴，報告要簡潔突出重點，告訴他們我們做了什么，有什么成就，有什么問題，我們未來的方向。
