incident-sentiment

事件情绪分析

概述

此技能会分析与事件相关的沟通内容——工作备注、附加评论、电子邮件往来和活动日志条目——以检测负面趋势、预测升级风险，并在事件生命周期内跟踪客户满意度。

• 提取并分析工作备注、评论和电子邮件沟通中的文本
• 将情绪分类为积极、中性、消极或危急
• 根据情绪变化轨迹和语言信号计算升级风险分数
• 在客户正式升级问题前识别心怀不满的客户
• 跟踪事件各生命周期阶段的情绪趋势
• 生成考虑情绪因素的优先级建议

适用场景： 监控活动事件的升级风险、分析客户满意度模式，或为存在风险的工单构建主动干预工作流时。

前提条件

• 角色： itil、incident_manager 或 analytics_admin
• 插件： com.snc.incident（事件管理）
• 访问权限： 对 incident、sys_journal_field、sn_si_incident、sys_audit、sys_email 具有读取权限
• 知识： 了解所在组织的升级标准和 SLA 阈值
• 数据： 用于分析、包含工作备注和客户沟通记录的事件

操作步骤

步骤 1：选择要进行情绪分析的事件

查询活动事件，优先选择近期有活动或即将违反 SLA 的事件。

使用 MCP（Claude Code/Desktop）：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: active=true^priorityIN1,2^sys_updated_on>=javascript:gs.hoursAgo(24)
  fields: sys_id,number,short_description,priority,state,assigned_to,assignment_group,sla_due,sys_updated_on
  limit: 30

使用 REST API：

GET /api/now/table/incident?sysparm_query=active=true^priorityIN1,2^sys_updated_on>=javascript:gs.hoursAgo(24)&sysparm_fields=sys_id,number,short_description,priority,state,assigned_to,assignment_group,sla_due,sys_updated_on&sysparm_limit=30

步骤 2：检索工作备注和评论

提取每个事件的所有日志条目（工作备注和附加评论）。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: sys_journal_field
  query: element_id=[incident_sys_id]^elementINwork_notes,comments^ORDERBYsys_created_on
  fields: sys_id,element,value,sys_created_by,sys_created_on
  limit: 50

使用 REST API：

GET /api/now/table/sys_journal_field?sysparm_query=element_id=[incident_sys_id]^elementINwork_notes,comments^ORDERBYsys_created_on&sysparm_fields=sys_id,element,value,sys_created_by,sys_created_on&sysparm_limit=50

步骤 3：检索电子邮件沟通记录

检查与事件相关的电子邮件往来。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: sys_email
  query: instance=[incident_sys_id]^type=received
  fields: sys_id,subject,body_text,sender,sys_created_on
  limit: 20

使用 REST API：

GET /api/now/table/sys_email?sysparm_query=instance=[incident_sys_id]^type=received&sysparm_fields=sys_id,subject,body_text,sender,sys_created_on&sysparm_limit=20

步骤 4：对每条记录进行情绪分类

分析每条文本记录并指定情绪分类：

情绪	分数范围	指标
危急	-1.0 至 -0.7	威胁、脏话、提及向高管升级、法律相关表述
消极	-0.7 至 -0.3	沮丧、反复投诉、紧急措辞、全大写文字
中性	-0.3 至 0.3	事实更新、状态查询、技术信息
积极	0.3 至 0.7	表示感谢、认可、表达满意
非常积极	0.7 至 1.0	明确赞扬、问题已解决且客户满意

消极情绪关键词和短语：

类别	关键词 / 短语	权重
沮丧	"still not working"、"again"、"how many times"、"unacceptable"	-0.4
紧急	"ASAP"、"immediately"、"critical"、"business impact"、"revenue loss"	-0.3
升级意图	"manager"、"supervisor"、"escalate"、"executive"、"CIO"	-0.5
不满意	"disappointed"、"poor service"、"no response"、"ignored"	-0.4
威胁	"legal"、"contract"、"SLA penalty"、"vendor review"	-0.6
再次联系	"calling again"、"third time"、"follow up again"	-0.3

积极情绪关键词和短语：

类别	关键词 / 短语	权重
感谢	"thank you"、"appreciate"、"great job"、"helpful"	+0.4
解决	"fixed"、"working now"、"resolved"、"all good"	+0.5
认可	"understand"、"makes sense"、"will try that"	+0.2

步骤 5：计算升级风险分数

根据情绪变化趋势计算总体升级风险分数：

escalation_risk = (current_sentiment * 0.40)
                + (sentiment_trend * 0.25)
                + (sla_proximity * 0.20)
                + (reassignment_count * 0.15)

其中：

• current_sentiment：最新情绪分数（反转：-1.0 的严重负面情绪 = 1.0 风险）
• sentiment_trend：变化速率（情绪恶化 = 风险更高）
• sla_proximity：距离 SLA 违约的接近程度（0.0 = 时间充裕，1.0 = 已违约）
• reassignment_count：标准化后的重新分配次数（每次重新分配都会增加摩擦）

风险等级	分数	建议操作
低	0.0-0.3	继续正常处理
中等	0.3-0.5	提高监控频率
高	0.5-0.7	通知团队负责人，考虑主动联系
严重	0.7-1.0	需要经理立即介入

步骤 6：检查结构化事件数据

查询结构化事件情报表，获取其他信号。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: sn_si_incident
  query: incident=[incident_sys_id]
  fields: sys_id,incident,sentiment_score,customer_effort_score,escalation_likelihood
  limit: 1

使用 REST API：

GET /api/now/table/sn_si_incident?sysparm_query=incident=[incident_sys_id]&sysparm_fields=sys_id,incident,sentiment_score,customer_effort_score,escalation_likelihood&sysparm_limit=1

步骤 7：生成情绪报告

生成逐个事件的情绪分析报告：

使用 MCP：

Tool: SN-Add-Work-Notes
Parameters:
  sys_id: [incident_sys_id]
  work_notes: |
    === SENTIMENT ANALYSIS REPORT ===
    Incident: [number]
    Analysis Date: [current_date]
    Entries Analyzed: [count]

    SENTIMENT TIMELINE:
    [timestamp] Comment (Customer): NEGATIVE (-0.6)
      "This is the third time I've called about this issue..."
    [timestamp] Work Note (Agent): NEUTRAL (0.1)
      "Reassigned to Network team for further investigation"
    [timestamp] Comment (Customer): CRITICAL (-0.8)
      "I need this escalated to management immediately..."

    CURRENT SENTIMENT: CRITICAL (-0.8)
    SENTIMENT TREND: Worsening (declined -0.4 over 48 hours)
    ESCALATION RISK: HIGH (0.78)

    RISK FACTORS:
    - Customer used escalation language ("management", "escalate")
    - Third contact about same issue (repeat contact indicator)
    - SLA at 85% consumed with no resolution path identified
    - Two reassignments in 48 hours

    RECOMMENDED ACTIONS:
    1. Immediate callback from team lead or manager
    2. Provide clear timeline for resolution
    3. Offer interim workaround if available
    4. Document escalation handling in work notes

步骤 8：批量分析情绪趋势

分析多个事件的情绪，以检测模式。

使用 MCP：

Tool: SN-Query-Table
Parameters:
  table_name: incident
  query: active=true^assignment_group=[group_sys_id]
  fields: sys_id,number,priority,state,assignment_group,sys_updated_on
  limit: 100

汇总指标：

指标	值	基准
平均情绪分数	-0.22	-0.10
情绪负面的事件	34%	20%
情绪严重负面的事件	8%	3%
情绪预测的升级事件	12	--
已验证的实际升级事件	10	--
预测准确率	83%	--

步骤 9：设置主动预警

为基于情绪的自动预警设定阈值：

使用 MCP：

Tool: SN-Update-Record
Parameters:
  table_name: incident
  sys_id: [incident_sys_id]
  data:
    work_notes: "SENTIMENT ALERT: Escalation risk score exceeded 0.7. Automated notification sent to incident manager. Customer sentiment has declined from neutral to critical over the last 3 interactions."
    urgency: 1

工具用法

工具	用途	使用时机
SN-Natural-Language-Search	使用自然语言条件查找事件	初步发现
SN-Query-Table	获取日志条目、电子邮件和事件数据	核心数据收集
SN-Update-Record	标记有风险的事件，更新紧急程度	主动干预
SN-Add-Work-Notes	记录情绪分析结果	报告和审计追踪
SN-Get-Table-Schema	探索情绪数据的表结构	设置和发现

最佳实践

1. 分析两个渠道 —— 工作备注反映 Agent 的视角，评论反映客户的视角；两者都很重要
2. 提高近期条目的权重 —— 最近的沟通是最强的信号
3. 考虑技术语言 —— 在技术语境中使用的“严重”（如严重故障的服务器），与情绪语境中使用的“批评”（如批评支持服务）含义不同
4. 跟踪变化趋势，而不只是静态结果 —— 情绪分数从此前的正面转为中性，比始终稳定在中性更值得关注
5. 结合结构化数据 —— 单靠情绪分析并不足够；还应交叉参考 SLA 状态、重新分配次数和优先级
6. 尊重隐私 —— 情绪分析应关注服务质量，而非为个别客户建立档案
7. 按团队校准阈值 —— 不同支持团队的情绪基准模式可能不同
8. 根据分析结果采取行动 —— 不采取干预措施的情绪分析毫无价值；确保预警能触发实际行动

故障排除

“未找到事件的日志条目”

原因： 工作备注和评论存储在 sys_journal_field 中，事件的 sys_id 作为 element_id 解决方案： 确认查询使用 element_id（而非 sys_id）来匹配事件记录。还要检查是否存在日志条目——新事件可能还没有日志条目。

“情绪分数似乎不准确”

原因： 技术行话、缩写或特定领域的语言可能会干扰情绪分析 解决方案： 建立特定领域的关键词词典。“终止进程”或“结束会话”等说法指的是技术操作，并非负面情绪。

“升级警报误报过多”

**原因：**阈值过于敏感，或未根据你的环境进行校准 **解决方案：**分析历史升级数据。逐步提高阈值，直到误报率降至 15% 以下。可考虑要求连续出现多条负面记录后再发出警报。

“电子邮件的 body_text 为 HTML 格式”

**原因：**电子邮件在 sys_email 中以 HTML 标记存储 **解决方案：**在情感分析前剥除 HTML 标签。重点分析 body_text，而不是 body 字段，或进行 HTML 到文本的转换。

示例

示例 1：及早发现升级风险

**事件：**INC0056789 - “市场部的电子邮件服务器宕机”

情感变化时间线：

• 第 0 小时：中性（0.0）- “我们团队无法使用电子邮件”
• 第 4 小时：负面（-0.4）- “仍然没有进展，这影响了我们的营销活动发布”
• 第 8 小时：严重负面（-0.8）- “无法接受。我需要立即请 CIO 办公室介入”

**升级风险：**0.82（严重） **操作：**事件经理在 15 分钟内致电客户，提供处理时间表和临时解决方案，避免了正式升级至高管层。

示例 2：跟踪问题的正面解决情况

**事件：**INC0056790 - “通过 VPN 无法访问共享驱动器”

情感变化时间线：

• 第 0 小时：中性（0.0）- “通过 VPN 连接时，我看不到共享驱动器”
• 第 2 小时：中性（0.1）- “谢谢你们调查此事”
• 第 3 小时：正面（0.6）- “问题解决了，驱动器映射现在可以正常工作了。谢谢！”

**升级风险：**0.05（低） **操作：**无需干预。事件已解决，客户反馈积极。

示例 3：发现不易察觉的挫败情绪

**事件：**INC0056791 - “4 楼打印机无法打印”

情感变化时间线：

• 第 1 天：中性（0.0）- “401 室的打印机无法打印”
• 第 3 天：轻微负面（-0.2）- “跟进一下此事，打印机仍然无法使用”
• 第 5 天：负面（-0.5）- “这是我第三次跟进了。我们团队已经一周没有打印机可用。”

**升级风险：**0.61（高） **操作：**已向团队负责人发送警报。Agent 致电客户，安排备用打印机并升级处理维修事宜。

相关技能

• itsm/incident-triage - 根据情感分析结果确定优先级并进行分诊
• itsm/suggested-steps - 为存在风险的事件生成解决步骤
• csm/sentiment-analysis - 客户服务管理情感分析
• hrsd/sentiment-analysis - HR 案例情感分析
• itsm/major-incident - 重大事件管理与利益相关方沟通