在搭建客服系統時，我們會需要對業務模式、核心指標與系統架構進行構建，而除此之外，我們還需要對當前的業務體量進行評估，并衡量好當前業務體量情況下的工作重點。那么這個階段我們要如何進行？一起來看看作者的分析與解讀。

前面三節我們已經大致對業務模式、核心指標和系統架構做了介紹，當我們進入一家公司開始從0到1搭建客服系統時，面對繁雜的業務場景和對接系統，千頭萬緒如何找到切入的第一根線，系好第一顆扣子，就是我們本節要回答的核心問題。

那么，下面我們就進入正篇部分的最后一節，如何評估當前業務體量，以及各業務體量下工作重點。

一、概述

業務體量或者說業務階段，并不是新概念，經常接觸產品工作的朋友一定都見過這張圖。橫軸代表時間，縱軸代表用戶量或者營收，體現一款產品在完整生命周期中核心指標的變化。每個周期都需要針對制定策略讓產品盡快進入下一個周期或在當前周期停留更長時間。

區別于TO C產品，類似客服產品的體量評估要綜合考慮客服工作量和整體業務成熟度。在此我們將客服產品分為三個階段，并對每個階段去做具體闡釋：

• 小體量定型階段；
• 單一業務成長期；
• 大體量及多業務并行階段。

二、各業務階段闡釋

1. 小體量定型期

• 階段特征：業務模式不成熟，產品未定型迭代速度快，客服工作量小。
• 工作重心：配合業務模式探索，以發現和反饋問題為重點。

嚴格來說在此階段并不需要客服產品，產品初創期一切為增長和商業模式驗證服務，此時用戶量較小，對應所需客服人數較少（3-5人）甚至部分工作由運營和產品直接處理。

產品工具方面，通過站內用戶反饋、400電話和第三方通訊工具（QQ/微信等）可以直接滿足溝通訴求，記錄層面使用在線文檔等工具也可快捷實現。

2. 單業務成長期

• 階段特征：業務模式基本定型，產品數據高速增長，服務引發率高，客服工作量快速增加。
• 工作重心：規范客服工作流程，引入第三方工具過渡使用，開展系統基礎建設。

業務模式驗證后開始大規模投放引流，此時產品會迎來快速增長，同時由于新用戶對產品熟悉度低和細節流程不完善，客服工作量增幅會高于業務增長速度。以電商舉例，月訂單量300w，月增速10%，服務引發率在2%左右波動（成熟業務一般在1%以下），客服團隊所需人數30左右，并會快速增加。

此時需要客服產品逐步提供產品工具，滿足逐漸規?；l展的客服團隊訴求。同時由于在業務高速增長期，整體后臺建百廢待興，審核、財務、風控、權限和數據平臺等系統都在建設階段，開發資源相對有限，以及業務流程細節不完善，對應的客服處理流程也經常變動。因此系統建設的切入點要把握好兩個原則：

1）急需落地工具可先引入第三方服務

如IM通訊系統，市場上已有較為成熟的產品（七魚、環信、UDESK等），基本可以實現快速引入，引入時需對數據安全問題著重考慮，比如訂單、用戶信息在第三方系統的呈現，個人建議比較好的選擇是僅對部分用戶信息披露，客服可識別進線用戶即可，其余信息在內部系統查詢使用。

一般完整的第三方服務還會提供任務記錄、數據分析等功能，利用好這些能力，可以在初期就開始沉淀數據，為后面的數據看板等功能做數據儲備。

2）高敏模塊和基礎架構提前搭建

高敏模塊在客服業務中的表現是投訴系統，因為涉及到賠款、糾紛判責等場景，尤其是涉及資金部分，必須優先保障安全。這里需要強調強烈不建議客服使用財務系統操作資金事宜，員工角色和角色之間，系統之間需要保持邊界，而邊界是B端產品實踐中最重要的部分。

基礎架構指任務中心尤其是任務引擎部分，任務引擎做為客服系統的核心能力，主要作用是推動流程節點，同時滿足任務的創建、分配、完成、回收。不僅可以滿足客服各個系統使用，同時可以作用于審核、權限、審批等各個系統，是可以做為中臺化的模塊。

備注：這里是我們從第一節后首次提到中臺的概念，有別于對某項業務定制的后臺模塊，中臺是多業務線可抽象能力的集合，關于是否應該存在中臺，個人理解在部分業務中是合理的，以客服、審核、財務系統為代表，后面我們在番外一中再詳細聊聊。

3. 大體量及多業務并行期

• 階段特征：業務成熟，市場占有率較高，公司多業務線并存，客服團隊較龐大并引入外包。
• 工作重心：實現從第三方到自建遷移，逐步抽象中臺能力，BP到業務線精細化運營。

如果我們所在的公司最終走到了這一階段，舉例參考，某OTA平臺客服人數5000+，某短視頻平臺審核人數3W+，并且該團隊需要同時服務于內部多條業務線，且已經有員工分級和自營外包區分。這階段我們將要并行去做三件事情：

1）第三方服務到自建系統遷移

數據是一個公司的核心資產，第三方服務的形式決定我們無法在系統和系統之前是先完全意義的信息共享，即無法做到信息閉環，這對客服后續的精細化運營效率提升將造成最大的障礙。

自建是精細化運營的開始也是必由之路，在初期需要注意的是兩個系統遷移過程中的數據繼承及員工操作習慣的保留，值得提醒的是我們并非要做一套和第三方服務完全不一樣的公司，而是在保留員工操作習慣的同時，改變產品內核，為以后的產品優化做準備。

2）逐步搭建客服中臺

如果公司仍是單一業務線運營模式，可以忽略這部分，不過有野心的公司，在進入成熟期末尾時，為避免衰退一般都會擴大自身邊界。因為有之前的成功經驗和人才積累，新業務會跑得更快，要求其中如客服審核相關的支撐系統，即敏捷又穩定。

這時整個客服系統在針對新業務的服務時，更多像是一個公司內部的第三方服務系統，需要提供的更多是模塊化的基礎能力，參考比較主流的租戶形式，實現數據間的完全隔離，將客服的基礎功能模塊化，供給各業務團隊使用。

3）精細化運營

第二和第三并不沖突也沒有先后，無論任一業務進入成熟期，都可以做精細化運營，通過各種手段，提升相關指標。

核心還是用戶評價和效率，分支我們可以通過比如用戶自助、交易流程優化、機器人服務改進、信息閉環深入、模塊操作易用性提升等手段和方式，深入到客服業務中，發現和解決問題。

同時這一階段我們可能會存在龐大的外包團隊，以及客服同崗位員工內部分級，需要我們在權限設計、分配邏輯設計中考慮同崗多角色情況；以及會對接其他多系統的多個角色，必要時需要實現系統和系統間的信息傳遞。謹記核心要義，無論內部系統模塊間還是各個系統間，確認好邊界，高聚合低耦合。

三、最后說兩句

到此為止，我們該系列的四篇正文就結束啦，其實可以深入的東西還有很多，比如每個系統模塊的建設規則具體是什么，有幾個信息層級，對應多少個頁面，甚至原型應該怎么畫，更多講的還是偏宏觀的內容。確實也很難通過短短四節內容講好每個細節，更多是想陳述作為一個客服產品，我們在每個階段該做什么事情，以及我們為什么要做這些事情，至于具體怎么做，只是在第三節做了框架描述。

略有遺憾不過暫時也可以作為方法論的收尾了，后面兩篇番外我們繼續聊聊對中臺的認識和客服中臺怎么做。有機會再繼續分享每個模塊的設計細節吧，老坑未填新坑已至，感謝看到這里的同學，謝謝。