OP-03 · 客户工单回复与进度通知

① 场景引入

一、这件事现在是什么样

算力运营与客户服务 · 真实业务触发

8 月 21 日凌晨 2:30，星澜科技的工程师在群里 @ 值班：「训练任务 iter time 从 0.87 秒涨到 1.42 秒，什么情况？」——此时机房正在处置告警，值班员要同时面对三件事：查原因、安抚客户、不能说错话（每句话都是将来的 SLA 证

据）。

二、痛点 · 每条都有来源

1. 中小 IDC 客户服务还在「电话找工程师、微信发截图」阶段 —— 工单上了系统客户还是打电话，因为系统里的回复没法当证据用
   依据：中小 IDC 客户服务大量还在「电话找工程师、微信发截图」阶段 —— 上了工单系统但客户还是打电话，说明系统没被用起来
2. SLA 合同约定投诉受理后 24 小时内出书面报告 —— 客户群里随口的一问一句承诺，都在为将来的争议埋伏笔
   依据：IDC 托管 SLA 协议明确约定：受理投诉后 24 小时内向甲方提供第一份书面形式的投诉处理情况报告 —— 故障后的文书压力是合同刚性的
3. 故障处置与客户沟通是两件事同时压一个人 —— 误告警半夜频繁响起的值守现实下，回复质量全凭个人状态
   依据：「凌晨业务流量极低，CPU、内存偶尔小幅波动就触发固定阈值告警，手机铃声半夜频繁响起，起床排查后发现是误报」—— 夜班误告警的第一人称自述4「传统的做法靠纸质工单或者微信群通知，效率低还容易丢」—— 群里的口头结论三天后就找不到了，SLA 争议时谁都拿不出完整沟通记录依据 ·「传统的做法靠纸质工单或者微信群通知，效率低还容易丢」—— 微信群是隐形的生产系统，客户报障、跨班组协作、变更通知大量在里面

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 中小 IDC 客户服务还在「电话找工程师、微信发截图」阶段 —— 工单上了系统客户还是打电话，因为系统里的回复没法当证据用
• SLA 合同约定投诉受理后 24 小时内出书面报告 —— 客户群里随口的一问一句承诺，都在为将来的争议埋伏笔
• 故障处置与客户沟通是两件事同时压一个人 —— 误告警半夜频繁响起的值守现实下，回复质量全凭个人状态「传统的做法靠纸质工单或者微信群通知，效率低还容易丢」—— 群里的口头结论三天后就找不到了，SLA争议时谁都拿不出完整沟通记录

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 工单结构化 · 群消息变成正经工单谁报的、影响什么、紧急程度、涉及哪个区 —— 群里的随口一问变成结构化工单
2. 客户档案对齐 · 这位客户的服务边界他的 SLA 承诺、配额、所在区域、历史问题 —— 回复的口径由这些决定
3. 回复草拟 · 能说的、不能说的、待核实的事实（时间线）+ 已采取的动作 + 下一步与更新时限；结论未定的事标注「排查中」，不写任何补偿性表述
4. 进度通知 · 主动更新而不是被追着问按约定时点（如每 2 小时）生成进度通知草稿 —— 客户体验的差别就在「主动告知」与「追问」之间
5. 留痕归档 · 沟通记录进工单档案本轮沟通全部归档并与事件编号关联 —— SLA 争议时的完整证据链

要准备什么：客户消息与群聊记录（触发时刻）客户问了什么、语气如何、着急程度该客户的配置档案（机柜区/IP 段/配额/合同 SLA）谁在问，他的服务边界是什么当前事件的状态快照（告警/处置进度）此刻能说什么、不能说什么历史工单与该客户过往沟通记录同样的问题上次怎么答的、承诺过什么

为什么这个场景值得做

优先级评分：痛感 3 × AI 适配 4 ÷ 落地难度 2 = 7.2

最大差异点：与智能客服机器人的区别：机器人答的是 FAQ（机房几点能进场），本场景处理的是事件级沟通 ——每条回复都从事件的真实数据里长出来（该客户哪个区、哪个任务、什么时间线），且每句都标注与事实记录的对应关系，留痕归档。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：客户沟通记录归档.xlsx 正式件 · 本轮沟通与事件关联 · 留痕
• 可派发清单：工单与回复草稿.xlsx 可派发 · 结构化工单与审定后回复

这套东西不承诺什么：不替人做对外承诺（补偿、赔付、时限承诺一律不写死，只写事实与下一步）。回复草稿须经值班工程师审定后发出 —— 发出去的是人的话，不是 AI 的话。「原因已查明」这类结论性表述在根因确认前不出。想看具体怎么跑？Live Demo 里有一个完整案例的每一步，包括 Agent 在哪一步拦住了

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：云枢智算 8 月 21 日凌晨。02:30 星澜科技训练平台工程师在客户群里 @ 值班：「训练任务 iter time 从 0.87涨到 1.42，什么情况？」此时 A12 模块降频已持续43 分钟、原因未定，维修厂商还在联系提前进场。夜班值班员孙倩要同时干三件事：查原因、安抚客户、保证说出去的每句话经得起将来翻合同 —— 今年 2 月那次随口一句「大概一小时恢复」，在续约谈判里被客户拿出来用了三次。回复草稿写完，要过值班工程师审定才能发：发出去的是公司的话。

触发工单8.21 02:30 星澜群问 iter time 0.87→1.42 秒（WO-0821-01）事件状态处置中 · 降频净持续 5.2 小时 · 08:00 任务迁移回复口径事实 + 动作 + 下次更新时间（05:00 前），不写恢复时间与补偿结论草稿经值班工程师审定后发出

输入算力基础设施企业手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_客户群消息_8.21凌晨.txt 星澜科技客户群 8 月 21 日 02:30-08:30 完整对话（值班手机截图转文字）值班群 · 8 月 21日归档到工单
• 02_星澜科技客户档案.xlsx 星澜科技的配置档案：租用、月费、SLA 承诺、历史敏感点 —— 回复口径由这些决定客户经理吴敏维护 · 历史敏感点一栏 2 月新增
• 03_事件状态快照_8.21凌晨.xlsx 8.21 事件当前状态：动环告警、处置进度 —— 此刻能说什么、不能说什么的依据值班记录 + 动环后台 + 工单系统三源汇总
• 04_星澜历史工单与沟通记录.xlsx 星澜过去 6 个月工单与沟通记录 —— 上次怎么答的、承诺过什么、被引用过什么工单系统导出 · 平时没人翻，出事才调

注意标橙色那一份 —— 04_星澜历史工单与沟通记录.xlsx。它工单系统导出 · 平时没人翻，出事才调，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

星澜的工程师凌晨在群里问任务变慢的事，事件还在处置中。客户的配置档案、当前告警状态和上次的沟通记录都在这里。 帮我起草回复：发生了什么、我们在做什么、下次什么时候更新。 别写任何补偿和恢复时间的承诺，原因没定论之前别下结论。写完我自己过一遍再发。

回复的口径规则（事实+动作+下一步，不承诺恢复时间与补偿）已内置，客户只需提供聊天记录与档案。

触发事情是这么来的

客户半夜问「我的任务怎么了」，值班的人一个人扛着三件事

8 月 21 日 02:30，星澜科技训练平台工程师在群里 @ 值班：「训练任务 iter time 从 0.87 涨到 1.42，什么情况？」此时A12 模块降频已持续 43 分钟、原因未定。夜班值班员孙倩要同时干三件事：查原因、安抚客户、保证每句话经得起将来翻合同 —— 群里的每一句回复，将来都是 SLA 争议时的证据。

第 1 步 · 工单结构化 · 群消息变成正经工单

谁报的、影响什么、紧急程度、涉及哪个区 —— 随口一问变成可追溯的记录

第 2 步 · 客户档案对齐 · 这位客户的服务边界

他的 SLA、配额、历史承诺 —— 回复口径的边界由这些决定

这一步的看点 · 从历史里想起了公司踩过的坑今年 2 月值班员那句「大概一小时恢复」—— 实际用了 4 小时，续约谈判时被客户拿出来用了三次，档案里就记着这一条。这次草稿里所有时限表述都改成「下次更新时间」：05:00 前同步、08:30 再同步 —— 更新承诺我们守得住，恢复时间在根因没定时谁都给不了。这个口径的坑，踩过一次就够了。3回复草拟 · 能说的、不能说的、待核实的

事实（时间线）+ 已采取的动作 + 下次更新时限；结论未定的事标注排查中

回复段落草稿内容对应事实记录事实A12 模块 01:47 起部分节点进风温度偏高，触发降频保护，您的 iter time 变化与此相关动环告警 01:47 · 事件快照排除初步判断不是您侧代码问题 —— 同模块其他客户节点同步出现时钟下降，问题在基础设施侧值班初判 02:47 · 快照已做动作已上报集群组长；受影响任务迁移评估进行中；维修厂商已在协调提前进场工单 WO-0821-01 · 快照下次更新05:00 前主动同步进展（无论是否有结论）口径规则不写的内容预计恢复时间 / 补偿金额 /「原因已查明」2 月教训 + 审定规则审定值班工程师审定后发出 —— 发出去的是公司的话，不是值班员的话—

这一步的看点 · 该拦的地方拦住了草稿结论：「本轮回复不包含任何补偿性表述 —— 事件原因尚未定责，涉及定责的结论一个字都不出」。02:36 客户主动问「是不是我们代码的问题」—— 排除客户侧可以马上给（有数据）；但「原因已查明」不能给（没定论）：先认再翻供的被动，比晚说半小时贵得多。

第 4 步 · 进度通知 · 主动更新而不是被追着问

按承诺时点推送 —— 客户体验的差别就在主动告知与追问之间

这一步的看点 · 排除性结论「客户侧代码变更可以排除 —— 与其任务同模块的其他客户节点同步出现 SM Clock 下降，问题在基础设施侧」。这句话 02:52 就给出去了 —— 02:36 客户自己都在怀疑是不是晚上改的那版数据加载脚本。第一时间把这句给出去，客户当晚就不用自查，愤怒值直接降一半，剩下的沟通全部对准处置。

第 5 步 · 留痕归档 · 沟通记录进工单档案

本轮沟通全部归档并与事件编号关联 —— SLA 争议时的完整证据链

这一步的看点 · 把技术动作翻译成钱按星澜口径粗算：整个 30 节点训练任务受影响 5.2 小时 = 30 × 8 × 5.2 = 1,248 卡时，按卡时单价 10.92 元折算约 1.4 万 —— 这笔账我们比客户先算出来，进 OP-01 月报按合同口径核算。真正的大数是：星澜年合同 2,340 万（195 万 × 12），2 月那句「大概一小时」在谈判桌上被引用了三次 —— 口径值多少钱，续约的时候才知道。

草稿能用，但不能直接发草稿已成形，但发出前必须过值班工程师审定 —— 发出去的是公司的话，不是值班员的话。事件仍在处置中（08:00 迁移、厂商进场都在执行），任何口径失误都会在月度核算（OP-01）和续约谈判里被放大。方案一：按本轮草稿口径发 —— 事实 + 排除 + 动作 +「05:00 前下次更新」，值班工程师审定后 10 分钟内发出；本轮不提补偿，影响账（约 1.4 万，1,248 卡时 × 10.92 元）留给月报按合同口径算 —— 客户体验优先，金额争议后置。方案二：若客户在群里直接追问「会不会补偿」—— 回复仍不接金额，只回「本次事件的影响我们将按合同第 6 条（月费 195 万的阶梯口径）在月报中如实核算，结果由客户经理书面同步」—— 把金额话题从凌晨的群里挪到白天的正式渠道，商务接得住，9 月 5 日月报（OP-01）就是接的那个盘子。

之后这一次跑完，公司多了什么

不讲省了多久：讲少了几个隐患、沉淀了什么

• ✓ 群消息变成结构化工单 —— SLA 争议时拿得出完整沟通证据链
• ✓ 「下次更新时间」替代「预计恢复时间」的口径固定下来 —— 2 月那种承诺陷阱不会重演
• ✓ 进度通知从被动应答变成主动推送 —— 客户体验的改善直接进续约谈判
• ✓ 值班工程师在故障处置与客户沟通的双线压力下有了支撑 —— 回复质量不再取决于凌晨三点的状态

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 客户就是想要个恢复时间怎么办？ 给「下次更新时间」而不是「恢复时间」—— 更新承诺我们守得住，恢复时间在根因没定时谁都给不了。给了就是埋雷。
• AI 直接回复客户会不会更快？ 草稿秒出，但发出必须人过目 —— 发出去的话是公司的承诺，AI 不替人担这个责。审定一遍比从零写快得多，这就是价值。
• 每个客户的话术都要单独配吗？ 口径规则是统一的，客户档案（SLA/配额/历史）各自加载 —— 新客户第一次用建档，之后全自动。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

客户工单回复与进度通知 —— 客户半夜问「机器怎么了」，值班的人不该一个人扛 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

customer-ticket-reply.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是算力基础设施企业手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁OP-03 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

• 01_客户群消息_8.21凌晨.txt 星澜科技客户群 8 月 21 日 02:30-08:30 完整对话（值班手机截图转文字）
• 02_星澜科技客户档案.xlsx 星澜科技的配置档案：租用、月费、SLA 承诺、历史敏感点 —— 回复口径由这些决定下载
• ↓XLS03_事件状态快照_8.21凌晨.xlsx 8.21 事件当前状态：动环告警、处置进度 —— 此刻能说什么、不能说什么的依据
• 04_星澜历史工单与沟通记录.xlsx 星澜过去 6 个月工单与沟通记录 —— 上次怎么答的、承诺过什么、被引用过什么

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

星澜的工程师凌晨在群里问任务变慢的事，事件还在处置中。客户的配置档案、当前告警状态和上次的沟通记录都在这里。 帮我起草回复：发生了什么、我们在做什么、下次什么时候更新。 别写任何补偿和恢复时间的承诺，原因没定论之前别下结论。写完我自己过一遍再发。

为什么这么短就够了：回复的口径规则（事实+动作+下一步，不承诺恢复时间与补偿）已内置，客户只需提供聊天记录与档案。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 2 份

• OP-03_客户沟通记录归档.xlsx 正式件 · 本轮沟通与事件关联 · 留痕
• OP-03_工单与回复草稿.xlsx 可派发· 结构化工单与审定后回复

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：客户消息与群聊记录（触发时刻）客户问了什么、语气如何、着急程度该客户的配置档案（机柜区/IP 段/配额/合同 SLA）谁在问，他的服务边界是什么当前事件的状态快照（告警/处置进度）此刻能说什么、不能说什么历史工单与该客户过往沟通记录同样的问题上次怎么答的、承诺过什么

人工边界：不替人做对外承诺（补偿、赔付、时限承诺一律不写死，只写事实与下一步）。回复草稿须经值班工程师审定后发出 —— 发出去的是人的话，不是 AI 的话。「原因已查明」这类结论性表述在根因确认前不出。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

算力运营与客户服务 · 产出即下一步输入

• OP-01 · 客户 SLA 月报与赔付预警：月报是续约与赔付的依据，不是形象工程
• OP-02 · 闲置算力盘点与资金占用报告：每天一睁眼，两百台机器在替你烧钱

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。