通信运营商 · 行业场景库

岗位依据

岗位依据与数据 · WorkBuddy · 通信运营商场景库

6 个子角色为什么这样切，依据在哪

公开的组织架构上，运营商分公司写的是「网络部 → 市场部 → 客服部 → 政企部」各管一段、权责分明。但真实 JD与从业者自述里写的是另一回事：政企客户经理校招 JD 要求「客户走访、商机挖掘、客户对账调账、欠费回收，主导项目招投标、方案设计、合同签订及回款跟进」一个人横跨售前、投标、交付、回款四段；网维岗「不再单纯做无线优化，新增大量台账填报、投诉处理、市场支撑、各类专项报表，所有人都背营销指标」；智家工程师「装、移、修、营销、维系五合一，24 小时随时待命」；而材料负担的量化描述是「至少三分之一的运营商员工每天活在材料里，一个不到半小时的材料，前后动用几十人整一个月」。部门墙画在组织图上，口径不一致的坑踩在每一份工单、每一份通报、每一份标书里。

所以这套场景库按一件事的完整旅程切分，而不是按大企业的职能表：守网络的（告警与割接）、调网络的（KPI 与投诉关联）、卖卡的（通报与资费）、灭火的（投诉与申诉）、打单的（方案与集采）、接考核的（代维结算）——这六类活在市/县分公司和代维公司里往往分别由同一拨人兼着干，区别只在什么时候被追责、错了谁担、产出物被谁消费。

网络运维与割接

Network Operations & Cutover

守网络的人是「告警一响就得动」的人：割接窗口永远在凌晨，处置完故障下一单已经来了——这个岗位真正的产出物不是修好的设备，是能盖章的故障报告和能过审的割接方案。

2 个场景

这个子角色为什么真实存在：故障管理流程原文：集中化故障工单要求代维在两套系统各回一遍单，事故报告栏目是法定格式（报告单位盖章、报告时间精确到分、是否上报通管局）从业者自述「处置事件只花一小时，攒证据写报告要熬三天」——80% 精力耗在事后流程，而不是处置本身网维岗早已不纯做无线优化：台账填报、投诉处理、市场支撑、专项报表都压上来，夜间割接 0 点开工凌晨 4 点收工，第二天照常上班

公开来源：集中化故障管理流程：代维双系统回单、事故报告法定栏位（报告单位盖章、时间精确到分、主送单位、是否上报通管局）「处置事件只花一小时，攒证据写报告要熬三天」：80% 精力耗在事后流程网维岗不再单纯做无线优化：台账填报、投诉处理、市场支撑都压上来、人人都背营销指标；夜间割接 0 点开工凌晨 4 点收工，第二天照常上班

它实际在用的数据：EOMS 工单流水导出（派单/受理/处理/回单时间戳）网管告警流水导出（设备号/告警类型/发生与恢复时间）微信群处置通报转写（值班经理每小时口播）历史故障报告归档包（近 12 个月 docx，散在各班组文件夹）关键字段与口径事故报告法定栏位：报告单位盖章、报告时间精确到分、主送单位、是否上报当地通管局割接方案硬指标：OTDR 双向测试 1310nm≤0.36dB/km、1550nm≤0.22dB/km回退预案与双人交叉核验点、每一步确认前不能进行下一步影响范围核算口径（用户数与小区数，网管口径与 BOSS 口径算法各异）

本组场景：

• NW-01 故障处置报告初稿 —— 从工单流水与告警记录里攒证据，不从空白文档里写起 · 优先级 12.0

升为客户真实案例还缺什么：近 12 个月故障报告归档原件、两套系统各一份工单流水导出、本机房设备台账（设备型号/厂家/投运年份）、省公司割接管理规范原文。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

网络质量优化

Network Quality Optimization

调网络的人天天和阈值打交道：掉线率、接通率、PRB 利用率——但真正难的不是盯数，是「指标拐点和参数调整日从来没有被放在同一条时间轴上看过」，以及投诉来了才发现上周的调整埋了雷。

2 个场景

这个子角色为什么真实存在：网优工程师的一天：9 点半起登录平台盯 KPI、异常小区根因分析、14 点起用 MML 命令调参数（功率、迟滞、邻区增删）、17 点写日报更新台账优化台账必备栏位：参数调整记录（调整项/旧值/新值/调整人/效果观察 24h）——栏位设计本身就说明「调整与效果的对应关系」是这行的核心资产「KPI 恨不得每天一算，而且需要手动核算，后台没有联网的数据系统，底下口径经常不一，每到要统计就要花大半天」

公开来源：网优工程师的一天：9 点半盯 KPI、异常小区根因分析、MML 调参、处理工单、17 点写日报更新台账网优KPI 阈值与优化台账栏位：掉线率/接通率/PRB 指标线、参数调整记录（旧值/新值/调整人/效果观察 24h）广东区县后端员工自述：KPI 每天一算且手动核算、后台没有联网数据系统、口径不一、统计要花大半天

它实际在用的数据：KPI 小时级导出（小区粒度：掉线率/接通率/切换成功率/PRB）参数调整台账（调整项/旧值/新值/调整人/时间）投诉工单清单（时间/小区/用户号码/投诉内容）路测与 MR 数据、历史优化案例归档

关键字段与口径：KPI 指标变化：掉线率、接通率、切换成功率、PRB 利用率（含阈值线）异常小区清单（连续越限时长/影响用户数）参数调整记录：调整项/旧值/新值/调整人/效果观察 24h遗留问题与观察期结论

本组场景：

• OP-01 网优质量周报 —— 数据全在网管里，报告不该再手写一遍 · 优先级 8.8
• OP-02 信号投诉根因关联 ——用户说没信号，数要说清是哪一段的锅 · 优先级 8.8

升为客户真实案例还缺什么：优化台账原件（近 6 个月）、投诉工单与 KPI 指标两份导出、本省 KPI 考核口径定义表、历史优化案例归档。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

市场渠道与资费 Marketing, Channel & Tariff

卖卡的人活在通报里：蜗牛榜天天发、复盘会开到夜里 11 点——但天天发的通报，数是从三个系统手工拼的；天天要答的资费问题，口径散在几十份文件里，营业厅答一个、打客服听到另一个。

2 个场景

这个子角色为什么真实存在：营业员跨 BOSS/业务系统/知识库/报表/维系系统多系统操作，「办 2G 进 BOSS，办 3G 进另外一个系统」，数据散、口径经常不一工信部 2025 年起推进资费精简行动，本省资费政策文件极多且频繁变更，营业员/客服/客户经理各条线都在问「这个套餐到底能不能改」「至少三分之一的运营商员工每天活在材料里」，日报周报制度下每周几十个报表，很多都是重复的

公开来源：IT 支撑系统数量多但互不联通，营业员跨 BOSS/业务系统重复操作，「办 2G 进 BOSS，办 3G 进另外一个系统」工信部资费精简「明白办、放心用」行动：本省资费政策文件多且频繁变更，各条线口径需统一「至少三分之一的运营商员工每天活在材料里」，日报周报制度下每周几十个报表

它实际在用的数据：当日发展量导出（宽带/移网/融合三张表，从经分系统导出）昨日通报归档与网格基础信息表本省资费政策文件包（资费公告/营销案/口径答复）月度考核口径表（指标/权重/目标值）

关键字段与口径：网格经营通报：总量榜与完成率榜、环比、遗留问题闭环资费口径问答对：问题/标准答复/政策依据文号/生效日期口径标注：每个数的来源系统与算法

本组场景：

• MK-01 网格经营日报 —— 蜗牛榜天天发，数不该天天手凑 · 优先级 14.4
• MK-02 资费政策问答与口径核对—— 政策月月变，答案不能靠群里问 · 优先级 9.6

升为客户真实案例还缺什么：三张发展量表导出原件、本省资费政策文件（近 12 个月）、考核口径定义表、近一个月通报归档。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

客服与申诉处理

Customer Service & Appeals

灭火的人是全公司离监管最近的人：百万用户申诉率季度红线 20 人次，超时限每件扣 0.5 分——这个岗位的产出物是能同时对上录音、工单、台账三处记录的答复报告，任何一处对不上都是新的申诉。

2 个场景

这个子角色为什么真实存在：客服中心管理规范要求升级投诉 24 小时内出方案，要跨客服/网维/市场/法律四部门凑资料：调录音、查工单、查营销记录、看协议12381 申诉件直接计入分公司绩效考核、与评优挂钩，1-3 天内必须响应；省级细则：超时限每件扣 0.5 分、回复不真实每件扣 1 分2026 年 9 月国标实施后「经营者不能以算法生成为由免责」——对外答复的责任边界已立法，AI 直接对外答复是踩线

公开来源：客服中心管理规范：升级投诉 24 小时内出方案，需跨客服/网维/市场/法律四部门凑资料12381 申诉件直接计入分公司绩效考核，与员工绩效、评优挂钩，1-3 天内必须响应2026 年 9 月国标：企业不能以「算法生成」为由对 AI生成内容免责，对外答复责任在经营者

它实际在用的数据：申诉工单历史库（申诉编号/诉求/办理记录/答复归档）通话录音转写件处理留痕记录（各系统操作时间线）投诉工单清单（含越级与升级标记）

关键字段与口径：申诉答复法定栏位：事实经过/处理过程/答复口径/依据文号/是否上报时间线：每步带系统出处（录音时间戳/工单流转/操作日志）申诉率台账：百万用户申诉率、超时限件数

本组场景：

• CS-01 工信部申诉答复报告 —— 每一件都计考核分，每一句都要有出处 · 优先级 7.3
• CS-02 投诉升级件时间线还原 —— 全班组翻录音的那个晚上，本可以不用熬 · 优先级 8.0

升为客户真实案例还缺什么：近三个月申诉工单与答复归档、涉诉号码的通话录音转写件、办理业务的工单与营销记录、申诉考核细则原文。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

政企客户与集采投标

Gov-Enterprise & Bidding

打单的人一个人横跨售前、投标、交付、回款四段——JD 原文写着「主导项目招投标、方案设计、合同签订及回款跟进」，所以他的场景必须一条链打通：方案从历史应答库长出来，标书在封标前夜被拦住废标风险。

2 个场景

这个子角色为什么真实存在：联通政企客户经理 JD：主导项目招投标、方案设计、合同签订及回款跟进——一个人横跨四段，没有专职售前帮他磨方案电信政企客户经理 JD 十二项职责：客户走访、商机挖掘、对账调账、欠费回收、区县售前支撑——写方案的时间是挤出来的37% 的电子标废标出在签章细节；评审端已上大模型（102 份标书检出 85 处异常）——投标端的合规检查还是人肉

公开来源：联通政企客户经理 JD：主导项目招投标、方案设计、合同签订及回款跟进——一人横跨售前/投标/交付/回款四段电信政企客户经理 JD：客户走访、商机挖掘、客户对账调账、欠费回收、区县售前支撑等十二项职责37% 电子标废标出在签章细节；某县接入大模型电子评审，102 份标书检出 85 处异常——评审端已上 AI

它实际在用的数据：历史投标应答库（近 24 个月 docx，散在各客户经理电脑）本省政企案例台账（客户/项目/金额/验收时间）专线与云网产品目录价表（目录价/折扣权限/协议价）资质证书包与法人授权文件

关键字段与口径：方案三段式：技术方案/商务报价（三档并列）/案例证明标书响应表：星号条款逐项响应、正文支撑页码业绩证据链：合同/验收/发票日期先后关系、逐页小签

本组场景：

• GQ-01 政企解决方案初稿 —— 上次给中医院怎么报价的，这次还要再问一遍吗 · 优先级 8.8
• GQ-02 集采标书合规检查 —— 37% 的废标出在签章，不出在文笔 · 优先级 6.8

升为客户真实案例还缺什么：近两年投标应答原件、本省废标与扣分教训台账、产品目录价与折扣权限表、资质证书有效期清单。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

代维与考核结算

Maintenance & Settlement

接考核的人每月的产出是一份能对上每一条扣分工单号的应答包——被扣的每一分都要有申诉证据，因为考核分直接挂钩结算金额，两三折中标价之下，4.5 分就是项目部的利润。

2 个场景

这个子角色为什么真实存在：铁塔系统会议点名「维护费扣罚占比高、代维单位服务月报质量不高」——月报质量写进了甲方评价，也写进下一次招标评分上市公司公告披露代维服务费与考核得分直接挂钩；中标价两三折背景下扣款直接决定盈亏代维同时登录两套系统处理同一张工单，回单内容两处各填一遍——月底对数据时两边的数经常对不上公开来源铁塔系统会议点名：维护费扣罚占比高、代维单位服务月报质量不高、岗前培训不到位宜通世纪半年报：代维服务费与考核得分挂钩、扣款直接决定盈亏、中标价两三折的行业背景代维 20 年从业者自述：运维困境、双系统回单、人员与指标恶性循环

它实际在用的数据：代维工单导出（两套系统各一份：工单号/时间戳/处理记录/闭环状态）巡检记录导出（站点/巡检项/完成时间/异常项）当月考核扣分明细（条款/扣分值/关联工单号）当月割接方案与故障报告归档

关键字段与口径：月报各考核项完成率（带工单号级出处）扣分-工单-证据三级映射表申诉理由与证据链索引（铁证/口径争议/无据可申三级）

本组场景：

• DW-01 代维服务月报 —— 被甲方点名「月报质量不高」之后 · 优先级 12.0
• DW-02 考核扣分对账 —— 被扣的每一分都要能对上工单号 · 优先级 8.0

升为客户真实案例还缺什么：两套系统工单导出原件、甲方考核扣分明细原件、考核细则原文、当月割接方案与故障报告归档。

这里列的是这个岗位真实会用到的数据类型，不表示已经取得任何客户的生产数据。

不做什么

明确不做的伪需求 · WorkBuddy · 通信运营商场景库

23 个伪需求以及为什么不做

客户看到「四十个场景」的第一反应不是「好全」，而是挑最不靠谱那个来问。

一个伪需求会削弱旁边所有真场景的说服力 —— 所以这一页存在的意义，是让 15 个真场景更可信。

运营商条线是「AI 提效」口号喊得最响的领域，也是伪需求密度最高的领域——因为它的每个环节都能生成点什么，但生成出来有没有人接着用、会不会碰监管红线，是另一回事。判断只需要三句话：这份材料现在有人看吗？这个数据现在有人维护吗？如果 Agent 明天就把这件事做完了，下游的人会不会因此改变行为？第三句答不上来，就不要

做。

4

法则一 · 一段脚本更快更准更便宜

3

法则二 · 需物理感知或对外担责

6

法则三 · 真实瓶颈不在这一步

!

最典型的一条：办公用品领用登记电子化

它看起来完全合理：纸质登记乱、统计麻烦、月底要追问还剩多少。

但制度里写着「月度汇总提交采购与财务作成本核算依据」——

现实中签完字这件事就结束了，汇总表没有人看。

把一张没人看的表加速录进系统，等于加速垃圾数据入库。

真正有价值的是另一个问题：为什么某个部门的耗材是别人的三倍。

清单逐条说明

最后一列是客户主动提出时的回应口径 —— 不是拒绝，是把他引到真场景上

伪需求命中法则

更优解 / 真实瓶颈在哪客户提出时怎么回应

AI 代填故障工单并闭环红线 · 强监管留痕工单留痕是审计与追责依据，无人工确认的自动闭环等于虚假记录，审计一查一个准现场话术：闭环动作必须人来点——我们做的是回单内容的草稿与出处清单，让点下去的那一下有底气。AI对外资费答复与承诺红线 · 对外担责2026 年 9 月国标实施后，经营者不能以「算法生成」为由免责——AI 直接答复客户等于公司为算法背书现场话术：对内口径核对我们做（资费政策问答场景），对外那一句话必须人说——这不是能力问题，是责任问题。割接 AI 最终确认与自动执行红线 · 业务连续性割接失败直接影响业务连续性，「每一步确认前不能进行下一步」是铁律，回退决策必须人在现场现场话术：我们做的是方案初稿与审批链校验，把人从写材料里解放出来去盯真正的执行风险。营销外呼话术全自动生成投放红线 · 监管专项行动骚扰电话治理是工信部专项行动重点，全自动外呼是重点打击对象现场话术：外呼合规这条线碰不得——要做就做对内的活动方案初稿，从历史活动效果数据里长出来。装维/代维巡检照片 AI 生成或代拍照红线 · 造假五连拍是留证要求，AI 生成合规照片实质是帮助造假现场话术：这个方向我们不碰。反过来，照片合规的人工审查我们也慎做——误判就要扣人钱，对抗性太强。渠道酬金自动核算法则一 · 确定性规则佣金规则是确定性公式，规则引擎或脚本更快更准更便宜现场话术：算钱这种事用不着 AI——真正没人管的是酬金口径的答复口径，那才是我们的场景。网络资产台账一致性核对法则一 · 确定性规则网管自动发现脚本对设备台账的比对更准更便宜，AI 无增益现场话术：这个用网管的自动发现功能就能做——我们做的是台账背后那些「谁投运的、修过什么」的非结构化记忆。反诈/骚扰治理监管报表法则一 · 确定性规则监管口径固定的报表，BI 脚本即可，AI 无增益现场话术：固定口径的报表让 BI 出——AI 的价值在口径不固定的地方，比如申诉答复那种一单一案的材料。话务量与流量统计日报法则一 · 确定性规则BOSS 出数加报表脚本，几十年的成熟链路现场话术：这个链路比我们的岁数都大，不用动它。AI 客服直接对外应答法则二 · 对外担责中消协已将 AI 客服不实承诺、人工接入困难列为投诉新热点；国标要求企业对 AI 客服回复担责现场话术：对外触点都是投诉源头，对内工具才是安全区——同样的能力装到坐席的屏幕上，效果一样，责任边界完全不同。合同风险条款审查法则二 · 专业资质法务专业性高、误报代价大，成熟法务 AI 已存在现场话术：这个交给专业法务工具——我们守标书合规这条线就够了，同样是拦风险，我们的主场在废标细节。割接现场物理操作辅助法则二 · 物理感知光纤熔接、设备倒换是物理操作，AI 感知不了现场现场话术：现场的手艺活归师傅——我们管的是操作前后那两份纸面材料。营业厅客流预测排班法则三 · 瓶颈错位营业厅的真实瓶颈是指标考核与人效压力，不是排班算法现场话术：先问一句「排班表优化了，考核压力会变吗」——不会的话，钱该花在别处。渠道巡检报告自动生成法则三 · 瓶颈错位瓶颈在巡检执行本身（人到没到、看了没看），不在写报告现场话术：巡检没做，报告写得再快也没用——先把执行管起来。专线资源预查与报价助手法则三 · 瓶颈错位专线的真实瓶颈在勘察与施工排队，报价环节只占几天现场话术：客户等的是施工队不是报价单——方案侧我们能帮（政企方案场景），勘察排期帮不了。装维拍照合规审查法则三 · 对抗性强处罚取证场景，AI 误判一次就扣人钱，一线会把系统往死里对抗现场话术：识别摆拍技术上做得，但做了就是跟一线为敌——这个决定不该由算法做。培训考试题生成法则三 · 产出没人看公式分高但痛感低，「同一个视频看第四遍」说明培训本身是形式主义重灾区现场话术：培训没人看，题出得再好也没人做——先把「学完到底改变了什么」想清楚。值班日志自动美化法则三 · 产出没人看「都是给领导看的，下面的人没几个看」——把垃圾产出做得更快没有意义现场话术：真正该自动化的是交接班的实质内容（遗留问题闭环检查），不是排版。通用会议纪要与邮件润色通用覆盖 · 私有数据弱移动九天·文思等集团级办公助手已内置写作/问答/提单/会议四件套，作为入口附赠可以，作为主打场景必死现场话术：这些通用能力我们有，但不会拿它当卖点——我们的差异在「引用了本机房 3 月那单故障」的报告，通用工具写不出。通用通话质检通用覆盖 · 行业标配浙江移动已实现质检覆盖率 1%→100%、准确率 96%——通用质检是红海；差异仅在申诉举证场景的录音-工单-台账交叉还原（已并入申诉答复场景）现场话术：通用质检不用再买了——要买就买「申诉答复取证」这一个点，那才是扣分与通报的正面战场。通用告警根因分析通用覆盖 · 厂商主场华为/中兴 AIOps 在根因分析上已很强；差异仅在本机房历史告警-故障配对（已并入故障报告场景的案例召回）现场话术：设备商的 AIOps 管实时告警——我们管的是处置完之后那份报告和它沉淀下来的记忆，两个不打架。竞品资费监测简报通用覆盖 · 公开信息以公开信息为主，私有数据输入弱，通用搜索加摘要即可覆盖现场话术：友商资费网上都有——真正缺的是自家口径的统一，那是资费政策问答场景的活。政企客户行业情报简报通用覆盖 · 公开信息同上，公开信息扫描，私有数据弱现场话术：情报扫描不值钱，值钱的是「这个客户上次投我们标时挑过什么刺」——那在您的应答库里。

声明这套东西不承诺什么

主动讲限制比被问出来强得多

这是演示与验证资产，不是已接入生产系统的软件所有 Live Demo 页面展示的是「应该怎么跑、每一步看什么、交付什么」，使用的是真实业务格式的脱敏构造数据，不冒充任何客户的生产数据。不承诺效率提升百分比本场景库不出现任何「三天压到半天」「节省百分之九十」这类数字 —— 没有用客户自己的单据实测过，这种数字说出来就是砸口碑。我们讲的是可核实的能力差异：参与角色怎么变、覆盖范围多大、产出多少条。拿不到的数据会明确说拿不到跨网投诉拿不到对方公司的工单记录、纸质巡检记录没有数字化、历史归档只有扫描件 —— 这些情况会在报告里写清「本项无法分析，建议后续建立什么记录」，而不是估一个数填上去。高风险动作只建议不执行对外资费答复、工单闭环提交、割接最终确认、投标终稿上传、申诉答复盖章上报、对外发文与用印 —— 这六类动作本场景库全部只出清单和依据，不代替人做决定，也不自动执行。产出是初稿与清单，最终签字权在人所有正式交付物都留有编制 / 审核 /会签 / 批准签批栏，责任认定、处理意见、整改承诺、推荐报价这几栏一律留空 —— 自己给自己打分的报告，没人会信。

那哪些是真场景？15 个逐条打过分的场景，全部保留了评分口径可核

回到场景总览 →

来源说明

本场景库的痛点均有公开来源可查。网页版已对来源中的具体机构做了脱敏处理，不再逐条列出。

场景审核

场景审核 · WorkBuddy · 通信运营商场景库

先过场景不急着做素材

共 12 个场景。逐个点「保留 / 待讨论 / 后置」，

结果只保存在本机浏览器，可以复制出来。

建议的判断顺序：先问这件事没做好谁会生气（痛感）→

再问错了能不能当场看出来并改（能不能交给 Agent）→

最后问客户手上现有的文件够不够跑（落地难度）。

需要客户先做数据治理的场景，不要放在第一批。

清空选择

返回总览

网维

网络运维与割接

守网络的人是「告警一响就得动」的人：割接窗口永远在凌晨，处置完故障下一单已经来了——这个岗位真正的产出物不是修好的设备，是能盖章的故障报告和能过审的割接方案。

2 个

NW-01

12.0

故障处置报告初稿 —— 从工单流水与告警记录里攒证据，不从空白文档里写起处置事件只花一小时 · 攒证据写报告要熬三天

保留

待讨论

后置

NW-02

8.8

割接方案初稿与审批链校验 —— 历史方案是私有资产，别再从空白文档写起割接文档模板全网都在传 · 每个机房的坑只有自己知道

保留

待讨论

后置

网优

网络质量优化

调网络的人天天和阈值打交道：掉线率、接通率、PRB 利用率——但真正难的不是盯数，是「指标拐点和参数调整日从来没有被放在同一条时间轴上看过」，以及投诉来了才发现上周的调整埋了雷。

2 个

OP-01

8.8

网优质量周报 —— 数据全在网管里，报告不该再手写一遍白天开车测 DT · 晚上通宵写报告

保留

待讨论

后置

OP-02

8.8

信号投诉根因关联 —— 用户说没信号，数要说清是哪一段的锅投诉单上写着「信号差」 · 真正要回答的是「谁的锅」

保留

待讨论

后置

市场

市场渠道与资费

卖卡的人活在通报里：蜗牛榜天天发、复盘会开到夜里 11 点——但天天发的通报，数是从三个系统手工拼的；天天要答的资费问题，口径散在几十份文件里，营业厅答一个、打客服听到另一个。

2 个

MK-01

14.4

网格经营日报 —— 蜗牛榜天天发，数不该天天手凑通报天天发 · 数是天天手凑的

保留

待讨论

后置

MK-02

9.6

资费政策问答与口径核对 —— 政策月月变，答案不能靠群里问每个套餐都能改 · 每个营业员的说法都不一样

保留

待讨论

后置

客服

客服与申诉处理

灭火的人是全公司离监管最近的人：百万用户申诉率季度红线 20 人次，超时限每件扣 0.5 分——这个岗位的产出物是能同时对上录音、工单、台账三处记录的答复报告，任何一处对不上都是新的申诉。

2 个

CS-01

7.3

工信部申诉答复报告 —— 每一件都计考核分，每一句都要有出处申诉件直接计入分公司考核 · 答复却是连夜手写的保留

待讨论

后置

CS-02

8.0

投诉升级件时间线还原 —— 全班组翻录音的那个晚上，本可以不用熬升级投诉 24 小时内要出方案 · 事实却散在四套系统里

保留

待讨论

后置

政企

政企客户与集采投标

打单的人一个人横跨售前、投标、交付、回款四段——JD 原文写着「主导项目招投标、方案设计、合同签订及回款跟进」，所以他的场景必须一条链打通：方案从历史应答库长出来，标书在封标前夜被拦住废标风险。

2 个

GQ-01

8.8

政企解决方案初稿 —— 上次给中医院怎么报价的，这次还要再问一遍吗方案模板网上一搜一大把 · 本省案例库只在老师傅脑子里

保留

待讨论

后置

GQ-02

6.8

集采标书合规检查 —— 37% 的废标出在签章，不出在文笔评审席上已经坐了 AI · 投标席上还在人眼盯小签

保留

待讨论

后置

代维

代维与考核结算

接考核的人每月的产出是一份能对上每一条扣分工单号的应答包——被扣的每一分都要有申诉证据，因为考核分直接挂钩结算金额，两三折中标价之下，4.5 分就是项目部的利润。

2 个

DW-01

12.0

代维服务月报 —— 被甲方点名「月报质量不高」之后工单都在系统里躺着 · 月报却是月底熬夜手写的

保留

待讨论

后置

DW-02

8.0

考核扣分对账 —— 被扣的每一分都要能对上工单号扣分单上只有条款和分数 · 申诉证据要翻五套系统

保留

待讨论

后置

审核进度未选择 12

交付说明

交付说明 · WorkBuddy · 通信运营商场景库

通信运营商场景库怎么用这套东西

这是一套售前演示与客户验证资产，不是已经接入客户生产系统的软件。

包含 6 个子角色、12 个场景、36 个内容页、

12 个 Skill 包与配套素材和预期输出。

12完整场景

36三件套页面

23明确不做的伪需求

39可核验来源

路径三种人怎么看

客户初次看

从总览按子角色选场，先看「场景引入」。三分钟看清这件事现在什么样、痛点依据在哪、产出是什么。

打开场景总览

现场演示

打开「Live Demo」逐步讲。重点讲 Agent 在哪一步拦住了 ——

一、个会在该停的地方停下来的助手，比一个永远给得出答案的助手可信得多。

看一个完整 Demo

内部选型

在「场景审核」页逐场标保留 / 待讨论 / 后置，复制结果后再决定哪些进入真实素材制作。

打开场景审核

话术现场必备的三句话

开场 · 先说 AI 做不到什么

把限制先摆出来：不承诺效率百分比、拿不到的数据会说拿不到、高风险动作只建议不执行。

主动说限制比被问出来强得多 —— 而且这一句会把后面所有内容的可信度垫起来。

中场 · 用一句话帮客户剔掉伪需求

客户提到某个表单类需求时，问一句：「这张表现在有人看吗？看完做了什么决定？」

答不上来就当场建议先不做。这一下建立的是顾问式信任 ——

客户会开始相信你不是来卖东西的。

收尾 · 三个问题要金额

「你们上一次工信部申诉答复，从接到转办单到盖章上报隔了几天，中间翻了几套系统的记录？上一张超时故障单的扣分，代维的申诉证据链翻得出对应工单号吗？上一次集采投标，逐页小签和业绩证据链是谁最后一天熬夜核的？」

三、问都答不上来，场景就成立了。

状态已完成与未冒充完成

已经完成6 子角色 × 12 场景完整内容每场景：场景引入 / Live Demo / 能力沉淀 三页每场景：Skill 包（含输出骨架与渲染脚本）、素材、预期输出痛点逐条挂来源，可点开核对23 个伪需求逐条说明命中哪条排除法则岗位依据页说明子角色为什么这样切

明确未冒充完成尚未接入任何客户的生产系统素材是真实业务格式的脱敏构造数据，不是客户生产数据场景尚未用客户自己的原始文件实跑过（这是下一步）有来源支撑不等于完成客户一手验证没有实测前不出现任何效率提升百分比割接最终确认、对外资费答复、工单闭环提交、投标终稿上传、申诉答复盖章上报、对外发文与用印一律人工

下一步怎么往前推

第 1 步过场景12 个逐场标保留 / 待讨论 / 后置

第 2 步选 3 到 5 个按客户类型组合，优先零集成的

第 3 步要一手材料真实文件、审批链、一次出过问题的案例

第 4 步用客户文件实跑记录结果、返工点、真实耗时

第 5 步再谈系统对接此时才评估 API、权限与回写