关于 predict-assignment
predict-assignment 是用于 ServiceNow 的 incident 路由技能,面向服务台团队,根据历史解决记录和文本信号预测分配组、类别与子类别,并支持置信度判断和效果追踪。
主要功能
- 01分析描述中的关键词信号
- 02匹配相似历史事件
- 03按成功率和解决时长排序分组
- 04预测类别与子类别
- 05按置信度应用分配并跟踪准确率
适用场景
- 01将未分配事件路由到合适团队
- 02为事件补充类别和子类别
- 03低置信度事件转交人工分诊
MCP 相关
通过 ServiceNow MCP 工具查询事件及历史记录、更新分配和类别,并添加预测依据备注。
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ happy-technologies-llc/ happy-platform-skills --skill predict-assignment安装后在 Claude Code 中输入/predict-assignment确认已加载。
详细介绍
预测分配
概述
此技能通过分析历史解决模式、关键词频率和群组绩效指标,预测传入事件最合适的分配群组和类别。它可实现服务台的零接触路由。
- 分析传入事件的简短描述和描述,提取关键词信号
- 查询文本相似的历史事件,确定由哪些群组解决
- 根据解决成功率和平均解决时间对候选分配群组进行排序
- 根据内容分析预测事件类别和子类别
- 应用预测的分配,并为其评分,同时提供备用路由
- 跟踪预测准确率的变化,并完善路由规则
适用场景: 当新事件未分配或类别不正确,且你希望通过自动预测正确的分配群组和类别来减少人工分类所需时间时。
先决条件
- 角色:
itil、incident_manager或assignment_rule_admin - 插件:
com.snc.incident(事件管理) - 访问权限: 对
incident具有读写权限;对sys_user_group、sys_choice、sn_agent_workspace、sys_cs_channel具有读取权限 - 知识: 熟悉组织的支持群组结构和类别体系
- 数据: 至少 3-6 个月的已解决事件数据,以确保预测可靠
流程
步骤 1:获取传入事件
获取需要路由的新事件或未分配事件。
使用 MCP(Claude Code/Desktop):
Tool: SN-Query-Table
Parameters:
table_name: incident
query: active=true^state=1^assignment_groupISEMPTY
fields: sys_id,number,short_description,description,category,subcategory,contact_type,caller_id,cmdb_ci,priority
limit: 25
使用 REST API:
GET /api/now/table/incident?sysparm_query=active=true^state=1^assignment_groupISEMPTY&sysparm_fields=sys_id,number,short_description,description,category,subcategory,contact_type,caller_id,cmdb_ci,priority&sysparm_limit=25
步骤 2:提取关键词和信号
解析事件的简短描述和描述,提取路由信号:
| 信号类型 | 示例 | 权重 |
|---|---|---|
| 技术关键词 | VPN、SAP、Exchange、Oracle、AWS | 0.35 |
| 症状关键词 | 崩溃、缓慢、错误、超时、服务中断 | 0.20 |
| 基础设施术语 | 服务器、数据库、网络、防火墙、负载均衡器 | 0.25 |
| 业务背景 | 薪资、发票、订单、运输、合规 | 0.20 |
根据事件文本构建信号向量,用于与历史数据进行匹配。
步骤 3:查询历史事件以匹配模式
查找描述相似的已解决事件,以确定路由模式。
使用 MCP:
Tool: SN-Query-Table
Parameters:
table_name: incident
query: state=6^resolved_atONLast 180 days@javascript:gs.daysAgoStart(180)@javascript:gs.daysAgoEnd(0)^short_descriptionLIKE[primary_keyword]^assignment_groupISNOTEMPTY
fields: sys_id,number,short_description,category,subcategory,assignment_group,resolved_by,resolve_time
limit: 50
使用 REST API:
GET /api/now/table/incident?sysparm_query=state=6^resolved_atONLast 180 days@javascript:gs.daysAgoStart(180)@javascript:gs.daysAgoEnd(0)^short_descriptionLIKE[primary_keyword]^assignment_groupISNOTEMPTY&sysparm_fields=sys_id,number,short_description,category,subcategory,assignment_group,resolved_by,resolve_time&sysparm_limit=50
步骤 4:排列候选分配群组
汇总历史结果,按适合度对群组进行排序:
评分公式:
group_score = (frequency * 0.40) + (success_rate * 0.30) + (speed_score * 0.30)
其中:
- frequency:该群组解决类似事件的频率(归一化为 0-1)
- success_rate:无需重新分配即可解决的事件百分比(0-1)
- speed_score:相对于 SLA 的平均解决时间的倒数(0-1)
| 排名 | 分配群组 | 频率 | 成功率 | 平均解决时间 | 得分 |
|---|---|---|---|---|---|
| 1 | 网络运营 | 34/50 | 94% | 2.1 小时 | 0.91 |
| 2 | 基础设施团队 | 10/50 | 88% | 3.4 小时 | 0.72 |
| 3 | 服务台 L2 | 6/50 | 70% | 8.2 小时 | 0.48 |
步骤 5:预测类别和子类别
查询有效的类别/子类别组合,并根据内容进行匹配:
使用 MCP:
Tool: SN-Query-Table
Parameters:
table_name: sys_choice
query: name=incident^element=category^inactive=false
fields: sys_id,label,value
limit: 100
使用 REST API:
GET /api/now/table/sys_choice?sysparm_query=name=incident^element=category^inactive=false&sysparm_fields=sys_id,label,value&sysparm_limit=100
将提取的关键词与类似历史事件中最常见的类别进行交叉比对。
步骤 6:根据 Agent Workspace 上下文进行验证
检查事件是否来自 Agent Workspace 或会话渠道,以获取更多上下文:
使用 MCP:
Tool: SN-Query-Table
Parameters:
table_name: sys_cs_channel
query: source_record=[incident_sys_id]
fields: sys_id,channel_type,conversation,state
limit: 5
使用 REST API:
GET /api/now/table/sys_cs_channel?sysparm_query=source_record=[incident_sys_id]&sysparm_fields=sys_id,channel_type,conversation,state&sysparm_limit=5
步骤 7:应用预测的分配
将排名最高的分配群组和预测类别应用到事件:
使用 MCP:
Tool: SN-Update-Record
Parameters:
table_name: incident
sys_id: [incident_sys_id]
data:
assignment_group: [predicted_group_sys_id]
category: network
subcategory: vpn
state: 2
使用 REST API:
PATCH /api/now/table/incident/{sys_id}
Content-Type: application/json
{
"assignment_group": "[predicted_group_sys_id]",
"category": "network",
"subcategory": "vpn",
"state": "2"
}
步骤 8:记录预测依据
使用 MCP:
Tool: SN-Add-Work-Notes
Parameters:
sys_id: [incident_sys_id]
work_notes: |
=== PREDICTIVE ASSIGNMENT ANALYSIS ===
Model: Keyword-Historical Pattern v1.0
Keywords Detected: "VPN", "disconnect", "remote"
Signal Category: Network / VPN
Assignment Group Predictions:
1. Network Operations (score: 0.91, confidence: HIGH)
- 34/50 similar incidents resolved by this group
- 94% first-touch resolution rate
- Avg resolution: 2.1 hours
2. Infrastructure Team (score: 0.72, confidence: MEDIUM)
3. Service Desk L2 (score: 0.48, confidence: LOW)
Category Prediction: Network > VPN
Based on: 68% of similar incidents categorized as Network/VPN
Action Taken: Assigned to Network Operations (highest score)
Fallback: Infrastructure Team if reassigned within 30 minutes
步骤 9:跟踪预测准确率
监控重新分配率,以衡量预测质量:
使用 MCP:
Tool: SN-Query-Table
Parameters:
table_name: incident
query: work_notesLIKEPREDICTIVE ASSIGNMENT^sys_updated_onONLast 30 days@javascript:gs.daysAgoStart(30)@javascript:gs.daysAgoEnd(0)
fields: sys_id,number,assignment_group,reassignment_count,state
limit: 200
需要跟踪的关键指标:
- 首次分配准确率:未被重新分配的预测所占百分比
- 类别准确率:预测类别未被更改的百分比
- 节省的路由时间:从创建到分配所用的时间,与人工处理基准相比
- 重新分配率:预测的分配被覆盖的频率
工具用法
| 工具 | 用途 | 使用时机 |
|---|---|---|
SN-Natural-Language-Search | 以自然语言查找未分配的事件 | 初步发现候选项 |
SN-Query-Table | 查询历史数据、类别和群组 | 模式分析与验证 |
SN-Update-Record | 应用预测的分配和类别 | 路由事件 |
SN-Add-Work-Notes | 记录预测依据 | 审计跟踪与透明度 |
SN-Get-Table-Schema | 发现事件和群组字段 | 设置与配置 |
最佳实践
- 要求最低数据量 —— 如果 short_description 少于 3 个词,则不要进行预测
- 设置置信度阈值 —— 仅当分数 >= 0.75 时自动分配;否则标记以供审核
- 切勿覆盖人工分配 —— 如果人工已分配群组,则不要覆盖
- 遵守优先级升级规则 —— P1 事件始终应由人工确认
- 定期重新训练 —— 随着团队变化,每月重新计算关键词与群组的关联
- 妥善处理新类别 —— 没有历史匹配时,默认分配给 Service Desk L2
- 考虑 CI 关系 —— 如果 cmdb_ci 已填充,请将其支持群组作为强信号
- 监控漂移 —— 当预测准确率低于 80% 时发出警报
故障排除
“预测总是路由到同一个群组”
原因: 历史上某个群组解决了大多数事件,导致频率分数偏高
解决方案: 降低频率的影响,或按类别进行归一化,而非全局归一化。
“类别预测与子类别不匹配”
原因: 类别与子类别存在预测时未强制执行的父子关系
解决方案: 使用 dependent_value 查询 sys_choice,以确保组合有效。
“大多数预测的置信度都很低”
原因: 历史数据不足,或描述过于含糊
解决方案: 扩大历史数据时间范围,或结合基于 CI 的路由以获取更强的信号。
“未找到 Agent Workspace 上下文”
原因: 事件并非通过 Agent Workspace 或 Virtual Agent 创建
解决方案: 门户或电子邮件创建的事件出现此情况是正常的。改用纯文本分析。
示例
示例 1:VPN 连接事件
输入: INC0078901 - “连接到公司网络时 VPN 不断断开”
分析:
- 关键词:“VPN”、“断开”、“已连接”、“公司网络”
- 历史匹配:42 个相似事件,其中 36 个由 Network Operations 解决
- 类别预测:Network > VPN(置信度 86%)
- 首选群组:Network Operations(分数:0.93)
操作: 分配给 Network Operations,类别为 Network/VPN。
示例 2:SAP 授权错误
输入: INC0078902 - “用户 JSMITH 执行 SAP 事务 SU01 时出现授权失败”
分析:
- 关键词:“SAP”、“事务”、“SU01”、“授权”
- 历史匹配:28 个相似事件,其中 24 个由 SAP Basis Team 解决
- 类别预测:Software > ERP(置信度 91%)
- 首选群组:SAP Basis Team(分数:0.95)
操作: 分配给 SAP Basis Team,类别为 Software/ERP。
示例 3:含糊的请求
输入: INC0078903 - “有些东西无法正常工作”
分析:
- 关键词:未检测到具体关键词
- 历史匹配:信号不足
- 置信度:0.22(低于阈值)
操作: 标记以供人工分流。添加工作备注:“信息不足,无法进行预测性分配。建议联系来电者以获取更多信息。”
相关技能
itsm/incident-triage- 手动分诊和确定优先级itsm/case-auto-resolve- 分配后自动解决itsm/incident-lifecycle- 完整的事件管理工作流itsm/suggested-steps- 为已分配的事件生成解决步骤itsm/incident-sentiment- 分析情绪以确定路由优先级