客服转产品反馈，别只递抱怨，要递一张可判断的问题卡

教程定位

这篇教程解决什么问题

客服把用户抱怨转给产品时，最常见的问题不是信息太少，而是信息没有被翻译。用户说“导出又坏了”“你们后台太难用”“这个问题已经催三次了”，客服如果原样转发，产品只能继续追问：哪个入口、什么账号、哪些用户、能不能复现、影响范围多大、有没有临时绕法、和上周那个问题是不是一回事。

这篇教程给客服产品接口人一套做法：把零散工单、截图、账号线索和一线处理记录，整理成产品能判断的问题卡。它不是客服内部标签统计，也不是替产品写完整需求方案。它的目标只有一个：让产品经理拿到反馈后，能判断这是不是产品问题、影响谁、是否值得进入排期、还缺什么证据。

最终产物是一张“产品反馈卡”，包括问题描述、用户场景、影响范围、证据、复现方式、临时解决方式、优先级建议和待确认问题。写好这张卡，客服不再只是传声筒，产品也不用在一堆情绪化截图里找线索。双方讨论会从“用户很不满”变成“这个场景是否需要修、先修到什么程度、上线后怎么验证”。

本文样例均为安全虚构，不包含真实用户姓名、手机号、邮箱、订单号、公司名称、账号 ID、内部链接或截图原文。真实使用时，请先脱敏，再让 AI 辅助整理。

使用场景

什么情况下最适合用这一套

你是客服和产品之间的接口人。每天一线客服会把用户反馈发给你，产品同事也会在群里问“最近用户到底在抱怨什么”。你手里有很多材料：工单摘要、聊天截图、用户账号、客服备注、临时处理办法、同类问题数量。但这些材料还不是产品能直接判断的反馈。

比如，最近企业客户反复反馈“账单明细导不出来”。一线客服已经收集了几十条工单。有的用户说导出按钮没反应，有的说页面提示成功但邮箱收不到，有的说管理员账号能导出但财务协作者不行，还有的说昨天可以今天不行。客服主管希望尽快推动产品修复，于是把截图打包发给产品。

产品收到后却很难接。因为“导不出来”可能是权限规则问题、邮件发送延迟、文件生成超时、浏览器兼容、导出字段过多、账号套餐限制，也可能只是用户不知道下载入口在哪。产品需要的不是更多截图，而是一张可判断的问题卡：哪个用户场景下，期待发生什么，实际发生什么，影响多少账号，客服能否复现，有哪些证据，是否已有绕行方案。

这就是客服产品接口人的价值。你不需要替产品决定最终方案，也不需要把所有工单做成复杂分析报告。你要做的是在转给产品前完成一次翻译：把用户情绪翻译成任务场景，把“很多人反馈”翻译成影响范围，把“看起来像 bug”翻译成复现条件，把“很急”翻译成优先级建议和依据。

好的产品反馈卡通常能让产品经理在 5 分钟内做出第一轮判断：

如果反馈卡写不清这些，产品就会继续追问；如果每次都要产品追问，客服会觉得产品不重视，产品会觉得客服只会甩锅。翻译这一步，正是为了减少这种消耗。

• 这是一个明确的问题，还是多个问题混在一起。
• 当前证据是否足够进入排查。
• 影响的是全部用户、某类用户，还是个别账号。
• 客服是否有临时解决方式，能撑多久。
• 下一步需要产品、技术、客服分别补什么信息。

材料准备

开始前先把材料和边界备齐

开始前，先把材料分成六类。不要把所有截图和聊天记录一股脑丢给 AI，也不要只给一句“用户说账单导不出”。

第一类是用户工单。保留工单编号、创建时间、渠道、用户原话摘要、客服处理记录、关闭状态和是否重复追问。用户原话要做脱敏，保留意思，不保留个人身份。比如把“张三，手机号 138xxxx，在 XX 公司账单中心导不出 6 月账单”改成“企业客户 A 的财务协作者，在账单中心导出 6 月明细失败”。

第二类是问题截图。不要直接把包含隐私的原图发给 AI。可以把截图转写成文字：页面路径、按钮文案、报错文案、时间戳、账号角色、关键状态。产品判断问题时，更需要“截图里显示什么”，不一定需要看到原图。

第三类是账号和环境信息。至少准备用户类型、套餐、角色权限、使用入口、设备、浏览器或 App 版本、所在地区、是否开了某个配置。很多产品问题只发生在特定角色或特定配置下。没有这些信息，产品很难判断影响范围。

第四类是复现步骤。把用户或客服实际做过的步骤写成可重复动作：从哪个入口进入，点击什么，选择什么条件，期待看到什么，实际发生什么。如果客服没有复现成功，也要写清“未复现”和已尝试条件，而不是假装已经确认。

第五类是影响范围。准备同类工单数量、时间范围、影响用户类型、是否集中在某个版本或模块、是否影响付费客户、是否影响关键业务动作。优先级不是靠声音大小判断，而是靠影响范围、业务阻断程度、发生频率和是否有绕行方案判断。

第六类是临时解决方式。客服有没有帮用户绕过去？比如改用管理员账号导出、缩短日期范围、改走人工邮件发送、让用户等待批处理完成。临时方案很重要，因为它会影响优先级判断：没有绕行且阻断关键任务的问题，通常要比有稳定绕行的问题更急。

还有一个准备动作容易被忽略：先确认这批工单是否真的属于同一个问题。用户都说“导出失败”，但如果有的是按钮不可见，有的是邮箱没收到，有的是文件字段缺失，有的是权限不足，就应该拆成不同反馈卡。产品反馈卡宁可小而准，不要大而糊。

实操流程

按这套步骤把工作跑起来

第一步，先把用户抱怨还原成用户任务。

不要直接写“用户吐槽账单导出很烂”。先问：用户原本想完成什么任务？比如“财务协作者想导出上月用量明细，用于月度对账”。任务写清后，产品才能判断这个问题阻断了哪个业务流程。用户情绪可以作为证据，但不能替代问题描述。

第二步，把问题写成“期望结果 vs 实际结果”。

产品最容易判断的表达是：在什么条件下，用户期望发生什么，实际发生什么。比如“企业版财务协作者在账单中心选择 2026 年 6 月用量明细并点击导出后，页面提示导出任务已提交，但 30 分钟内邮箱未收到下载链接；同一企业的管理员账号可成功收到”。这句话比“账单导不出来”更长，但它已经包含场景、角色、动作和异常表现。

第三步，拆掉混在一起的多个问题。

如果一批工单里同时出现“按钮不可见”“导出后无邮件”“文件打开失败”“字段缺失”，不要合并成“导出功能有问题”。你可以先让 AI 帮你分组，再为每个高频组写一张反馈卡。产品排查和排期通常按问题边界推进，而不是按用户抱怨的关键词推进。

第四步，补齐影响范围。

影响范围不要只写“很多用户”。更好的写法是“过去 7 天收到 24 条同类工单，涉及 11 个企业账号，其中 8 个为企业版付费客户；客服已确认 6 条发生在财务协作者角色，管理员角色暂未出现同类失败”。如果样本还不够，也要诚实写“当前仅能确认工单样本，尚未有后台全量数据”。

第五步，整理证据包。

证据不等于截图越多越好。产品反馈卡里的证据要能支撑判断，常见证据包括用户原话摘要、截图转写、客服复现记录、账号角色、发生时间、错误文案、同类工单数量、临时解决方式、历史版本变化。每条证据最好能回答一个问题：它证明了什么？如果不能证明，就不要堆进卡片。

第六步，写复现方式和复现状态。

复现方式至少包括前置条件、操作路径、输入条件、实际结果、期望结果和复现频率。比如“使用财务协作者角色，进入账单中心，选择 2026-06，用量明细，点击导出，页面出现提交成功，但测试邮箱 30 分钟内未收到邮件。客服使用测试企业账号复现 2 次，均失败；管理员角色复现 2 次，均成功”。如果客服没有测试账号，就写“待产品提供测试账号或日志排查”，不要编造复现。

第七步，给优先级建议，但不要替产品拍板。

客服可以给建议，例如“建议 P1 排查”或“建议进入本周缺陷池”，但必须写依据。优先级建议可以按四个维度：业务是否被阻断、影响用户范围、是否有可用绕行、是否涉及付费或关键客户。不要只因为用户语气激烈就写最高优先级，也不要因为工单量暂时少就忽略高价值客户被阻断。

第八步，写清客服已经做过什么。

产品最怕收到重复问题后，还要从零问客服“有没有安抚、有没有绕行、有没有收集账号”。反馈卡里应写明客服已尝试的动作：已指导用户用管理员账号导出、已人工发送一次明细、已记录用户同意等待、已收集账号角色和时间范围。这样产品知道当前风险是否被临时兜住。

第九步，列出待产品确认的问题。

一张好的反馈卡不一定把所有答案都写完，但要把缺口写清。比如“是否近期调整过账单导出权限”“财务协作者是否本应收到邮件”“邮件发送任务是否有失败日志”“是否需要补充下载中心入口”。这些问题能帮助产品快速决定下一步找谁。

第十步，把反馈卡交给产品前做一次人工复核。

检查它是否只讲一个问题，是否有用户场景，是否有影响范围，是否有证据，是否有复现方式，是否标明不确定点。复核后再发给产品，而不是把 AI 初稿原样贴进群里。

输入示例

可以直接参考的输入材料

下面是一组安全虚构的输入材料。真实使用时，请替换成你们自己的脱敏工单、截图转写、账号信息和复现记录。

这组输入的关键，是把“账单导不出来”拆成了可验证信息。它没有只保留用户情绪，也没有把所有导出相关工单混成一个结论。CS-133 可能只是大文件延迟，不一定属于同一个问题；这类边界要在反馈卡里单独标出。

【任务背景】
我是客服产品接口人，需要把一批“账单明细导出失败”的用户工单整理成产品能判断的反馈卡。请不要写用户回复话术，也不要写完整产品方案，只整理产品排查和定优先级需要的信息。

【产品模块】
企业后台 > 账单中心 > 用量明细导出

【已知入口】
用户进入企业后台，点击“账单中心”，选择月份，选择“用量明细”，点击“导出到邮箱”。

【工单样本，已脱敏】
工单 CS-117
时间：2026-07-01 10:12
用户类型：企业版付费客户
账号角色：财务协作者
用户原话摘要：我点击导出后页面提示“导出任务已提交”，但邮箱一直没有收到下载链接，昨天管理员同事可以导出。
客服处理：确认邮箱正常收信；建议先让管理员导出后转发给用户。
状态：已临时解决，用户要求尽快修复。

工单 CS-129
时间：2026-07-01 15:46
用户类型：企业版付费客户
账号角色：财务协作者
用户原话摘要：6 月用量明细导不出来，页面没有报错，只说提交成功。我们今天要对账。
客服处理：收集页面路径和截图转写；用户不愿意改用管理员账号，担心权限不合规。
状态：升级中。

工单 CS-133
时间：2026-07-02 09:20
用户类型：团队版试用客户
账号角色：管理员
用户原话摘要：导出的文件晚了 20 分钟才收到，不确定算不算失败。
客服处理：告知大文件生成可能延迟；暂未升级。
状态：已关闭。

工单 CS-141
时间：2026-07-02 11:03
用户类型：企业版付费客户
账号角色：财务协作者
用户原话摘要：导出 2026 年 6 月账单时没有收到邮件，改成 2026 年 5 月也不行。
客服处理：客服用同企业管理员账号测试 6 月导出成功；用财务协作者角色测试 2 次，均未收到邮件。
状态：升级中。

【截图转写】
- 页面路径：企业后台 / 账单中心 / 用量明细
- 按钮文案：导出到邮箱
- 成功提示：导出任务已提交，请稍后查看邮箱
- 未出现错误码
- 用户邮箱设置页显示邮箱已验证

【账号和环境信息】
- 已确认 7 天内同类工单 24 条，涉及 11 个企业账号。
- 其中 8 个企业版付费客户，3 个团队版试用客户。
- 可明确角色的 9 条里，6 条为财务协作者，2 条为管理员延迟收到，1 条角色未知。
- 暂未发现移动端相关反馈，主要来自 Web 后台。
- 浏览器信息不完整，已收集到 Chrome 3 条、Safari 1 条。

【客服复现记录】
- 使用测试企业 A 的财务协作者账号：选择 2026 年 6 月，用量明细，点击导出到邮箱，页面提示提交成功，30 分钟内未收到邮件。复现 2 次。
- 使用同企业管理员账号：同样条件下 5 分钟内收到邮件。复现 2 次。
- 缩短日期范围到 7 天：财务协作者仍未收到邮件。

【临时解决方式】
- 让管理员账号导出后转发给财务协作者。
- 对催得急的企业客户，由客服申请后台人工导出一次。
- 绕行方案会增加客服处理时间，也不适合权限管控严格的客户。

【希望 AI 输出】
- 一张产品反馈卡。
- 帮我区分这批工单里哪些不应放进同一张卡。
- 给出优先级建议和依据，但不要替产品做最终决定。

提示词

可复制使用的提示词

下面这段提示词可以直接复制使用。建议每次只处理一个相对明确的问题组，不要把全量客服抱怨都塞进去。

如果 AI 输出太像产品需求文档，可以追加：

如果 AI 仍然把多个问题混在一起，可以追加：

你是客服到产品之间的反馈翻译助手。请根据我提供的脱敏工单、截图转写、账号信息、复现记录、影响范围和临时解决方式，整理一张“产品反馈卡”。

工作目标：
- 把用户抱怨翻译成产品可判断的问题。
- 不写客服回复话术，不写完整 PRD，不替产品决定最终方案。
- 如果材料里混有多个问题，请先指出应拆分的部分。
- 如果证据不足，请明确写“待补证据”，不要用猜测填满。

请严格遵守：
1. 所有内容必须基于输入材料，不编造用户数、日志、结论或产品方案。
2. 问题描述必须包含用户场景、前置条件、期望结果和实际结果。
3. 影响范围必须写清已确认范围和未知范围，不能只写“很多用户”。
4. 复现方式必须写明角色、路径、操作、结果和复现状态。
5. 优先级只能给建议，并说明依据；不要把建议写成最终排期决定。
6. 如输入材料包含真实手机号、邮箱、姓名、订单号、公司名称、内部链接或截图原文，请先提醒我脱敏。

请按以下结构输出：

一、是否需要拆分问题
- 哪些工单属于本反馈卡
- 哪些工单应排除或单独建卡
- 判断理由

二、产品反馈卡
- 建议标题
- 产品模块
- 用户场景
- 问题描述：期望结果 vs 实际结果
- 已确认影响范围
- 证据清单
- 复现方式
- 临时解决方式
- 优先级建议
- 建议产品下一步排查
- 待补证据或待确认问题

三、客服侧后续动作
- 还需要补采哪些字段
- 如何向一线客服说明这类工单的记录要求
- 哪些话不要再直接转给产品

以下是材料：
[粘贴脱敏工单]
[粘贴截图转写]
[粘贴账号和环境信息]
[粘贴复现记录]
[粘贴影响用户数]
[粘贴临时解决方式]

请压缩为客服转产品用的反馈卡，不要写解决方案设计。保留问题、证据、复现、影响和待确认问题即可。

请重新检查样本，把“导出后无邮件”“邮件延迟收到”“按钮不可见”“文件内容错误”分开判断。每张反馈卡只能处理一个可复现问题。

输出样例

AI 应该输出到什么程度

下面是基于前面虚构材料得到的产品反馈卡初稿。正式提交前仍需人工复核，尤其是影响范围、复现结论和优先级建议。

这份样例的重点不是把方案写得多完整，而是把产品判断需要的信息放在同一张卡里。产品可以继续追日志、看权限、确认全量影响；客服也知道下一步要补采哪些字段。和直接转发截图相比，这张卡降低了产品的判断成本，也减少了客服被反复追问的概率。

### 一、是否需要拆分问题

- 建议本反馈卡聚焦：财务协作者在账单中心导出用量明细后，页面提示提交成功，但邮箱未收到下载链接。
- 可纳入样本：CS-117、CS-129、CS-141。
- 建议排除或单独观察：CS-133。该工单为管理员账号延迟 20 分钟收到文件，更像大文件生成或邮件延迟，不足以证明与财务协作者无邮件问题相同。

判断理由：本卡的关键共同点是“财务协作者角色 + 导出到邮箱 + 提示成功 + 30 分钟内未收到邮件”。管理员延迟收到属于不同表现，不应混入当前问题结论。

### 二、产品反馈卡

**建议标题**
财务协作者导出账单用量明细后提示成功，但邮箱未收到下载链接

**产品模块**
企业后台 > 账单中心 > 用量明细导出

**用户场景**
企业客户的财务协作者需要在月初导出上月用量明细，用于内部对账。该角色不一定拥有管理员权限，但承担财务核对工作。

**问题描述：期望结果 vs 实际结果**
在企业版账号中，财务协作者进入账单中心，选择 2026 年 6 月用量明细并点击“导出到邮箱”后，页面提示“导出任务已提交，请稍后查看邮箱”。用户期望在合理时间内收到下载链接。实际情况是多名财务协作者 30 分钟内未收到邮件，页面也没有失败提示；同一企业的管理员账号在相同条件下可以收到邮件。

**已确认影响范围**
- 过去 7 天收到 24 条“账单明细导出失败或无邮件”相关工单，涉及 11 个企业账号。
- 当前能明确角色的 9 条中，6 条为财务协作者，2 条为管理员延迟收到，1 条角色未知。
- 已确认至少 3 个企业版付费客户受到影响，其中 2 个客户反馈月度对账被阻断。
- 尚未知全量影响范围，需产品或技术从导出任务和邮件发送日志确认。

**证据清单**
- 用户反馈均出现“页面提示提交成功，但邮箱未收到下载链接”的描述。
- 截图转写显示页面无错误码，仅显示提交成功提示。
- 用户邮箱设置页显示邮箱已验证，暂未发现邮箱未绑定问题。
- 客服用测试企业 A 的财务协作者角色复现 2 次，30 分钟内未收到邮件。
- 客服用同企业管理员角色复现 2 次，均在 5 分钟内收到邮件。

**复现方式**
1. 使用企业版测试企业 A。
2. 登录财务协作者账号。
3. 进入企业后台 > 账单中心 > 用量明细。
4. 选择 2026 年 6 月。
5. 点击“导出到邮箱”。
6. 页面显示“导出任务已提交，请稍后查看邮箱”。
7. 等待 30 分钟，检查该账号绑定邮箱是否收到下载链接。

当前复现状态：客服侧使用财务协作者角色复现 2 次均失败；同企业管理员角色复现 2 次成功。

**临时解决方式**
- 让管理员账号导出后转发给财务协作者。
- 对紧急企业客户，由客服申请后台人工导出一次。
- 绕行方案不稳定：会增加客服处理时间，且对权限管控严格的客户不适合。

**优先级建议**
建议按 P1 缺陷进入排查。依据：该问题影响企业版付费客户的月度对账流程；客服侧已有角色差异复现；页面提示成功但实际无邮件，会导致用户重复催问；现有绕行依赖管理员或客服人工处理，不适合长期兜底。最终优先级仍需产品结合日志中的全量失败率和近期排期确认。

**建议产品下一步排查**
- 检查财务协作者角色是否具备创建导出任务和接收邮件链接的完整权限。
- 检查导出任务创建成功后，邮件发送队列是否按角色过滤或失败。
- 检查页面“提交成功”是否只代表任务创建成功，而非邮件发送成功。
- 判断是否需要在导出记录或下载中心提供可见的任务状态。

**待补证据或待确认问题**
- 全量导出任务中，财务协作者角色的邮件发送失败率。
- 最近是否有账单权限、邮件队列或导出任务相关发布。
- 浏览器是否影响该问题，目前样本不足。
- 团队版试用客户是否也受影响，目前仅能确认企业版样本更集中。

### 三、客服侧后续动作

- 一线客服继续记录账号角色、月份、导出类型、是否收到邮件、等待时长、浏览器、是否能由管理员导出。
- 遇到管理员延迟收到的工单，先单独标记为“邮件延迟”，不要直接并入本卡。
- 转给产品时不要只说“用户说导出失败”，要写清角色、路径、提示文案和是否已复现。

人工验收

人要怎么检查和改到可用

提交给产品前，先做一次人工复核。AI 可以帮你整理，但不能替你确认事实、判断排期或承诺修复时间。

第一，检查隐私和脱敏。产品反馈卡里不应出现真实姓名、手机号、邮箱、公司名称、完整账号 ID、内部系统链接、合同金额、订单号或截图原图。如果产品排查必须用真实账号，应该走内部安全流程单独提供，而不是把敏感信息贴进 AI 对话或公共群。

第二，检查是否只描述一个问题。标题里如果出现“导出失败、邮件延迟、字段缺失、权限异常”等多个表现，通常说明卡片太大。把它拆开。产品能处理的是边界明确的问题，不是一个情绪集合。

第三，检查问题描述是否可判断。至少要有用户场景、前置条件、操作路径、期望结果、实际结果。缺任何一项，都可能让产品继续追问。尤其要避免“用户无法使用”“体验很差”“功能异常”这类无法直接排查的表达。

第四，检查影响范围是否诚实。已经确认的范围和未知范围要分开写。可以写“已确认 24 条相关工单”，但不要写“影响所有企业客户”，除非有后台数据支持。客服样本能说明趋势，不能自动代表全量。

第五，检查证据是否支撑结论。客服复现了财务协作者无邮件，就可以说“客服侧已在该角色下复现”；不能因此直接断言“权限系统有 bug”。结论要停在证据能到达的位置。

第六，检查优先级建议是否有依据。建议 P1 或 P2 都可以，但要写清原因：是否阻断关键任务、是否影响付费客户、是否集中爆发、是否有绕行、客服兜底成本多高。不要因为某个客户催得急就直接写最高级别。

第七，检查临时解决方式是否真实可用。有些绕行方案只适合一两个客户，不适合规模化，比如客服人工导出、让管理员代操作、手工改数据。写卡时要说明绕行的成本和限制，不要让产品误以为问题已经被稳定兜住。

第八，检查是否夹带未经确认的产品方案。客服可以建议“需要产品判断是否补充任务状态”，但不要直接写“请本周上线下载中心并改权限模型”。产品反馈卡的核心是帮助判断，不是越过产品流程定方案。

【适用边界】

这套方法适用于客服已经收集到一定材料、需要把同类工单交给产品判断的问题，例如功能疑似缺陷、页面提示不清、权限规则争议、批量用户无法完成某个操作、临时方案成本过高。

它不适用于三类情况。第一，正在发生的大面积故障，应走事故响应或值班升级，不要先花很久写卡。第二，涉及赔付、合同、封号、法律或安全风险的个案，必须走对应审批和合规流程，AI 只能辅助整理事实。第三，只有一条情绪化抱怨且没有任何复现、账号或截图材料时，不要强行写成产品问题，可以先列为待补证据。

失败反例

这些失败反例要提前避开

反例一：把用户情绪原样转发给产品。 错误做法是把十几张聊天截图丢进产品群，然后补一句“这个问题用户已经炸了，麻烦尽快看”。产品看不到场景、角色、路径、影响范围，只能继续追问。正确做法是保留情绪作为风险信号，但把主体翻译成“谁在什么条件下无法完成什么任务”。

反例二：把多个不同问题揉成一张反馈卡。 “账单导出失败”下面可能包含按钮不可见、提交成功但无邮件、邮件延迟、文件打不开、字段缺失。它们需要不同排查路径。如果全部写在一张卡里，产品很难定 owner，也很难验证修复效果。正确做法是先按表现和复现条件分组，再分别写卡。

反例三：没有复现条件却要求最高优先级。 有些反馈只写“多个客户说不行，建议 P0”。但没有账号角色、入口、时间范围、错误文案，也没有客服复现记录。产品无法判断是个别操作问题还是系统缺陷。正确做法是写“建议先补证据或做日志排查”，优先级建议必须和证据强度匹配。

反例四：只报工单数量，不写业务影响。 “本周 24 条工单”有用，但不够。产品还需要知道这些工单是否阻断付费客户对账、是否导致重复催问、是否需要客服人工处理、是否有可用绕行。正确做法是把数量和业务后果放在一起：多少客户、什么任务、被阻断到什么程度、客服兜底成本如何。

反例五：把客服临时方案包装成产品需求。 客服为了救急让管理员代导出，于是反馈里写“建议产品增加管理员一键转发功能”。这可能只是绕行，不一定是正确方案。正确做法是写清临时方案和它的限制，让产品判断根因和方案，而不是直接把一线兜底动作变成需求。

反例六：把 AI 生成的初稿当成事实结论。 AI 可能会根据材料推测“权限校验异常”或“邮件队列失败”。如果材料里没有日志，就不能把推测写成确定结论。正确做法是让 AI 帮你组织证据，同时把未确认内容放进“待产品确认问题”。

主题边界

它和相邻主题的区别

这篇文章解决的是“客服如何把工单翻译成产品能判断的反馈卡”。它关注的是一张要交给产品的问题卡，核心字段是用户场景、影响范围、证据、复现方式和优先级建议。它不追求搭建完整归因体系，也不追求统计所有工单类别。

它不同于“工单归因分类表”。归因分类表关心一批工单应该落到哪些一级原因、二级原因和责任团队，适合周报复盘和长期治理。产品反馈卡关心的是某一个具体问题能不能被产品接住，适合进入缺陷排查、需求评估或版本讨论。

它也不同于“工单标签质检”。标签质检关注客服有没有把现有标签打对，产物是错标类型、正确标签和培训建议。本文的产物不是检查标签，而是把已收集到的客服材料转写成产品判断材料。即使标签完全正确，产品仍然可能需要一张反馈卡来判断是否排期。

它还不同于产品需求文档。客服接口人不需要替产品设计最终方案，也不应该越过产品流程承诺上线时间。你要提供的是清楚、克制、可验证的问题输入：这个问题发生在谁身上，怎样发生，影响多大，有什么证据，现在怎么兜底，还缺什么判断。把这一步做好，产品才有条件做后面的取舍。