Salesforce Omni-Channel 实践：路由、容量与技能的取舍之道

二月 07, 2026

初识与预期：为何我们需要 Omni-Channel

我第一次深入接触 Salesforce 的 Omni-Channel 功能，是在一个对客服效率和客户体验有极高要求的项目中。当时我们的客户服务团队面临几个核心痛点：工作分配不均、高优先级案件响应慢、以及新老员工技能差异大导致的问题积压。我们期望 Omni-Channel 能像魔法一样，自动将最合适的案件分配给最合适的员工，并确保紧急事务能得到优先处理。

在我看来，Omni-Channel 最核心的价值，就是它提供了一个统一的、实时的工单路由引擎。它不仅仅是“把工单塞给空闲的人”，更重要的是，它能通过复杂的规则，实现基于技能、优先级和容量的智能分配。但真正上手配置和实施时，我才发现这套系统远比我想象的要精妙，也容易掉入一些“想当然”的坑里。

第一个挑战：从简单队列到技能路由的取舍

问题：简单队列路由的局限性

项目初期，我们曾考虑采用最简单的路由方式：基于 Salesforce 标准的队列（Queue）进行分配。我们的初步设想是：将不同类型的案件（比如“产品A咨询”、“产品B故障”、“技术支持”）分配到不同的队列，然后让具备相应技能的客服人员订阅这些队列。

我们很快发现这种方式的局限性：

技能重叠与复杂性：如果一个员工同时处理产品A的咨询和产品B的故障，他需要同时监听两个队列。但如果产品类型多达十几种，技能组合就会变得异常复杂，管理多个队列变得非常繁琐。
优先级处理困难：队列本身没有内置的优先级概念。高优先级的案件可能被埋没在大量普通案件中，需要人工干预去“捞”出来。
动态调整困难：当团队结构或技能要求发生变化时，调整队列和员工的映射关系会很麻烦。

当时我们意识到，这种粗放的分配方式无法满足我们对精细化运营的需求。我们需要一个更智能、更动态的路由机制。

决策：选择技能型路由（Skills-Based Routing）

经过一番调研和内部讨论，我们决定采用 Omni-Channel 的技能型路由（Skills-Based Routing）。虽然它的配置复杂性更高，但我们权衡利弊后认为这是唯一能解决我们痛点的方法。主要原因有以下几点：

精准匹配：技能路由能确保案件分配给真正具备处理能力的员工，避免员工接到不熟悉的工作，提高首呼解决率。
灵活性：当员工技能提升或团队分工调整时，只需更新员工的技能档案，而无需大动干戈地调整队列。
优先级支持：技能路由与优先级结合，可以确保高优先级案件即使只有少数员工能处理，也能迅速被推送。

实施过程中的“为什么”：定义技能与赋能员工

采用技能路由后，我们面临的第一个具体问题就是：如何定义“技能”？是越细越好，还是越概括越好？

我的经验是，一开始可以从比较核心的、区分度大的维度入手，比如：Product_A_Expert, Technical_Support_Level_2, English_Speaker。然后，再根据实际情况逐步细化或增加。如果一开始就定义得过于细致，你会发现管理起来非常困难，而且很多技能可能只有少数员工具备，导致工作分配不畅。

定义完技能后，另一个关键步骤是给员工赋能技能（Assign Skills to Service Resources）。这通常通过创建 Service Resource 记录并关联 Skills 来完成。我们当时采取的方案是：

与各部门经理协作，梳理出每个员工的核心技能。
在 Salesforce 中创建对应的 Skill 记录。
为每个员工创建 Service Resource 记录，并添加 Skill 关联。

在案例（Case）等可路由对象上，我们则通过自动化流程（比如 Flow）来动态评估案件的类型、紧急程度等信息，并为其分配所需的 Skills（通过创建 Skill Requirement 记录）。

// 概念性示例：假设通过Flow为高优先级产品A案件添加技能需求
// 步骤1: 获取Case记录的ProductId, Priority
// 步骤2: 决定所需的技能
IF Case.ProductId == 'ProductA' THEN
    Add SkillRequirement 'Product_A_Expert'
IF Case.Priority == 'High' THEN
    Add SkillRequirement 'High_Priority_Handler'

这里我的理解是，Skill Requirement 就像是案件的“求职简历”，而 Service Resource 上的 Skills 则是员工的“个人能力档案”。Omni-Channel 的路由引擎会尝试匹配这两份档案。

第二个挑战：容量（Capacity）与优先级（Priority）的平衡

问题：如何避免员工过载，同时确保紧急案件优先

仅仅有技能路由还不够。我们很快发现，即使员工有能力处理，也不能无限量地分配工作。而且，不同类型的案件对员工的精力占用是不同的。一个简单的咨询可能只需1个单位的容量，而一个复杂的故障排查可能需要3个单位。

同时，我们还需要解决高优先级案件“插队”的问题。即使某个员工正在处理其他案件，但如果他有能力且容量允许，高优先级案件应该能优先分配给他。

决策：精细化配置容量与优先级

Salesforce Omni-Channel 提供了容量（Capacity）和优先级（Priority）这两个核心概念来解决上述问题。

容量（Capacity）：
我们选择的是基于“单位”（Units）的容量模型，而不是简单的“标签页”（Tabs）模型。理由是，不同类型的工单对员工的占用确实不同。通过为不同的工单类型（在 Service Channel 中设置）分配不同的容量单位，我们可以更精确地控制员工的工作负荷。例如：
- 普通咨询工单：1单位
- 复杂故障工单：3单位
- 紧急电话呼入：5单位 (占用的容量大，但处理时间短，需要快速响应)
每个员工（Service Resource）都有一个总的容量上限。当员工被分配工单时，其剩余容量会减少；工单关闭或转移后，容量会恢复。这样就有效避免了员工过载。

我当时的一个理解误区是，以为容量是针对某个特定技能的。实际上，容量是针对员工整体的。也就是说，一个员工的总容量是固定的，无论他处理的是哪种技能要求的工单，都会消耗这个总容量。
优先级（Priority）：
在 Routing Configuration 中，我们可以设置不同的优先级值。值越低，优先级越高（例如，1最高，10最低）。当有多个待分配的工单时，Omni-Channel 会优先分配优先级更高的工单。

我们为不同级别的案件（例如：P1紧急、P2高、P3中、P4低）配置了不同的路由配置，从而赋予它们不同的优先级。这样，即使一个 P3 案件先到达队列，如果此时有一个 P1 案件进来，Omni-Channel 会先尝试分配 P1 案件。

为什么这样设计？我们希望在员工有空闲容量且技能匹配的情况下，确保最紧急的客户问题能够第一时间得到关注。优先级就像是告诉路由引擎：“这些事情更重要，先处理它们。”

第三个挑战：Presence Statuses 的精细化管理

问题：员工状态与工单分配的联动

一开始，我们只简单地创建了“在线”和“离线”两个 Presence Status。但很快发现这不够用。员工可能需要短暂离开（例如午餐、茶歇），或者正在进行内部会议，此时他们虽然“在线”，但不应该被分配客户工单。

决策：自定义 Presence Status 并关联容量

我们创建了多个自定义的 Presence Status，例如：

Available - Chat：可以接受 Chat 和 Case。
Available - Case Only：只接受 Case。
Break：不接受任何工作，且会暂时释放容量。
Meeting：不接受任何工作，但可以保持当前工单打开（不释放容量，后续再处理）。

关键在于，这些自定义状态可以配置是否允许接受特定渠道的工作，以及是否会释放容量。这让我们能够更灵活地管理员工的实际工作状态，并确保 Omni-Channel 的路由行为与员工的实际情况保持一致。

我发现，Presence Status 是 Omni-Channel 中一个非常容易被忽视但又极其重要的组成部分。它是连接员工行为和路由引擎的桥梁。如果这里配置不当，路由规则再完美也无法正常工作。

Omni-Channel Supervisor 与持续优化

光是配置好系统还不够，我们还需要知道它是否真的运行良好。Omni-Channel Supervisor 是我们监控和优化的重要工具。

实时监控：我们可以看到哪些员工在线、他们的状态、正在处理多少工作、队列里有多少待分配的工单。
队列深度：通过监控队列深度，我们可以判断是否需要调整员工的容量、招聘更多人手，或者优化技能分配。
报表与仪表盘：结合标准的报表和仪表盘，我们可以分析不同技能组的工作量、平均处理时间等关键指标，为后续的优化提供数据支持。

这个阶段，我们主要关注“工单的平均等待时间”、“员工的平均工作量”、“高优先级工单的响应时间”等指标。如果某个指标异常，我们就需要回头检查路由配置、技能分配或员工容量是否合理。

我的几点体会和当前看法

回顾整个过程，我对 Omni-Channel 有了更深的理解：

它是一个生态系统，而非单一功能：Omni-Channel 不仅仅是路由引擎，它与 Service Channels、Routing Configurations、Queues、Service Resources、Skills、Presence Statuses 等多个 Salesforce 对象和功能紧密关联。理解它们之间的交互关系至关重要。
“为什么”比“是什么”更重要：在配置每一个参数时，我都会问自己“为什么我要这样设置？”。理解背后的业务逻辑和预期的系统行为，才能做出正确的选择。例如，选择单位容量是为了区分不同工单的复杂程度。
迭代优化是常态：第一次的配置几乎不可能完美。业务需求、团队结构、员工技能都在动态变化，Omni-Channel 的配置也需要持续的监控和迭代优化。它更像是一个活着的系统。
文档有时会有些迷惑：Salesforce 的官方文档虽然详细，但在某些概念的解释上（例如，容量与优先级在特定场景下的交互），我发现还是需要通过实际测试和经验积累才能真正领会其意。

目前，我们还在探索如何将 Omni-Channel 与 Service Cloud Voice 更紧密地集成，实现语音渠道的智能路由。这带来了新的挑战，比如如何实时同步座席的电话状态与 Omni-Channel 的 Presence Status，以及如何基于通话内容进行动态技能匹配。这块目前还在验证阶段，但相信随着功能的成熟，Omni-Channel 将在全渠道客户服务中发挥更大的作用。

Salesforce中文网