在前面兩篇對客服產品的業務和核心數據有了一定了解之后，本文我們來看看如何做客服產品的架構設計，希望對你有所幫助。

終于來到這系列的核心部分–產品架構，我寄希望于這一節的內容既能描述清楚業務全貌，同時也能實際闡述客服產品工作細節。所以分為廣義客服產品和狹義客服產品分別介紹，廣義指客服系統在整個業務生態中所處的位置以及相關聯系統；狹義指僅客服部門使用的系統。前者幫助我們理解業務全貌，后者幫助我們深入工作細節。

一、廣義客服產品

廣義客服產品指包含在客服系統內的，業務中會產生關聯的任何系統，同時由于客服工作的特殊性，需要服務整個公司的所有用戶，基本會涵蓋所有業務相關系統的信息查詢模塊，基于此出發，我們回答三個問題：

1. 是什么：和客服關聯的業務系統都有哪些
2. 為什么：為什么客服需要使用到這些系統
3. 怎么辦：客服同各個系統間的對接方式如何設計

1. 廣義產品框架

2. 擴大客服權限的意義

核心數據篇章中提到過客服在服務過程中要做到有問快答，有問必答，如上圖以交易品臺舉例，凡是涉及用戶和商家在日常使用中可能會產生疑問和糾紛的地方，都是客服的覆蓋范圍。得益于客服的核心考核機制，將這些信息對客服共享，可以讓用戶獲得更好的使用體驗，對業務產生正向影響，同時因為敏感信息過多，設計好權限系統至關重要。

簡述一下各個系統客服用途：

• 訂單系統：訂查詢、取消、修改，根據業務流程提前介入訂單履約環節
• 用戶系統：查詢用戶信息，幫助用戶處理封禁情況，
• 營銷系統：查詢活動內容，用戶領用優惠券情況，發放優惠券
• 商品系統：商品信息查詢、更新、庫存維護
• 商戶系統：商戶信息查詢、更新，系統使用答疑
• 支付系統：支付信息查詢、開票、提現、資金凍結
• 風控系統：異常狀態查詢，內容審核進度查詢，舉報結果查詢
• 數據中心：數據看板和分析支持
• 權限系統：客服部門內各角色權限控制
• 日志系統：客服操作日志寫入、查詢

3. 對接方式設計

客服系統相比于其他業務系統有較為成熟的系統框架，市面上也存在較多SaaS服務商，比如環信、七魚、udesk等等。因此我們系統對接方式先大致分為三方服務和公司內部系統對接，三方服務對接我們放入體量階段判斷中闡述（就是下一章節），我們本次先聊一下內部系統對接。內部系統對接有三種方式。

（1）去別人家做客

指通過頁面按鈕鏈接跳轉到對方系統，可以用拼接URL或者攜帶ID參數等形式直接查詢結果。好處是開發成本較低；弊端是一方面對客服人員在對方系統內的權限設置有要求，另一方面無法對客服需求做定制化產品把控力較低。

（2）把別人邀請到自己家

指通過接口調用將信息集成在客服系統，針對客服訴求做定制化開發，作為客服系統一部分存在。好處是產品把控力強可以最大限度滿足訴求；弊端是開發成本較高，可能會有重復開發和產品邊界問題。

（3）在自己家和別人家之間修條路

指通過雙方的工單等協作工具傳遞信息。和前兩種方式較為不同，此種方式適用于無法由客服閉環處理的業務場景，需要公司其他團隊協作，同時需要對協作內容做系統留存的場景。

二、狹義客服產品

狹義客服產品指主要由客服團隊使用的系統模塊，即對如前的客服系統做更細致的描述，按客服架構分業務、管理和系統支持三部分描述。業務模式萬萬千，這部分介紹不涉及產品原型，僅對各個模塊的核心功能及細節注意事項做強調。

1. 狹義產品框架

2. 各模塊核心釋義

總述：

（1）業務層核心目標：通過系統優化提升人員效率，產品為主

• 進入人工前，重點在提高機器解決率，通過智能機器人、自助服務等手段，減少人工介入比例。
• 進入人工后，重大在提升分配效率和人員處理效率，分配邏輯+信息整合，減少客服尋找信息消耗。

（2）管理層核心目標：通過管理手段提升人員效率，管理為主，產品提供管理工具

分述：

（1）任務中心

任務引擎：

所有業務模塊的核心產品邏輯，通過對節點的流轉，滿足各個模塊中的隊列分配和審批流，可以認為是相對中臺化的建設。

任務分配三大邏輯，所有隊列分配邏輯的基礎，可根據具體場景使用或疊加維度變形使用

1. 遇閑分配（多勞多得），指每個員工有分配上限，優先分配上限不足且當前處理量偏少員工
2. 輪詢分配（平均分配），指每個員工無分配上限，按員工排序輪番分配，不判斷當前處理量
3. 指定分配（指定對象），指根據唯一標識（員工ID）分配給某個指定員工處理

任務分類，涵蓋了各個一線組別需要處理的業務場景，包含人工和系統創建，對處理事項做記錄，以及便于后續流轉。

流轉通知：

通過郵件、站內信、內部通訊產品（釘釘、飛書、企業微信）對重點事項觸發通知

（2）呼叫中心/IM系統

彈屏頁：

電話或IM消息接入時，員工屏幕彈出的信息整合頁面，便于提升員工處理效率

歷史記錄：

通話錄音和IM聊天記錄，電話一般另配置語音轉文本能力，便于后續分析和AI質檢。

電話和IM異同：

• 呼叫模塊是比較傳統的處理方式，因為僅能滿足對用戶一對一溝通，效率較低，目前在一步步被IM取代，但是其中基礎呼叫能力還是需要后續持續使用的。
• IM系統因可以一對多處理問題現在被大多數公司使用，且通過智能機器人、自助服務等可以將更多簡單事宜交由機器完成。
• IM系統根據公司體量不同，除滿足客服使用外，可以做中臺規劃，供給到服務商以及作為公司內部通訊工具使用，這部分我們在體量判斷中舉例說明。

（3）投訴系統

賠償計算器/賠款審批：

投訴是體驗的最后一道防線，賠款是投訴系統的核心：賠償計算器指對于標準缺陷場景制定賠償標準，由賠償計算器觸發完整賠款流程，減少員工判斷和操作風險，涉及不同的賠款金額，根據員工權限不同，觸發到上一級審批，確保資金安全。

輿情監控：

通過第三方服務或自建輿情監控平臺，及時感知外部輿情情況，聯系相關信息發出者，減少外部負面評價。

（4）客服管理

人員、角色、組別信息配置：

• 組別信息決定人員歸屬那個版塊，處理什么事務
• 角色信息決定人員的級別和權限
• 人員信息是員工的基本信息，除了用于日常工作，還作為績效考核信息的基礎

現場監控/運營報表：

• 數據監控手段，前者用于現場管理員工實時工作情況使用，后者用于板塊管理。

排班/考勤/績效：

• 客服為綜合工薪制崗位，一般24小時或8:00-22:00覆蓋，所以其中需要根據高低峰輪班
• 考勤為各個員工出勤和加班情況記錄
• 績效根據質檢+計件+考勤+核心指標（好評率）對員工月度工作分級核算工資使用。

（5）質量檢查

質檢配置：

• 根據具體情況制定抽檢規則，按時（一般按天為周期）分配抽檢任務給到質檢組員工
• 初檢、復檢、疑議

質檢的三個環節，前兩者指對同一內容需要判斷兩次保障公平，疑議指員工對質檢結果有問題的部分，可以由其組長發起疑議再次處理。

（6）知識庫/調查問卷

• 知識庫主要是對流程的記錄文件，方便員工查閱，同時可以和系統關聯，在對應場景中顯示其處理流程描述，通過浮窗或跳轉等形式。
• 調查問卷主要是對用戶發送問卷調查，回收用戶反饋使用，或者也可以作為NPS評分使用。

最后說兩句

本節我們簡單去闡述了廣義和狹義的客服產品架構都包含哪些模塊以及各個模塊的功用，其中的每個模塊都值得單獨開一篇去細細琢磨，目前的篇幅只能做個目錄索引。同時希望讀到的同學除開這些描述以外，能體會到一些形而上的東西——產品設計中閃爍的人性關懷。

比如作為客服產品，去思考每個系統功能改進的背后是一個個我們的同學戰友，在高強度的工作節奏下，在給用戶提供情緒價值，那么我們設計邏輯的背后，也可以或者說需要去照顧他們的情緒訴求。另外比如在設計智能機器人的轉人工流程時，兼顧效率和體驗，堅持不讓用戶以放棄訴求為前提提升解決率，不將人工智能變成人工智障。

下節的體量判斷我們結合本節的IM系統、權限系統舉例，看看各個體量下的產品，用何種方式和途徑實現功能更優。