OP-02 · 信号投诉根因关联
用户说没信号，数要说清是哪一段的锅
痛点 投诉单上写着「信号差」 · 真正要回答的是「谁的锅」
① 场景引入
一、这件事现在是什么样
网络质量优化 · 真实业务触发
客服批量转来滨湖片区 47 件信号类投诉，要求 7 个工作日内逐件回复；网优班长要在回复里写清「网络侧 / 用户侧 /覆盖侧」归因，写错归因，下一周同类投诉还会再来一遍。
二、痛点 · 每条都有来源
1网维岗「不再单纯做无线优化，新增大量台账填报、投诉处理、市场支撑、各类专项报表」——投诉处理是网优背上最重的杂活依据 · 代维 20 年从业者自述：运维困境、双系统回单、人员与指标恶性循环2投诉工单与 KPI 数据、参数台账、故障工单分散在四套系统，逐件关联靠人工，一个片区 40 多件投诉至少一整天依据 · 集中化故障管理流程：代维双系统回单、事故报告法定栏位（报告单位盖章、时间精确到分、主送单位、是否上报通管局）3归因写「已优化」但用户感知没变，二次投诉升级为越级申诉——每件越级申诉按细则扣考核分，责任人另罚 300-2000 元依据 · 淄博铁通越级投诉管理案例：越级投诉的认定与处置流程4用户感知劣化往往先于 KPI 劣化出现，但没人把「投诉时间点」与「指标拐点」「参数调整日」放在同一条时间轴上看过依据 · 网优工程师的一天：9 点半盯 KPI、异常小区根因分析、MML 调参、处理工单、17 点写日报更新台账5广电 192 类跨网投诉要在两家公司间流转，「投诉单跨过一道公司边界，落到另一个考核体系里」，时限对不上、责任说不清依据 · 广电 192 跨网投诉归属：一张投诉单跨两家公司、两个考核体系，时限与责任错位
三、换个做法之后
变化不在「快」，在「参与的角色」和「覆盖的范围」
✕ 现在的做法
- 网维岗「不再单纯做无线优化，新增大量台账填报、投诉处理、市场支撑、各类专项报表」——投诉处理是网优背上最重的杂活投诉工单与 KPI 数据、参数台账、故障工单分散在四套系统，逐件关联靠人工，一个片区 40 多件投诉至少一整天归因写「已优化」但用户感知没变，二次投诉升级为越级申诉——每件越级申诉按细则扣考核分，责任人另罚 300-2000 元用户感知劣化往往先于 KPI 劣化出现，但没人把「投诉时间点」与「指标拐点」「参数调整日」放在同一条时间轴上看过
✓ 交给 Agent 之后
- 多来源文件一次读入，先做口径与完整性校验，再开始算
- 每条结论绑定来源文件、字段或条号，可以被审
- 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
- 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案
四、场景闭环
6 步 · 每一步的产出都是下一步的输入
- 投诉聚类 · 按小区与问题类型归并47 件散诉先聚成几个问题簇，逐簇处理而不是逐件处理
- 时间轴对齐 ·投诉时间与 KPI 拐点、参数调整日、故障时段并排谁先谁后决定因果方向
- 根因匹配 · 逐簇关联四条线的证据每一簇给出「可归因 / 待排查」两态与依据链
- 责任边界划分 · 网络侧 / 用户侧 / 覆盖侧 / 跨网侧每一簇落到边界上，跨网的单列
- 回复口径生成 · 内部支撑件（不对外）每簇一段回复草稿与证据索引，供客服引用
- 留证与签批 · 汇总成批处理台账逐件工单号的归因结论与证据出处，班组长签字
要准备什么：客服转办投诉工单清单（xlsx：工单号 / 小区 / 投诉时间 / 问题描述）问题描述是用户原话，非结构化，先聚类再关联KPI 日值（xlsx，OMC 导出：小区 / 指标 / 日值）投诉时间点前后各 7 天的窗口参数调整台账（xlsx：日期 / 小区 / 调整项 / 旧值 / 新值）与 OP-01 共用同一份台账——全库联动故障工单流水（xlsx，EOMS 导出：工单号 /小区 / 故障级别 / 起止时间）星标素材——故障单躺在网维系统里，客服和网优平时都不翻
为什么这个场景值得做
优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.8
最大差异点：投诉处理工具市面上都是「分派与跟踪」，管的是流程流转。这里做的是归因：把投诉、KPI、参数、故障四条线放回同一条时间轴，每一件投诉给出「可归因 / 待排查」两态，可归因的写清依据链。
评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；
AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；
落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。
五、会产出什么
判断标准只有一个：这份东西能不能直接进企业的流程
- 正式件本体：
投诉根因关联台账.xlsx逐簇归因 + 责任边界 · 每条带证据出处 - 可派发清单：
待排查投诉清单.xlsxKPI 全绿仍投诉的工单 · 建议排查方向 · 可派发 - 可派发清单：
内部回复口径支撑件.docx逐簇回复草稿与证据索引 · 供客服引用这套东西不承诺什么不替人对用户做最终答复——回复口径涉及对外承诺，归因结论与答复话术只做内部支撑件。跨网（如广电-移动）投诉只梳理本网侧时间线，对方网络的数据拿不到就明确说拿不到。
② Live Demo（演示逐步）
演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。
案例设定：南江通信云山分公司网优班组。08-18，客服批量转来滨湖片区 47 件信号类投诉（08-14 至 08-17 受理），要求 7 个工作日内逐件回复——网优班长要在这批回复里写清「网络侧 / 用户侧 / 覆盖侧」归因。
投诉总量47 件 · 5 个问题簇时间特征39 件集中在 08-16 后关联故障EOMS-2608-1573 · 9.5 小时回复时限7 个工作日 ·从 08-18 起
输入运营商条线手上能拿到的东西
不需要整理格式、不需要改文件名 · 直接拖进对话框
01_投诉工单清单_滨湖47件.xlsx客服转办的 47 件信号类投诉，工单号、小区、受理时间与用户原话客服部批量转办 ·08-18 转来02_KPI日值_投诉窗口三周.xlsx涉及小区近三周（07-28 至 08-17）KPI 日值，投诉时间点前后各留一周窗口OMC 导出 · 08-18 取数03_参数调整台账_滨湖.xlsx与 OP-01 共用同一份台账——07-29 邻区批量调整的记录与旧值网优班组自维护 · 全库联动04_EOMS故障工单流水_滨湖.xlsxEOMS 里滨湖片区近一周的故障工单流水——客服系统看不见它，用户的「没信号」往往对应它EOMS 导出 · 网维系统
注意标橙色那一份 —— 04_EOMS故障工单流水_滨
湖.xlsx。它EOMS 导出 · 网维系统，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。
提示词就说这么几句
没有模板、没有表单 · 专业规则由 Skill 兜底
客服转来滨湖片区 47 件信号投诉，工单清单给你， 最近三周的 KPI 日值、参数调整台账、还有 EOMS 故障工单流水也都给你。 先把投诉按小区和问题聚成几簇，再把投诉时间、指标拐点、调参日、 故障时段放到同一条时间轴上，看谁先谁后。 能归因的写清证据链，归因不了的标「待排查」，别硬编。 责任边界按网络侧、用户侧、覆盖侧、跨网侧分。 回复口径做内部支撑件就行，对外的口径客服定。
短是因为专业规则都写在能力包里了。你只需要说清这是什么事。
触发47 件散诉批量转来 · 逐件处理一整天，逐簇处理一上午
投诉单上写着「信号差」，真正要回答的是「谁的锅」
47 件按用户原话看五花八门：掉线、信号弱、断网、通话断续、室内差。但落到小区和时段上，它们是 5 个问题簇、2个根因。过去的处理方式是逐件给网维打电话问「你们那边有没有故障」——现在把四条线并排看，这个问题在桌子上有答案。
第 1 步 · 投诉聚类 · 47 件归成 5 簇，逐簇处理
散诉先归簇，回复才能批量给口径
第 2 步 · 时间轴对齐 · 投诉受理、指标拐点、调参日、故障时段并排
谁先谁后决定因果方向
第 3 步 · 根因匹配 · 逐簇关联四条线证据
每一簇给出「可归因 / 待排查」两态与依据链
第 4 步 · 责任边界划分 · 网络侧 / 覆盖侧 / 用户侧分开落
归因写错，下一周同类投诉还会再来一遍
第 5 步 · 回复口径生成 · 内部支撑件，每簇一段证据索引
对外的口径客服定，对内的证据这里备齐
第 6 步 · 留证与签批 · 汇总成批处理台账
逐件工单号的归因结论与证据出处，班组长签字
不讲省了多久 · 讲少了几个隐患、沉淀了什么
③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）
1. Skill 能力包
导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短
信号投诉根因关联 —— 用户说没信号，数要说清是哪一段的锅 · Skill
SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范
版本 v1.0
signal-complaint-root-cause.zip
在 WorkBuddy 里直接上传这个 zip 即可导入
包内结构
SKILL.md主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界references/output_template.md输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本references/judgement_rules.md判据与口径 —— 什么情况算异常、什么情况必须拦住
references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。
2. 原始素材
这些就是运营商条线手上真实能拿到的东西 —— 格式不统一是常态，不是问题
📁OP-02 · 演示素材
脱敏构造数据 · 真实业务格式 · 埋点可核验
共 4 份
XLS01_投诉工单清单_滨湖47件.xlsx客服转办的 47 件信号类投诉，工单号、小区、受理时间与用户原话下载
↓XLS02_KPI日值_投诉窗口三周.xlsx涉及小区近三周（07-28 至 08-17）KPI 日值，投诉时间点前后各留一周窗口 XLS03_参数调整台账_滨湖.xlsx与 OP-01 共用同一份台账——07-29 邻区批量调整的记录与旧值04_EOMS故障工单流水_滨湖.xlsxEOMS 里滨湖片区近一周的故障工单流水——客服系统看不见它，用户的「没信号」往往对应它
怎么用
- 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
- 粘贴下方提示词发送
- 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填
3. 提示词卡片
客服转来滨湖片区 47 件信号投诉，工单清单给你， 最近三周的 KPI 日值、参数调整台账、还有 EOMS 故障工单流水也都给你。 先把投诉按小区和问题聚成几簇，再把投诉时间、指标拐点、调参日、 故障时段放到同一条时间轴上，看谁先谁后。 能归因的写清证据链，归因不了的标「待排查」，别硬编。 责任边界按网络侧、用户侧、覆盖侧、跨网侧分。 回复口径做内部支撑件就行，对外的口径客服定。
为什么这么短就够了：短是因为专业规则都写在能力包里了。你只需要说清这是什么事。
换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，
该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。
自己组织输入的三步法
- 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
- 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
- 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。
分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。
4. 预期输出
不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构
📋正式交付物
带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」
共 3 份
OP-02_投诉根因关联台账.xlsx逐簇归因 + 责任边界 · 每条带证据出处OP-02_待排查投诉清单.xlsxKPI全绿仍投诉的工单 · 建议排查方向 · 可派发OP-02_内部回复口径支撑件.docx逐簇回复草稿与证据索引 ·供客服引用
Skill 里固化了什么：从故障工单里想起了那晚的割接该拦的地方拦住了排除性结论把技术动作翻译成钱
输入清单：客服转办投诉工单清单（xlsx：工单号 / 小区 / 投诉时间 / 问题描述）问题描述是用户原话，非结构化，先聚类再关联KPI 日值（xlsx，OMC 导出：小区 / 指标 / 日值）投诉时间点前后各 7 天的窗口参数调整台账（xlsx：日期 /小区 / 调整项 / 旧值 / 新值）与 OP-01 共用同一份台账——全库联动故障工单流水（xlsx，EOMS 导出：工单号 / 小区 / 故障级别 / 起止时间）星标素材——故障单躺在网维系统里，客服和网优平时都不翻
人工边界：不替人对用户做最终答复——回复口径涉及对外承诺，归因结论与答复话术只做内部支撑件。跨网（如广电-移动）投诉只梳理本网侧时间线，对方网络的数据拿不到就明确说拿不到。
升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）
5. 同一角色下的其他场景
网络质量优化 · 产出即下一步输入
- OP-01 · 网优质量周报：数据全在网管里，报告不该再手写一遍
上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。
说明：以上为 WorkBuddy 官方行业场景库三级页面与库级页签的完整整理；均为官方脱敏演示件，用于讲解与交付底稿，不代表已接入客户生产系统、不承诺效率百分比。
场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。
想把这个场景在你们企业跑通？
顾问会先看你们的数据和流程够不够，再决定从哪一步开始。
