技能提升网9:12，客户说导出的文件只有表头；10:20，客服转发第二张截图；11:00，客户又来问什么时候能好，研发却还不知道用什么账号、什么筛选条件重现。把这条虚构时间线放在一起就能看出：消息变多了，可用于排查的条件并没有自动变完整。客服需要补的是一份能交接的升级单。
先把客户的催促还原成问题和影响
以虚构工单 T204 为例，客户编号 C17。现有记录说明：筛选后的列表有记录，导出文件只有表头；管理员账号测试也出现相同现象，更换浏览器后仍出现；客户需要在 14:00 前提交业务材料。暂时不知道其他客户是否受影响，也没有确认服务端根因和修复日期。上述内容是教学示例，未对真实产品执行测试。
准备脱敏后的完整对话、已有测试记录、报错原文、相关文件和内部工单。截图应配发生时间和操作说明，避免把不同账号、不同日期范围下的现象当成同一次故障。密码、访问令牌、完整客户数据不应随着升级材料四处转发。
先用 ticket-triage 整理问题类别、业务影响、临时办法和建议处理归属。它原始说明包含优先级、重复工单检查和路由建议。接入客服或项目系统时才能检索相应记录；未接入时，只能比对提供的材料，不能写成“全系统未发现同类问题”。
本例可以提出“疑似导出功能异常，需要技术支持进一步判断”。优先级理由应引用被阻塞的具体工作、影响范围和截止时间。客户催了三次是沟通压力的信号，但不能单凭次数认定为全站重大事故；原 Skill 中的分级和时间框架也应按团队实际服务规则调整。
一份可复现描述，要有起点和终点
收集足够条件后，交给 customer-escalation 组织升级单。这个 Skill 的职责是整理背景、复现步骤、影响和接手请求，不是自动找到故障根因。
对于 T204，复现描述应包括测试环境或版本、账号角色、数据范围、筛选条件、操作顺序、发生时间以及结果文件。只有“点导出就出错”仍然缺少条件。已经提供的管理员与浏览器测试记录可以引用，但要注明由谁、何时执行；没有做过的测试列为建议，不改写成已通过或已排除。
预期结果写成“导出的文件应包含当前筛选范围内、该账号有权访问的数据行”；实际结果写成“文件可打开，但只有表头”。如果列表数量与导出数据条数本来就有分页或汇总差异，应先核对产品规则，不能直接认定二者必须相等。
让研发知道现在需要它做哪件事
升级单中可以写：“请确认导出模块的调查负责人，并根据工单记录的时间、环境及请求标识核对服务端处理情况；如证据不足，请列出缺失项。请同时评估是否有可验证的临时办法。”比起“客户很急，尽快修复”，这段话更接近研发实际能开始的工作。
一个可用的示例摘要是：
T204，C17 报告筛选后导出文件仅含表头。现有记录显示管理员账号及更换浏览器后仍出现，相关条件与脱敏文件已附。客户需在 14:00 提交材料，临时办法未确认。影响范围和根因待查。请求导出模块负责人接手调查，确认所需证据，并评估可行的临时处理办法；客服保留客户沟通责任。
业务影响应写已知事实。“客户今天要提交材料”有明确来源；“将损失几十万元”如果客户没提供可靠依据，就不要写入。截图、日志和文件也要有名称与时间，不把“见附件”当成完整证据说明。
资料缺失时，先把缺口问到位
如果客服尚未获得复现条件，可以先列一张短清单：在哪个环境、哪个账号角色、筛选了什么范围、何时出现、实际结果是什么、是否每次都发生。只问对本次调查有用的问题，避免让客户重新填写整份背景调查。
遇到无法复现的情况，记录已经试过的条件与结果，并注明“暂未复现”。如果已存在同类主工单，应把新增客户和证据关联进去，而不是创建一个没有关联的新问题。是否属于同一故障仍需技术确认，不能只因报错相似就合并根因。
接手确认和客户反馈要分别跟踪
发出升级材料后，记录接手团队、实际负责人、下一次内部反馈时点和客服对客户的反馈安排。Skill 生成了材料，并不代表研发已经接单；自动发消息或创建记录还取决于连接工具及明确授权。
客户要求 14:00 拿到材料，不等于团队已经承诺 14:00 修复。客服可以按真实情况回复：“问题已转交导出模块排查，当前正在确认临时办法，我们将在约定时间反馈进展。”只有确实完成了转交和接手确认，才使用对应措辞。
问题解决后，让客户确认原业务操作可以继续，并保留处理原因、验证条件和适用范围。下次相似工单再出现，接手人就能先查已有记录，而不用从一张没有说明的截图开始。
