一个人管 20 家店，听起来像压榨，做顺了就是流程。多店铺的难处从来不是「忙」，而是忙得没有章法：不知道先回哪条、谁管哪家、交接给谁。这篇按顺序讲四件事：分组、排班、权限、口径，最后再说怎么把瓶颈找出来。
管 20 家店靠分组，不靠死扛
消息不会按店铺排队进来，它按时间砸过来。一个人如果按「看到哪条回哪条」的方式处理，20 家店就是 20 个互相打断的现场，再努力也只能顾上眼前几条。
分组的目的只有一个：让每一次切换都值得。常见的分法有两种。按平台分，把天猫的店放在一起、抖店放在一起——同平台的消息节奏与活动节点更接近，回复时不用反复换思路；按类目分，同一套商品知识、同一套话术，换店不换脑子。店铺多了以后，两种分法可以混着用。
分组还有一个附带好处：出问题的时候能快速定位。某一组店的差评集中爆发，大概率是这类目的话术或知识库有问题，而不是某个客服偷懒。没有分组，「哪里出了问题」只能靠猜。
这件事不必全靠脑子记。零九AI 的多平台聚合接待把所有会话收进同一个工作台：可以按平台、店铺、意向度筛选，未读与超时自动置顶——分组不只是管理动作，列表本身就替你把「该先看谁」排好了。
排班：按咨询高峰排，不按作息排
20 家店的咨询高峰不会落在同一个点上。直播店晚上忙，货架店白天忙，做批发的早上八九点最忙。所以排班表的第一版，应该照着咨询量的分布画，而不是照着「大家习惯几点上班」画。
一个够用的起点是三个班次：上午、下午、夜间。白天的两个班次按高峰偏移；夜间交给 AI 值守，常规问题照常应答，答不了的进转人工队列，排进第二天早上的待办。夜里的咨询不留到白天，这是排班能不能省人的关键一笔。
班次之间要留重叠时间。比如上午班到 13:00，下午班 12:30 就到，这半小时用来交接和消化上午的尾巴。不留重叠，待办、未回复的会话就全挤在换班的那几分钟里。另外，排班表不用一次排到完美：每周看一次数据，把班次往高峰挪半小时，一个月就能调到位。
排班表要写清楚三件事：每个时段谁在线、每个人盯哪几家店、超时多久算事故。写完别只发在群里——要落到系统里，子账号的接待权限就是按这张表设的。
子账号与交接班：会话跟着人走
多人协作的第一条纪律是权限分明：接待权限和可见范围按角色分配。谁负责接待、谁负责复核，工作台里一眼可见；谁在处理哪条会话，也不用在群里挨个问。
交接班是最容易漏的环节。口头交代「这单还在等回复」，人一忙就丢。系统里的交接班把未处理的会话自动转交给下一班，接手的人打开就是完整上下文，不用把前因后果再讲一遍。
这里有一个硬约束要提前算清楚：多人使用需要按席位数购买，同一个账号在两台电脑上登录会互相顶下线。这不是设置问题，是账号体系的规则——排班之前先把席位数定下来，别等上线第一天才发现不够。多人使用的细节，在帮助中心里有更细的说明。
快捷话术库：让口径先统一
20 家店如果各说各话，买家换一家店问同一个问题、得到两个答案，信任就是这么丢的。快捷话术库解决的是这件事：高频回答沉淀成模板、按场景分组，回复框里输入关键词就能调出来。
它的价值在第一天最明显：新人打开话术库，就能用统一口径回复，不用翻聊天记录找模板，也不用等老客服有空。话术库支持从 CSV 批量导入，场景名、话术内容两列即可，现有的话术本几分钟就能搬完。
话术库也需要维护：把每周出现的新问题补进去，把过期的活动话术撤下来。这件事交给一个人负责，比每人各自更新要靠谱——口径怕的不是少，而是乱。
话术库不是让每个人都照抄。模板给的是口径的底线，具体怎么说，可以有自己的语气。
另外，话术库与知识库是两套东西，别混着用：知识库喂给 AI，话术库留给人工；两份内容的语气可以不同，口径必须一致。
从预警到回看：每周花半小时
再细的排班也有漏网的会话，重要消息预警兜住它们：超时未回、投诉倾向、高意向三类会话优先提醒。漏掉哪一类，代价都直接。
每周再留半小时做数据回看。接待量与响应效率按店铺与客服拆开看：是某家店消息量特别大，还是某个人总在某个时段掉链子。瓶颈经常不在人手，而在某一家店的知识库没配好，问题全压给了人工。
售后的部分也有人接。同一个买家的售前咨询与售后请求连在同一条记录上，不用客户再解释一遍，交给售后管理系统接力处理。
顺着这个顺序走，一周之内就能跑起来：
- 先分组：按平台或类目把店分好，把子账号权限一次配到位；
- 再排班：按咨询高峰画班次，夜间交给 AI 值守；
- 然后统一话术：把高频回答导入话术库，给新人一份统一口径；
- 最后开预警与数据回看：每周半小时，找出真正的瓶颈。
一个人管 20 家店不是目标，少漏一条消息、少一次来回切换，才是。