汇总用户反馈，同时保留原始请求

反馈分散在客服工单、团队频道和问题单中。同一个问题会有不同说法，一条消息可能包含多个请求，而长对话也可能看起来像许多条独立投诉。

选择智能体应读取的客服收件箱、频道或项目，然后指定日期范围和筛选条件。分组前，先让它保存检索到的消息 ID、来源链接和检索时间。这样，即使有新回复出现，审查所依据的输入也保持固定。

Read last month’s conversations in the connected support inbox about booking times.
Follow the replies in each matching thread. Save the source IDs and links.
Propose groups, distinguish feature requests from reported bugs, and count distinct accounts where IDs are available.
Compare the groups with issues in the connected project tracker.
Show likely existing matches and draft new issues for review. Do not send customer replies.

搜索结果只是起点。阅读上下文对话，可能会发现报告中的错误已经解决、客户更改了请求，或者两条看似无关的报告其实涉及同一事件。将相关摘录保留在工作文件中，不要复制审查用不到的联系信息。

三条消息，两个不同问题

以下是调度产品中虚构的示例：

时区分组中有三条来源消息。邮件问题只有一条。两个分组共提到四次问题，但消息只有三条，因为 F02 包含两个问题。如果报告使用“请求”一词，应明确说明它指的是消息数、提及次数，还是不同账户数。

每条分类旁边都保留一段简短摘录。“预约页面只显示办公室所在时区的时间”可能是在说标签令人困惑，也可能是缺少时间转换功能。将这种歧义放入审查栏，而不要悄悄选定一种解释。

除了消息数，还要统计受影响的客户数

假设 F01 和 F02 来自同一个账户，而 F03 来自另一个账户。时区分组仍包含三条消息，但只涉及两个已知账户。如果检索到的记录没有账户 ID，账户数量就无法确定。措辞相似，并不能证明两条消息来自同一个人。

一组客服工单能告诉你人们因为什么问题联系了客服团队，却不能说明所有客户中有多大比例遇到了这个问题。即便是“本次审查中的十个账户里有两个”，也只描述了所选对话。将收集时段、筛选条件和渠道标注在数量旁边，让读者知道这些数字涵盖的范围。

你可以让 Beeuni 对比不同时期的主题，但要确保比较依据一致。如果上个月的数据只包含客服工单，而本月还加入了产品内调查，数量增加可能是因为新增了数据来源。保留渠道标签，这样在对趋势下结论前，你可以先比较客服渠道与客服渠道。

后续跟进可能会拆分一个看似明确的主题

继续使用这个虚构的调度产品示例。团队询问 F01 和 F03 的撰写者使用了哪个页面，以及他们预期看到什么时间。一位回复说，显示的时间是正确的，只是时区标签藏在需要滚动才能看到的位置。另一位则说，访客选择其他时区后，预约时间仍停留在办公室所在时区的时间。这两条报告现在指向了不同的问题。

保留“时区”作为更宽泛的主题，再将标签显示问题与可能的转换故障分开。把回复关联到原始来源 ID。第一个问题可能需要调整设计。第二个问题需要复现，以确定出错的是计算、保存的偏好设置，还是显示。即使分组名称改变，也不应遗漏任何一条报告。

F02 中的邮件问题需要单独跟进。询问预约是否已完成，以及用户期待收到哪封确认邮件。即使提及次数较少，缺少确认信息也可能让人无法找到预约详情。你可以先调查此事，同时让时区问题在频次表中继续排在首位。说明这样安排顺序的理由。

制作一份可以复核的报告

• 一份带注释的来源文件，其中包含分组标签和待审查标记。
• 一份分组摘要，其中列出消息数、可用时的不同账户数，以及示例来源 ID。
• 一份待解决事项清单，涵盖含义模糊的评论、相互矛盾的报告和可能的重复项。

区分用户请求的行为与报告的故障。“增加另一种导出格式”和“现有导出功能无法使用”可能属于同一领域，但需要不同的后续处理。如果一条消息同时包含两者，就保留这两个标签。

创建新问题单前，让智能体在已连接的问题跟踪工具中搜索涉及相同行为的问题。它可能适合添加到现有问题单中，并附上新的来源链接。审查这些匹配结果和建议的问题单文本，然后明确提出你希望进行哪些更新。将检索到的来源文件与注释后的报告一并保存，以便之后审查时区分新反馈与分组方式的变化。