【资源调度】3-客服调度问题领域建模

导读：本期是全网最全【资源调度】系列推文的第3期(共50期左右)。我们将对客服调度问题的目标、约束、关键属性做出详细介绍，明确我们要解决的【客服调度】问题的具体定义。

---

作者1：向杜兵，某制造业龙头算法专家
作者2：张哲铭，某互联网大厂算法专家

---

大家好！我们是IndustryOR团队，致力于分享业界落地的OR+AI技术。欢迎关注微信公众号/知乎/CSDN【运筹匠心】。

邀请大家 【加入粉丝群】，群里经常分享硬核内容，且大佬多多，说不定你未来的leader就在其中！【加群方式附在文章结尾】~~

本篇文章共分为3个部分，依次为：
01 调度问题建模
02 问题属性设计
03 小结

在何为调度一文中，我们总结了客服调度本质上可以看作求解供给与需求在时空上的最优匹配。那么，什么样的匹配是最优的呢？显然，在整个调度过程中，存在用户、客服人员、平台三方主体，各个主体存在不同的诉求：

• 用户：问题响应快速，处理效率高
• 客服人员：薪资水平与工作安排公平，任务量与任务难度安排合理
• 平台：最大化效率，最小化成本，最大化收益

一个调度引擎理论上应该能够同时满足上述三方的所有诉求。然而，三方的很多诉求是相互矛盾的，用户想要获得全时刻的即时响应，就意味着需要在全时段安排足够的客服人员，增加客服人员的劳动强度的同时，也必然会提高平台的运营成本。

因此，调度引擎在其中扮演的其实是一个“调和者”的角色，其作用是如何寻求一个三方利益的最优天平，在业务发展的不同时期，这个天平会向不同的方向倾斜。

业务发展初期，平台期望能够快速吸引大量用户，那么，就像访问一个网页一样，对于用户而言，当点击按钮后，期望的不是一直旋转不停的圆圈或者永远99%的进度条，而是自己的问题能够得到瞬间的回应，响应时长是一个会极大程度地影响用户体验的指标。同样重要的是任务是否被有效处理，如果任务没有被分配给一个合适的客服人员（例如用户只会说英语，但是分配的客服却无法熟练使用英语），则可能会出现“你就说我反应得快不快”而至处理是否妥善、问题是否得到有效解决于不顾的局面，这就需要我们能够考虑客服人员所拥有的技能与任务所需的技能是否契合。

随着业务规模的扩大，业务模式的成熟，以及业务数据的丰富，整个调度引擎越来越关注如何满足个性化、人性化的需求。以客服人员的角度为例，我们需要从多方面考虑其工作的公平性：在薪资水平相当的前提下，首先需要保证其工作时长的公平性。其次，实际任务的难度存在显著差异，有的问题处理复杂，耗时长，工作强度大，如民航中的“红眼航班”（通常指在深夜至凌晨起飞的航班），这样的任务如果频繁地分配给同一个机组人员，将增加人员的工作负荷，人员流失率可能也会因此提高。因此，在不同阶段，调度引擎存在不同的侧重点，接下来我们将对客服调度问题中的目标与约束进行梳理，形成对于该问题的领域建模。

01 调度问题建模

我们由简入繁，将要解决的问题整体划分为两个阶段：

第一阶段考虑少量目标和约束，第二阶段增加更多实际业务中需要考虑的目标与约束，这也更贴近实际业务和技术方案的迭代过程。值得一提的是，在静态问题全局优化中，我们考虑的是所有已知输入构成的单个问题，而在动态在线调度中，我们将考虑如何纳入未来信息以实现长期的最优。

下表为考虑的目标与约束种类，①代表第一阶段，②代表第二阶段基础上新增的目标和约束。

目标	约束
任务处理效率①	在岗时长规则①
最快响应时间①	班次/在岗时间段规则①
最大工时利用率②	技能匹配①
服务时长公平②	间休规则②
任务量公平②	用餐时间窗②
任务难度公平②	服务任务数限制②

相关说明：

任务处理效率：同一个任务，不同人员的处理效率不同，最理想的情况是分配给了一个处理时长最短的人员，但除非客服人员（供给）十分充足或者任务（需求）十分稀少，否则该情况很难达到。定义该目标的量化形式为所有任务理论最短处理时长总和/所有任务实际处理时长总和。

最快响应时间：一味地追求任务处理效率可能导致任务响应时长的增加，如任务请求来临的时刻，只有技能相对不熟练的人员空缺，那么其处理时长可能会较长，如果过于追求任务处理效率，可能会延迟处理该任务，待技能更熟练的人员空闲时，再来处理该任务，这将导致响应时长的增加，降低用户体验。因此，我们定义最快响应时间的目标，其量化形式为所有任务实际响应时长的总和。

最大工时利用率：在满足工作负荷业务规则下，期望人员在岗时段内处理任务的数量越多越好，总的处理时间越长越好，这意味着效率的提高。定义该目标的量化形式为所有客服人员处理任务的总时长/所有客服人员总在岗时长。

服务时长公平：定义该目标的量化形式为所有人员处理任务总时长的标准差。

任务量公平：定义该目标的量化形式为所有人员分配的任务数量的标准差。

任务难度公平性：某些任务难度大，处理时间长，不能连续、频繁地分配给同一个人员。定义该目标的量化形式为所有人员分配特殊任务数量的标准差。

在岗时长限制：每个人员需要满足一定的在岗时长，若某个人员分配的最后一个任务的开始时刻在其在岗期间内，允许一定的加班时长来完成其最后一个任务，因此算法需要考虑不能分配处理时长过长的任务，导致频繁出现加班时长超时的情况。

班次/在岗时间段规则：任务的到达可能是全时段的，因此需要在不同时段均安排足够的人员，人员只能在其在岗时间段内才能处理任务，早于或晚于人员在岗时间段的任务都不能分配给该人员，同时人员的班次还会存在轮换的情况（这属于资源排班的范畴）。

技能匹配：
1）硬规则：必须满足，如任务处理需要英语交流，则必须安排一个会英语的人员；
2）软规则：虽然人员拥有某个技能，可以处理某类任务，但同一个技能也存在等级，不同等级的人员在该技能上的熟练程度不同，可体现在任务处理时长的差异。

间休规则：员工连续工作一定时长后，必须有一段休息，且休息时长足够。

用餐时间窗：分为午餐用餐时间窗与晚餐用餐时间窗，为了保证一定的服务水平，需要保证每个时段都有一定的在岗人员，因此不同人员的用餐时段存在差异。

服务任务数限制：相同长度的时间内，任务处理数量将影响客服人员的工作体验。每个任务处理完成后，人员在处理下一个任务时，需要一定的时间才能进入良好的工作状态，过于频繁地处理任务可能会不断降低人员的精力，导致处理任务的效率越来越低。

02 问题属性设计

如前所述，人员、任务、规则、目标构成了整个问题，下面我们将考虑其中必要的属性，以支持后续对于问题的量化定义。

人员属性

1. 唯一id
2. 技能集：人员拥有的技能集合
3. 班次集：同一人员在整个问题的时间周期内（如一周）可能有不同的班次

任务属性

1. 唯一id
2. 任务产生时刻
3. 最大响应时长
4. 任务类型
5. 技能要求

规则属性

人员在岗时长规则参数：标准工作时长以及允许的最大加班时长

班次类型：不同的在岗时段，包括上班时刻和下班时刻

技能匹配表：

• 强规则：人员技能——任务类型匹配表
• 软规则：人员技能——任务类型处理时长表

间休规则参数：连续工作X时长，必须休息Y时长

人员用餐时间窗：人员-用餐时间窗二维表，单个用餐时间窗包括用餐开始时刻与用餐结束时刻

服务任务数限制参数：类型-任务数上限二维表

03 小结

上篇（如何解决资源调度问题）：我们选择【客服调度】场景作为【资源调度】问题的具象化代表，为大家详细介绍了该问题的业务背景、问题抽象、技术路径和解决方案等内容。

本篇（客服调度问题领域建模）：我们从调度引擎在业务发展过程中对不同相关方的诉求进行调和入手，梳理确定了客服调度将考虑的目标与约束，并给出了必要的属性设计，最终形成了对该问题的领域建模。之后我们需要依据这些逻辑和属性，采用具体的数据来量化问题。由于没有大量真实的数据，我们将采用数据仿真相关技术来得到我们的问题数据集。另外，可以看到很多数据实际上是无法事先确定，存在一定随机性的（如在实际过程中很难事先确定一个任务需要多久才能处理完成），后续也会采用ML/DL等技术实现对问题更精准的刻画。

下篇（数据仿真建设）：我们将基于一份实际数据，生成【客服调度】问题数据集，其中涉及数据增强、假设检验等方法，为后续的算法求解提供数据支撑。敬请期待~~~

最后，请大家多多点赞！！！转发！！！关注！！！ 大家的支持是我们持续创作的动力。我们是 【运筹匠心】 ，咱们下期见~~~

---

04 加群方式

请加管理员进群：IndustryOR