## 服务台工单 SLA 日报 {.case data-case-id="069"} | 字段 | 值 | | --- | --- | | 案例编号 | `069` | | 行业 / 部门 | SaaS / 企业 IT | | 角色 | 服务台负责人 | | 难度 | `进阶` | | 调用来源 | `schedule`（定时由获授权 Agent 经 App/Extension 读取 ITSM 工单统计） | SLA 达标与否等客户投诉或月底复盘才知道，服务台天天救火却说不清哪类工单拖了后腿。目标：每日定时让获授权 Agent 读取 ITSM 系统昨日的工单统计（工单量、首次响应时长、解决时长），把 SLA 违约与临期工单单列成日报，经服务台负责人确认后发到管理频道；回执只用工单编号与状态，不外带工单内容。判定只用系统时间戳，时间戳缺失的工单标"缺失数据·待确认"单独列出，绝不并入任何一类。指标：昨日 SLA 违约与临期工单 100% 出现在当日日报中；时间戳缺失的工单 100% 单列标注、0 例被并入达标或违约统计。 - **覆盖**：定时读取昨日工单统计、按正常/零工单/取数失败三种结果分流、SLA 违约与临期单列、时间戳缺失工单单列、经服务台负责人确认后发管理频道日报。 - **不覆盖**：自动改派工单、自动回复客户、自动计算客户赔付、自动写回 ITSM 系统。 - **假设**：有一个经授权能读取 ITSM 工单统计的 Agent（通过 App/Extension）；SLA 阈值在调用时作为输入提供；首次响应与解决时长只用系统时间戳计算。 把下面这段发给 Loop，它会在后台帮你创建这个 Workflow： ```text 帮我创建一个 Workflow：每日定时由获授权的统计 Agent 经 App/Extension 读取 ITSM 系统昨日工单统计，逐单返回（工单编号、原始时间戳、首次响应时长、解决时长、状态）并汇总工单量，形成 SLA 日报。判定只用系统时间戳：时间戳缺失的工单标"缺失数据·待确认"单独列出，不并入达标或违约任何一类，也不猜测补算。回执遵循最小披露：只用工单编号与状态，不外带工单内容与客户信息。 统计 Agent 回传 JSON：{stat_date: 日期, ticket_count: 非负整数, tickets: [{ticket_ref: 工单编号, first_response_min: 非负数|缺失, resolve_min: 非负数|缺失, status: 枚举(达标|临期|违约)|缺失, ts_missing: 布尔}], source_ok: 布尔, fields_missing: [枚举(ITSM)], audit_ts: 时间戳}。状态矩阵：audit_ts 与 source_ok 始终必填；source_ok=true 时 stat_date、ticket_count、tickets 必填、fields_missing 必为空且 ticket_count 必等于 tickets 长度，tickets 每个元素的 ticket_ref、ts_missing 必填；元素 ts_missing=false 当且仅当两个时长都存在，此时 status 必填，ts_missing=true 当且仅当至少一个时长缺失，此时 status 禁止出现；source_ok=false 时 fields_missing 必为 [ITSM]，stat_date、ticket_count、tickets 全部禁止出现。仅接受这些组合；其余 callback 一律拒绝，原 Effect 保持 awaiting。 触发：定时（计划）发起调用，调用时带入管理频道、SLA 阈值、统计 Agent、审批人和值班频道（值班频道作为调用输入提供，用于失败升级）。 结果分三类处理： 正常（昨日有工单）：汇总工单量与首次响应、解决时长，把 SLA 违约与临期工单各单列一节（附工单编号与状态），连同"缺失数据·待确认"清单一起经服务台负责人确认后发管理频道，并留审计时间戳。 昨日零工单：发一条"昨日零工单"汇总回执并留时间戳，不静默结束，也不当作取数失败。 取数失败（ITSM 不可达或数据陈旧）：告警失败、留审计时间戳，按重试上限重试，仍失败则升级到值班频道（作为调用输入提供）；不当作"昨日零工单"，也不发日报。 审批：日报发出前必须经服务台负责人确认，确认时能看到违约、临期与缺失数据三张单列清单；审批为二值确认或驳回，不设自动超时，无默认通过/否决；驳回则本次失败结束并留审计，不自动改判。 异常：统计 Agent 回传不合结构就停在等待点等它重新提交，不自动重跑；通知发送失败按重试上限重试，仍失败则升级到值班频道并保留待发内容供人工补发。 完成：日报、零工单回执、失败告警各自留审计时间戳后结束。 ``` ![案例 069 服务台工单 SLA 日报：定时让获授权 Agent 经 App/Extension 读取 ITSM 昨日工单统计；判定只用系统时间戳，缺失的工单标缺失数据待确认单列不并入任何一类；正常路径经服务台负责人确认后发管理频道日报（只用工单编号与状态），昨日零工单发零结果回执，ITSM 不可达按取数失败告警留审计重试升级；回传不合结构停在原等待点，驳回则失败结束](../../../media/cases/fig-case-069-01-flow.svg){#fig-case-069-01 width=92%} 如上图所示，正常路径、人工决策与异常同时可见，三种结果都有可见回执： 1. **定时触发**：计划到点（每日）发起一次调用，带入管理频道、SLA 阈值、统计 Agent 与审批人。 2. **读取工单统计**：获授权 Agent 经 App/Extension 读取 ITSM 系统昨日工单统计并逐单回传（工单编号、原始时间戳、首次响应、解决时长、状态）与汇总工单量；回传缺任一必填字段视为不合结构，停在原等待点，等其重新提交，不自动重跑。 3. **三种结果分流**： - **正常（昨日有工单）**：判定只用系统时间戳，SLA 违约与临期工单各单列一节，时间戳缺失的工单标"缺失数据·待确认"单独列出、不并入任何一类；经服务台负责人确认后发管理频道日报，只用工单编号与状态，留审计时间戳。 - **昨日零工单**：发一条零结果汇总回执并留时间戳，不静默结束，也不当作取数失败。 - **取数失败**：ITSM 不可达或数据陈旧，告警失败并留审计时间戳，按重试上限重试，仍失败则升级到值班频道。 你不需要手写代码或配置。把上面的提示词发给 Loop，AI 会理解意图、在后台画出这个"定时取数 + 三路分流 + 发前确认"流程——它知道"读工单统计"需要一个发消息并等待回调的 Agent 环节、"分三种结果"需要一个条件路由、"发前确认"需要一个审批环节、"日报与回执"各需要一个发消息环节，并把它们连起来。AI 还会在后台校验流程结构是否完整，你不必关心这些技术细节。 - **ITSM 不可达或数据陈旧**：不当作"昨日零工单"或静默结束，而是告警失败、留审计时间戳，按重试上限重试；仍失败则升级到值班频道由人工确认。 - **工单时间戳缺失**：判定只用系统时间戳，缺失的工单标"缺失数据·待确认"单独列出，不并入达标或违约任何一类；Agent 不用创建时间或猜测值补算，由服务台负责人确认时决定口径修正。 - **负责人驳回日报**：本次失败结束并留审计；要发就再发起一次确认，没有"AI 自动改判"。 - **日报发送失败**：按重试上限重试投递；超过上限则升级到值班频道，并保留待发内容供人工补发。 - **昨日零工单（结果为 0）**：仍发一条零结果汇总回执并留时间戳，让"没消息"变成可核验的记录，而不是无声结束。 - **统计 Agent 回传不合结构**：本次完成请求被拒绝，停在等待点等其修正后重新提交，不自动重跑。 - **长时间无人审批**：审批本身不设自动超时，流程停在等待状态。若业务需要响应时限，由另一条定时检查的 Workflow（或值班人员）扫出超时项并通知负责人。 日报发出前必须经服务台负责人确认。确认时负责人能看到违约、临期与"缺失数据·待确认"三张单列清单（只含工单编号与状态），所以是"有依据的快速决策"而非盲目拍板。审批只有确认或驳回两种结果，不设自动超时、无默认通过/否决，驳回即本次失败结束并留审计，没有"AI 自动改判"。若要更严（如出现核心客户违约单必须加签值班经理），在提示词里写明，AI 会在流程里多加一个审批环节。 本工作流对 ITSM 工单统计的读取由获授权 Agent 通过 App/Extension 完成，且只读不写——不回写工单状态、不改派、不回复客户，属纯读取场景；工作流本身不直接调用外部系统。管理频道、SLA 阈值与值班频道作为调用输入提供；ITSM 的访问凭据用 `` 占位，由 Agent 运行时从密钥引用。进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志仅记录白名单/令牌化字段（原值不进入以上任何一层），并按 10% 抽查四层实际记录。ITSM 不可达或数据陈旧属于取数失败，走失败回执与升级，不当作"昨日零工单"。回执遵循服务台脱敏：只用工单编号与状态，不外带工单内容与客户信息。 - **回放集与基准**：取最近 30 天 ITSM 工单快照（含达标、违约、临期、时间戳缺失样本）回放，人工基准答案为按 SLA 阈值与系统时间戳算出的违约与临期清单；日报判定与基准一致率 ≥ 95%。 - **缺失数据防线**：时间戳缺失的工单 100% 标"缺失数据·待确认"单独列出、被并入任何一类的为 0 例；不出现用猜测时间戳补算的工单。 - **最小披露**：日报内容 100% 只含工单编号与状态，不含工单内容与客户信息，按 10% 抽样核对；进入 Agent 消息、Run/Activation/Effect 记录与 App/Extension 工具日志的字段 100% 在白名单内（原值不进入以上任何一层），并按 10% 抽查四层实际记录。 - **结果可见**：日报、昨日零工单、取数失败三类结果 100% 各有可见回执，不出现静默成功；日报在服务台负责人确认后 1 小时内发出。 - **分母与口径**：一致率分母为回放工单总数；违约与临期判定只用系统时间戳；每次运行记录读取、确认与发出时间戳。 ### 复用与变体 - **同构迁移**：客服工单首响日报、运维事件单处理时长周报、ITSM 变更单执行情况月报。 - **分级路由**：核心客户违约单确认后同时通知值班经理，普通违约只入日报汇总。 - **写回系统**：确认后再加一个 Agent 环节，由它通过 App/Extension 把"已入日报"标记写回 ITSM 工单；写回须是获授权 Agent 经 App/Extension 的幂等动作（幂等键=工单编号+统计日），响应未知先查后写、按重试上限有限重试、失败升级值班并置"待处理"保留补偿，全程留审计。