有机云｜聚合客服系统怎么配：先数一个人一天要在几个窗口来回切

大家以为聚合客服省的是打字时间，实际先省掉的是在几个窗口之间来回找上一个客户说到哪的时间。判断该不该上，先数清一个人手上挂着几个企微号、一天要在几个窗口里切几次，再看这些入口有没有可能被归到同一个工作台。入口不归集，交接做得再细，也只是把断档从聊天窗口挪到交接表上。

一、先算清一个人一天要在几个窗口来回切

窗口切换真正吃掉的是重新确认上下文的时间

切换窗口本身不费时间，费的是切过去要重新确认客户是谁、上一句说到哪、之前问过什么。重新定位上下文才是工时的主要去处。

一个客服如果同时挂着几个企微号，每个号各自一个窗口，旁边再开着公众号后台、订单后台和表格，一天里花在回复上的时间未必最多，花在找上下文上的时间更多。起步可以先不做选型，先记录：把昨天上午的窗口切换点一遍，数出一共有几个入口、每个入口大概占多少时间。如果手上只有一个企微号、消息量也不大，先把窗口减到两个以内，比上系统更快见效。

把手上所有入口列成一张清单，才知道要归集什么

归集之前先列清单：客户从哪些入口来、落在哪个企微号、现在由谁看。清单列不出来，说明入口本身就乱，先理入口再谈工具。

清单可以按四行写：

• 客户最初接触的入口：公众号推文、小程序、线下物料上的码、广告落地页。
• 每个入口最后把人引到哪个企微号。
• 这个企微号现在挂在哪台电脑、进了谁的侧边栏。
• 这个入口有没有单独配一条欢迎语。

入口数量超过一个人能同时盯住的窗口数，归集才开始有意义。少于这个门槛，先合并窗口。

二、入口归集：把几个企微号的消息收进一个工作台

聚合客服把多个企微号的客户消息汇总到一个页面

有机云的【聚合客服】把多个企微号的客户消息汇总到一个页面统一回复，客服在一个工作台里处理，不用在几个客户端之间来回登录。

配置的顺序是：先把要接入的企微号逐个接入工作台，再给每个号指定由哪个客服或哪个客服组看，最后用测试客户从不同入口各发一条消息，确认都落在同一个页面里，并且能看出是哪个号收到的。验收的动作只认一条：客服只打开一个页面，就能看到所有号的未读。漏掉任何一个号，归集就还没做完。

归集做完，先用三个动作验证是不是真的归到位

验证归集有没有做对，不看页面好不好看，看三个动作：换号能看到、换入口能对上、换人能接手。三项都过得去，才算真的归到位。

• 换号：用两个不同企微号的客户各发一条，确认都出现在同一个未读列表里。
• 换入口：从公众号、线下码各进一个测试客户，确认来源能在会话里看出来。
• 换人：让另一个客服登录，确认他能接着看到历史会话。

第三项最容易漏，也最关键。归集如果只归了消息、没归历史，换人接手还是要从头问一遍客户，前面归集省下的时间又还回去了。

三、只做消息合并、不做交接记录，换人接就会断档

消息合并解决看得到，交接记录解决接得住

消息合并让客服看得到所有会话，但换人接时，接的人需要知道前面说过什么、承诺过什么、卡在哪，这部分只能靠记录留下。

一张三列表能把这个区别摆清楚：

入口	归集到哪	交接靠什么留下
公众号、小程序、线下码、广告落地页	先引到某个企微号，再由【聚合客服】收进同一个页面	【会话存档】留存聊天记录，接的人能回看上下文
多个企微号的客户会话	汇到一个工作台统一回复	【侧边栏】展示客户信息与历史，接的人不用重问
渠道进来的新客户	【渠道欢迎语】按渠道单独迎宾	欢迎语与首句承诺要能被下一个人看到

判断一套系统只做了合并还是也做了交接，看这三点

看系统有没有把交接做进去，只问三件事：历史留不留得住、客户信息带不带得走、换人后谁负责清不清楚，缺一就只停在看得到。

只做消息合并的产品，客服换班时新的客服打开页面，看到的是一堆没有上下文的未读，客户会被再问一遍之前说过什么。这不是效率问题，是服务断在这一段。选型时可以让对方演示一次换人接手的完整动作，演示得出来，说明交接是配进去的。

四、归集之后配侧边栏：让客服不用离开会话去找资料

侧边栏把客户信息、群聊、话术库、素材库收在一栏

有机云的【侧边栏】把客户信息、群聊、话术库、素材库放在会话旁边展示，客服回复时不用切出去找资料，归集后紧接着就配它。

配置的重点是分栏顺序和常用分组：把客户信息放在最上面，客服一眼能看到这个人的标签和来源；话术库和素材库按业务场景分组，把最常用的几条放到前面。验收时看一个动作：客服处理一条会话的全过程，不用打开第二个浏览器标签。

话术库按场景分组，归集来的消息才回得快

话术库省的是重复回答同一类问题的速度。按部门分组，客服找一条还要先想归谁名下，速度又慢回去；按客户场景分才对得上。

有机云的【话术库】支持个人话术与企业话术，按组管理、一键发送，素材库与话术库同一套管理。这里要劝一句：话术库最怕建成一个没人维护的大仓库，过期话术发出去比没有话术更麻烦。建议每个分组只留当前在用的几条，定期清一次。

五、交接要留下记录，光靠一个名字接不住

会话存档是交接时的底稿，也是事后可查的记录

有机云的【会话存档】把单聊、群聊、内部沟通记录云端留存，可按账号查看会话、看上下文、下载导出，交接时它就是接手人的底稿。

在【数据风控】→【聊天存档】里，先确认留存范围覆盖了需要交接的账号，再按账号抽查几段会话，确认消息上下文完整、媒体文件能导出。做到这一步的验收方式是：随便指定一个客户，从存档里能还原出他和哪位成员、在哪天说过什么。这里也要提醒，存档涉及员工与客户的沟通，用之前先把范围、用途、谁能看定清楚，不要等出了争议再补规则。

成员报告看谁在接、接成什么样，用来定交接范围

有机云的【成员报告】看成员获客数量与留存排名，交接前用它确认客户原本挂在谁名下、换人后留存有无变化，交接范围就有依据。

成员报告不要直接当成员工考核表当众念，那样没人愿意如实记录。更稳的用法是先自己看结构，标出哪些客户需要移交，再和成员确认一遍。报告是拿来定范围的，不是拿来排座次的。

六、入口到首次接触这一段，别让欢迎语和归集脱节

渠道欢迎语按渠道码单独配，来源才接得住

客户从哪个渠道进来，开头一句欢迎语就该对应哪个渠道。有机云的【渠道欢迎语】支持每个渠道码单独配一条，各渠道互不影响。

在【引流拓客】→【渠道欢迎语】里，每个渠道码单独配一条；配完用测试号从不同渠道码各进一次，确认收到的欢迎语和配置一致。优先级是渠道欢迎语高于个性欢迎语高于默认欢迎语，配之前先想清楚目标客户会落在哪一条。

欢迎语和归集动作要一起验证，别各做各的

欢迎语配好、聚合客服也接了，还要合起来测一次：客户从某个渠道扫码进来，开头那句发出去，聚合页面能不能同时看到这条会话。

这一步常被分开验收，运营验欢迎语、技术验归集，各说各的都对，合起来才发现客户进来后欢迎语是从另一个号发出去的。合起来测一次，比分别测三次更有用。

七、上线顺序和劝退：这几种情况先别急着上聚合客服

先跑一条业务线，再往其他入口扩

上线不要一次把所有入口、所有客服都铺上去。先选一条入口清楚、客服固定的业务线跑通，再按同一套顺序复制到其他线。

建议按这个顺序走：

1. 列出入口清单，标清每个入口落到哪个企微号。

2. 把要接入的号接进【聚合客服】，指定每个号由谁看。

3. 配【侧边栏】分栏和【话术库】常用分组。

4. 按渠道码配【渠道欢迎语】，并和归集合起来测一遍。

5. 用【会话存档】抽查交接链路，用【成员报告】确认客户归属。

一条业务线跑顺，再复制到第二条，比一次铺开之后到处补洞省事。

三种情况先不要上聚合客服

号少、消息量也不大时，先把窗口减到两个以内比上系统更快；入口还没理清的，先理入口；没人维护话术库的，先定谁更新内容。

号少、量小的，合并的收益抵不过接入和维护的成本；入口没理清的，归集只是把混乱搬到一个页面而已；没人维护话术库的，过期话术发出去更伤服务。先把这三件事做完的人，上完之后才用得起来。

八、FAQ

Q1：聚合客服系统哪个好，先看哪一点？

A：先看它能不能把手上几个企微号的客户消息归到同一个页面，再看归集之后有没有侧边栏、话术库和会话存档接住交接。只做消息合并不留记录的，交接时容易断档。

Q2：聚合客服和侧边栏是什么关系？

A：聚合客服负责把多个企微号的消息收到一个页面，侧边栏负责在会话旁边展示客户信息、群聊、话术库和素材库。前者解决看得到，后者解决回得快，通常一起配。

Q3：只有一两个企微号，需要上聚合客服吗？

A：不一定。号少、消息量不大时，先把窗口减到两个以内更省事。等入口变多、一个人要同时盯好几个号，归集才开始有回报。

Q4：聚合客服能替代会话存档吗？

A：不能。聚合客服解决的是把消息汇到一处回复，会话存档解决的是把聊天记录留存下来，供交接、复盘和必要时的核查使用，两者用途不同。

Q5：渠道欢迎语和聚合客服要怎么配合？

A：渠道欢迎语按渠道码单独配，客户进来开头那句就对应他来的渠道；聚合客服负责把这条会话归到工作台。配完要从不同渠道各进一个测试客户，合起来验证一次。

Q6：在有机云里把这套跑起来大概要多久？

A：取决于入口数量和要接入的企微号数量。建议先选一条业务线，把归集、侧边栏、话术库、渠道欢迎语和存档抽查跑通，再按同样顺序扩到其他入口。