客服自动化能否顺利运作，取决于案件数据、分派规则与人员状态是否一致。Salesforce Service Cloud 建置需要把这些条件一起设计。本文从 Case Management、Omni-Channel 与自动化规则切入，整理设置前的判断、常见问题与验收方法，协助企业建立稳定的客服流程。
摘要
Service Cloud 建置应把案件、分派与自动化视为连续流程。案件字段要有共同定义，Omni-Channel 要核对工作类型、人员资格、可用状态与容量，自动化则需要明确触发及例外处理。本文沿用 Service Cloud 名称，目前官方文件亦使用 Agentforce Service；设置与授权应以实际方案及现行文件确认，尤其不要直接套用已退役的 Standard Omni-Channel 操作方式。
1. Case Management 先建立一致的案件语言
定义案件、分类与优先序
一笔 Case 应代表可追踪的服务需求。企业需要说明同一问题的后续回复如何延续、不同问题何时分开，以及重复进件如何处理。若案件边界不清楚，后续分派与报表都容易失真。
分类字段应服务实际处理，例如产品、问题类型或支持团队。选项太细可能增加判断负担，太粗又无法支持分派。可先以代表案件测试分类是否容易理解，再逐步完善。
优先序也需要明确标准。客户影响、时间敏感度与服务安排可能共同影响排序，不能让每个人自行解读「紧急」。规则应包含谁能调整，以及变更后是否需要重新评估分派或通知。
状态要能说明下一步
案件状态不只是报表标签，还应让团队知道目前由谁负责、在等什么及何时需要跟进。等待客户数据与等待内部支持的处理方式不同，应按运营需要设计。
每个状态都要有进入与离开条件。若所有案件长期停留在处理中，主管便难以分辨真正的工作量与等待量。需要记录的信息应与任务结合，避免客服为了通过必填字段而填入无意义内容。
结案与重新开启也要纳入流程。客户再次回复、补充新问题或表示尚未解决时，应有明确判断及责任，并测试它们对服务时限、后续通知与统计口径的影响。
2. Omni-Channel 分派需要四类条件
工作类型与分派入口
先确认要分派的是 Case、讯息工作或其他支持物件，再核对服务通路及路由设计。不同通路可能有不同授权、生命周期与设置，不能把一套案件分派方法直接套用到所有工作。
在使用伫列分派的情境中，案件需要进入正确的伫列，并有对应的路由设置。数据分类若在进入后才完成，还需确认何时重新评估，避免工作被送到不适合的团队。
人员资格与可用状态
能查看案件，不一定代表能接收该类分派。企业应核对人员的通路、相关权限、伫列或技能安排，以及可使用的状态，让业务规则与系统条件一致。
可用状态需要反映实际工作。登录系统不等于正在接案，休息、处理其他任务或交班时，也应有清楚操作方式。培训要说明状态对接收工作的影响，而不只教人员如何切换按钮。
容量与工作负荷
容量是分派的重要条件，应同时检查人员可承担的工作量与每类工作所需容量。若单一工作需求超过可用容量，即使有人在线，仍可能无法分派。
企业应依工作性质设置合理权重。简单查询与需要深入排查的案件，未必适合以相同负荷看待。先用实际样本观察，再调整规则，比单纯提高容量数字更有依据。
不同容量模型对工作完成或状态变更的处理可能不同，必须确认何时释放容量。不能把关闭画面一概视为完成案件，也不能假设案件仍指派给某人就一定使用同一种容量计算。
图 1：分派需共同确认工作类型、人员资格、可用状态及容量。
3. 优先序、转交与无人接收要预先设计
分派优先序应反映服务目标，并处理同一团队同时承接不同工作时的取舍。设置高优先序不会增加实际人力，若高优先工作持续累积，仍需检视团队安排与上游原因。
转交时，接手人员应取得问题摘要、已做处理及下一步，而非只看到拥有人改变。企业要定义转交是否需要接收确认，以及未接收时由谁继续负责，避免案件落在责任空隙。
没有符合技能或可用容量的人员时，应有替代程序，例如保留等待、通知主管或按核准条件改由另一团队处理。具体做法需配合通路及路由方式测试，不宜假设平台自动处理所有例外。
高峰与非营业时间的情境也要演练。客户应获得符合实际安排的回复，客服主管则需要看到待处理量与最久等待。避免自动回复承诺了团队无法提供的处理时间。
官方目前已以 Enhanced Omni-Channel 为主要方向，Standard Omni-Channel 于 Summer ’26 版本退役。既有企业应检查当前组织设置、升级结果与适用文件，避免把旧教学中的预设视为现况。
4. 客服自动化从触发、动作与例外开始
明确说明何时执行
自动化规格应回答哪个事件触发、需要满足哪些条件，以及同一案件是否可以再次执行。例如案件优先序改为高时通知负责人，与每次保存高优先案件都通知，是不同设计。
Salesforce Flow 的记录触发流程可依记录建立或更新及条件执行。建置时要确认真正需要的触发时点，并测试不相关字段更新是否会重复产生动作，避免通知或任务被放大。
动作要有清楚责任与范围
动作可能涉及更新信息、通知人员或交接工作，应说明由谁使用结果、是否需要回复及如何确认完成。系统成功执行一个动作，不代表业务上已完成服务。
若标准规则、Flow 与外部整合同时修改案件，应整理共同的执行边界。哪些字段由谁维护、哪些动作只能执行一次，都要有一致设计，避免互相覆写或反复触发。
例外需要可追踪
缺少客户数据、找不到接收人或外部系统暂停时，自动化应有适当处理与通报。错误记录至少要让维护人员知道影响哪个工作、何时发生及是否需要重试。
重试也要考虑先前是否已完成部分动作。若通知已发出而后续更新失败，直接重跑可能造成重复。企业应在设计时说明如何辨认已处理状态，并以测试验证恢复方式。
图 2：客服自动化应先定义触发条件、执行动作与例外处理。
5. 服务时限与知识内容要支持实际处理
首次回复、解决与等待是不同概念。企业可评估 Entitlement Processes 与 Milestones 如何支持服务时限，但先要定义适用客户、案件、营业时间及完成条件，再核对设置。
不能只以自动回复代表真正回应。若企业衡量的是客服已理解并处理问题，就需要相应记录与共同定义。否则指标可能看似良好，客户却仍长时间等不到有用信息。
知识内容与常用回复可以减少重复工作，但应有适用情境、审核与更新责任。客服需要容易找到相关内容，也要知道何时不能直接套用、何时需要进一步排查或升级。
若规划 AI 辅助服务，先确认实际功能、授权与数据范围，并设计人工接手与验证方式。不要在基本案件流程尚未稳定时，把所有例外都交给尚未验证的新能力处理。
6. 分派异常可以如何逐层检查
当案件没有送到预期人员时，先选一笔可重现的记录，确认问题发生的时间与当时条件。不要同时改动多个设置，否则即使暂时恢复，也难以知道真正原因。
- 确认案件类型、分类数据与实际分派入口。
- 核对案件是否进入预期伫列或路由流程。
- 检查服务通路、路由设置与适用权限。
- 确认接收人员当时的资格及可用状态。
- 比对工作所需容量与人员剩余容量。
- 检查例外路径、转交与外部整合记录。
- 修正后以相同情境验证，并保留结果。
若只有部分案件出现问题，应比较它们与正常案件的差异，例如产品、语言、来源或建立时间。若所有工作都受影响，则优先检查共同入口与人员状态，再逐步缩小范围。
跨环境部署后也要重新验证相关参照与权限。测试环境能运作，不代表正式环境的伫列、用户与整合设置完全一致。部署清单应包含这些差异及确认人。
7. 用代表情境完成上线验收
假设一家企业有一般客服与产品技术团队，首期可把一般问题送到客服，符合特定条件的技术案件再转交。这是假设建置情境，目的在于检查责任与信息是否能完整接续。
验收应包含有符合人员、所有人忙碌、缺少分类、转交失败与结案后再回复等情况。每一笔都应能说明预期路径、实际处理与最后责任人，而非只看案件最后停在哪个伫列。
自动化测试也要区分建立与更新情境。确认第一次满足条件、仍维持相同条件及离开后再次进入时的结果，才能判断是否符合原本设计，并减少重复执行。
正式上线后保留一段有明确支持安排的观察期，收集客服与主管反馈。优先处理影响接案、回复及数据正确性的问题，再安排便利性改善，让变更有清楚次序。
让设置与运营记录保持一致
为每个分派与自动化规则保留简明说明，包括用途、拥有人、依赖字段与最近验证日期。当有人提出修改需求时，团队便能先查找既有规则，减少为相同目的建立多套互相干扰的设置。
变更前应列出受影响的案件类型与相关动作。例如新增优先序选项，可能同时影响分派、通知、时间规则及报表。只改选单而未更新其他部分，容易造成部分案件走向未预期的路径。
也要说明人工调整与自动化的关系。客服手动更换负责人或优先序后，哪些规则仍会执行、哪些应保留人工决定，必须事先定义。否则人员可能反复修改，系统又持续改回原值。
监控时除了失败数量，也应观察工作是否停在不应停留的位置。例如通知已发出但长期未接手，可能是责任或人员安排问题；不能只因技术记录显示成功，就把它排除在改善范围之外。
主管回顾应结合案件品质与工作负荷。若某类问题经常转交多次，可检查分类及所需信息；若容量经常用尽，则评估工作权重与实际人力。数据应帮助找出原因，而非只用来比较个别人员的结案速度。
最后，将解决过的异常转成可重复使用的测试情境。每次修改路由或自动化后，重新验证关键情境，能让过去的经验持续保护日常流程，并降低相同问题再次出现的机会。
测试记录亦应保留当时的设置版本，让后续比较能建立在相同条件上，而不只是记得曾经测试成功。
8. 常见问题（FAQ）
人员在线，为什么案件仍然没有分派？
在线只是其中一项条件。还需检查工作类型、路由入口、相关资格、可用状态及容量。以一笔案件重现当时情况，通常比单看目前画面更容易找出原因。
Case 自动化是不是愈多愈好？
不是。每项自动化都应对应清楚需求，并有触发、例外及维护责任。重叠规则会增加理解与测试负担，应先确保现有流程稳定，再增加必要能力。
可以直接把测试环境的设置搬到正式环境吗？
需要先检查环境差异并重新验证。用户、伫列、权限、数据及外部连接可能不同；正式部署应有检查清单、测试证据与恢复安排。
9. 结语
Service Cloud 建置要让案件语言、分派条件与自动化规则互相配合。把正常及例外路径一起验证，并建立逐层查找问题的方法，能让客服流程更容易维护。
LeadsTech 可协助企业讨论 Salesforce 客服系统、案件流程与整合需求，厘清建置重点及改善方向。
如遇到案件分派或自动化维护问题，可整理代表情境与目前设置范围，与团队讨论合适的处理方式。
相关文章
企业 AI MarTech 趋势分析 2024-2029 年展望报告
从 AI 内容生产力工具，转变为营收增长与营销转型的核心引擎
白皮书 PDF 将寄送至您的信箱。
邮件格式错误
请输入有效的电子邮件地址。
谢谢！
白皮书已发送至您的收件箱。如果您没有看到，请检查垃圾邮件或促销内容文件夹。
