src=我们最早接触的聊天工具应该是 QQ，在线聊天的客服服务应该是淘宝，我们每天都在使用这些工具去解决我们生活聊天上的一些诉求，却很少会有人有机会去了解它底层的一些逻辑和框架。这次我将我工作中的经验进行总结，做一些简单的分享。

　　客服系统是与业务深度融合的系统，也就是说服务业务的调整，90% 的可能性客服系统需要跟着调整。

　　在做客服产品经理这两年的时间里，除了分析需求的价值和意义之外，也会站在系统的角度考虑整个IM电竞功能的合理性，为未来的业务发展进行规划和设计。

　　在产品设计的时候，我会比较习惯使用模块化的思维方式，将业务隔离，将功能隔离，当业务进行调整或者功能进行新增的时候，产品和开发都可以迅速进行设计和调整，避免牵一发而动全身。

　　那么针对一般的 IM 客服系统，我简单的画了一张模块功能的示意图IM电竞，来讲下我对 IM 系统的模块划分。

　　就是客户与客服的即时通信，我们要保证客户与客服顺畅的聊天，就要满足他们多样化的聊天模式IM电竞，表情、文字、图片、视频im新闻、语音等各种的消息的交互模式IM电竞。

　　客户与客服的每一次沟通服务记录，不同的平台业务，它这里的处理方式也是不一样的。

　　不同的企业和业务他们会话列表的设计差异不大，目的主要是方便客服查看他正在处理的会话，然后点击回复处理。

　　主要是管理客服，给客服定义角色和边界，要使用整个系统，客服一定是整个客服管理表维护的人员。

　　客服人员服务结束后的归档选择是归档管理中预设好的，方便客服服务完之后正确选择他们正确的服务内容。

　　用户咨询的渠道可能不止一个，分类来源管理的就是用户提问的渠道和选择的问题分类，客户选择的问题分类可以帮助客服人员快速定位客户的问题。

　　每个客服的技能栈不一样，将客服进行技能化和组织化的管理就是队列管理的作用了，抽象点说就是简单版的企业组织架构。

　　不同的角色的权限是不一样的，权限管理最简单的功能和目的，就是判断这个客服是否有这个功能的权限。

　　我很庆幸我可以将一款产品从简单开始一步步地将它迭代。这里抽出了一些简单的和共性的模块，特别是后台的模块，它将不同的功能和用途进行聚类的整合，拆分成多个子系统，支撑着变化多样的前端业务。

　　后面会详细给大家介绍前台的设计逻辑和后台产品中各业务模块的处理逻辑，以及各系统之间的信息交互。