Part 1 · 需求验证
整体判断：8 个需求点中，5 个强验证（1、2、4、7、8），2 个部分验证（3、6），1 个弱验证（5）。
方法前提：本调研是观察 + 跟访，无法直接验证 KANO 等级（必备 / 期望 / 魅力）。原文 KANO 标注应理解为研究方判断，不是数据结论。
交互提示：点击每条证据后的 🔍 查看调研原文，侧边会打开对应的 Markdown 原文并高亮匹配段落。原文 MD 也可在同目录下的 3 个 .md 文件中直接阅读。
结论速览
| # | 需求点 | 验证状态 | 证据覆盖 |
|---|
| 1 | 客户希望后续服务接得上前情 | 强验证 | 5 个明确场景 |
| 2 | 客户希望多轮处理后不用再重新对齐 | 强验证 | 3 个明确场景 |
| 3 | 客户希望低成本把问题讲明白 | 部分验证 | 仅"基础信息收集"维度 |
| 4 | 客户希望等待时知道事情有人在推进 | 强验证 | 5 个明确场景 |
| 5 | 客户希望沟通不要机械生硬 | 弱验证 | 仅间接推断 |
| 6 | 客户希望着急时先听到最关键的话 | 部分验证 | 仅"先恢复业务"子场景 |
| 7 | L1 希望推进问题不用到处翻找信息 | 强验证 | 多场景全面覆盖 |
| 8 | L1 希望少做重复的信息搬运 | 强验证 | 4 个明确场景 |
逐条验证
支持证据
-
跨时间断裂致电 400 Case 1用户上午来电下午没回复再次来电，还要问 L1 是不是上午那位、重新共识故障
查看调研原文
来源：致电 400 调研 · Case 1（新增网段上不了网）痛点分析1. 用户上午打过电话，到下午还没有回复，他就再次来电
2. 用户会问L1是否是上午的同一个 -> （不是）再次共识发生了什么故障
3. 没有远程工具（小锐云桥），下载了六分钟，不确定下载渠道
4. 没有排查工具（SourceCRT），远程连接后先帮忙下载
5. L1提醒用户不要动（远程工具用户鼠标动 L1就不能操作）
6. L1代码调试用户是看不太懂的，L1会解释一下这段代码就是什么什么意思
7. 用户对问题有自己理解的原因和解决方式，L1一般要先回复解释
-
跨触点断裂闪电侠 痛点 2 旧故事用户在客服平台沟通掉线后接手的不是同一位 L1，被迫再次描述——之后用户主动要求建微信群，已形成应对策略
查看调研原文
来源：闪电侠转人工调研 · 痛点 2（多平台切换 - 上下文断裂）L1：
- 客服平台（最初问题）（一段时间不回复就有可能断线，所以会拉wx群）
- 企业微信（拉群沟通）
- 语音（关键沟通）
- 小锐云桥（远程）
- 闪电兔（查命令）
- 官网（查资料）
用户：
- 被迫多平台配合（客服、微信群、远程工具、语音）
- 如果客服平台掉线，用户就不得不再 和新客服介绍发生了什么
- 会问午休会不会换工程师
旧故事：用户之前在客服平台沟通问题发生过掉线，再次进线不是道同一个L1这里，导致他需要再次描述一遍发生了什么。所以之后用户一进入客服平台就要求建一个微信群聊沟通。
-
跨团队断裂致电 400 旧故事 2用户已联系 EG 工程师确认非 EG 侧问题，转到 L1 仍被重新询问"EG 那边有没有排查？"
查看调研原文
来源：致电 400 调研 · 服务流程与职责边界混乱 · 旧故事 2用户已经联系过EG工程师，并确认问题不在EG侧。
在新的排查过程中，用户再次联系交换机工程师，希望继续推进问题解决。
但在沟通开始时：
工程师重新询问：
- "EG那边有没有排查？"
- "具体情况是怎么样？"
用户需要再次：
- 解释之前的排查过程
- 重复提供已经确认过的信息
-
多任务并行下断裂闪电侠 痛点 1L1 处理用户 1 过程中切去处理用户 n，双方反复确认"你还在吗"
查看调研原文
来源：闪电侠转人工调研 · 痛点 1（多任务并行 - 任务失控）L1：
- 没有任务优先级、管理，全靠记忆去处理多个任务
用户：
- L1响应不连续，没有自己的专属客服
旧故事：L1遇到复杂任务（用户1），排查时间久，中间就会遇到新任务（用户n）进入。L1在帮用户1远程处理中间，可能会回复用户n，但不能帮用户n远程处理，导致L1不断和用户（1和n）说'等一下'，用户（1和n）反复确认'你还在吗'。
-
用户主动表达持续性担忧闪电侠末尾用户 1 担心"午休没人了"，明确要求"随时有人"
查看调研原文
来源：闪电侠转人工调研 · 11:37 用户 6 进入段落用户1又担心上午之后午休没人了，L1说随时有人
需求成立。频率高、影响广，且观察到用户已采取应对动作（主动要求建微信群）——这是需求强度的可观察信号。
支持证据
-
致电 400 信任与认知 旧故事 2用户已自行排查、尝试过配置、得出初步结论，希望"在已有排查基础上继续往下走"。但工程师仍从基础步骤重新验证——用户甚至主动说"这个我已经试过了"，流程仍继续重复
查看调研原文
来源：致电 400 调研 · 信任与认知问题 · 旧故事 2用户在联系工程师之前，已经自己尝试过一些解决方案：
- 做过排查
- 尝试过配置
- 甚至已经得到过初步结论
因此在打电话时，用户希望："可以在我已有排查基础上继续往下走"
但在实际过程中：
- 工程师仍然从基础步骤重新验证
- 对用户提供的信息持保留态度
- 重复执行用户已经做过的操作（不过确实会出现工程师重复操作就能成功解决）
随着排查推进：
- 用户开始感到不耐烦
- 甚至会主动说明："这个我已经试过了"
但流程仍然继续重复验证。
-
致电 400 旧故事 1升级到研发后用户再次进入等待状态，但不知道问题是否已被确认、多久会有人跟进、当前卡在哪一步
查看调研原文
来源：致电 400 调研 · 信息与工具割裂 · 旧故事 1用户遇到网络问题后拨打电话，希望尽快定位原因并恢复业务。
电话接通后，工程师表示需要"先查一下"，用户只能在电话那头等待，不清楚工程师在查什么、进展如何。
随后双方开始用远程工具一起排查：
- 工程师不断询问信息
- 用户配合操作、反复验证
- 过程持续较长时间
但最终仍然没有明确结论。
工程师告知问题需要上升到研发处理，并开始整理升级信息。
在这段时间内，用户再次进入等待状态，但：
- 不知道问题是否已经被确认
- 不确定后续多久会有人跟进
- 也不清楚当前卡在哪一步
最终只能被动等待新的工程师联系。
-
Case 1用户再次来电时还要和 L1 重新共识故障背景，多轮触达后历史背景未继承
查看调研原文
来源：致电 400 调研 · Case 1 痛点分析第 1、2 条1. 用户上午打过电话，到下午还没有回复，他就再次来电
2. 用户会问L1是否是上午的同一个 -> （不是）再次共识发生了什么故障
需求成立。"已做过的被要求重做"与"上升后状态不明"两类场景证据都充分。
支持证据（仅覆盖"基础信息收集"子维度）
-
Case 2用户不知道在哪看 SN，花 2 分钟无引导
查看调研原文
来源：致电 400 调研 · Case 2（有线无法访问外网，排查后恢复 10min）痛点分析1. 用户要提供产品型号、序列号（不知道在哪里看序列号 2min，也没有引导），后续又可以直接接工程师了
-
Case 3邮箱口头录入输错，用户没收到要重新发
查看调研原文
来源：致电 400 调研 · Case 3（环路配置，发送配置文档 3min）L1接听用户咨询并查看工单【工单系统】
用户咨询环路配置相关问题，想要说明文档
L1在锐捷官网中检索相关配置文档【锐捷官网】
L1通过邮件发送配置内容【闪电兔】【邮箱】
发送方式：发送文档链接（考虑文档本身可能涉及保密）
完成问题处理
L1工单解决【工单系统】
L1引导用户晚一点挂断，进行满意度评价
后续发现邮箱输错了，用户没有收到，再次电话反馈，重新发邮箱
痛点分析：
1. 多个工具，用户邮箱是靠口头再输入的。信息传递阻碍
-
致电 400 痛点 3信息输入靠口述（型号/SN/邮箱）易错
查看调研原文
来源：致电 400 调研 · 痛点 3（用户参与成本高）本质：问题解决是"人+人远程协作"，但没有好的协同机制
场景：
- 等待：下载远程工具 6min；用户操作 → L1等待（无反馈）
- 操作冲突： 用户动鼠标 → L1无法操作
- 信息输入： 型号 / SN / 邮箱靠口述（易错）
- 用户认知问题：看不懂代码 → 需要解释；不信任 → 反复验证（1小时）
-
闪电侠 痛点 5远程工具无法获取 excel、图片等信息，只能让用户再发送
查看调研原文
来源：闪电侠转人工调研 · 痛点 5（工具限制 - 用户承担错误成本）L1：
- 远程工具无法获取excel、图片等信息，只能让用户再发送
用户：
- 时不时地被需要操作（发送信息、操作实体设备）
未被验证的部分：需求点 3 原文指向"问题一时说不清楚"，但调研中用户对故障现象的描述大多简明（"上不了网""无法访问外网"等）。观察到的主要是基础信息（SN / 型号 / 邮箱）输入成本高，不是问题描述本身复杂讲不清。
"基础信息收集成本"维度成立；"问题描述本身低成本表达"维度未被验证。建议拆分后再决定优先级。
支持证据
-
闪电侠 痛点 4研究方直接概括："用户最想了解的是问题是什么怎么解决，但 L1 只说排查到哪了……也没法给出具体时间，用户等待的时候是一个黑盒"
查看调研原文
来源：闪电侠转人工调研 · 痛点 4（无法得知进展和等待时间）用户：
- 想知道问题是什么，怎么解决（L1只说排查到哪了），用户有不确定，无法掌控的感受
- 用户想知道预计处理时间
旧故事：用户看到L1在排查，但并没有和用户交流发生了什么。用户最想了解是什么问题要怎么解决，但L1在排查过程中往往无法回答，只能说排查到了可能出问题的部件，所以也没法给出具体的时间，用户等待的时候是一个黑盒。
-
Case 8用户 10 分钟开始不耐烦，问了一次问题在哪，13 分钟又问一次
查看调研原文
来源：致电 400 调研 · Case 8（接口速率/版本问题排查 17min）痛点分析1. 和用户排查问题很久，用户尝试过也告知了但L1会再尝试一次（pin不同）
2. 用户会有不耐烦（10min左右），问了一次所以问题在哪（13min又问了一次）
3. 闪电侠->官网，信息在不同地方，搜索有一定麻烦
-
致电 400 旧故事（排查依赖经验）用户开始不安，追问"现在问题找到了吗？""大概是什么原因？"，但工程师仍在排查无法给出明确结论
查看调研原文
来源：致电 400 调研 · 排查过程依赖经验 · 旧故事用户遇到故障后拨打电话，希望工程师能够快速定位问题并给出解决方案。
电话接通后，工程师通过远程工具开始进行排查：
- 偶尔询问一些信息（设备、现象等）
- 中间有一段时间在操作代码或思考
- 再继续尝试不同的方式验证
整个过程中：
- 用户不知道工程师具体在排查什么
- 也不清楚当前已经排除了哪些可能性
- 更无法判断现在是在接近问题，还是在"试一试"
随着时间推移（10分钟以上）：
- 用户开始变得不安
- 主动询问：
"现在问题找到了吗？"
"大概是什么原因？"
但工程师仍在继续排查，无法给出明确结论。
-
闪电侠 痛点 1用户反复确认"你还在吗"
查看调研原文
来源：闪电侠转人工调研 · 痛点 1 旧故事L1遇到复杂任务（用户1），排查时间久，中间就会遇到新任务（用户n）进入。L1在帮用户1远程处理中间，可能会回复用户n，但不能帮用户n远程处理，导致L1不断和用户（1和n）说'等一下'，用户（1和n）反复确认'你还在吗'。
-
闪电侠 用户 1用户在等待中反复询问"L1 是不是还在"，强调希望先恢复业务
查看调研原文
来源：闪电侠转人工调研 · 10:32 用户 2 结束 / 11:02 继续用户 1L1回到微信群，
用户1 询问L1是不是还在，以及希望L1能尽快辅助他先恢复业务，再去排查
再次和L1确认问题是什么
L1 回答了现状（不是判断、解决方式）
用户1在此强调希望L1能尽快辅助他先恢复业务，再去排查
……
L1回复用户1
用户1反馈灯亮着，刚还有网，现在服务器都没网了，用户发现自己拨错了
L1和用户1又开始语音，继续排查
需求成立。用户的不耐烦行为（重复追问、明确表达不掌控感）有清晰可见的可观察特征。
支持证据（间接、偏少）
-
Case 1 痛点 6/7L1 调试代码用户看不太懂需 L1 解释；用户对问题有自己理解，L1 要先回复解释
查看调研原文
来源：致电 400 调研 · Case 1 痛点分析第 6、7 条6. L1代码调试用户是看不太懂的，L1会解释一下这段代码就是什么什么意思，用户可以选择做什么什么（例如用户想要新增网段全被占用，L1发现其他接口有空闲，用户再次确认问是什么）用户也会想要了解正在干什么
7. 用户对问题有自己理解的原因和解决方式，L1一般要先回复解释
-
闪电侠 旧故事用户 1 想要"解决方案"（连续追问怎么办），但 L1 只给出排查的现状
查看调研原文
来源：闪电侠转人工调研 · 10:49 左右观察用户1想获得解决方案（连续追问怎么办），但L1只给出排查的现状
……
用户1想要继续语音聊，但是L1回复没有空
-
致电 400 痛点 5用户有自己的理解 → 需要说服
查看调研原文
来源：致电 400 调研 · 痛点 5（信任与认知问题）用户 vs 工程师 vs AI 三方信任
典型场景：
- 用户不信任判断 → 强行验证
- 用户有自己理解 → 需要说服
- 同一问题的解决方法： 用户试过 → L1还要再试一遍
- AI（闪电侠）错误 → 导致决策错误
未被验证：调研中没有出现"L1 追问机械""回应生硬"的直接观察；研究方在所有痛点总结里都没概括过这一点。可能原因：（a）实际跟访的 L1 整体沟通相对耐心专业；（b）"沟通生硬"更适合从用户视角（不满意来电回放、满意度访谈）验证，本研究是工程师侧观察。
方向相关但直接证据不足，存在优先级被高估的风险。建议从用户侧补充验证后再决定是否纳入。
支持证据
-
闪电侠 用户 1用户 1 多次强调"希望 L1 能尽快辅助他先恢复业务，再去排查"——这是"先给方向、再深究"的最直接证据
查看调研原文
来源：闪电侠转人工调研 · 10:32 用户 2 结束，继续处理用户 1L1回到微信群，
用户1 询问L1是不是还在，以及希望L1能尽快辅助他先恢复业务，再去排查
再次和L1确认问题是什么
L1 回答了现状（不是判断、解决方式）
用户1在此强调希望L1能尽快辅助他先恢复业务，再去排查
-
Case 8用户担心业务中断、询问处理时长，L1 给出预估"10-20 分钟"——L1 自己也意识到"给时间"回应很关键
查看调研原文
来源：致电 400 调研 · Case 8（接口速率/版本问题排查 17min）L1返回 CRT 继续排查与验证【CRT】
L1用鼠标向用户解释 CRT 中返回结果（无数值表示交换机未发出），建议要升级
用户担心业务中断，询问处理时长
L1回复预计10–20分钟，并建议在节假日或夜间进行测试
L1工单解决【工单系统】
-
闪电侠 痛点 4用户想知道是什么问题怎么解决，但 L1 只说排查到哪了——用户的重点与 L1 给的信息不匹配
查看调研原文
来源：闪电侠转人工调研 · 痛点 4用户：
- 想知道问题是什么，怎么解决（L1只说排查到哪了），用户有不确定，无法掌控的感受
- 用户想知道预计处理时间
旧故事：用户看到L1在排查，但并没有和用户交流发生了什么。用户最想了解是什么问题要怎么解决，但L1在排查过程中往往无法回答，只能说排查到了可能出问题的部件，所以也没法给出具体的时间。
未被充分验证：原文需求点 6 包含"该先安抚时先安抚、该先给结论时先给结论、该先说明风险时先说明风险"等多场景智能切换。调研中仅观察到"先恢复业务"和"先给时间预估"两个子场景，其它子场景没有直接证据。
关于"魅力需求"：从观察数据看，"先恢复业务"更接近显性的期望需求（用户主动多次提出），不是未说出口的惊喜。KANO 等级需要专门方法验证。
方向成立但被压缩成了"先恢复业务、先给时间"这一核心子场景；不宜泛化承诺所有分场景切换。
支持证据
-
致电 400 补充信息L1 处理过程中切换：工单系统、呼叫中心、工作台、飞书、闪电侠、闪电兔、锐捷官网，外加豆包等外部 AI
查看调研原文
来源：致电 400 调研 · 补充信息在实际处理过程中，L1工程师会同时使用多种工具进行沟通、查询与问题排查：
可能会使用外部AI工具（如 豆包）进行辅助（很多时候）：
- 查询其他厂商信息（如华为设备说明，内部工具无法覆盖）
- 对英文内容或代码进行翻译
- 通过截图识别界面或命令并进行理解
L1工程师在处理过程中会在多个系统之间切换：
- 【工单系统】：查看与更新工单信息
- 【呼叫中心】：接听与呼出电话
- 【工作台】：承接来自微信、官网等渠道的转人工服务（今日未遇到）
- 【飞书】：内部沟通与信息同步
- 【闪电侠】：搜索知识与排查方案（对其半信半疑，认为一半以上不能用）
- 【闪电兔】：查找配置文档或操作说明
- 【锐捷官网】：查找官网文件
-
致电 400 痛点总结 1配置文档找闪电兔、排查方案找闪电侠、说明文档找官网、搜不到就问人；搜索路径依赖经验（新手需一个月熟练）；信息重复但不一致（AI 还会答错）
查看调研原文
来源：致电 400 调研 · 痛点总结 1（信息与工具割裂）使用工具上面已全部列出
场景1：工程师对于说明文件回去官网查询，配置操作+文档会去闪电兔，对于排查方案会去闪电侠试一下，部分文档还回去搜索飞书（几个搜索工具会有重叠场景，但就基于用户的判断选择一个），一般不会都搜索，完全搜索不出的更倾向于直接问人
场景2：上升故障，需要将故障、排查信息（口头交流）转化为文字填写为升级报告（耗时至少5min用户只能等待）
结果：
- 搜索路径依赖经验（新手很难）
- 信息重复但不一致（AI还会答错）
- 口头信息需要梳理为文字，重复又耗时
-
闪电侠 痛点 2客服平台、企业微信、语音、小锐云桥、闪电兔、官网共 6 个平台来回切换
查看调研原文
来源：闪电侠转人工调研 · 痛点 2L1：
- 客服平台（最初问题）
- 企业微信（拉群沟通）
- 语音（关键沟通）
- 小锐云桥（远程）
- 闪电兔（查命令）
- 官网（查资料）
-
闪电侠 痛点 3聊天散落在两个平台并不会实时记录进展……知识存在但不可直接决策，多次出现问其他 L1、问服务代表
查看调研原文
来源：闪电侠转人工调研 · 痛点 3（排查不结构化 - 知识依赖"人"而不是系统）L1：
- 聊天散落在两个平台，并不会实时记录进展
- 中断当前任务，依赖经验者（多次出现问其他L1、问服务代表）
- 本质：知识存在，但"不可直接决策"
旧故事：L1在CRT排查的时候，要对比用户传来的图片信息，所以他会在微信群和客服平台切换查看图片。在查询闪电兔之后，仍遇到不知道排查下一步的时候，只能去问身边有经验的L1，让用户等着。
-
Case 4授权问题中售前→产品经理→400 互相踢皮球
查看调研原文
来源：致电 400 调研 · Case 4（交换机授权内部 5min）痛点分析1. 不确定责任人：（授权）售前去找产品经理，产品经理说找400；售前找400，400说应该找售前
-
闪电侠 用户 4L1 自己也说不知道怎么处理，需去问其他 L1 并搜闪电兔
查看调研原文
来源：闪电侠转人工调研 · 11:24 用户 4 来催 / 11:21 用户 5 段落L1继续处理用户1的问题，但不知道怎么解决，所以和用户1说你稍等一下，L1随机问身边的其他L1工程师
和其他L1工程师描述了一遍问题+排查到哪了
其他L1工程师判断可能是vlan7有问题，问L1是不是VRP两边没有配置一致，叫L1去搜闪电兔，又问这个L1会不会搜
L1和用户1说我先挂了，帮他再问一下
需求成立。这是本次调研中被反复证实的最强痛点之一——工具碎片化、知识依赖人、AI 不可信三层叠加。
支持证据
-
致电 400 痛点 1 场景 2上升故障时要把故障、排查信息（口头交流）转为文字填升级报告，耗时至少 5 分钟，用户只能等待
查看调研原文
来源：致电 400 调研 · 痛点总结 1 场景 2场景2：上升故障，需要将故障、排查信息（口头交流）转化为文字填写为升级报告（耗时至少5min用户只能等待）
-
Case 10L1 整理信息并上升给 L1.5，填写信息约 6 分钟
查看调研原文
来源：致电 400 调研 · Case 10（有线上网很卡 25min）L1（判断自己无法解决）添加用户企业微信，转为线上沟通【企业微信】
L1整理信息并上升问题给L1.5（填写信息约6分钟）【工单系统】
填写：
（设备型号，问题现状，已排查：
1、终端有线直接核心上网卡顿，测速只有二三十兆，有线直连eg网关网速正常
2、终端使用无线上网正常不卡的，测速能到100兆
3、有线和无线都是通过eg上外网
4、eg同事有看过eg设备正常
5、核心交换机没有任何限速）
网络拓扑：eg 1和2口—— ag2 核心 gi1/1/11——电脑终端
（一共填写了五分钟）
-
闪电侠 提要"客服平台对话不会直接建立工单，需要手动输入——该工程师是在下午统一填写上午的单"——这是工程师为节省时间形成的应对策略，是强需求的可观察证据
查看调研原文
来源：闪电侠转人工调研 · 提要这次观察的L1工程师是在客服平台处理故障、咨询的，所以整体处于同时处理多个用户、频繁切换任务的状态。
拉群：简单问题可以短时间解决掉的会在工作台【客服平台】解决，短时间无法解决的且需要内部确认会拉微信群【企业微信】处理，客户一定时间未回复会掉线，加微信群处理也可以防止后续无法联系客户
工单填写：在客服平台上的对话不会直接建立工单，需要手动输入（该工程师是在下午统一填写上午的单）
-
致电 400 旧故事 2邮箱靠口述易错、错了还要再来一次
查看调研原文
来源：致电 400 调研 · 信息与工具割裂 · 旧故事 2用户希望获取一份配置或说明文档，于是通过电话向工程师咨询。
工程师表示会通过邮件发送文档，用户需要口头提供邮箱地址。
通话结束后，用户开始等待邮件。
但过了一段时间（如一小时），用户发现始终没有收到：
- 不确定是自己邮箱报错了
- 还是工程师没有发送成功
- 也没有任何状态反馈
用户只能再次拨打电话，重新说明需求并再次确认邮箱地址，直到确认收到邮件后才结束。
需求成立。"工单堆到下午统一填"是真实痛点的行为证据。