Deskhero
中文
免费试用

← Back to articles

2至3个标签试点：支持团队的技能路由

2至3个标签试点：支持团队的技能路由

基于技能的路由会将每个传入联系分配给技能与请求相匹配的用户，而不是仅依据谁有空。它用基于语言、产品知识或授权级别等因素的匹配机制，取代了“下一位可用用户”模式。支持经理通常借此改善首次联系解决率（FCR）、平均处理时长（AHT）和转接率。在 Deskhero 中，新工单自动化可以通过在配置的条件匹配时将工单分配给某位用户或某个群组，提供一种更简单的此类工作流。

简要总结：

  • 基于技能的路由同时考虑技能和可用性，可以提高首次联系解决率并减少转接。
  • 构建有效的技能分类体系，需要重点关注语言、产品知识和授权级别等高影响力技能，并设置熟练度级别和定期更新机制，以防止体系逐渐偏离实际情况。
  • 成功实施需要先在单个队列中进行试点，准确标记联系，并持续监测 FCR、AHT 和转接率等 KPI，以便不断优化。
  • AI 可以帮助对传入联系进行分类，但团队仍然需要明确的规则、测试和人工监督。
  • 小型团队可以从有限的路由条件开始，只有在结果证明有必要时，才逐步增加复杂度。

目录

什么是基于技能的路由？简明解释

基于技能的路由（SBR）会将每个联系的需求，与用户实际掌握的技能档案进行匹配。一位用西班牙语发送账单争议邮件的客户，会被路由给同时标记了账单和西班牙语技能的人员，而不是发送给队列最短的某位用户。这就是整个概念：一侧是联系需求，另一侧是经过验证的用户技能，中间由规则引擎将两者配对。

大多数团队会跟踪少量几类技能：

  • 语言（西班牙语、法语、普通话）
  • 产品或功能知识（账单、技术设置、企业账户）
  • 渠道熟练度（电话、聊天、电子邮件、社交媒体）
  • 授权级别（退款额度、账户变更、升级处理权限）

传统的基于队列或 ACD（自动呼叫分配器）的路由，可以按照可用性发送联系，而不考虑专业知识。当每位用户都能处理所有问题时，这种方式很有效。随着团队日益专业化，仅基于可用性的路由可能会增加联系需要被转接的概率。

为什么实施基于技能的路由：可衡量的收益及其失效场景

是否采用基于技能的路由，应在你自己的 KPI 仪表板中进行验证。当路由规则和技能数据准确时，团队可能会看到以下结果：

  • 首次联系解决率提高，因为接手联系的用户通常已经知道如何解决问题
  • 平均处理时长降低，因为搜索答案、升级处理或转接的情况减少了
  • 整体转接次数减少，而转接是引发客户不满的最大因素之一
  • 客户满意度提高，因为需要重复说明或转接的联系减少了

为什么这很重要： 学术界的呼叫中心研究描述了将不同类型的联系匹配给技能不同的用户所涉及的复杂性。通过试点，你可以在更大范围推广之前，验证这种复杂性是否能改善自身的服务指标。

用户也能从中受益。处理符合自身实际优势的联系，意味着不必费力寻找答案，也能减少返工，而这往往不仅体现在指标上，也会体现在士气上。

SBR 并不一定值得投入设置成本。一个小型的通才团队可能无法从正式的分类体系中获得多少收益。当联系类型不可预测，或标记数据不一致到无法信任时，情况也可能如此。在这些情况下，基于可用性的模型或简单的优先级队列，可能以更少的维护工作完成任务。

基于技能的路由如何运作：技术工作流

其机制可以分为三个阶段：建立技能分类体系，将用户映射到该分类体系，然后配置路由和分配规则。Microsoft 的实施文档提供了一个具体示例，其中包括评分模型、技能类型、技能分配、分类方法和分配方法。

  1. 建立分类体系。定义与你的业务相关的有限技能清单（语言、产品领域、渠道、授权层级）。
  2. 将用户映射到技能。根据平台的不同，每位用户可能只需接受简单的是/否技能分配，也可能需要按照规定的熟练度量表获得评分。
  3. 配置路由规则。引擎读取传入联系的标签，并与用户档案进行匹配，在需要时应用最低熟练度阈值。

联系可以从 IVR 菜单选择、CRM 账户数据、电子邮件主题行、标头或对消息的自动分类中获得路由数据。当有多位用户符合条件时，平台需要有记录在案的平局处理规则。根据系统的不同，选项可能包括熟练度、处理容量、空闲时间或轮询。

集成点 在路由决策中的作用
ACD / IVR 捕获初始联系并收集路由信号（菜单选择、来电号码）
CRM 提供账户背景信息（等级、历史记录、语言偏好）
聊天机器人 / AI 分类 读取自由文本，以推断意图和所需技能
劳动力管理 确认哪些具备相应技能的用户已排班且处于可用状态

这也是基于技能的路由开始不再像单一功能，而更像一个小型集成项目的地方。每个为联系提供标签的数据源都必须保持准确，否则即使分类体系设计得很好，匹配质量也会下降。

设计技能分类体系并为用户建立映射

应围绕会影响服务结果的差异来构建分类体系，而不是囊括某人可能拥有的每一项技能。关于呼叫中心设计的研究说明了当联系类型和用户能力不同时，路由复杂度会如何迅速增加。规模较小的试点分类体系更容易测试和维护。

有两项设计决策最为重要：

  • 熟练度量表。如果平台支持评分，定义明确的量表和最低阈值，就能区分常规工作与需要更深层专业知识的案例。
  • 责任归属。提前决定由用户自行报告熟练度变化、由经理审核和批准，还是两者结合。自行报告速度更快；经理审核则能发现偏差。

从试点开始。选择一个队列，应用分类体系，并在进一步扩展前衡量 KPI 的变化。

专业提示： 首次使用技能分类体系时，应在单个队列中运行一个短期试点，并在推广到其他队列前，将 FCR 和 AHT 与基准值进行比较。如果数字没有变化，需要重新设计分类体系，而不是增加更多队列。

应将分类体系视为运营策略中不断发展的组成部分，而不是一次性的设置任务。你选择的类别应跟踪那些真正推动 CSAT 和解决率的因素，而随着产品和客户群体发生变化，这份清单也会改变。

实施清单：设置、测试和发布计划

基于技能的路由最适合以分阶段项目的方式推出，而不是直接一键切换。

  1. 先设定目标。在开始构建之前，确定你希望改善哪些 KPI（FCR、AHT、转接率）。
  2. 选择试点队列。选择一个技能要求明确的联系类型，而不是问题最复杂的队列。
  3. 组织利益相关者。让一位经理、几位资深用户，以及负责 CRM 或帮助台数据的人员共同参与。
  4. 创建技能清单。保持清单精简，并与第一步设定的目标一致。
  5. 标记联系。配置 IVR、CRM 和电子邮件标记规则，确保联系到达时带有正确的元数据。
  6. 分配用户和阈值。按照熟练度级别将用户映射到技能，并为每项技能设置最低阈值。
  7. 设置平局处理规则。确定多位用户符合条件时的后备顺序。
  8. 使用模拟流量进行测试。上线前让示例联系经过这些规则，并确认没有合格用户空闲时，后备路由能够正常工作。
  9. 分阶段发布。按队列逐步扩展，培训用户熟悉新的流程，并在第一周密切关注仪表板。

衡量、审计和维护基于技能的路由

如果没有人关注，基于技能的路由会在不知不觉中失效。值得持续跟踪的 KPI 包括 FCR、CSAT、AHT、转接率、用户占用率和 SLA 达成率。其中任何一项出现下降，尤其是 FCR 或转接率下降，通常都是用户档案不再符合实际情况的第一个信号。

路由模型是否保持最新，取决于其背后的档案和规则是否保持最新。指定负责人，明确熟练度变化的审批方式，并按照固定计划定期审查模型。

一个可行的节奏如下：

  • 每天：扫描仪表板，查找异常（AHT 突然激增、异常的转接模式）
  • 每周：抽查部分已路由的联系，并与用户的实际表现进行对照
  • 每季度：根据当前业务重点审查完整的分类体系

需要有人负责这一流程，无论是团队负责人还是运营经理；同时，用户激励机制应奖励准确报告自身技能，而不是夸大技能。夸大的熟练度几乎比其他任何因素都更快地破坏路由准确性。

AI 与基于技能的路由：AI 能带来什么，以及人工监督仍不可或缺的地方

基于技能的路由早于当前的生成式 AI 系统出现，其基于规则的核心仍然有用。AI 可以增加一个分类层，根据联系的自由文本消息估计其需求。

AI 通常通过三种方式发挥作用：

  • 意图分类：读取自由文本（电子邮件、聊天消息），推断实际问题，而不只是客户选择的类别
  • 技能预测：当联系无法明确归入 IVR 菜单时，标记适用的技能标签
  • 路由支持：提供类别或置信度信号，供配置好的分配规则使用

许可、语言或授权等硬性要求应继续保留为明确规则。一种谨慎的流程是：先对联系进行分类，应用必需的技能规则，在符合条件的用户之间使用有记录的平局处理规则，然后将模糊案例交由人工审核。

实施基于技能的路由时的挑战和常见陷阱

为路由逻辑提供数据的来源经常会成为失败点。如果用户档案在入职时创建后从未审核，分类体系就会逐渐偏离当前能力。当菜单选项或自动类别无法与定义的技能清晰对应时，联系也可能被错误分类。这些错误可能会把工作发送到错误的队列，或造成可以避免的转接。

过度设计可能与疏于维护一样具有破坏性。大量狭窄的技能可能导致许多联系找不到完全合格且可用的用户，从而迫使系统不断使用后备路由。存档的呼叫中心研究说明了为什么在不同联系类型和用户能力之间进行路由，是一个存在实际权衡的优化问题。

小型团队面临着不同的问题：每种技能组合下的用户太少，因此“最合格”的用户经常不可用，而每次后备处理实际上都会退回到“下一位可用用户”模式。相比增加规则，交叉培训在这里更有帮助。

最后，许多团队上线 SBR 后就再也不回顾它。没有审计节奏，没有熟练度更新，也没有分类体系审查。上线时看起来很完善的系统，会慢慢与实际负责处理工作的团队脱节，直到 FCR 悄悄下滑了一个季度，才有人注意到问题。

实施基于技能的路由时的挑战和常见陷阱：概览图

基于技能的路由与其他路由策略的比较

轮询路由会在可用用户之间循环分配联系，而不会尝试匹配专业能力。它配置简单，并且旨在平均分配工作，因此适合每位用户都能处理任何联系类型的团队。

基于优先级的路由会按照紧急程度或客户等级对联系进行排序（VIP 账户可以跳过队列），但仍然不会考虑哪位用户最适合提供帮助。你可以将优先级规则与 SBR 结合使用，大多数成熟的设置也确实如此：在技能匹配的用户池中，使用优先级决定谁先得到处理。

最长空闲或下一位可用路由是 ACD 的默认方式，纯粹按照用户工作量的公平性进行优化。它速度快且无需任何配置，但会将账单问题和技术故障视为完全相同的问题，把两者都发送给空闲时间最长的人。

基于技能的路由用精准性换取了这种简单性。它需要分类体系、用户映射和持续维护，而轮询和下一位可用模式完全不需要这些。其收益是减少转接并加快解决速度，但前提是底层技能数据保持准确。如果团队没有足够精力维护这些数据，那么在至少达到足以证明投入合理的联系量和复杂度之前，采用更简单的模型并叠加优先级规则，通常更合适。

四种支持路由策略的比较

基于技能的路由：行业特定用例和示例

电子商务支持团队可以按照产品线和问题类型进行路由。运输延迟问题可以交给熟悉物流的用户，而付款争议则可以交给拥有适当退款授权的人员。

SaaS 公司可以按照产品领域和技术深度划分工作。账单问题和 API 集成问题通常需要不同的知识，因此将它们路由给不同的群组，可以减少不必要的升级处理。

医疗相关支持团队可以根据角色、培训和访问权限，对预约、保险和账单问题进行路由。路由设计应体现组织自身的隐私和合规要求。

提供多语言服务的零售和旅游品牌通常将语言作为主要技能类别，并叠加特定地区的产品知识。这样，遇到预订问题的法语客户就能联系到真正能够阅读当地条款和条件的人员，而不仅仅是能翻译这些文字的人。

金融服务团队可以将授权级别与产品知识结合起来。相关培训、权限和许可要求取决于具体产品和司法管辖区。

基于技能的路由对员工满意度和培训的影响

将工作与用户的优势相匹配，可以减少不必要的转接，以及反复处理陌生问题所带来的挫败感。应通过用户反馈和质量审查来衡量其影响，而不是想当然地认为它一定会改善员工留任。

培训方式也会随之改变。团队不必试图让每位用户在所有方面都同样熟练，而是可以先培训新员工掌握较少的一组技能领域，验证其熟练度，再逐步扩大覆盖范围。

但另一方面，如果管理不当，专业化也可能造成信息孤岛。只处理一个技能领域的用户可能会停滞不前；同时，交叉培训需要有意识地持续进行，避免团队形成单点故障：一位用户休假，就会导致整个技能类别出现覆盖缺口。让用户轮流接触次要技能，即使采用较低的熟练度阈值，也能保持系统的韧性，并为用户提供成长路径，而不是让他们永远被固定在某条工作轨道上。

AI 辅助分类可以减少为自由文本联系添加标签的人工工作。不过，它的实用性仍取决于准确性检查、置信度阈值，以及针对不符合分类体系的消息设置后备处理方式。

一些路由平台还支持机器学习分类，或支持在符合条件的用户池中进行可配置的排名。应将这些功能视为需要测试的输入，而不是取消硬性资格要求的理由。

绩效数据可以帮助经理识别过时的熟练度评分，但根据结果数据自动更改资格也会带来自身风险。应确保变更可供审查，并记录谁有权批准这些变更。

知识库集成可以通过在工单到达正确用户后呈现相关指南，为路由提供补充。路由质量和答案质量仍应分别衡量。

Deskhero 面向中小型支持团队的方法

Deskhero 不提供带有熟练度评分或基于容量排名的完整技能档案引擎，但提供新工单自动化，可设置用户、群组、优先级、状态、标签或下拉式自定义字段。条件可以使用自动检测到的语言、主题或消息文本、请求者详细信息，或自然语言条件“任意（AI 评估）”。因此，团队可以试点少量分配规则，而不必将结果称为企业级基于技能的路由。

无需彻底改造整个平台，即可试点技能感知路由

Deskhero 允许中小型团队在保留现有电子邮件地址的同时测试简单的分配规则。它可以与 Gmail 或 Microsoft 365 建立双向同步，因此回复仍会从公司的自有地址发出。

Deskhero

在路由试点中，Deskhero 可以检测工单语言，并应用配置好的自动化条件来设置其群组、受派人或标签。其支持 14 种语言的多语言功能可以帮助用户阅读和回复受支持的语言。已解决的工单可以为建议的公开 FAQ 条目提供内容，但条目在公开前必须由用户批准。AI 聊天机器人只会根据已批准的公开 FAQ 回答问题，并且必须至少有 100 条已批准的 FAQ 条目后才能启用。

30 天免费试用无需信用卡。你可以利用它配置少量新工单自动化，使用具有代表性的消息进行测试，并将分配准确率、转接率和解决结果与基准值进行比较。

来源

关于基于技能的路由的技术机制，Microsoft 的文档解释了 Dynamics 365 中的技能评分、分类、匹配和分配。Wikipedia 提供了历史背景。如需简明的行业定义，请参阅 NICE 术语表条目。

常见问题

Salesforce 中的基于技能的路由是什么？

Salesforce Omni-Channel 可以在路由受支持的工作项时使用已分配的技能。具体行为取决于组织对技能、服务渠道、队列和路由规则的配置方式。

基于队列的路由和基于技能的路由有什么区别？

基于队列的路由会将队列中的每个联系发送给下一位可用用户，而不考虑其专业能力；基于技能的路由则会先根据经过验证的技能匹配对用户池进行筛选，然后才将可用性作为平局处理因素。

你能举一个基于技能学习的例子吗？

在支持场景中，基于技能的学习意味着围绕特定的、带标签的能力（例如退款授权或某条产品线）培训用户，而不是采用通用的入职课程，这样路由系统中的熟练度评分就能反映实际且经过验证的能力。

设置基于技能的路由需要多长时间？

没有统一的设置时间。试点所需时间取决于技能数量、现有数据质量、路由平台、测试量，以及团队收集有意义的 KPI 对比结果所需的时间。

基于技能的路由适合小型支持团队吗？

适合，前提是不同联系类型之间的差异足以证明路由规则的必要性。在 Deskhero 中，小型团队可以利用检测到的语言、消息内容、请求者详细信息或 AI 评估条件，通过新工单自动化将工单分配给某位用户或某个群组。Deskhero 不提供完整的基于熟练度的技能引擎。