CloudCruiser1. 为什么“多开窗口”不是解决排队的万能钥匙
先从一个我亲身经历的场景说起。有次陪家人去银行办业务，工作日下午三点半，大厅里坐满了人，取号机上显示的当前号码是C108，而柜台屏幕上才叫到C089。等候区里一个背着双肩包的小伙子有点坐不住了，走到大堂经理面前问：“后面还有二十多个人，能不能多开一个窗口？”大堂经理解释说今天有三个柜员在岗，其中一个还在处理对公业务，暂时没法增开。小伙子显然不满意这个回答，嘟囔着“每次来都要等这么久”，转身坐回座位继续刷手机。
这个场景我见过太多次了。客户觉得“多开窗口就能解决”，管理者觉得“明明已经排了足够多的人手”，两边都很委屈。但真正的问题在于：排队这件事本身是有随机性的，靠拍脑袋定窗口数量，永远会在“人多了排队”和“人少了浪费”之间反复横跳。
这就是排队论真正发挥作用的地方。排队论是以数学方式研究“顾客到达—排队等待—接受服务—离开”全过程的理论工具，最早可以追溯到20世纪初丹麦数学家Erlang对电话交换系统的研究。他用一套概率模型算清楚了一个问题：对于随机到达的电话呼叫，交换机到底需要配备多少条线路，才能让相当比例的呼叫不用等待。这套思路后来被广泛应用到银行、医院、呼叫中心、机场安检、仓库物流甚至计算机系统的性能评估中。
服务质量评估这个课题，本质上就是在问三件事：客户要等多久才轮到？系统要有多大的容量才能接住这些客户？今天这个服务配置到底能不能达到承诺的SLA？这三个问题，排队论都能给出一个明确的、可计算的回答，而不是靠“感觉”或“经验”来拍板。
这篇文章不是要讲纯理论推导，而是想用一套完整的实操框架，把排队论和服务质量评估之间的那条线打通：从建模开始，到指标选择，到实例计算，再到数据采集的坑和后续行动决策。不管你是银行网点运营负责人、医院门诊管理者、呼叫中心排班员，还是做系统容量规划的工程师，里面这套思路都可以直接套用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 建模前必须搞懂的四件事
排队论再漂亮，建模思路错了，后面的计算全白搭。我见过太多人把公式背得很熟，但一到实际场景就套错模型，问题几乎都出在同一处：对系统里的几个核心要素没有先想清楚。这四个要素是到达过程、服务时间、服务台数量、队列结构。
2.1 到达过程：客户来得有多随机
排队论里最常用的到达过程是泊松过程。这个概念听着吓人，其实意思很朴素：客户到达彼此独立，不会因为前面来了一个人就影响后面一个人；在很短很小的时间段内，到达概率和这个时间段的长度成正比；两个或多个客户几乎不可能在完全同一瞬间到达。满足这三个条件的单位时间到达人数，就服从泊松分布。
为什么大家都爱用泊松过程？因为大量现实场景确实符合这个规律。超市收银台的顾客、客服电话的来电、医院门诊的挂号，如果按某个固定时段来看，到达间隔基本都是服从指数分布的——也就是那种“短间隔很常见、长间隔偶尔出现”的形态。这也是M/M/1、M/M/c这些经典模型里，第一个字母M的由来。
但要注意，泊松过程有一个隐含前提：到达率λ是稳定的。现实中很多服务场景有明显的峰谷时段，比如银行上午十点和下午两点是高峰，中午相对冷清。这时候直接把全天数据揉在一起算平均到达率，算出来的结果毫无意义。正确做法是分时段建模，把上午、中午、下午拆成互不干扰的独立时段，分别估计各自的λ。这一点后面还会展开讲。
2.2 服务时间：快慢波动的规律
服务时间分布决定了模型里的第二个字母。如果服务时间服从指数分布（即大多数客户很快就办完，极少数客户耗很长时间，分布呈长尾），模型标为M；如果服务时间是常数或接近常数，比如自助缴费机每次操作几乎都是固定时长，模型标为D；如果是任意分布，标为G。
很多人一上来就直接默认服务时间是指数分布，这是最容易出错的地方。指数的特点是方差大，等于均值的平方，换算成变异系数（标准差除以均值）就是1。但现实中的服务时间变异系数经常小于1，甚至只有0.3到0.5，说明服务时长波动没那么大，均值附近更集中。这时候用M/M/c模型会高估等待时间，给出的建议就会偏向“过度配置”。
判断服务时间分布的最简单办法：收集一段时间内每个客户的服务时长，算出均值和标准差。如果变异系数明显偏离1，就得考虑M/G/c模型，或者干脆用仿真来算，硬套M/M/c公式会失真。
2.3 服务台数量与队列结构
第三个字母后面加一个数字，表示服务台数量。M/M/1是单服务台单队列，M/M/c是多服务台共享一条队列。区别很关键：一个窗口一个队，还是多个窗口一条队？
说实话，单队列多服务台（M/M/c）的体验远好过多队列单服务台，因为单队列能天然实现“先到先服务”，不会出现你排的这条队特别慢、旁边那条队一直往前走的情况。这也是为什么银行、医院、政务大厅现在都推排队叫号系统——把物理柜台抽象成一条虚拟队列，客户只需要取一个号，剩下的交给系统分配。
但单队列多服务台也有前提：这个队列必须是FIFO（先进先出），且客户不会因为等待过久中途离开。如果有客户等了十分钟不耐烦走了，这个系统就不完全是标准M/M/c，得考虑顾客流失率，模型复杂度立刻上升。
2.4 Kendall符号：一张图读懂系统类型
我习惯把Kendall符号理解为排队系统的“身份证”。完整形式是A/B/c/K/N/P，其中A是到达间隔分布，B是服务时间分布，c是服务台数，K是系统容量，N是顾客总体规模，P是排队规则。平时用得最多的是前面三个，简写为A/B/c。
比如M/M/1：客户到达间隔服从指数分布（即到达为泊松过程），服务时间指数分布，1个服务台。M/M/3就是3个服务台共享队列。M/D/1则是顾客随机到达但服务时间是常数，自助设备和自动化流程经常用这个模型。
搞清楚这个符号，一大好处是沟通的时候不会产生歧义。你说“我们系统是M/M/2，容量有限，排队规则FCFS”，对方立刻就知道你在描述什么系统，甚至不用多解释参数。这套语言是跨行业的通用语言，我在和呼叫中心团队、医院信息科、零售运营部的人沟通时，都能靠这串符号快速对齐信息。
2.5 两条最基础但最关键的公式
第一个是Little定律：L = λ × W。这个公式在任何稳态排队系统中都成立，系统里的平均客户数等于平均到达率乘以客户在系统里平均逗留时间。它好用在于不依赖具体分布假设，无论M/M/1还是M/G/c都适用。我平时估算吞吐量、反推系统容量时经常拿它先算一笔粗账。
第二个是利用率公式：ρ = λ / (c × μ)，其中μ是单个服务台的服务率。当系统进入稳态的前提是ρ必须小于1，否则客户到达速度超过服务速度，队伍会无限膨胀。这个约束简单到有点不起眼，但很多人忽视它。有位做呼叫中心的朋友曾经跟我说，他们某个时段平均来电率高于接听能力，所以队列时长持续往上飙，怎么优化话术都没用——后来把时段排班加了一个人，问题立刻缓解。这就是ρ > 1导致的不稳定状态。
这两条公式是我在任何建模工作里首先要算的，先判断系统稳不稳定，再谈具体指标优化。
3. 服务质量评估指标：先分清谁是甲方
服务质量评估最忌讳的是指标一锅炖。排队论能算出来的指标很多，但不加筛选全部展示出来，管理者和决策者根本记不住。我习惯把指标分成两个视角：客户视角和运营视角。客户关心的是“我要等多久”，运营关心的是“资源用满没有”。两个视角的指标经常相互矛盾，评估框架要把它们的优先级说清楚。
3.1 客户视角：等待时间与服务水平
客户视角的核心指标有三个。
平均等待时间Wq：客户从进入队列到开始接受服务的平均时长。这是最常被引用的一个数，但也是最容易被误读的一个数，因为平均值掩盖了尾部风险。平均等待3分钟，听起来还能接受，但如果有10%的客户要等15分钟，这批客户的体验其实已经崩了。
平均逗留时间W：客户从进入系统到接受完服务离开的平均总时长。这个指标反映的是客户完整的服务体验，包括了排队加办理全程。
服务水平：等待时间不超过某个阈值的概率，也就是P(Wq ≤ t) ≥ target。这是呼叫中心和银行最常用的服务水平定义，比如“90%的电话在20秒内接通”“95%的客户在5分钟内叫到号”。这个指标比单纯的平均值更有业务意义，因为SLA承诺的是概率而不是均值。
客户视角的评估一定要围绕这三个指标来展开，而且一定要落在“满足某个目标”上，不能只报一个平均数。平均等待2.6分钟的网点，可能只有82%的客户5分钟内叫到号，如果公司SLA要求是95%，那就是不达标。
3.2 运营视角：利用率、队列长度、忙期
运营视角侧重资源效率。系统利用率ρ是最直观的指标，它表示服务台有多忙。但利用率不是越高越好，因为当利用率接近1时，等待时间会急剧恶化。这就像高速路，流量达到90%容量时，一个事故就能让整条路堵死，而且恢复时间极长。
队列长度Lq同样重要。队列过长不只是客户体验问题，候检区座位不够、停车位不够、等候区拥挤，这些物理空间的代价也是成本。在现实中，Lq超过一定阈值之后，客户流失率会快速上升。
还有一个容易被忽略的指标是忙期分布——服务台连续工作不间断的平均时长。这个指标对人力资源排班有意义，连续忙两个小时和断断续续忙两个小时给人的疲惫感完全不同，这在排班时应该被考虑进去。
3.3 指标联动案例：一个指标好了另一个就坏了
做服务质量评估时一定要明白，指标之间是联动的，不是独立的。利用率往上走，等待时间也往上走；等待时间降下来，利用率通常会跟着掉。所以我一直强调：评估报告里不能只给一组数字，要把指标之间的关系讲清楚，让决策者看到“你要什么”和“你愿意付出什么”之间的权衡。
举个例子，一个服务系统目前利用率80%，平均等待2.6分钟。如果运营目标是要把平均等待压到1分钟以内，通过调整服务台数量你会发现，可能需要牺牲十个点的利用率，这意味着人手成本上升。这就是服务质量评估最有价值的地方：不是告诉管理者“你不行”，而是告诉管理者“你要达到目标，需要多少资源”。
3.4 SLA怎么写才合理
很多团队的SLA写得非常随意，拍个数字就上墙了，完全不过脑子。比如“客户平均等待不超过5分钟”，这句话就有问题：是平均值不超过5分钟，还是95%的客户不超过5分钟？两种口径对资源配置的要求完全不同，前者在当前配置下可能已经达标了，后者可能需要加人。
我的建议是SLA按分位数写法来定义，比如：95%的客户等待时间不超过6分钟，85%不超过4分钟。这样既保证了大部分客户的体验，又给特殊业务留出口子，而且可以用排队论公式直接校验。
另外SLA的设定要和成本挂钩。把SLA从“95%不超过6分钟”提升到“95%不超过4分钟”，通常意味着至少增加10%到15%的窗口资源。评估报告里把这些对应关系写清楚，决策流程会顺畅很多。
4. 用M/M/c模型算一笔完整的账
公式和指标聊了一堆，现在用一个完整的实例把整个流程走一遍。这个例子我选用一个典型的社区银行网点，因为它结构简单、参数直观，适合做完整的演算，而且计算结果能直接对应到“要不要多开一个窗口”这个经典决策。
4.1 场景与参数设定
假设某个社区银行网点在下午高峰时段，客户平均到达率λ = 60人/小时，也就是大约每分钟来一位客户。每个柜员平均每小时能服务μ = 25位客户，也就是服务一个客户平均需要2.4分钟。当前开设有3个现金柜台，即c = 3，按单队列叫号模式运行。
先把基础参数算出来。强度a = λ / μ = 60 / 25 = 2.4，系统利用率ρ = a / c = 2.4 / 3 = 0.8。利用率80%，这意味着柜员在高峰时段大约有五分之一的空闲时间，但80%的利用率在排队论里已经不算低了，后续的等待时间会开始变得敏感。
4.2 计算过程
M/M/c模型的第一步是求系统空闲概率P0，也就是所有服务台都没有客户在服务的概率。公式是：
P0 = [Σ(n=0到c-1) a^n / n! + a^c / (c! × (1-ρ))]^(-1)
代入数字：
- n=0：1
- n=1：2.4
- n=2：2.4² / 2 = 2.88
- 前三项累计：1 + 2.4 + 2.88 = 6.28
- 最后一项：13.824 / (6 × 0.2) = 11.52
所以P0 = 1 / (6.28 + 11.52) ≈ 0.0562，也就是5.62%。
P0有了，后面的指标就都能算：
平均队列长度Lq = P0 × a^c × ρ / [c! × (1-ρ)²] = 0.0562 × 13.824 × 0.8 / (6 × 0.04) ≈ 2.59人。
平均等待时间Wq = Lq / λ = 2.59 / 60小时 ≈ 2.59分钟。
平均逗留时间W = Wq + 1/μ = 2.59 + 2.4 ≈ 4.99分钟。
系统内平均客户数L = Lq + a = 2.59 + 2.4 ≈ 4.99人。
客户需要排队等待的概率，也就是到达时至少一个柜员忙碌的概率，P_wait = P0 × a^c / (c!×(1-ρ)) ≈ 0.647。大约有64.7%的客户到网点后需要排队，只有约35%的客户能直接走到柜台前办理。
4.3 如果多开一个窗口
现在回答那个经典的灵魂拷问：如果4个窗口开着，会怎么样？
设c = 4，ρ = 2.4/4 = 0.6。重新算一遍：
P0 = 1 / (1 + 2.4 + 2.88 + 2.304 + 33.1776/(24×0.4)) ≈ 0.0831。
Lq = 0.0831 × 33.1776 × 0.6 / (24 × 0.16) ≈ 0.43人。
Wq = 0.43/60小时 ≈ 0.43分钟，约26秒。
W ≈ 2.83分钟。
把结果放一起对比：
| 指标 | 3个窗口 | 4个窗口 | 变化 |
|---|---|---|---|
| 系统利用率 | 80% | 60% | -20个百分点 |
| 平均队列长度 | 2.59人 | 0.43人 | -83% |
| 平均等待时间 | 2.59分钟 | 0.43分钟 | -83% |
| 平均逗留时间 | 4.99分钟 | 2.83分钟 | -43% |
| 等待概率 | 64.7% | 28.7% | -36个百分点 |
数字摆出来，结论一目了然。多开一个窗口，平均等待时间从2.6分钟直接压进半分钟以内，等待概率从接近三分之二降到不到三分之一。但代价是系统利用率从80%掉到60%，也就是说第四个窗口在高峰时段实际忙的时间只有60%，闲的时间达到40%。
4.4 用服务水平来判断要不要加
光看平均等待时间还不够，再套用服务水平指标做一次校验。假设公司的SLA要求是：95%的客户从取号到被叫到柜台，等待时间不超过5分钟。
M/M/c模型里等待时间超过t的概率近似为：P(Wq > t) = P_wait × e^(-c × μ × (1-ρ) × t)。
3个窗口时：P_wait = 0.647，c×μ×(1-ρ) = 3×25×0.2 = 15，t = 5/60小时，算下来e^(-1.25) ≈ 0.287，所以P(Wq > 5分钟) ≈ 0.647 × 0.287 ≈ 0.185。也就是说，5分钟内叫到号的客户比例只有81.5%，离95%的SLA目标差得很远。
4个窗口时：P_wait = 0.287，c×μ×(1-ρ) = 4×25×0.4 = 40，e^(-3.33) ≈ 0.036，所以P(Wq > 5分钟) ≈ 0.287 × 0.036 ≈ 0.010。5分钟内叫到号的比例接近99%，远超SLA。
到这里决策就很清晰了：在3个窗口的配置下，SLA根本不达标，4个窗口虽然消耗了更多柜员工时，但换来的是SLA从81.5%跳升到99%。这时候“要不要加人”就不再是个拍脑袋的问题，而是一笔有明确投入产出比的计算。
4.5 用Python脚本把计算固化下来
解析公式算一次可以，算十次就累了，而且手算容易出错。我建议把计算流程固化成一个小脚本，每次输入λ、μ、c三个参数，直接输出全套指标。下面这个是我自己常用的版本：
python复制import math
def mmc_metrics(lam, mu, c, target_min=5):
a = lam / mu
rho = a / c
# 检查稳态条件
if rho >= 1:
raise ValueError(f"系统不稳定: rho={rho:.2f} >= 1")
# P0
sum_part = sum(a**n / math.factorial(n) for n in range(c))
last_part = a**c / (math.factorial(c) * (1 - rho))
P0 = 1 / (sum_part + last_part)
# 核心指标
Lq = P0 * a**c * rho / (math.factorial(c) * (1 - rho)**2)
Wq = Lq / lam
W = Wq + 1 / mu
L = Lq + a
P_wait = P0 * a**c / (math.factorial(c) * (1 - rho))
# 服务水平: P(Wq <= target_min)
prob_over = P_wait * math.exp(-c * mu * (1 - rho) * target_min / 60)
svc_level = 1 - prob_over
return {
"rho": rho,
"P0": P0,
"Lq": Lq,
"Wq_min": Wq * 60,
"W_min": W * 60,
"L": L,
"P_wait": P_wait,
"service_level": svc_level
}
# 示例: 3个窗口
res3 = mmc_metrics(60, 25, 3, target_min=5)
for k, v in res3.items():
print(f"{k}: {v:.4f}")
脚本跑完，3窗口和4窗口的对比一目了然。我平时做评估时经常几分钟内用类似脚本跑完所有候选配置，把结果汇总成一张对比表，再拿去做决策汇报。比手动敲Excel公式效率高得多，而且可以反复调整参数做敏感性分析。
5. 数据采集与参数估计里的五个坑
模型再精确，参数输入错了，输出全是垃圾。这个道理做数据分析的人都知道，但在排队论项目的实操中，数据采集的坑比想象中多得多。我自己踩过好几个，也看别人踩过，下面一一列出来。
5.1 平均到达率掩盖了高峰期
最典型的错误是把一个营业时段内的所有到达人数加起来，除以总小时数，得到一个平均到达率，然后直接套公式。这样做的问题显而易见：如果上午十点到十一点到达率是90人/小时，下午一点到两点是30人/小时，平均下来可能是60人/小时，但用60人/小时建模得到的结果，对上午这个高峰时段完全无效，因为系统在上午可能已经过载了。
这个问题的解法说穿了也简单：按小时甚至按半小时分段建模。每个时段单独估计λ、μ，单独计算指标，最后取峰值时段作为瓶颈。我在做网点评估时一定是按半小时粒度整理数据，找到一天里的多个峰段，分别跑模型。有的网点下午时段有几个小高峰，只看全天平均值会把这些全部抹平。
5.2 服务时间未必服从指数分布
服务时间的分布假设是另一个重灾区。很多人为了套用M/M/c模型，强行假设服务时间服从指数分布，但实际情况往往不是这样。自助设备、标准化流程的窗口服务时间波动很小，变异系数通常只有0.3到0.5；而人工办理复杂业务时，服务时间才更接近指数分布。
有个简单可行的判断方法：收集200个以上样本的服务时长，计算标准差和均值，变异系数超过0.8的大致可以接受指数假设，低于0.6就建议换M/G/c模型或者用仿真。曾经有个项目用了M/M/c模型评估自助售票机的配置，结果算出来等待时间明显偏高，后来发现服务时间是近似常数，改用M/D/c模型模型后才接近真实观测。
5.3 样本量不足与统计口径不一致
样本量不足在排队数据里特别常见。有的网点只收集了两天的数据就想做全年规划，两天正好赶上突发情况（比如系统升级导致服务时间暴涨），数据全部失真。我一般建议至少收集连续一周以上的工作日数据，如果要考虑周末，就把周末单独拿出来看。样本量方面，每个时段至少要有30个以上的到达间隔观测值，否则λ的置信区间会宽到没有参考价值。
统计口径不一致也经常出问题。比如“等待时间”的起算点，是从客户到店取号算起，还是从客户开始排队算起？如果客户取完号先去旁边坐着看手机，十几分钟后才坐回等候区，这个时间算不算等待？如果不定义清楚，不同网点报上来的数据根本没有可比性。
5.4 数据窗口覆盖不完整
只看把高峰时段算进去，但没覆盖完整业务周期，也会给评估带来偏差。比如银行网点每月初、每个季末是代发工资和理财到期的高峰，如果做评估时躲过了这些节点，模型会对峰值运力给出严重低估的配置建议。反过来，如果只挑了最忙的那一周做评估，又可能过度冗余。合理做法是把“常规周”和“峰值周”分开建模，分别评估各自的配置需求，最后在排班上做弹性区间。
数据窗口还应该考虑季节性。医院门诊在流感季节的到达率会明显上升，呼叫中心在促销活动期间来电暴增，这些都能通过历史数据提前识别，评估报告里要单独列出这类特殊时段的结论。
5.5 人工作业数据里的隐性噪声
最后一个坑来自数据采集环节本身。如果靠手工抄写到达时刻，经常会出现漏记同一个时刻连续到达的情形，因为人眼和手速跟不上实际到达节奏。建议用系统打点数据，摄像头识别加时间戳，或者叫号机的记录。如果只能手记，最好安排专人，并明确要求对连续到达的客户逐个记录到达时刻，不要用“三分钟内来了五个”这种模糊描述。
数据清洗也很关键。比如系统记录的“服务开始时间”和“服务结束时间”中间可能夹杂着客户咨询、打印、电话等不属于服务的操作，这些都要按业务口径剔除。还有个容易忽略的点是系统自动录入了“无效记录”——客户取号后离开网点，根本没有办理业务，这条记录不能进服务时间的统计样本。
6. 算完账之后，怎么把指标变成行动
评估报告的最终目的不是输出一堆漂亮的指标，而是要回答“接下来怎么办”。从排队论模型推导出改进动作，通常有几条路径，我按常见的优先级来梳理一下。
6.1 加窗口之外的选择
很多管理者一看到等待时间超标，第一反应就是加人加窗口。但模型计算往往显示，在利用率不高的时候增加服务台，边际收益很小。比如第三节的例子中，3窗口到4窗口的改善是巨大的，但如果从4窗口加到5窗口，平均等待时间从26秒降到不到10秒，客户几乎无感，成本却不低。
所以在动用人力和场地之前，我会先检查两件事：一是现有服务台有没有真正全部开放，很多网点明明配置了6个窗口，但因为人员吃饭、培训、会议等原因，高峰时段实际只有3个窗口在运作；二是业务类型能不能分流，把所有客户扔进一条队列再做差异化处理，往往比加窗口更管用。
6.2 分流与差异化服务
排队论里的一个经典结论是：把方差大的业务和方差小的业务混在一起，会让整条队列的效率变差。 原因在于长尾业务会偶尔长时间占住服务台，导致后面所有客户的等待时间被拉长。解决思路也很直接：把简单业务和复杂业务拆成两条队列，简单业务用快速窗口，复杂业务用普通窗口。
我在一个政务大厅的案例里见过这样的改造：原来所有业务混在一个窗口，平均办理4.2分钟，变异系数0.9，90%的客户等待时间超过8分钟。改造成“简事快办”窗口和综合窗口的双队列模式后，简单业务的平均办理时间压到1.8分钟，复杂业务虽然在综合窗口的等待略有上升，但两类服务的SLA分别达标了。这在排队论视角来看就是降低了服务时间的整体方差，让模型里的μ更加稳定。
6.3 预约制和削峰填谷
预约制本质上是把到达过程从“随机泊松”拉低成“可控到达”，把高峰的到达率摊到全天。如果预约能达到全量业务的三成以上，峰值时段的λ可以显著下降，排队指标的改善非常可观。
当然预约制能不能落地，取决于客户习惯。有些场景客户就是偏好随到随办，银行和政务大厅的客户年龄结构偏大，预约渗透率很难拉高。这时候可以考虑“引导式错峰”：通过APP展示实时排队人数，让客户看到当前网点忙不忙，能不能晚一点再来。这个做法不改变到达过程本身，但可以影响客户的到达决策，间接削峰。
6.4 动态排班
动态排班很值得投入精力，因为它能在不增加总人力的前提下大幅提升服务水平。核心思路是根据历史数据预测未来时段（比如未来一周每天每个小时的到达率），然后用排队论模型倒推每个时段需要开设几个服务台，再据此安排柜员的上班时间和休息时间。
有人力资源管理系统支持按小时级别排班制的行业（呼叫中心就是典型），这套方法落地效率很高。银行网点因为柜员有运钞车押运时间、日终轧账等硬约束，全动态排班比较难，但退一步也可以做混合排班：核心柜员固定班次，机动柜员在预测的峰值时段补位。
6.5 仿真模拟作为补充
解析模型算得快，但有几个天生的短处：对到达过程的非平稳性处理能力弱，对队列结构复杂的系统表达不灵活，对“客户中途离开”这类行为很难建模。所以当系统复杂度高、指标要求细致的时候，我会在解析模型之后补一层离散事件仿真。
用Python的simpy库写一个简单的排队仿真是很顺手的事，几十行代码就能模拟一天的到达和服务过程，输出等待时间分布、队列长度分布，甚至能模拟客户不耐烦中途离场。仿真的好处是可以把“人”的行为加进去，比如等待时间超过10分钟的客户流失率、客户被叫号后没有及时到窗口导致的服务空转，这些因素解析模型很难量化，但仿真可以轻松表达。一般我的做法是：先用解析公式快速筛出候选配置，再用仿真对推荐配置做精细化验证，两者结合，结论的可靠度要高很多。
这个内容后续还可以沿着两条线继续展开：一条是做成本优化，把排队指标换算成人力成本和客户流失损失，直接输出“最佳配置”的成本报告；另一条是做预测，用历史数据训练到达率预测模型，把排队论的输入参数从“历史均值”升级成“未来预测值”，实现提前一天的动态调度。无论是哪条，本质上都还是在回答那三个老问题：客户要等多久？资源够不够？怎么配置最划算？