任何的推廣，小編都覺得需要把服務放在第一位，ToB 的推廣也是如此，那麼該怎麼做好 ToB 的服務管理呢？下面就來跟大家聊聊看。
ToB 早已不是一個新課題，幾乎每個行業都在使用產品捆綁。可對於企業市場而言，比起產品捆綁式的宣傳和推銷，給客户全方位浸入式的服務體驗，牢牢抓住客户的心，不給競爭對手任何挖牆腳的機會，在銷售漏斗之餘創造更多的價值，或許更為重要。
自入職騰訊以來我一直從事於 2B 業務的工作，明顯感覺到一種轉變：從一開始我們講產品功能設計、用户體驗、資料 WooCommerce 運營到現今成立 SPDM(服務與交付經理) 團隊，研討微軟銷售管理流程，挖掘客户商機，協調客户、團隊內部、競爭對手、合作伙伴的利益鏈條，並針對商務落地過程進行控制——譬如：招投標、客户業務、財務、法務、 IT 流程、簽單的控制。
那麼，在數字化時代，2B 產品成功的秘訣是什麼?
幾乎每個行業都在使用產品捆綁，可通常它並不是具體戰略和意向戰略的一部分。
回答這個問題之前，我們先來回顧一個現象。
在 19 世紀，統計學家恩斯特·恩格爾提出恩格爾定律：當人們很窮時，會將其大部分收入分配給生活必需品 (食物、住房等); 當收入增長後，人們會在食物的消費上投入更多，但並不會將增長的所有收入都用來消費食物，因為這種需求到一定程度會達到飽和。因此，隨著收入的增長，擁有更多收入的人們傾向於將更多的錢用於購買服務，可用於購買物品的錢會減少。
當然，新興服務業增長的背後驅動力除了人們的收入改變之外，社會和人口的變革，還有企業中日益增長的專業化和技術進步。
那什麼是服務呢?
《服務管理整合的視角》一書中，Paul Gemmel 和 Bart Van Looy 將服務定義為：所有那些無形的並通過顧客和服務提供者之間的互動來實現的經濟活動。
同樣的，對於 2B 產品而言，站在該產品服務的目標羣體視角上，放眼望去，他們也同樣經歷著社會的變革，感受著電子資訊化和數字轉型的催化。比起產品捆綁式的宣傳和推銷，給客户全方位浸入式的服務體驗，牢牢抓住客户的心，不給競爭對手任何挖牆腳的機會，在銷售漏斗之外創造更多的價值，或許會更為重要。
本文基於該命題，結合微軟的優秀服務管理諮詢和華為的服務體系，並通過在騰訊內私有化產品的實際服務交付過程中，給出一些感悟和分享。
一、 TO B 服務體系框架
前文提到，在 TO B 市場上，不僅要客户導向，更是需要一套全方位的服務管理。一套優秀的服務體系遠超出效率本身的範疇，而是決定客户專案成敗的關鍵因素。而服務需要業務的滋養，才能變得更為茁壯。
通過初期的服務體系建設，投入到客户專案中進行驗證和實踐，再由客户專案驅動，去對服務體系進行更新和迭代。
下圖是 to B 產品的銷售管理流程，從售前服務到售中交付，再到售後服務階段。不難看出，縱使客户千人千面，但我們可以通過搭建一套通用的服務框架體系去管理和跟進客户專案。
每個客户專案均可以在上述的流程中找到對應的位置。
此時，該客户我們需要投入什麼資源，我們期盼客户有什麼產出呢? 哪怕是 to B 產品，我們也希望明確投入產出比。
下圖是我根據此前負責的企業微信的實際現狀與展望擬定的服務管理體系框架。
不妨回想下，在早期往往一個新專案的開展除了資料可以被重複使用之外，服務卻不能被重複使用。
可其實服務的重用比資料重用能帶來更多好處，資料是原始的生產資料，服務則包含邏輯，是工廠的加工車間。如果加工過程也一樣可以複製，將帶來生產效率的大幅度提升。
而服務管理體系正是充當了本軟件的加工車間的角色。所有服務體系散佈在銷售管理流程中的方方面面，為了協助客户專案在銷售管理和專案交付過程中的執行，我們通過標準的服務體系和知識管理體系為客户專案添磚加瓦，確保客户專案可以流水線、共享式地運作，無需耗費重複的勞動力。
下面我想重點根據客户在售前支援和售中交付階段對應的服務體系一一做下解讀。
二、售前服務
1. 確認商機
發現機會，挖掘潛在支持者：
這個階段最難也最容易被人忽視，因此你可能會看到一種現象，商務牽線客户過來後，大力吹捧客户的影響力、本產品與客户需求的完美契合度，然後就開始索取資源。
注意! 此時一旦你掉以輕心，抱著 “無所謂的反正也就個把時間的功夫我直接搞定就好” 的態度，迎接你的將是無止境的索取和投入。這僅是一個客户，倘若是十個，一百個，上千個客户呢!
從迎接第一個客户開始，就要做好服務於成百上千個客户的準備。最大的浪費不是重複建設，而是不斷地重複建設。
客户初次登場，對商機的把握程度，決定了後續團隊的資源投入。商務牽線客户過來後，如何判斷該客户是我們的目標客户，並找出潛在的專案機會及可能的支持者?
從客户的痛與癢入手：客户的痛點是什麼? 是否存在強迫機會? 當前客户內部使用在使用同型別的軟件? 有什麼不足與優點? 客户對該軟件的態度如何?
探索客户的購買設想：客户考察的其他競品有? 當年是否有預算? 採購方式確定了麼? 如果是公開招標，預計招投標時間?
獲得客户進一步的溝通意願：該專案由客户的哪個部門負責? 客户內部的決策鏈是? 每次溝通的內容是否逐步深入?
確定並推動專案機會：
明確該客户是我們的目標客户——這是我們單方面的考察。而客户也同樣在考察著我們，他在諸多廠商中選型，或許搖擺不定，或許已有所傾向。我們需要明確得到客户決策層的支援。在得到一個明確的態度之後，開始明確售前團隊。
考察客户決策層的態度：你是否完全瞭解客户內部的關係? 客户決策人的職務? 他的關注點是? 對我方產品的態度?
明確本公司內的資源投入：商務支援、售前支援、技術支援都確定下來了嗎? 每種售前角色的任務分工是什麼?
明確公司外的資源投入：是否要引入合作伙伴? 若是，則合作伙伴的權責利各是什麼? 與我司的合作模式是什麼?
2. 方案交流& 確認
此前我主要負責私有部署化產品在對外專案交付中的工作，在此以省部級政府客户為例。
常態化、多層次、立體化的政務服務體系正在逐步形成，政府治理模式正從單向管理向雙向互動轉變，從單純的政府監管邁向社會協同治理，推動政務服務向基層延伸,“縱向到底、橫向到邊、覆蓋全省 (國)” 的政務服務體系不斷完善提升。
那麼，政企機構的領導層在關心什麼?
全國的數字化轉型如火如荼，他們有政績壓力，想打造創新標杆，百忙之中抽空去聽的不是你對產品的推銷，而是結合他自身的業務需求去形成的整套解決方案。
通常情況下，方案交流階段在整個銷售管理漏斗裏佔據較大的比例。這個環節決定了客户對你提供的產品服務的青睞程度是否夠持久，夠穩定。總體來説，提案製作與客户宣導的過程中佈滿血與淚，你進我退，你退我攻，充分發揮工農紅軍在土地革命時期的游擊戰爭指導原則就對了。
考慮到政企內部的人員分佈，一般來説我們會從客户內部的三個層級去考慮方案的設計：
方案評估與完善:
考察各方人士對方案的態度：客户決策層對方案的建議? 內部領導對方案的態度? 執行團隊對方案的態度?
客户評估方案：方案的評估結果? 客户的需求與方案的匹配程度? 客户決策人對方案是否認同?
明確客户的採購意願:
客户決策層的採購意願：客户決策人對我們是否支援? 客户在我司和競爭對手的投入精力比，客户的傾向?
招標引導：協調客户內部關係，獲得客户認同的控標點，防備競爭對手，控制合作伙伴的預期。
3. 專案驗證& 成交
在提交滿足客户需求並高於客户期望的解決方案，同時也獲得了客户非正式的認可之後，利益鏈的協調仍在繼續。
客户試用本軟件:
通常來説，尤其針對政企客户而言，除了解決方案之外，還需要進行概念驗證。注意! 這個節點是資源投入較為密集的關卡，需要我們嚴格控制客户預期，避免給團隊造坑。
POC 部署前的調研：客户的 POC 部署目的? 計劃試用時長? 期望驗證的功能範圍?POC 部署後的下一步計劃?
POC 部署：是否明確部署方案和支援方案? 客户決策人對方案是否認可?POC 部署是否標準化，是否可交由合作伙伴實施?
商務投標與合同簽署：
不知不覺已進入售前階段的最後一環，此時稍有不慎就會給後續的專案交付工作埋下天坑。一方面，客户關係需要商務持續維護; 另一方面，對於標書制定與合同管理也同樣需要做好萬全準備。
在擬定合同前，請先明確專案經理，再請專案經理捫心自問：
範圍：專案目標是什麼? 專案的邊界是什麼? 專案的每一部分都有哪些工作? 你瞭解客户的業務需求嗎? 針對客户需求你有對應的方案嗎?
時間：專案實施團隊有哪些成員組成? 完成這個專案要多長時間? 專案的分工如何? 團隊如何跟蹤實際程序? 誰有權批准進度的變更?
成本：完成這個專案需要花費多少成本? 這個專案預算是多少? 如何跟蹤控制成本? 誰能授權改變預算?
每個專案都會在不同程度上收到範圍、時間和成本的約束，這些限制條件在專案管理中通常被成為三項約束。如果等專案正式開始實施的時候才開始考慮這些因素就晚了，在合同簽署前，就應該給出一個大體的專案計劃書作為合同附件，與客户對齊要求，作為後續專案交付的原始根據。
三、售中交付
合同簽署完畢，正式進入售中交付階段。此時專案計劃書作為專案交付的戰略地圖，它指導並管理專案執行，確保專案的交付成果滿足預先定義好的質量度量標準。
1. 專案計劃
前文提到，專案管理中的三項約束需要在合同擬定前大致確定下來。
那麼，如何避免在達到範圍、時間和成本目標的同時卻忽視了質量或客户滿意度而產生的問題呢?
因此，基於合同裏的粗粒度專案計劃書，專案經理需要再進行細化。
基於上述的專案管理框架，專案經理不僅要實現三項約束，還必須協調整個專案過程，以滿足專案參與者、客户的需求和預期。
一般來説，一份完整詳細的專案計劃書包含如下內容：
專案概述
專案範圍
實施服務範圍
專案計劃和交付項
專案資源規劃
專案組織和條款
專案變更控制流程
專案驗收
服務水平
責任與義務
違約責任
保密協議
附件：本軟件產品和服務目錄列表
2. 專案交付
若本專案引入了服務合作伙伴，則專案交付環節需嚴格按照我司與合作伙伴之間的分工邊界來運作，避免造成後續資源報價、費用結算的問題。
注意，每個專案參與的角色是固定的，但分配到該角色的人員是流動的。因此，根據角色去定義服務內容項會更為可靠。
基於這個流程，我們將專案實施團隊 (含騰訊& 合作伙伴) 裏的每種角色的職責分工通過 wbs 定義清楚，每項任務分別配備對應的資料庫 (表單、標準配套文件等)，便於每種角色除了明白自己要做什麼，還懂得如何做。
3. 專案結案
每個專案都可以劃分為多個專案階段，每個階段的投入可以通過定性或定量的方式來衡量，而每個階段的產出均可視為一個里程碑事件，需要專案經理定期輸出專案里程碑總結。
同時，在最終客户正式驗收後，不僅可以對專案成員 (含合作伙伴) 進行考核評估，還可以向客户進行滿意度調查，以此推進服務的持續改善。
四、總結
做 to B 產品，商業解決方案往往比產品本身有著更長的生命週期。不僅臉要貼著客户，服務也要照顧到方方面面，才能避免解決方案遲遲無法落地和交付。
回顧上述內容，對服務提供者而言，從售前、售中到售後階段，每個環節都需要標準化的流程佈局，並配備相應的資料參考，確保有序並高效地服務於客户; 對被服務者而言，與服務者的每一次接觸點都影響著他們的採購意願和價值傳播。
在此以 “滿意鏡” 的形式説明客户與服務提供者的關係。
我也承認這套服務體系肯定會存在不足之處，但通過在實際業務中的持續滾動和改善，定能真正輔助客户專案的流暢執行。
一套好的服務管理體系並不依賴於產品本身，它具有強大的重用性。我在騰訊內負責過多款軟件的服務管理與交付支援工作，在實際的客户專案中幾乎都驗證了這一點。如果以後能拍著胸脯説，這套服務管理體系適用於所有的 TO B 產品就好了。
畢竟，未來的前景不是由購買產品的消費者決定的，關鍵在於使用服務的客户。