在前面两篇对客服产品的业务和核心数据有了一定了解之后，本文我们来看看如何做客服产品的架构设计，希望对你有所帮助。
终于来到这系列的核心部分–产品架构，我寄希望于这一节的内容既能描述清楚业务全貌，同时也能实际阐述客服产品工作细节。所以分为广义客服产品和狭义客服产品分别介绍，广义指客服系统在整个业务生态中所处的位置以及相关联系统；狭义指仅客服部门使用的系统。前者帮助我们理解业务全貌，后者帮助我们深入工作细节。
一、广义客服产品
广义客服产品指包含在客服系统内的，业务中会产生关联的任何系统，同时由于客服工作的特殊性，需要服务整个公司的所有用户，基本会涵盖所有业务相关系统的信息查询模块，基于此出发，我们回答三个问题：
【资料图】
1. 广义产品框架
2. 扩大客服权限的意义
核心数据篇章中提到过客服在服务过程中要做到有问快答，有问必答，如上图以交易品台举例，凡是涉及用户和商家在日常使用中可能会产生疑问和纠纷的地方，都是客服的覆盖范围。得益于客服的核心考核机制，将这些信息对客服共享，可以让用户获得更好的使用体验，对业务产生正向影响，同时因为敏感信息过多，设计好权限系统至关重要。
简述一下各个系统客服用途：
订单系统：订查询、取消、修改，根据业务流程提前介入订单履约环节 用户系统：查询用户信息，帮助用户处理封禁情况， 营销系统：查询活动内容，用户领用优惠券情况，发放优惠券 商品系统：商品信息查询、更新、库存维护 商户系统：商户信息查询、更新，系统使用答疑 支付系统：支付信息查询、开票、提现、资金冻结 风控系统：异常状态查询，内容审核进度查询，举报结果查询 数据中心：数据看板和分析支持 权限系统：客服部门内各角色权限控制 日志系统：客服操作日志写入、查询3. 对接方式设计
客服系统相比于其他业务系统有较为成熟的系统框架，市面上也存在较多SaaS服务商，比如环信、七鱼、udesk等等。因此我们系统对接方式先大致分为三方服务和公司内部系统对接，三方服务对接我们放入体量阶段判断中阐述（就是下一章节），我们本次先聊一下内部系统对接。内部系统对接有三种方式。
（1）去别人家做客
指通过页面按钮链接跳转到对方系统，可以用拼接URL或者携带ID参数等形式直接查询结果。好处是开发成本较低；弊端是一方面对客服人员在对方系统内的权限设置有要求，另一方面无法对客服需求做定制化产品把控力较低。
（2）把别人邀请到自己家
指通过接口调用将信息集成在客服系统，针对客服诉求做定制化开发，作为客服系统一部分存在。好处是产品把控力强可以最大限度满足诉求；弊端是开发成本较高，可能会有重复开发和产品边界问题。
（3）在自己家和别人家之间修条路
指通过双方的工单等协作工具传递信息。和前两种方式较为不同，此种方式适用于无法由客服闭环处理的业务场景，需要公司其他团队协作，同时需要对协作内容做系统留存的场景。
二、狭义客服产品
狭义客服产品指主要由客服团队使用的系统模块，即对如前的客服系统做更细致的描述，按客服架构分业务、管理和系统支持三部分描述。业务模式万万千，这部分介绍不涉及产品原型，仅对各个模块的核心功能及细节注意事项做强调。
1. 狭义产品框架
2. 各模块核心释义
总述：
（1）业务层核心目标：通过系统优化提升人员效率，产品为主
进入人工前，重点在提高机器解决率，通过智能机器人、自助服务等手段，减少人工介入比例。 进入人工后，重大在提升分配效率和人员处理效率，分配逻辑+信息整合，减少客服寻找信息消耗。（2）管理层核心目标：通过管理手段提升人员效率，管理为主，产品提供管理工具
分述：
（1）任务中心
任务引擎：
所有业务模块的核心产品逻辑，通过对节点的流转，满足各个模块中的队列分配和审批流，可以认为是相对中台化的建设。
任务分配三大逻辑，所有队列分配逻辑的基础，可根据具体场景使用或叠加维度变形使用
遇闲分配（多劳多得），指每个员工有分配上限，优先分配上限不足且当前处理量偏少员工 轮询分配（平均分配），指每个员工无分配上限，按员工排序轮番分配，不判断当前处理量 指定分配（指定对象），指根据唯一标识（员工ID）分配给某个指定员工处理任务分类，涵盖了各个一线组别需要处理的业务场景，包含人工和系统创建，对处理事项做记录，以及便于后续流转。
流转通知：
通过邮件、站内信、内部通讯产品（钉钉、飞书、企业微信）对重点事项触发通知
（2）呼叫中心/IM系统
弹屏页：
电话或IM消息接入时，员工屏幕弹出的信息整合页面，便于提升员工处理效率
历史记录：
通话录音和IM聊天记录，电话一般另配置语音转文本能力，便于后续分析和AI质检。
电话和IM异同：
呼叫模块是比较传统的处理方式，因为仅能满足对用户一对一沟通，效率较低，目前在一步步被IM取代，但是其中基础呼叫能力还是需要后续持续使用的。 IM系统因可以一对多处理问题现在被大多数公司使用，且通过智能机器人、自助服务等可以将更多简单事宜交由机器完成。 IM系统根据公司体量不同，除满足客服使用外，可以做中台规划，供给到服务商以及作为公司内部通讯工具使用，这部分我们在体量判断中举例说明。（3）投诉系统
赔偿计算器/赔款审批：
投诉是体验的最后一道防线，赔款是投诉系统的核心：赔偿计算器指对于标准缺陷场景制定赔偿标准，由赔偿计算器触发完整赔款流程，减少员工判断和操作风险，涉及不同的赔款金额，根据员工权限不同，触发到上一级审批，确保资金安全。
舆情监控：
通过第三方服务或自建舆情监控平台，及时感知外部舆情情况，联系相关信息发出者，减少外部负面评价。
（4）客服管理
人员、角色、组别信息配置：
组别信息决定人员归属那个版块，处理什么事务 角色信息决定人员的级别和权限 人员信息是员工的基本信息，除了用于日常工作，还作为绩效考核信息的基础现场监控/运营报表：
数据监控手段，前者用于现场管理员工实时工作情况使用，后者用于板块管理。排班/考勤/绩效：
客服为综合工薪制岗位，一般24小时或8:00-22:00覆盖，所以其中需要根据高低峰轮班 考勤为各个员工出勤和加班情况记录 绩效根据质检+计件+考勤+核心指标（好评率）对员工月度工作分级核算工资使用。（5）质量检查
质检配置：
根据具体情况制定抽检规则，按时（一般按天为周期）分配抽检任务给到质检组员工 初检、复检、疑议质检的三个环节，前两者指对同一内容需要判断两次保障公平，疑议指员工对质检结果有问题的部分，可以由其组长发起疑议再次处理。
（6）知识库/调查问卷
知识库主要是对流程的记录文件，方便员工查阅，同时可以和系统关联，在对应场景中显示其处理流程描述，通过浮窗或跳转等形式。 调查问卷主要是对用户发送问卷调查，回收用户反馈使用，或者也可以作为NPS评分使用。最后说两句
本节我们简单去阐述了广义和狭义的客服产品架构都包含哪些模块以及各个模块的功用，其中的每个模块都值得单独开一篇去细细琢磨，目前的篇幅只能做个目录索引。同时希望读到的同学除开这些描述以外，能体会到一些形而上的东西——产品设计中闪烁的人性关怀。
比如作为客服产品，去思考每个系统功能改进的背后是一个个我们的同学战友，在高强度的工作节奏下，在给用户提供情绪价值，那么我们设计逻辑的背后，也可以或者说需要去照顾他们的情绪诉求。另外比如在设计智能机器人的转人工流程时，兼顾效率和体验，坚持不让用户以放弃诉求为前提提升解决率，不将人工智能变成人工智障。
下节的体量判断我们结合本节的IM系统、权限系统举例，看看各个体量下的产品，用何种方式和途径实现功能更优。
本文由@小白方法论 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash, 基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
标签：
