gap-analysis

知识缺口分析

概述

此技能提供一种系统化方法，通过将事件和案例数据与现有知识文章关联，找出 ServiceNow 知识库中的缺口。知识缺口会导致解决时间延长、重复升级以及自助服务使用率低。

此技能可帮助你：

• 找出缺少对应知识文章的高频事件类别
• 分析搜索日志，找出返回零条或不相关结果的查询
• 将已解决事件与知识库覆盖情况关联，发现缺失的文档
• 检查反馈信号，找出内容不完整或没有帮助的文章
• 根据事件量、业务影响和解决复杂度，确定文章创建的优先级
• 制定数据驱动的知识创建待办清单

适用时机： 开展季度知识审查期间、注意到特定类别的事件量上升后、自助服务分流率下降时，或引入新的支持领域时。

前提条件

• 角色： knowledge_manager、knowledge_admin，或具有报告访问权限的 itil
• 访问权限： 对 kb_knowledge、incident、sn_customerservice_case、kb_feedback、search_log 和 kb_use 表具有读取权限
• 插件： 已激活 com.glideapp.knowledge（知识管理）
• 推荐插件： 使用 com.glide.search（搜索分析）分析搜索日志
• 知识： 了解事件分类体系和知识库结构

操作步骤

第 1 步：按事件量找出热门事件类别

获取有限数量的事件样本，并在本地按类别和子类别汇总，找出过去 90 天内事件量最高的主题。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^active=false^state=6
  fields: sys_id,category,subcategory
  limit: 1000
  instance: dev

在本地按 (category, subcategory) 统计返回的行数，按计数降序 排序，并保留排名前 25 的结果。由于记录数上限为 1,000，这只是一个样本； 如需完整覆盖，请有计划地进行分页。

使用 REST API：

GET /api/now/stats/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^active=false^state=6&sysparm_group_by=category,subcategory&sysparm_count=true&sysparm_orderby=COUNT&sysparm_limit=25

第 2 步：检查热门类别的知识覆盖情况

针对每个高频类别，搜索涵盖相关主题的已发布文章。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: kb_knowledge
  query: workflow_state=published^kb_category.label=Network^ORshort_descriptionLIKEnetwork
  fields: sys_id,number,short_description,kb_knowledge_base,kb_category,sys_view_count,rating,sys_updated_on
  limit: 20

使用 REST API：

GET /api/now/table/kb_knowledge?sysparm_query=workflow_state=published^kb_category.label=Network^ORshort_descriptionLIKEnetwork&sysparm_fields=sys_id,number,short_description,kb_knowledge_base,kb_category,sys_view_count,rating,sys_updated_on&sysparm_limit=20

第 3 步：找出没有任何 KB 文章覆盖的事件主题

将热门事件类别与知识库覆盖情况交叉比对。查询第 2 步未返回任何文章的类别中的事件。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=6^category=network^subcategory=dns^resolved_byISNOTEMPTY
  fields: sys_id,number,short_description,close_notes,category,subcategory,resolved_by,resolution_code
  limit: 30

使用 REST API：

GET /api/now/table/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=6^category=network^subcategory=dns^resolved_byISNOTEMPTY&sysparm_fields=sys_id,number,short_description,close_notes,category,subcategory,resolved_by,resolution_code&sysparm_limit=30

第 4 步：分析搜索日志，找出失败的查询

找出用户在知识门户中输入但未返回结果或仅返回少量结果的搜索词。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: search_log
  query: sys_created_on>=javascript:gs.daysAgoStart(30)^results_count=0^search_application=knowledge
  fields: sys_id,search_term,results_count,sys_created_on,user
  limit: 50

使用 REST API：

GET /api/now/table/search_log?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(30)^results_count=0^search_application=knowledge&sysparm_fields=sys_id,search_term,results_count,sys_created_on,user&sysparm_limit=50

获取有限数量的失败搜索词样本，然后在本地统计相同的规范化 搜索词，找出最常见的未满足查询：

Tool: SN-Query-Table
Parameters:
  table_name: search_log
  query: sys_created_on>=javascript:gs.daysAgoStart(30)^results_count=0^search_application=knowledge
  fields: sys_id,search_term
  limit: 1000
  instance: dev

第 5 步：查看现有文章的负面反馈

找出用户标记为没有帮助的文章，这可能表明某个主题的内容覆盖不完整。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: kb_feedback
  query: sys_created_on>=javascript:gs.daysAgoStart(90)^rating=not_helpful^ORrating=1
  fields: sys_id,article,article.number,article.short_description,rating,comments,sys_created_on
  limit: 30

使用 REST API：

GET /api/now/table/kb_feedback?sysparm_query=sys_created_on>=javascript:gs.daysAgoStart(90)^rating=not_helpful^ORrating=1&sysparm_fields=sys_id,article,article.number,article.short_description,rating,comments,sys_created_on&sysparm_limit=30

第 6 步：检查未关联 KB 文章的已解决事件

找出未关联知识文章的已解决事件，这表明解决方案是临时处理的，且没有记录成文档。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=6^close_notes!=^kb_knowledgeISEMPTY
  fields: sys_id,number,short_description,close_notes,category,subcategory,assignment_group,resolved_by
  limit: 40

使用 REST API：

GET /api/now/table/incident?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=6^close_notes!=^kb_knowledgeISEMPTY&sysparm_fields=sys_id,number,short_description,close_notes,category,subcategory,assignment_group,resolved_by&sysparm_limit=40

第 7 步：分析 CSM 案例，找出特定服务的知识缺口

如果已启用客户服务管理，请检查缺少知识覆盖的案例主题。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: sn_customerservice_case
  query: opened_at>=javascript:gs.daysAgoStart(90)^state=3^knowledge=false
  fields: sys_id,product,category
  limit: 1000
  instance: dev

在本地按 (product, category) 统计行数，并保留排名前 20 的结果。除非明确对完整日期范围进行分页，否则请将结果视为有限样本。

使用 REST API：

GET /api/now/stats/sn_customerservice_case?sysparm_query=opened_at>=javascript:gs.daysAgoStart(90)^state=3^knowledge=false&sysparm_group_by=product,category&sysparm_count=true&sysparm_limit=20

步骤 8：构建优先级缺口报告

将发现汇总为优先级列表。根据事件数量、业务影响和解决复杂度，为每项缺口评分。

缺口评分矩阵：

因素	权重	评分范围
事件数量（90 天）	40%	根据数量评分，1-5 分
事件平均优先级	25%	1-5 分（P1=5，P5=1）
搜索失败频率	20%	根据数量评分，1-5 分
负面反馈数量	15%	根据数量评分，1-5 分

步骤 9：创建知识缺口记录

将已识别的缺口记录为知识作者的任务。

使用 MCP：

Tool: SN-Create-Record
Parameters:
  table_name: kb_submission
  data:
    short_description: "Knowledge Gap: DNS Configuration Troubleshooting"
    description: "Gap Analysis identified 47 resolved incidents in 90 days for DNS configuration issues with no matching KB article. Top search terms: 'dns settings', 'dns not resolving', 'configure dns'. Priority score: 4.2/5."
    kb_knowledge_base: [target_kb_sys_id]
    category: Network
    assignment_group: Knowledge Authors

使用 REST API：

POST /api/now/table/kb_submission
Content-Type: application/json

{
  "short_description": "Knowledge Gap: DNS Configuration Troubleshooting",
  "description": "Gap Analysis identified 47 resolved incidents...",
  "kb_knowledge_base": "[target_kb_sys_id]",
  "category": "Network",
  "assignment_group": "[group_sys_id]"
}

工具用法

MCP 工具参考

工具	使用时机
SN-Query-Table	查询事件、文章、反馈和搜索日志；检索范围受限的字段，以便在本地汇总
SN-Natural-Language-Search	使用自然语言搜索主题覆盖情况
SN-Create-Record	为缺口创建知识提交记录
SN-Add-Work-Notes	在现有记录中记录分析发现

REST API 参考

端点	方法	用途
/api/now/table/incident	GET	查询已解决的事件
/api/now/stats/incident	GET	汇总事件数据
/api/now/table/kb_knowledge	GET	检查现有文章的覆盖情况
/api/now/table/search_log	GET	分析失败的搜索查询
/api/now/table/kb_feedback	GET	查看文章的负面反馈
/api/now/table/kb_submission	POST	创建知识缺口记录

最佳实践

• 定期执行： 每月或每季度进行缺口分析，及时跟进新兴主题
• 使用多种信号： 结合事件数据、搜索日志和反馈，全面了解情况；单一来源无法反映全貌
• 聚焦已解决的事件： 仅分析已关闭或已解决，且解决方案记录在结案备注中的事件
• 邀请 SME 参与： 与主题专家分享缺口发现，由他们验证并确定文章创建的优先级
• 跟踪转移影响： 衡量填补已识别缺口前后的事件转移率
• 考虑自助服务： 优先处理可支持终端用户自助服务的缺口，而非仅供内部使用的文档缺口
• 过滤噪声： 排除一次性事件，聚焦出现 5 次以上的重复模式

故障排除

“搜索日志表为空或无法访问”

原因： 搜索分析插件未激活，或未启用搜索日志记录
解决方案： 确认 com.glide.search 已启用，且属性 glide.ts.search.log 已设为 true

“事件类别与知识库类别不匹配”

原因： 事件分类与知识分类使用了不同的分类体系
解决方案： 在事件类别/子类别与知识库类别标签之间创建映射表，以便准确交叉引用

“返回的事件过多，且没有知识库链接”

原因： 未强制执行以知识为中心的服务（KCS）实践；Agent 未关联文章
解决方案： 按预期使用 KCS 的分配组筛选，并聚焦于已有文章但未附加文章的类别

“聚合查询超时”

原因： 事件表过大，日期范围过宽
解决方案： 将日期范围缩短至 30 天，或按特定分配组或类别筛选

示例

示例 1：发现网络 DNS 知识缺口

分析：

• 90 天内有 47 个已解决事件属于“DNS”子类别
• 搜索“dns settings”和“dns not resolving”时，有 23 次知识搜索失败
• 没有已发布的知识库文章与 DNS 配置相关
• 事件平均优先级：P3

缺口评分： 4.2/5（事件数量多，搜索失败频繁）

建议： 创建一篇全面的 DNS 故障排除文章，涵盖常见配置错误、解决步骤和升级处理途径。分配给网络运营知识作者。

示例 2：新员工入职知识缺口

分析：

• 90 天内，「账户设置」类别发生了 112 起事件
• 搜索「新员工访问权限」「第一天设置」「入职清单」失败 45 次
• 找到 2 篇现有知识库文章，但两篇都被评为「没有帮助」（收到 8 条负面反馈）
• 现有文章已有 18 个月历史，且引用了已弃用的工具

缺口评分： 4.8/5（数量非常多，现有内容已过时）

建议： 停用过时文章，并创建一份全新的综合入职指南。与 HR 和 IT 协调，涵盖所有配置步骤。由于会影响新员工的工作效率，应设为高优先级。

示例 3：CSM 产品退货知识缺口

分析：

• 有 38 个「产品退货」客户服务案例未标记知识标记
• 门户中搜索「退货政策」「退货标签」「退款状态」失败 15 次
• 外部客户知识库中没有已发布的文章

缺口评分： 3.9/5（数量中等，对客户有影响）

建议： 创建一篇面向客户的文章，涵盖退货资格、流程步骤、标签生成和退款时限。将文章发布到外部知识库，以便客户自助解决问题，减少客服需求。

相关技能

• knowledge/duplicate-detection - 在进行缺口分析前清理冗余文章
• knowledge/content-recommendation - 为事件推荐现有文章
• knowledge/article-generation - 根据已解决的事件生成文章，以填补缺口
• knowledge/gap-grouping - 按主题对已识别的知识缺口进行聚类和优先级排序