免费工具 在线客服排班计算器：客服排班表每小时要几个人
在线客服一个人能同时接两三个会话，照搬电话客服的公式算，人数会多出好几倍。把每小时进来多少咨询、每个会话聊多久、一个人同时接几个填进来，就能得到全天每小时的排班人数表。
- 按并发接待算
- 每小时排班人数
- 本地计算
在线客服每小时排班
示例是一家 09:00–23:00 营业、晚上 8–10 点最忙的电商店铺，数字都是示例；换成你们客服报表里的分时数据即可。
一个小时内新开始的会话。
一行一个小时：20:00 110。也可以只写一串数字，如 12, 30, 45（正好 24 个时按 0–23 点读）。每行按 1 小时算。
从客服接入到会话结束，按你们平时的并发数统计。6 或 5:30。
一名客服同时最多接几个会话。
新会话最多等多久要有客服接入。
例如 80 = 80% 的会话在时效内被接入。
带薪但不能接待的时间：休息、开会、培训、请假。
需要在线客服
—
在线、正在接待的人数。
需要排班人数
—
扣掉损耗后，向上取整。
时效内接入
—
占新会话的比例。
平均等待接入（秒）
—
所有会话的平均。
接待位占用
—
客服接待位平均有多少在用。
高峰排班人数
7
最忙的那个小时。
全天人·小时
59
每小时排班人数相加。
全天会话数
975
多一个人、少一个人会怎样
绿色为达标。
每小时排班
工作量 = 平均同时进行的会话数（会话数 × 时长 ÷ 60 分钟）。
| 时段 | 会话数 | 工作量 | 在线客服 | 排班人数 | 时效内接入 | 平均等待 |
|---|---|---|---|---|---|---|
| 09:00 | 30 | 3 | 2 | 3 | 99.0% | 932 毫秒 |
| 10:00 | 55 | 5.5 | 3 | 4 | 99.2% | 668 毫秒 |
| 11:00 | 70 | 7 | 3 | 4 | 95.3% | 4.51 秒 |
| 12:00 | 50 | 5 | 2 | 3 | 85.8% | 20.1 秒 |
| 13:00 | 45 | 4.5 | 2 | 3 | 91.4% | 10.7 秒 |
| 14:00 | 65 | 6.5 | 3 | 4 | 97.1% | 2.54 秒 |
| 15:00 | 70 | 7 | 3 | 4 | 95.3% | 4.51 秒 |
| 16:00 | 60 | 6 | 3 | 4 | 98.4% | 1.35 秒 |
| 17:00 | 50 | 5 | 2 | 3 | 85.8% | 20.1 秒 |
| 18:00 | 40 | 4 | 2 | 3 | 95.3% | 5.31 秒 |
| 19:00 | 65 | 6.5 | 3 | 4 | 97.1% | 2.54 秒 |
| 20:00 | 110 | 11 | 4 | 5 | 91.3% | 8.25 秒 |
| 21:00 | 130 | 13 | 5 | 7 | 96.6% | 2.57 秒 |
| 22:00 | 95 | 9.5 | 4 | 5 | 97.3% | 2.14 秒 |
| 23:00 | 40 | 4 | 2 | 3 | 95.3% | 5.31 秒 |
分享这组输入：数值写在链接的 # 后面，不会发到服务器。
https://tapcub.com/zh/tools/chat-staffing-calculator
版本 v1.0更新于 更新记录
这张表在告诉你什么
每个小时单独计算，所以这张表就是一条人数曲线，班次照着它铺。
工作量
每小时会话数 × 平均时长 ÷ 60：同一时刻平均有几个会话开着。130 个 6 分钟的会话 = 同时开着 13 个。
在线客服
接待位（人数 × 并发数）能让目标比例的会话在时效内接入的最少人数。示例 21:00 是 5 人，即 20 个接待位。
排班人数
在线人数 ÷（1 − 损耗率），向上取整。全天加起来就是人·小时，再按班次长度铺满每个小时。
接入和等待
接入是客服把会话接过来的时刻。访客看到的首响时间还要加上阅读和打字的时间，所以总会长一点。
这是近似算法：把每名客服看成几个互不影响的接待位，再对这些接待位套 Erlang C。它没有考虑同时接得越多每个会话越慢、分配不可能绝对均匀、访客等不及就走、AI 已经回答掉一部分咨询。
从客服报表到排班表
需要从历史会话里取三个数，再做一个决定。
-
1
拿到分时咨询量
导出一个典型日（或几个周一的平均）每小时新会话数，粘进来。大促日单独算一份。
-
2
按实际并发统计时长
用客服在平时并发数下，一个会话从接入到结束的平均时长。并发越高，时长越长。
-
3
定并发和时效
定一个人最多同时接几个、新会话多快必须接入。
-
4
铺班次
填上损耗率，看每小时的「排班人数」，把早班、中班、晚班铺上去。可以对比并发 3 和 4 的差别。
对「接待位」套 Erlang C
在线客服不是电话排队：一个客服开着 3 个会话，就像 3 条各自独立释放的「线」。所以计算器数的是接待位，不是人。
- 每名客服 = 并发数个接待位；一个会话从头到尾占一个接待位
- 只有所有接待位都满了，新会话才要等（M/M/m 排队，m = 人数 × 并发数）
- 没考虑：并发高时回复变慢、分配不均、访客中途离开、AI 接待的会话
- 分时表的每一行是一个小时，小时内咨询速度视为不变
工作量（接待位 Erlang）
A = 每小时会话数 × 时长（秒）÷ 3,600
130 × 360 ÷ 3,600 = 13
N 名客服的接待位
m = N × 并发数
5 × 4 = 20
时效内接入比例
SL = 1 − C(m, A)·e^(−(m − A)·t ÷ 时长)
5 人 → 20 秒内接入 96.6%
排班人数
排班 = ⌈N ÷ (1 − 损耗率)⌉
⌈5 ÷ 0.8⌉ = 7
同样的咨询量，并发数不同
一小时 100 个会话，每个 6 分钟（平均同时开着 10 个），目标 20 秒内接入 80%，损耗 20%。示例数字。
| 每人同时接待 | 在线客服 | 接待位 | 20 秒内接入 | 排班人数 |
|---|---|---|---|---|
| 1 | 14 | 14 | 86.1% | 18 |
| 2 | 7 | 14 | 86.1% | 9 |
| 3 | 5 | 15 | 92.3% | 7 |
| 4 | 4 | 16 | 95.9% | 5 |
从一次接一个到一次接四个，纸面上排班从 18 人降到 5 人。但同时接得越多，每个会话聊得越久；请用计划并发数下实测的时长再算一遍。
在线客服排班常错在哪
多数错误来自把在线客服当电话客服，或者把并发数当成免费的倍数。
直接用电话的 Erlang C
把每个客服当一条线，忽略并发接待，人数大约多算两到三倍。
时长和并发数对不上
一对一 6 分钟能聊完的会话，同时开 3 个时可能要 9 分钟。用计划并发数下实测的时长。
按全天总量排班
网站咨询跟着流量走：午休、晚上、推送和直播之后都会冒尖。要用分时曲线，不要用全天总数。
把 AI 已解决的会话也算进去
AI 助手独立回答并结束的会话不会到客服手里。排班前先从咨询量里扣掉。
这些输入，从你自己的客服数据里来
TapCub 在线客服和统计用同一段代码，下面这些正是这个计算器要用的数。
在线客服需要几个人怎么算？
先算工作量：每小时会话数 × 平均时长 ÷ 60 分钟，再除以并发数得到下限。然后留出让会话很快被接入的余量（排队模型算的就是这部分），最后除以（1 − 损耗率）。
一个客服同时能接几个会话？
常见是两到三个，取决于问题复杂度和打字速度。往上调时盯着首响时间和满意度：超过某个点，每个会话都会变慢。
为什么不能直接用 Erlang C？
Erlang C 假设一个人一次处理一个来电。开着 3 个会话的客服更像 3 个接待位，直接套 Erlang C 会多算人。这个计算器是对接待位套 Erlang C。电话和工单请用 Erlang C 话务量计算器。
这个模型忽略了什么？
并发越高会话越慢、分配不可能完全均匀、有些访客等不及就走、AI 可能回答掉一部分。把结果当起点，上线后再对照实际首响时间调整。
接入时效和首次响应时间是一回事吗？
不是。接入是客服接过会话；首次响应是访客看到第一条人工回复。中间差的是阅读和打字时间，打字测试可以测其中一部分。
每小时人数怎么变成排班表？
把「排班人数」一列加起来得到人·小时，再按你们的班次长度（比如 8 小时、早中晚三班）铺到曲线上，保证每个小时不少于表里的人数，高峰时段让班次重叠。