坐席从 50 扩到 200：呼叫中心扩容最容易低估的四件事

接到扩容需求时，第一句话通常是「我们要从 50 个坐席加到 200 个，报个价」。报完价之后，真正的项目才开始——因为许可证是整个扩容里最容易解决的一项。

一、并发与中继：坐席数不等于话务量

话务量不随坐席数线性增长，它取决于峰值时段的呼叫到达率、平均通话时长和话后处理时长。200 个坐席意味着峰值可能有几十路同时呼入，中继数量不够，表现就是高峰期忙音——坐席空着，电话进不来。这件事必须按话务模型算，不能按坐席数乘一个系数。

二、录音与存储：不是买硬盘的事

全员全程录音是政务和金融项目的硬要求。按每天八小时、每个坐席一段录音的体量累加，一年下来是几十 TB 级的规模。这里的关键不是买硬盘，而是买 IOPS、买备份策略、买检索能力。

录音还有一个更实际的问题：能不能按工单号、按客户号码、按时间片段检索。如果录音只是躺在磁盘上，质检和投诉溯源都用不上，等于只满足了「有存」这一条。

三、IVR 层级：每多一层多一次挂机

50 个坐席时，语音导航可以做得比较深，因为业务线少、用户也熟。200 个坐席时，主菜单每多一项、层级每多一层，都是一次额外的挂机机会。经验值是主菜单不超过四项、层级不超过三层，并且任意层级都能按 0 转人工。

四、质检抽样：百分之三不够用了

人工抽 3% 在 50 坐席时勉强可行，200 坐席时样本量已经不足以发现低频但高风险的问题。可行的做法是先做全量转写，用关键词与情绪规则筛出命中项，人工只复核命中的那部分——抽样的对象从「通话」变成「疑似问题」，效率完全不同。

三个隐性变化

还有一个隐性的变化：技能组。扩容前可能只有售前、售后两个组，扩容后会拆成六七个，路由规则的数量是乘出来的。溢出规则、借调规则、跨组排队规则都要在上线前定清楚，否则高峰期会出现「有人闲、有人排队」的怪现象。

坐席终端的性能也常被略过。扩容后一个坐席可能同时开客户管理、工单、知识库、质检四五个页面，还要挂软电话。如果终端内存和网络带宽还按老标准配，表现就是点一下卡一下，坐席自己会算出一套绕开系统的办法，数据就开始失真。

网络这块要单独说。语音是实时流，对抖动和丢包比网页敏感得多。200 坐席的办公区，如果把语音和办公网混在一条链路上，午休时段视频流量一冲，通话质量立刻下降。可行的做法是语音走独立网段并做 QoS 优先级，成本不高，效果立竿见影。

灾备是另一个容易被推迟的议题。50 坐席时系统挂了可以临时用手机接，200 坐席时没有这个选项。至少要有中继的冗余路由和一套可切换的备用接入，哪怕备用容量只有主用的三成，也能撑过抢修窗口。

最后是割接方式。扩容不建议一次性全量切换，按技能组分批更稳：先切一个业务量适中的组，跑一周看接通率、通话质量、工单流转，再逐步放大。分批的代价是多花两周，收益是出问题时影响面可控。

验收看峰值，不看平均

扩容项目的验收指标应该是峰值小时接通率，而不是平均接通率。平均值会把最糟的那一小时藏在里面——而那一小时，恰恰是客户记住你的那一小时。