今年私域流量大火，而微信成为了私域流量最好的转化平台，随之各种场景需求纷至沓来，其中在线客服系统场景的相关需求十分强烈。客服功能根据不同场景需求会有不同的业务模式，而模式的决定性因素主要都来自于商家的资源本身和业务侧重。
仅属于运营辅助需求的客服场景属于轻度需求，在功能设计上我们会把颗粒度放小，以好友和群成员为维度展示信息；而微信资源较多且对客服需求较为专业的公司我们需要搭建较为复杂的客服系统，将多个微信号私聊消息按照一定逻辑合理分配给客服人员进行消息处理。两种模式的设计目的都是为了让客服专注于自己关注的信息本身。下面我就从轻客服和专业客服两种模式分别介绍我们的产品设计：轻客服场景
运营为主，客服为辅，以下几点是该场景的用户特点：微信号资源较少，客服人员也较少；关注维度较细，群聊和私聊需要同时兼顾，侧重挖掘群内深层用户；没有固定服务时间，闲暇时才能关注信息；总结以上用户特点，在设计产品上我们大致分了两个方向：一是单号按群维度细分，二是多微信维度聚合操作；群维度的客服模块设计主要是帮助用户解决群消息太多无法定位有用信息的痛点；微信维度的客服模块设计主要是帮助用户多微信号聚合，在一个界面上统一操作和回复用户；下面是两种场景功能定位的逻辑架构：两种模式都增加了快捷回复和智能回复功能，这个功能会在文章的第三点智能客服篇章重点分析。基于微信平台搭建客服工具技术难度大、限制性强，难以根据需求搭建体验较好的客服系统；基于微信平台的专业客服系统运用场景比较小众，拓展性也差；微信本事是一款聊天工具，而客服系统本质上也是聊天工具，基于聊天工具重新定义聊天模式，大部分公司觉得没有市场。即使有种种限制原因，我们还是大胆一试，因为客服是微信运营生态圈必不可少的一环。将所有登录的微信号的客户聚合在一个池子内，当有客户消息接入系统后，不再按照微信号维度展示，而是按照一定的分配规则分发给不同的客服，客服回复后依然是以对应的微信号的身份回复给客户，即一个微信号背后存在多个客服人员。
这样就打破了一人一微信号的限制，登录的微信只是一个中转平台，而非真正的在线客服系统。在微信号资源十分庞大的情况下，程序也可以一个不漏的合理的将客户自动分配给客服团队。