1. 客服IM是解决用户问题的入口和渠道

客服流量分布情况：

• 热线渠道：25%
• 在线渠道：75%
  • IM 33%
    • 智能机器人
    • 人工坐席
  • 其他，如自助

在IM渠道中，有机器人和人工服务2中服务方式，用户在IM页面中解决问题的流程为：

1. 用户进线
2. -> 机器人服务解决问题
3. -> 如果机器人解决不了就转人工，进入人工服务方式，和坐席实时沟通解决问题，知道和坐席沟通结束。

结论：IM是解决用户问题的重要渠道

2. 客服IM业务特殊性对系统能力和品质提出了要求

2.1 特殊性表现

toc:

• 在IM渠道内用户和机器人、交互场景多，交互复杂，如卡片按钮的点击、自助点击、赞踩、账单选择、表单交互等
• 问题的解决方案通过消息来承载和展示，表现为：类型多、迭代快，如卡片信息、订单信息、表单信息

tob：

• 需要去量化坐席的服务质量，如考核坐席的在线时长、回复超时率，都需要IM的数据支持
• 降本需求，降断线工单、降重复进线，都需要在IM链路上做改造支持

2.2 要求表现在

公司在大背景下，客服在这块主要是提高用户留存率

结论：对客服IM的要求为支持业务迭代的同时保证用户在IM渠道内的体验

3. 客服IM方向目标：能力扩展&品质提升

业务目标是：在IM渠道内进行能力的扩展来支持业务需求迭代，同时提高IM系统的品质来保证用户体验

3.1 能力扩展

通过对消息能力和会话能力的扩展来支持用户、机器人、坐席在IM渠道内进行更好、更流畅的交互，以此解决用户的问题

• 消息能力
  • 发送消息
  • 接受消息
  • 历史消息
  • 离线消息
  • 内容安全
• 会话能力
  • 单聊
  • 群聊

3.2 品质方面

• 基本要求：消息能力可靠
  • 消息不丢
  • 消息不乱
  • 消息不重
• 在实时性上，要保证系统链路的低延时，最后通过产出系统指标和系统sla来衡量IM系统的品质

4. 在原系统中继续迭代成为IM能力扩展和品质保证的最大瓶颈

在原客服IM系统中，IM能力在C端系统和坐席系统2个异构系统中分别实现，C端研发负责开发维护C端系统，工作台研发负责维护工作台系统，2者通过内部打通的方式，对用户、机器人、坐席输出同样的IM能力。

问题：

• 业务上线一个需求，开发成本大，迭代周期长，效率低
  • IM能力耦和在业务系统中，链路改造需要7个系统10个模块，投入5个研发，开发重复的工作，平均一个需求至少1周的时间
• 同时在异构系统无法保证IM的品质，缺少衡量系统品质的IM指标
  • 消息能力不可靠，反馈的case数量，3个月100+，平均一天至少一列
  • Im能力耦和在业务系统中，变更上线相互影响，存在稳定性风险

5. 解法：沉淀新系统：扩展IM能力，提高系统品质

具体做法为：将IM能力下沉，在新系统内，扩展IM能力，建设IM能力，提高系统品质，C端和工作台系统接入新IM系统，来实现IM能力并提供给用户、机器人、坐席。
这样做：

• 降低IM能力扩展成本
  • Im能力模块化，能力扩展&沉淀&业务接入周期降低
  • 研发人力成本下降：5人 -》2人
  • 链路复杂性降低：7系统10模块 -》 3系统5模块
• 系统品质提高
  • 做IM系统指标建设，看清系统品质，为系统优化做指导
  • 消息能力可靠，保证消息不丢、不重、不乱
  • Im能力和业务能力独立变更上线，互不影响，稳定性提高

6. 解法：新IM系统建设

6.1 定位

新IM系统的定位为：客服体系下IM能力提供的系统，支持业务接入和迭代，并向用户提供高品质的IM体验。

研发同学对IM系统进行系统建设，输出统一能力，C端系统、坐席工作台系统、质检、听音系统接入IM系统后，为用户、机器人、坐席提供IM能力。

6.2 建设路径

在Im系统内部分3个步骤建设：

• 接入层：负责IM能力的接入
• 逻辑层：负责IM能力的沉淀、扩展
• 数据指标层：沉淀数据，建设系统指标来看清IM品质，并为系统优化指导方向

7. IM接入层：负责业务方IM能力的接入，不参与能力沉淀

7.1 问题 & 解法

问题1: 多个接入方接入，如何进行管理
例如目前接入方有C端系统、坐席工作台系统、质检、听音系统，如何看清各接入方的流量，并做监控和限流降级，如何根据接入方快速排查问题

解法：对接入方统一管理，接入方在Im接入层注册唯一标识，标识在链路中传递

问题2: 各接入方的用户体系不一样，登陆鉴权方式不一致
例如滴滴c端用户用passport、坐席用sso、运营用sso

解法：接入层根据接入方做统一的登陆鉴权，屏蔽差异对用户做统一的登陆鉴权

7.2 收益

系统收益：
目前接入层完成的建设：

1. 接入方管理：注册、配置通过apollo平台实现，相应的限流、监控也完成
2. 接入了passport、sso、租户平台的账户体系登陆鉴权能力
3. 接入方可以使用IM sdk 快速接入，实现IM能力

业务收益：

1. 支持客服体系下业务系统快速接入，从周级 下降到 天级别
   1. 例如听音系统接入IM系统能力就1d就完成了接入
2. 沉淀了登陆鉴权的组件到T2团队toolbox，方便大家使用，降低了研发成本

8. IM逻辑层：负责沉淀和扩展IM的能力

8.1 基础能力

在IM逻辑层内部对能力进行了基础抽象，分为消息能力和会话能力2个大类，在这2个大类下能力进行平铺。

• 消息能力
  • 发送消息
  • 接受消息
  • 历史消息
  • 离线消息
  • 内容安全
• 会话能力
  • 单聊
  • 群聊

结论：通用能力逻辑抽象出来，统一通过Base处理器实现

8.2 差异化能力

如果不同接入方，有差异化逻辑，通过具体实现类实现

8.3 收益

系统收益：
目前完成建设：

1. 扩展新的IM能力，新增平铺处理器即可
2. 支持差异化能力通过扩展Base处理器即可实现

业务收益：
沉淀了20多项IM能力，支持了3个租户30条业务线。例如未读消息、消息已读未读、正在输入等

9. 品质提高

在系统品质上，做了消息的可靠性设计，提高了系统品质和用户在IM上的体验。

9.1 消息不重

通过msgId实现，msgId在sdk发送端生成，带入到整个链路中，接受方根据msgId做去重来保证消息不会重复。

9.2 消息不乱

通过msgSeqId实现，msgSeqId在im系统中存储时生成，在发送链路时实时返回给了发送方，同时在接受链路也触达了接受方，这样下来整个链路都能感知msgSeqId，通过对msgSeqId做排序保证消息不乱

9.3 消息不丢

• 发送链路：同步发送并实时响应
• 接受链路：通过推拉结合的方式

10. 收益 & 数据

业务收益：

• 沉淀了20项IM能力，支持了3个租户30条业务线
• IM可靠性保证，反馈case数 -》0
• 从0-1产出了IM系统指标

技术收益：

• 开发成本降低88%
• 交付周期降低60%

品质上：

• 在线消息触达成功率：99.99%
• 端到端触达延迟<1s
• 系统接口sla，2000QPS，99分位500ms

11. 后续规划

还是跟着业务规划走，具体为能力建设 & 品质提升

11.1 能力建设上

消息能力在微信生态上的建设，例如离线消息通过小程序的方式触达（背景： 在app下架期间，客服流量在微信渠道生态的流量占比65%， 小程序占比98%）

11.2 品质提升

• 稳定性提升
• 体验提升：弱网环境下IM能力优化

12 个人思考总结

• 作为客服体系IM系统owner，具备方案选型/取舍和系统架构设计/规划的能力
• 作为项目owner能推进新IM系统落地，保证高质量交付
• 负责客服IM后端系统开发，在Im领域积累了相关经验于思考
• 日常工作中，在技术方面能主动思考并沉淀对周围同学产生正向影响

附：Im系统指标数据

• IM消息每日新增数据量600W+ (app下架期间)
• 机器人服务方式下消息占比55%，人工服务方式占比45%
• 触达率
  • 用户消息触达率：99%
  • 坐席消息：96%
  • 系统消息：88%
• 实时触达率：99.95%
  • 1s触达率
    • 用户：96%
    • 坐席：90%
    • 系统：76%
  • 3min触达率
    • 用户：99.96%
    • 坐席：99.66%
    • 系统消息：99.41%
• 消息接口sla：2000QPS，99分位500ms

结论：

• 坐席相对用户来说长链接的状态更加稳定、在线时间更长，所以触达率和实时触达率更高
• 由于系统消息发送时的场景，用户已经离线，故消息触达率和实时触达率相对较低
• 在消息触达率提升方面，需要建设离线消息的推送能力
• 需要做弱网环境下的消息链路的优化

• ← Previous Post
• Next Post →