導讀 To B行業無法迴避的客戶定製化需求是否有更好的滿足方式？本文將分享關於資料平臺 SaaS 化和開放能力建設的一些思考和實踐。
主要包括三大部分內容：
1. 資料平臺 SaaS 化建設的機遇與挑戰
2. 更好地滿足定製化需求
3. 資料產品工作思考
分享嘉賓｜李子坤 騰訊 產品經理
編輯整理｜李健娜 百度
出品社群｜DataFun
最近在 SaaS 領域比較火熱的一個名詞是 PLG（Product-Led Growth），即產品驅動的增長。這和 2010 年之前的銷售驅動模式的差別還是比較大的。
第一個特徵是主要面向大客戶、做的是大專案，一個專案的成交金額可能會到千萬級別，甚至有些非常大的集團公司能達上億。第二個特徵是這樣的專案客戶來購買服務時的要求是不一樣的，為他們提供 SaaS 服務的供應商通常會派出專門的售前、售後的銷售團隊來貼身服務。
最後一個特徵是站在使用者視角或者說站在產品經理視角，產品真正的使用者和真正決定購買這個產品的決策者之間是分離的。我們來看一個具體例子，左圖為 Garter 總結的以 B2B 銷售為主體的銷售模式的路徑圖，從準備立項到招投標，接標後開始分析甲方客戶的需求清單以及業務問題，再到專案交付驗收，整個過程非常複雜。其中涉及到的甲方使用者也是來回轉換的，首先是採購部門發起採購流程，在中途會引入一些業務專家或是真正的使用部門來評估和羅列需求清單，最後會由管理層來進行排版。在這個過程當中，需求轉了兩三道，在決策時考慮的因素就會融合很多其他的和最終使用者不太相關的因素。這是由行業特徵所決定的，銷售團隊需要針對一個客戶投入大量的資源和精力。
再看產品驅動的模式，這是外國的一個投資公司總結的 SaaS 化的市值規模（右圖所示）。在 2020 年之後，SaaS 企業的市值和規模是突飛猛進的，其主要特徵是：基於公有云服務於中小型公司成為了可能，在中小型公司大量興起之後，需求也越來越多，意味著 SaaS 化的服務模式以及服務需求場景也越來越多。在規模變大之後，一個企業或者說一個獨立的開發者就可以針對單點問題來提供 SaaS 服務，所以整個的需求量級以及捲入的開發資源甚至共建者都會越來越多。
第二點是，中小企業成為了需求的主力，基於成本的考慮，原來的銷售模式肯定無法提供貼身的服務。
第三點是，在做產品設計和打磨的時候，就真正的需要解決一個特定的場景問題並把它打磨透。當產品開始真正地解決使用者問題了，使用者就會主動地體驗選擇或者進行口碑傳播。產品使用者這時候已經可以反向影響企業的訂購決策流程了，比如說某一個專業崗位設計師，可能自己會嘗試使用 Figma，然後反向督促企業的採購部門來採購 Figma（企業版）。這樣的服務模式對於產品的要求更高，但是可能會壓縮銷售成本，讓我們更集中精力打磨我們的產品，這也是行業發展的趨勢。
我們來看一下中外行業的發展差距。18 年之前 ToC 領域是非常火熱的，像美國的 Amazon、Google 和 Facebook，中國與之對標的阿里巴巴、百度和騰訊，至少量級上來說是旗鼓相當的。但是 ToB 領域，美國微軟比較老牌，其他的新生力量像 salesforce 和 shopify 這種實質規模可達千億級或百億級，它們都是在美國已經站住腳的頭部 SaaS 供應商。目前在中國這一部分還稍顯空白，阿里雲、騰訊或者位元組也在開始搞這種平臺化的雲服務，但並不是非常純粹的 SaaS 服務，可能是打包售賣雲上的基礎設施來捆綁 SaaS 軟體。
總結起來 ToB 領域中的差距還很明顯，我們需要思考為什麼會有這樣的差距，大概有以下四方面的成本可能會影響企業的決策和 SaaS 從業者的選擇：
第一項是合規成本。對於外國尤其是歐洲企業，合規要求會非常高。作為供應商是不能出錯的，供應商需要把這個領域的合規要求吃透站穩腳跟之後再提供服務。例如美國企業有一個特徵就是大企業的供應商鏈條就是一個大企業，像特斯拉或蘋果，它的供應商上下游的鏈條可施加的影響力不管是硬性的還是軟性的，都是非常強大的。比方說特斯拉或蘋果的某個業務領域使用你的 SaaS 服務滿足了其需求，可能它上下游的供應商會跟隨來採購，使用你的產品，這樣會有更快的交付。此外，監管處罰力度也是比較大的，如果沒有合規到位，就無法生存。
第二項是寬頻成本，可以對比 ToC 和 ToB，對於 ToC，前幾年對於三大運營商一直在提一個“提速降費”，相當於是把 C 端使用者的流量成本降到了非常低的價位。因此，使用者上漲成本低了，線上化的使用場景成為了可能，由此催生了國內一大批 ToC 的企業。但是對於 ToB 來說，這部分寬頻成本還是非常高的，比如我們內部在做 SaaS 服務的時候會調研技術方案，在調研技術方案的時候，就不得不評估到企業的流量頻寬成本，即它的資料上報量。哪怕是做了一個 Demo 的活動也需要評估頻寬會不會耗費太多的成本。轉換一下，在面向真正的中小型企業採購者時，同樣也需要考慮頻寬成本，如果這個成本很高，下次服務可能就不會來了。
第三項成本是直接相關的人工成本，它是一個替代成本。中國的人力成本相對還是比較低的，雖然最近幾年工資成本有所提高，但是整體相對美國還是比較低的。目前甲方老闆預設的思考路徑是對於新問題如果投入人力能解決就投入人力來解決，但是美國人工成本比較高，可能這個路徑就堵死了。另外，我們真正在部署 SaaS 專案的時候，需要考慮到企業內使用這個 SaaS 產品的使用者的磨合成本。這個磨合成本是指，可能需要轉變之前的工作模式和之前使用工具的習慣，甚至整個工作流程都需要重構，磨合成本尤其在初期會非常高。這一部分可能也是無法避免的，但是在真正的提供這種服務的時候，如果考慮不到位，可能真正落地的時候就會無法往下走下去。尤其是對於現在，SaaS 化、PLG 是一種訂閱式的服務，可能第一年能夠靠品牌或者人脈讓客戶採購一年，但是後面的留存或者付費比就會下降，所以這個磨合成本在專案實施過程中需要考慮。
第四個就是實施成本，我們如果能夠提供標準化的產品，對於供應商來說成本是最低的。但是對於採購方來說，他們在選購服務的時候，首先要考慮的是自己的需求，這個和企業的治理結構有關係。我們提供 SaaS 服務時就需要考慮到這些採購者的不同特徵。另外，在國內，業務發展比較快、需求難以固化，為提供一個完全標準化的 SaaS 服務帶來了困難。對於甲方來說，或多或少會需要有一些定製化或者需要適配改造的地方，所以這些因素會造成中國 ToB 行業的 SaaS 服務發展比較慢。
首先看一下挑戰，大客戶和大專案定製化、快速能夠實現收入是主要的商業特徵。但是如果提供 SaaS 服務可以更好地滿足中小企業的需求，而且能夠沉澱標準化的產品解決方案，那麼長期來說，收益肯定是高於私有化部署或者定製服務於某一個大客戶的。要綜合考量行業特徵，判斷到底是走什麼樣的產品建設路徑。短期來說，可能會投入比較高、見效比較慢，那麼是否能夠有足夠的資源和底氣沿著這條路徑走下去很關鍵。國內的大型和中型的 SaaS 服務商的決策邏輯都會有一些區別，所以需要理解行業的客戶特徵來做最終的決策判斷。
首先是疫情的影響，不管是純粹的網際網路公司也好，還是偏傳統的企業也好，遠端辦公和線上協作的訴求都是越來越強的。
第二，平臺生態的發展，很多企業已經購買了釘釘或者飛書，逐漸培養起了員工的使用習慣，並逐步接受基於公有云和 SaaS 化的方式來提供工作工具的服務。
最後，IM 平臺為中小 SaaS 服務提供商提供了一個更快速變現的視窗。相對來說，如果沒有這樣的平臺，中小 SaaS 服務商來做獲客或口碑都是非常困難的，可能需要花費非常大的精力。如果融入 IM 平臺，都有應用商店，相對來說起步會更容易。由於 IM 平臺是一個開放性的模式，所以對於各個 SaaS 的服務商來說，他們的產品也是需要打磨到至少是有亮點的，即客戶使用之後能讓一部分使用者留存下進行後續的付費轉化，這是現在中國行業的一個特點。
最後說到 SaaS 產品的建設，目前阿里雲和騰訊雲這樣的大平臺，會包裝非常多的套餐或套件，類似於全家桶的服務模式。在國外可能單品突破的會比較多一些。下圖中的右圖是一個例子：在做 PPT 或者官網頁面的時候，一般會放企業的 Logo 牆，而這個產品就是隻做這一件事，你只要輸入企業的網址，它就能自動爬取並生成對應的企業 Logo 各個畫素、各個規格的 Logo 圖片，試用之後可以按照包年或包月的方式付費。目前來看，這種服務模式在國外是能生存的，中外這兩方面的差別還是挺大的。站在中國角度來說，可能未來的探索方向是以產品矩陣為基礎，對於一個行業的客戶來說，我們有相應的服務包或產品包來覆蓋其各種各樣的需求。但是對於不同的客戶，希望能夠達到一種可拆可合的狀態。這樣至少能夠對接到客戶，也能夠更好的滿足客戶，這是可能的一個探索發展路徑。
最後一個機遇就是用應用商店的模式，主要有三個特徵：第一個特徵，像 salesforce 是一個非常典型的例子：它最開始是基於 CRM，後面擴充套件了非常多的服務能力。它的應用商店非常開放，客戶也可以成為 SaaS 服務的開發者。這會讓客戶產生成就感，對客戶來說是很好的驅動力。這不再是單純的之前那種銷售驅動的模式，客戶生怕被坑蒙拐騙從而要來嚴格把控提供商提供的功能清單有多少功能，雖然某個功能客戶可能不需要，但是如果缺少功能，客戶就覺得自己吃虧了。而新的服務模式是客戶自己進入到這樣一個生態體系內，自己做一些外掛或者服務，對於自己的成就感、自己企業的品牌傳播以及解決方案的沉澱和分享都會有一定的促進作用。第二點是選購的靈活性，這個是完全站在交易的視角或者說企業的採購視角來說的，客戶來購買產品的時候肯定是希望以最低成本來買到最多的功能或者說能夠更好的解決企業問題。如果能夠加靈活的組裝形式，那成本就不會非常高。最後一個是，我們可以把整個行業的生態建設的更好一些，引入更多的獨立開發者或者說第三方的中小 SaaS 服務商來貢獻自己的力量。在整個生態搭建起來之後，比如在資料分析領域或者說資料平臺領域，我們可以透過基礎的產品服務包，加上各種各樣的開發者貢獻的能力集合，去更好的服務於企業的需求。對於 SaaS 的供應商、企業客戶和獨立開發者，都是三方共贏的。
首先，資料特徵天然需要統一維護和上下拉齊，即資料治理，並不是為了治理而治理，而是我們要看到一個準確的資料，並且希望資料來指導業務。當老闆看到一個資料發出了疑問，下面的執行層是不是能夠首先定位到問題所在；其次，透過一些有效手段來改善這個問題，進而來反向影響最終的結果指標，這樣整個企業的運轉才會更加良好，這是天然的需求場景所在。第二點就是資料平臺服務的業務場景是比較明確的，它不像 CRM 或者財務系統是非常複雜的，有時候可能一些法務、法規的變更就會造成系統有重大的調整。資料平臺專注的是業務的開展，而且是專注在資料分析、資料探勘方面的。這些都有特定的工作模式，這個模式對工具能力的供給、使用方式以及使用規範來說相對更好、能夠達成一致。第三點，是我們開展資料工作流的時候，這樣的解決方案有通用性和互相分享交流的價值。
第二部分，來看一下我們內部的具體實踐，如何更好地降本增效。我們在做一個資料平臺 SaaS 化的服務，不可避免的就是企業的定製化需求。可以看一下下面的兩個圖片：
左側的圖片是美國農場農田的規劃，它的一個考量就是標準化而且高效。它是圓形的，這是因為它的低灌的機器結構，是以秒針的形式來運轉的，所以圓形能夠澆到最大的面積，透過這種標準化高效率的工具和解決方案，可以創造最大的收益，使得農作物種植以及收割的效率都會比較高。右側是一個非常典型的中國的梯田，在丘陵地帶地少人稠，要抓住任何一塊能夠耕作的土地來爭取最大的收成。但是想要引入大型機械進行提效來說，提出了非常高的挑戰。這個放在中國的這種商業市場裡也有類似的特徵：美國是一個合規規範比較明確、發展時間悠久的國家，商業認知、工業化的合作思維相對來說比較到位，能夠信賴外部的第三方來幫助企業做這件事情，可以整合各方面的資源，只要滿足最終的目標就可以。而在中國商業環境中，企業及企業主有各自特殊的發展環境或發展歷程，對於引入外部工具來說，需要適配自身企業的發展需要，短期來看定製化需求在中國市場短期內是不可避免的。基於以上的思考判斷，我們在嘗試的一個解法就是透過平臺化和服務元件化的形態來對外提供服務。
這是粗粒度的一個概念：最底層是大資料平臺，首先是基座服務，這個可以對接到企業或不同的平臺、到它們的服務運營環境，相當於是底層伺服器執行的環境，同時可以提供公共的基礎服務，類似於一些租戶管理、企業基本的人員管理、許可權管理相關的，相當於是靠一個平臺的基座串聯起上面的各項服務能力。上面的各項服務能力會專注在視覺化、資料分析建模、使用者畫像、營銷觸達、推送告警、許可權管理等方面。加號代表開放能力，站在一個團隊的角度來說，不管這個團隊或大或小，想要滿足所有的資料分析場景的需求，都不太現實或者成本非常高、時間週期比較長。能不能把它抽象成一個服務元件，同時提供一個外部開發者能夠方便使用的開發環境，從而貢獻多種多樣的服務能力很重要，所以這也相當於是留了一個想象空間。上層的資料應用就是最終面向企業客戶真實的工作場景，比如資料大屏、面向管理者的駕駛艙，或者營銷工具等等。這些我們不會把它全做，可能需要引入業務知識，需要業務開發者或者業務團隊真正的理解業務的看數需求或分析資料的需求，然後來給予我們底座和服務能力提供介面、外掛或者說服務化的能力來得到最終的資料應用，這是總體的建設思路。騰訊希望將燈塔平臺做成公司最完整、最高效的資料分析工具。在這個分析平臺上有資料分析、使用者畫像、資料視覺化，也有資料驅動中工作流等一系列的元件。基於這些元件可以為使用者提供最基礎的資料服務，但是對於客戶來說，他們希望有一個強大好用的資料工具，希望可以按照企業、按照行業、或者按照業務場景進行靈活的定製，或者說希望有一些更高階的增值服務，比如可以為他們提供資料治理的服務，或者指標體系的梳理搭建等等。使用者的訴求和單純站在平臺建設者的視角來梳理這些功能之間是有 gap 的，我們需要將兩者有機的結合起來，才能為客戶提供真正有價值的產出或者交付物。需求輸入和能力供給之間進行有機組合之後，釋出到產品的應用市場或人力服務市場，在這裡企業客戶就可以選購自己想要的服務了。之前歷史沉澱的包括正在做的公有云是基於騰訊雲的分析套件，私有云像工業數字化，以及面向企業整合，就是 TME 集團的資料服務都是可以透過這種模式來搭建起來的。此外不得不說到的就是合作伙伴，我們希望有更多的共建者能夠把這套分析平臺做得更好、更靈活、能夠解決更多的問題。單靠一方或兩方很難，我們想做一個開放性的設計。我們會沉澱包括基座、服務能力的 OpenApI 開發文件、開發的工作環境，同時可以引入第三方開發者進入到這樣的平臺中，來整合各方的能力滿足相應的需求。下圖是開放平臺的設計，基本思路和上面一樣，只是會更多地關注細節：開發者怎麼進入到我們這裡開始開發，我們需要梳理 OpenApI、沉澱外掛化的改造 SDK 和一些基礎的視覺規範和視覺元素，做到線上的自動開發工作流的釋出，真正的能夠對接到剛才提到的這種黃色位置的服務能力和資料應用，使得它們都可以透過這種方式來進行線上化的開發和釋出。
資料產品的工作流程是發現問題、理解問題、產品建模和驗證迭代。首先，我們一定要永遠站在客戶的視角來思考我們做這件事情的價值或意義。C 端的產品經理感受會更直觀一些，例如最佳化了視覺或者提供了全新的服務，作為使用者能夠立刻感知到價值。但是 B 端產品經理在和業務人員打交道，需要做身份的切換、站在業務方視角來思考產品的這種服務模式或價格設計，是不是能夠更好的服務於這樣的行業或客戶。另外，我們提供的工具和服務需要真正幫助使用者解決問題，而不是簡單的功能的羅列或堆砌。有文章曾提到，國外 PLG 這麼成功，而中國一直在嘗試卻沒有立竿見影的效果，這可能有兩方面因素：一方面是甲方的採購者或老闆的思維觀念還停留在銷售驅動階段，擔心缺少功能和吃虧、以為是一錘子買賣；第二方面，站在 SaaS 行業從業者自身角度來說可能也會存在問題，商務團隊和後臺的產研是分開的，商務和產研不能真正的站在客戶的視角想問題。我們需要思考客戶選購了這樣的產品或 SaaS 服務是否能夠解決當前企業存在的一些問題，能夠降低成本或提高效率。最後，希望引入更多的貢獻者以達到價值增值的目標。如何把更多的人引進來，並且他們也願意並能夠貢獻高質量的外掛或服務也是比較有挑戰的事情，還需要經過時間的驗證，才能得到更充分的思考和實操的方法。問答環節
Q1：對於 ToB 的產品，定製化和成本之間的平衡是怎麼考量的？A1：定製化的成本肯定會更高一些，站在我們的視角，接收到一個定製化需求，首先需要理解這個需求是不是具有通用性，或者至少某一個場景是有價值的。如果有價值的話，我們再思考它的實踐方式，如果非常通用的話，我們會把它抽象為一個基礎能力，或者說是封裝成服務，如果是偏行業的，那我們會更多的讓客戶或者外部的合作者利用我們基礎的開放能力來進行支援。Q2：對於使用者的留存，B 端使用者和 C 端使用者在產品的發展和角色上有什麼樣的區別呢？A2：根據我的調研，C 端產品的使用者最先考慮的是產品對我是不是有幫助，像抖音和快手，最開始消磨使用者時間，之後讓使用者獲得放鬆，這對於使用者來說存在正向收益，使用者感知會非常明顯，C 端產品使用者的留存和他自己的偏好直接相關。那麼關於留存的影響因素會更容易定位或者說更好分析。比方說是不是我們產品的某次迭代傷害了某一部分核心使用者、是不是有一些影響產品口碑的事、或者輿情的發生、或者也有一些行業或政策因素等等，這些都會影響一個使用者的留存。C 端使用者留存的手段也會比較多一些，或者說老客的召回都會好做一些。相比來說，差別就在於使用者的感知和企業 SaaS 的選購週期的傳導會稍微慢一些，另外可能在甲方企業內部的資訊轉換也會不太一樣。ToB 產品的留存，在行業內主要考量的是次年的付費收入/今年的付費收入，如果大於 1，證明是正向的，那麼就是有更多的甲方企業，或者說更大範圍的甲方部門來選購我們的 SaaS 服務，這是一個正向的考核指標。如果說想要施加一些手段提高留存，我們可能需要投入更多的精力。由於服務是比較複雜的，它不會像 C 端的一個單點功能就會有明顯感知，而是可能整個鏈條都需要最佳化到一定地步，才能解決某一些客戶的問題。Q3：現在很多 SaaS 公司的盈利模式可能比較難，有沒有比較好的建議和策略可以增加公司的變現能力？有沒有體系化的一些想法？
A3：關於變現，我不太確定這個變現是說自己企業內部沉澱的之前的能力還是說把產品轉換為一個面向外部真正開始賺錢的業務。如果是這個問題的話，我的理解是迴歸到商業化的本質，你提供的服務在市場上是有需求的，這個需求相當於是一個雙邊交易市場。我有這樣的需求，有這樣的供給，才能促成這樣的一筆交易。如果是站在基於企業內部沉澱的服務能力來思考的話，首先第一點需要判斷我們要切入哪個市場、這個市場的特徵和規模是怎麼樣的；第二點需要判斷在這個市場下和這個細分領域下我們現在的產品有沒有一些亮點，或者說我們整體的一個服務是不是至少能夠和目前行業內已有的產品來做有利的競爭，相當於是先分析自身再看一下市場上的需求。如果市場的需求只靠人力就能解決，或者只是投入時間就能解決，但是不影響賺錢的業務場景或者切入領域的話，那麼當前進入的時機是不太友好的。由於要創造收入，對於自身或者對於整個企業的決策來說，及時的正向激勵才能促使我們更好的往下推進。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/70024420/viewspace-2939347/，如需轉載，請註明出處，否則將追究法律責任。