随着企業服務賽道的持續火熱，進入SaaS方向的企業也越來越多。本文基于服務商業化的目标延伸探讨如何擴寬内部系統的定義，使其為商業化服務和如何根據SaaS公司處所階段，來設計管理後台及具體模塊。推薦相關領域從業者閱讀交流觀點。

在過去的2021年，企業服務賽道的融資額達到6400億人民币，較上一年增長105%，創曆年新高。這一态勢在2022年依舊延續，就在前幾日，細分客戶服務賽道的SaaS企業“售後寶”剛剛完成紅杉中國、老虎環球基金領投的一億元A1、A2輪融資。

對于SaaS企業來說，在為客戶提供服務的時候，會自然的發現，自己需要一個内部系統來管理租戶，管理産品開通，為租戶做增購續費等服務。

然而這真的隻是内部系統的全部意義麼？

除了服務于已經确定服務的客戶，為他們做業務支持，是否還可以挖掘其他價值，解決SaaS企業最頭痛的标準化問題，進而為企業商業化作出貢獻呢？

一、重新認識内部使用系統

給出結論前，先來看看對内部系統的認識誤區都是怎麼産生的。

在如今，一個傳統企業可以通過使用SaaS軟件，找到實現标準化管理的方式，提升業務數據，但以售賣管理理念和管理工具著稱的SaaS企業，卻往往忽視自己的内部管理，忽視用管理工具來提升效率。

仿佛一位德高望重的專家古道熱腸，四處幫助同行實現企業數字化，但卻對自己企業的問題視而不見，還在用傳統的方式管理企業。

這個現象，别扭中又帶着一絲合理。畢竟内部系統的投入幾乎就等于沉沒成本，對它期望被放得很低。一般隻要求用最小成本，去支持當前必須支持的内容。多做不需要也不劃算，這就是它的現狀。

也正是基于這點認識，會産生常見的3個誤區。

誤區1：隻滿足于為客戶開通服務，把基礎功能當成全部功能

這是最為常見的刻闆印象。

當産品經理聽到“設計一個内部使用系統”的需求，大概率就把需求目标定為支持業務。用于給已付費的客戶開通産品，附帶管理客戶的升降級，增購，續費等服務。

進而會把功能範圍限制在客戶管理，産品管理，訂單管理。

這是把基礎功能當成了全部功能，沒有在公司内部統一系統的意義。

當你有1家客戶，大概率不需要一個系統，讓研發後台開通，手動記錄歸檔表格就可以。

當你有10家客戶投入使用，可能就開始需要系統支持以上的功能。特别是客戶買的版本不同，增購的服務不同，研發直接開通就顯得不那麼透明。另外如果新增的功能需要配置到不同版本，那就更需要一個後台，由産研團隊手動操作。

但當你有100家客戶呢？你關心的應該就不是為客戶開通系統這些事情了。此時你站在了SaaS增長的路上，更關心的是客戶使用得如何，客戶的留存如何，銷售的效率、成功的效率有沒有體現在客戶的指标上，能不能為LTV做到應有的貢獻。

所以，開通服務隻是基礎的後台能力，但僅僅隻有這個能力，是沒有辦法輔助SaaS後期發展的。

誤區2：隻需要少數人使用系統，盡量不要轟轟烈烈全體總動員

因為沒有對系統有正确的認識，會覺得讓所有人來操作系統是一件費時費力的事情，所以需要盡量減少操作系統人數。

此時值得思考的問題是：沒有系統的沉澱，我們通過什麼方式了解客戶呢？

服務客戶的過程，需要市場部，銷售部，産品部，成功部幾個部門通力合作，程程接力，最終達成客戶成功。每交接一程，客戶信息就被中斷一次，沒有完整的全面的信息，會造成極低的溝通效率。

當鍊條末端的成功部門到客戶，隻有反向去詢問，過程中必然會有信息的缺失和失真。

而日常客戶如果提出了需求，産品也隻有反複向銷售或成功了解客戶背景，揣測客戶心理，再去評估需求。

但如果有系統沉澱了客戶從線索到轉化，訂單到服務，工單到訪談等所有信息，客戶的畫像就十分生動地呈現于此，而隻要沉澱越久，我們對客戶的了解也越深，也就意味着可以提供更加具有競争力的服務，增加客戶的留存率。

記得有一則小故事，講述了在五星酒店裡。某位住客一進大門，經理就準确叫出了他的名字，微笑着歡迎光臨，辦理入住時，前台向主客确認：您之前住過的房型有空餘，還為您安排您喜歡的高空樓層可以嗎？

晚餐時分，走到餐廳，侍應生推薦道：之前您喜歡的和牛正在供應，可以為您推薦一下嗎？種種服務讓客人賓至如歸，一下就達到了體驗的颠覆，連連搖推薦這家酒店給自己的朋友。而酒店之所以能做到如此細緻的服務，有賴于沉澱客戶畫像。

而我們通過協作多部門，共同使用内部系統，完善用戶數據，也可以做到這點。

誤區3：隻需要功能夠用就可以了，忽視流程和安全

認為既然是内部使用，那不需要做得太過複雜，或者認為公司小不需要那麼規範，就隻需要專注在功能方面，從而忽視流程和安全。

可能會造成的問題有：

SaaS公司銷售的是軟件，而這些軟件需要在後台被開通給用戶，如果把公司類比成一家實體企業，那麼後台就是倉庫的鑰匙，而當這把鑰匙隻掌握在1個人手中時，足夠安全嗎？

以上問題一旦發生，損害的利益相當大。雖然說可以通過制度約束，但如果一開始就不把縫隙留給自己，那不是更好嗎？亡羊雖然可以補牢，但羊終究是丢了。

以上聊了常見的誤區，那我們應該如何走出誤區呢？

歸根結底，内部使用系統，是管理思維和管理方式的融合，它既是思路，也是工具。

經常聽到SaaS企業抱怨，說銷售難招，客戶成功難招。

有經驗的人畢竟是少數，大多數公司都是用無經驗或者少經驗的人去作戰，那在這種情況下大家難免犯錯，難免不知道做什麼，以及怎麼做。

如果有一套工具能夠指導大家，先用流程管控讓大家去這麼用，再在用的過程中逐漸明白為什麼要這麼用，以工具帶動思路，是不是也是一個方案呢？

而為了達成這個目的，要求既能體現經營管理的思路和目标，又能在過程中規範員工操作。

一套完整的SaaS内部管理系統，需要具備這3個部分的功能的能力：分别是CRM、PMS、CRM。

第一個CRM是指客戶關系管理系統，用于管理向客戶銷售的流程。

第二個PMS指的是産品管理。是對需要售賣的内容進行基礎的配置和管理。

第三個也叫做CRM，但是和第一個意義不同，是客戶留存管理的簡稱，這個概念比較新，在市面上還未看到被人提出和強調，但它對于SaaS企業來說，可以說是最重要最精華的一個部分。

因為SaaS和傳統軟件不同，它的成功會和客戶融合得更深。

甚至可以說，SaaS企業有多成功，取決于它的客戶有多成功。

SaaS企業的收入，首先依賴于客戶要存活，其次依賴于客戶會持續購買。這就要求，客戶的業務要發展的不錯，以及客戶真的用SaaS軟件解決了業務上的問題，兩者缺一不可，共同指向了客戶成功。

SaaS企業一直強調的是标準化服務，是希望快速服務更多的客戶來降低自己的服務成本，減少CAC（客戶獲取成本）和CRC（客戶留存成本），希望做客戶多做留存和增購，來提升客戶LTV（客戶生命周期價值），進而追求LTV/CAC >3的裡程碑指标。

所以SaaS的後續的服務及其重要，但現在的後台系統一般就變成了給客戶開一下對應的版本，僅提供這樣的能力，我們沒法及時了解客戶是否成功：客戶到底用得如何，有沒有流失風險，有沒有挖掘增購的潛力。

那可能大家會問，為什麼說要做到這3部分的能力呢？

因為我們如何服務客戶，取決于客戶如何選擇我們。

所以一切的設計，都要從客戶使用旅程開始。

客戶選擇和SaaS服務，要經曆圖中的5個旅程。

分别是選擇産品——試用産品——簽約使用——實施落地——持續使用。

圍繞這5個步驟，公司服務流程可以分為銷售和成功兩個環節。

分别去進行工作安排。

例如在銷售環節，可以錄入&分配客戶線索，管理客戶狀态，記錄客戶跟進事宜，管理客戶商機，開通試用服務生成客戶訂單，開通客戶服務。

在成功環節，可以管理客戶狀态，記錄客戶實施事宜，查看客戶數據，評估客戶流失風險，管理客戶工單，持續解決客戶問題；生成客戶增購&續費單，持續給客戶提供價值。

而進一步去細分這兩個環節，就發現需要支持這兩個環節的各個角色，包括了市場，銷售，成功，甚至背後的産品和研發，管理層。

這些角色覆蓋了客戶關系管理，産品管理，客戶留存管理三個部分，三者綜合，也就是我們對于内部系統的全部定義了。

二、如何設計内部使用系統

以上聊了對使用後台的定義，那在具體的設計中，我們應該秉承什麼樣的思路和方法去實施呢？

1. 設計思路

（1）3個系統，1個核心模塊，1個儀表盤。

首先要說明的是，客戶模塊是我們服務的底盤和核心。

各個部門間的協同，都是以客戶數據做串聯的，同時系統也要把數據采集下沉到客戶使用中。

其次，不管内部買再多套系統來支持業務，最後還是要有一個儀表盤，來彙總所有的業務系統上的數據，來反應經營上的指标。指标需要反應兩方面的内容，一是公司内部成本支出，二是公司外部獲取及服務客戶的成本支出和收益。

2. 設計流程管控

在系統上線後，就要開始同時要注意系統對工作流程的約束和控制了。

這樣能夠避免有意或無意的不規範操作，盡量避免公司的各方面風險。

以下有幾個值得注意的例子。

-注意離職員工的狀态同步，離職員工不可以登陸系統後台。如果願意更加精細，開發和測試環境也可以區分和限制，避免離職員工還可以看到後台的新能力。

-區分好試用訂單和真正式訂單，試用訂單可以0元支付，但有使用期限，每個客戶隻能購買1次或者限制購買次數，避免刷單使用。

-開通服務盡量自動化操作，避免人工操作不及時或者錯誤，且隻有當銷售提交了訂單，且财務審核通過後，才可以開通對應或延期對應的服務，同時可以預留手動開通的功能作為輔助。

3. 搭建方式

以上談論的是系統後台設計的全景，下圖是是支持全景的相關模塊和表單的描述。

然而實際過程中，我們未必有這麼理想的情況可以一次性到位。

受限于公司發展階段和資源，我們可以逐步搭建這個流程。

第一期：驗證匹配度。

首要滿足客戶試用 客戶使用 實施落地的需求，也就是全景圖中标紅的部分。

本期的設計目标，隻求服務于業務必要的闆塊，同時記錄關鍵信息。

具體模塊的定義和能力如下：

1. 産品管理：管理版本費用，各項增值服務費用。增值服務的形式多樣，具體可以參見之前寫過的一篇文章：如何做好SaaS版本定價？
2. 訂單管理：生成訂單，審核訂單，審核流程需要财務參與确認已經收款，訂單審核通過後自動延長服務的截止日期或用量。訂單可由銷售發起，也可由成功發起。
3. 服務管理：各項開通服務的存續狀态和用量。
4. 客戶管理：管理客戶的基礎信息，可以跟進維護客戶的相關數據，以及記錄和客戶的往來溝通，明确客戶畫像。可由銷售、售後共同維護。
5. 經營儀表盤：至少做到最簡單的登錄行為的統計，了解一個客戶下有多少個用戶在登錄，每天登錄的情況怎麼樣，趨勢是上升還是下降，對數據的階段，是最簡單的判斷産品價值的方法。

産生了這些數據以後，那應該如何使用呢？

考慮這個環節的客戶一般不多，可以在周會的時候，拉出本周所有客戶的往來溝通記錄，以及儀表盤數據，從主觀和客觀兩個方面，及時了解産品的接受程度。

第二期：開始追求客戶數增長，同時關心留存。

滿足業務的标準化運行，服務于增長。

每個模塊可以具體增加如下的能力：

1. 産品管理模塊：增加優惠券管理，可以為引入新用戶和留存做營銷。
2. 客戶關系管理：開始陸續增加線索，商機，報價單模塊。
3. 客戶留存管理：增加工單管理，分為需要實施的具體事項，需要安排人日去，以及客戶提出的需求或者服務的工單，可以通過工單。
4. 經營儀表盤：繼續深化數據采集和數據分析能力，關注經營性質指标，着重關心MRR（每月經常性收入），其次關心成本數據。

具體的使用上，以經營指标為總覽，分析具體的經營狀态。

第三期：客戶數增長減緩，更加追求留存。

此外，也開始注意客戶質量，開始打造标杆案例。

具體可以增加的模塊和功能如下：

1. 産品管理模塊：往往出現了多個版本，增加功能配置模塊，新增功能可以配置到不同的産品版本。
2. 客戶關系管理：通過結合營銷工具，展示客戶在售前環節的動作和行為，賦能銷售，也可以通過采購SCRM完成結合。延續二期的功能模塊，根據需要逐步安排上線。
3. 客戶留存管理：更細緻的工單管理，甚至可以統計到需求工單上線後的需求效果，對于研發成本進行管理。
4. 經營儀表盤：通過之前工單沉澱的數據，可以開始逐步量化成本（CAC，CRC）和LTV。開始嘗試做數據預測和預警。

第四期：增長數幾乎停止，把留存作為最重要的工作。

此時一般新的需求都是由老客戶提出，可以對客戶做更細緻的留存的管理和工作。

從産品上來說能力都具備得差不多了，數據層面上可以往數據決策的方向。

三、一期産品設計草案

聊了模塊的具體設計思路，接下來以第一期為例，簡單分各個模塊聊一下各個模塊的字段設計。因為時間有限，僅僅隻是不完整的草案，僅供參考。

1. 基礎模塊

1. 權限：常見模塊，不多贅述。
2. 登陸/退出：最好和内部協同軟件的在職離職狀态做對接。

2. 客戶管理

（1）字段

1. 客戶基礎信息：包括基礎的公司信息，描述公司實力和背景，也包括客戶聯系人。
2. 客戶開通時間：展示客戶第一次購買的日期。
3. 客戶當前狀态：試用中/正式使用/續費使用/已流失
4. 客戶服務信息：版本服務截止時間/當前使用版本/已開通服務（展示個數，點擊可進入查看服務細項、截止時間和剩餘用量，每個服務細項都對應着）。
5. 客戶付費信息：訂單金額總額/已交付訂單金額/待交付訂單金額
6. 客戶負責成功：姓名/聯系方式
7. 客戶負責銷售：姓名/聯系方式
8. 客戶跟進記錄：記錄時間/記錄人/記錄類型/記錄文字/記錄附件

（2）操作

3. 産品管理

（1）字段

1. 産品類型：版本産品/增值服務（受版本時間限制）/增值服務（獨立于版本）
2. 産品基礎信息：名稱/單位/價格
3. 産品狀态：啟用/關閉

（2）操作

增/删/改變狀态/修改（如果不同年份對應不同的産品價格，建議可以維護一個産品價格的生命周期，不要直接做修改）

4. 訂單管理

（1）字段

1. 基礎訂單信息：客戶/價格/訂單狀态，參照常見電商設計即可。
2. 關聯産品：名稱/單位/價格
3. 關聯服務：展示訂單購買後的關聯的具體服務。

（2）操作

1. 創建/修改/作廢訂單：訂單狀态變動會影響相應服務。
2. 審批訂單：需要财務參加審批。試用訂單可以不參加審批。

5. 服務管理

（1）字段

1. 基礎信息：服務ID/服務狀态（待生效/生效中/已結束/已作廢）
2. 關聯訂單信息：客戶/訂單ID
3. 關聯商品信息：産品/購買單位（時間/用量）

（2）操作

無法修改，隻能通過修改訂單變更。

以上是一期表單的設計草案，除此以外，有兩個概念也要提一下。

1. 租戶的概念是什麼？一套SaaS對應着一個租戶，代表奔逃SaaS軟件的使用者。這裡未單獨設計這個表單，和客戶做區分，是因為現實中90%的情況，一個客戶隻會購買一套産品，所以一個客戶對應一個租戶的設計一般也就足夠了。
2. 賬戶概念是什麼？如果你的SaaS産品是由餘額充值這樣的形式，在每個客戶上還需要有對應的虛拟賬号，來展示相應的數據。根據業務決定是否啟用即可。

四、結語

今天的主題是SaaS企業的内部系統，應該怎麼設計。

首先聊了常見的3種誤區。

1. 隻滿足于為客戶開通服務，把基礎功能當成全部功能。
2. 隻需要少數人使用系統，盡量不要轟轟烈烈全體總動員。
3. 隻需要功能夠用就可以了，忽視流程和安全。

基于對誤區的逐步剖析，我們把内部系統定義為：既能體現經營管理的思路和目标，又能在過程中規範員工操作的系統。

同時認為一套完整的SaaS内部管理系統，需要具備這3個部分的功能的能力：分别是CRM、PMS、CRM。

這是認識的層面，而在設計的層面。

先明确了思路要點：

1. 系統包括3個系統，1個核心模塊，1個儀表盤。
2. 系統需要強調流程管控。

接着論述了SaaS企業四個階段如何逐步實施，同時附上了系統全景圖，作為參考。

最後針對一期的能力，提供了設計草案，供執行的時候有一些具體思路。

SaaS企業扮演了數字化轉型中的重要力量，作為低成本的數字化專家，在忙于向外界賦能打硬仗的同時，我們希望“醫者也能自醫”，讓SaaS企業自身的系統也能練内功，賦能内部企業，為實現商業化加把勁。

作者：假裝是運營，SaaS學姐

本文由 @假裝是運營 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部