当 SaaS 用户很少时，要确定客户反馈的优先级，先按消息背后的问题分组，统计独立客户账户，再选定下一步：修复、开发、追问或暂缓。把证据和决定放在一起。小样本可以暴露真实缺陷或受阻的工作流程，却不能说明该问题在整个市场中有多普遍。
先明确要做的决定，再整理请求
先设定一个具体目标，例如帮助小型代理机构完成首次客户交付。这样，才能比较交付受阻与新增报表看板的请求。写下目标客户、当前工作流程，以及下次复盘前能够投入的时间。
保留客户的原话、来源、日期和账户 ID。区分客户报告的情况与自己复现的问题。同一账户的三封邮件是三条消息，不是三个独立客户。同一公司的两个人可以补充有用信息，但不会增加客户账户数。
- 用户描述的是现有承诺未兑现、某个步骤不清楚，还是缺少新功能？
- 他们原本想完成什么，实际发生了什么？
- 这个账户是否符合你选择服务的客户类型和工作流程？
- 什么观察结果会改变你的决定？
示例：四个账户的八条请求
本例中的产品、账户、消息、检查和决定全部虚构。这是教学案例，不是客户成果，也不是 Soloop 任务的产出。产品帮助小型代理机构发送客户交付内容并记录验收。本周的目标是让现有流程可用；可投入的资源只够做一项小型工程改动和几次追问。
账户 A 和 B 是已在使用交付流程的小型代理机构。C 是首次尝试交付的新代理机构。D 是正在评估产品的大型咨询公司，其采购需求不属于当前目标客户范围。在这个假设的一周内，陆续收到请求 R1–R8。
| 维度 | 请求与来源 | 评审时已有的证据 |
|---|---|---|
| R1 · 账户 A | 周一邮件：能加一个 ERP 连接器吗？我们需要在月报中列出验收日期。 | 客户报告了需求，尚不清楚报表的制作流程。 |
| R2 · 账户 A | 周二聊天：那个连接器有进展吗？ | 这是对 R1 的追问，不是另一个账户，也不是新问题。 |
| R3 · 账户 A | 周三邮件：我们的记账员也想要这个连接器。 | 来自 A 的另一位人员；仍需澄清工作流程。 |
| R4 · 账户 A | 支持记录：我们最新导出的文件缺少验收日期。 | 创始人复现了问题：已验收交付的导出文件中，日期为空。 |
| R5 · 账户 B | 支持记录：我们导出的验收日期也是空白。 | 脱敏的导出文件显示同样症状，但尚未确认根因相同。 |
| R6 · 账户 C | 设置通话：能做一个客户审批页面吗？我找不到从哪里发送。 | 在这次虚构的观察中，C 没有找到已有的“发送以供验收”操作。 |
| R7 · 账户 B | 访谈记录：能把交付内容保存为可重复使用的模板吗？ | B 表示每周都要重新创建类似的交付内容；尚未观察实际频率与工作量。 |
| R8 · 账户 D | 评估邮件：在全公司推广前，我们必须支持单点登录（SSO）。 | 一个非目标客户账户报告了采购要求，尚未做出交付承诺。 |
按问题分组，再核查哪些信息会改变判断
R1、R2 和 R3 是同一账户提出的连接器请求。R4 和 R5 涉及两个账户现有导出功能的可靠性。它们可能有关，但不要仅因都提到报表就合并。先问 A：文件导出后还要经过哪些步骤？
在这次虚构的追问中，A 表示记账员每月导入 CSV，只要验收日期列完整，就足以制作当前报表。这削弱了开发 ERP 连接器的理由，却不能证明其他客户都不需要连接器。导出缺陷仍值得调查，因为它破坏了已经承诺的输出。
在 C 的虚构设置通话中，指出已有操作后，C 成功发送了交付内容。这支持测试更清楚的标签或位置，但不能证明新用户无需帮助就能找到它。对于 B 的模板请求，仍需请对方演示最近一次重复交付，之后才能考虑承诺开发。
做出修复、开发、追问或暂缓的决定
修复，是恢复现有承诺；开发，是理解底层需求后补上缺失的功能；追问，是获取做决定所需的证据；暂缓，是记录当前不适合做的原因及重新考虑的条件。无需强行填满每一类：本周的证据不支持开发任何新功能。
没有依据时，不要给出精确的收入或影响评分。把可能的影响记为假设，把工作量记为估算。可复现的错误输出可以优先于反复提到的请求，同时也不能假装四个账户代表整个市场。
| 维度 | 决定与理由 | 负责人、检查与重新考虑的条件 |
|---|---|---|
| R4 + R5 · 修复 | 先调查验收日期缺失的问题。它影响已有承诺，并出现在两个账户中；是否同源尚未证实。 | 创始人界定导出修复的范围。检查已验收和待验收的交付，再请 A 和 B 验证各自的导出文件。若原因不同，则拆分任务。 |
| R1 + R2 + R3 · 暂缓 | 暂缓连接器。A 在追问中表示，完整的 CSV 能满足当前报表工作。三条消息仍是一个账户的请求。 | 创始人记录替代方案，并向 A 解释决定。如果修正后的导出仍无法支持预期流程，再重新考虑。 |
| R6 · 追问 | 在新建页面前，先测试新用户能否找到现有发送操作。有人帮助后完成，不等于能够自行发现。 | 创始人在获得许可后，观察下一家符合条件的新代理机构使用当前页面。之后再界定文案或位置调整的范围，并重新测试。 |
| R7 · 追问 | 请 B 演示最近一次重复交付。模板可能有帮助，但重复字段与实际耗时仍不清楚。 | 创始人请求脱敏的操作演示。只有观察到重复步骤，且现有流程无法妥善处理时，才考虑小规模开发。 |
| R8 · 暂缓 | SSO 超出当前目标客户范围和本周能力。不要为了让评估继续而承诺交付日期。 | 创始人告知 D 当前限制。若目标客户范围改变，或合适的潜在客户表明该要求阻碍了原本可行的采用，再重新考虑。 |
复制客户反馈决策工作表
每个底层问题建立一条记录，并关联所有来源消息。保留原始笔记，以便撤销错误分组。完成约定的检查后，重新审视记录，即使结论是无需开发任何东西。
| 维度 | 你的记录 | 虚构的导出示例 |
|---|---|---|
| 目标与客户 | [当前目标／目标客户群] | 为小型代理机构提供可靠的客户交付流程。 |
| 来源与计数 | [消息 ID／日期／独立账户 ID] | 示例周内的 R4 和 R5；A、B 两个账户。 |
| 底层问题 | [要完成的工作／障碍／当前替代方案] | 汇报已验收的交付，但导出日期为空。 |
| 证据与未知项 | [客户报告／已复现／缺失的证据] | 已复现 A 的故障，已检查 B 的导出文件，是否同源未知。 |
| 选择与边界 | [修复、开发、追问或暂缓／排除的工作] | 调查并界定导出修复范围；不做 ERP 连接器或新报表套件。 |
| 负责人与下次评审 | [负责人／约定日期或触发事件] | 创始人；复现并估算工作量后、承诺改动前评审。 |
| 验收与改变决定的条件 | [如何检查／什么会改变选择] | 已验收交付的日期正确，待验收交付的信息也保持准确。若 B 的原因不同，则拆分任务。 |
| 后续跟进 | [需要通知谁／声称已发布前所需的证据] | 验证发布成功后通知 A 和 B，并请他们检查导出的结果。 |
做好后续沟通，不轻易承诺路线图
用客户工作中的语言解释决定。对 A 可以说：我们发现导出文件缺少验收日期，正在优先调查。你说完整的 CSV 足以支持本月报表，因此我们暂未安排 ERP 连接器。如果这个前提不对，请告诉我们。
区分调查中、已计划、已检查和已发布。发布后，告诉受影响的客户改了什么、如何验证。代码检查通过，并不能证明客户的流程已经成功。暂缓请求时，把重新考虑的条件与原始来源一起保留，不要悄悄删除。
把一个决定带入 Soloop
你可以自行完成工作表，也可以把少量已获授权并脱敏的笔记连同产品背景带入 Soloop。请它保留来源引用、按问题归类请求、列出未知项，并提出一个下一步建议。行动前，将它的理解与原始笔记核对。
起始任务说明：我们的产品帮助[客户]完成[工作]。这里有来自[数量]个独立账户的[来源 ID]。请区分客户报告的需求与已复现的故障，将重复消息归到对应账户，为每个问题建议修复、开发、追问或暂缓。不要编造频率、收入影响或工作量。请提出一个下一步任务，并列出验收检查和未解决的问题。
如果下一项任务涉及代码改动，请提供受支持的项目或代码仓库背景，并审查范围、权限和费用。仅提供笔记，并不等于授予修改产品的权限。本指南不能证明 Soloop 可以原生接入每一种反馈工具，也不能证明存在从反馈自动到发布的流程。请遵循工作区中显示的控制与设置。
请自行复制任务说明和笔记；下方链接不会传输它们。有用的结果是你实际审阅过的决定，或亲自检查过的任务产出。是否改善产品采用、留存或收入，还需要另行观察。
来源与局限
来源核查于 2026 年 9 月 25 日。上述方法与虚构示例属于编辑撰写的教学材料。实践指南为问题提供参考；社区评论展示个人经历，不能证明整个市场的需求。本文没有测试客户成果或优先级管理工具。
FeaturAsk 讨论了问题归类、去重、战略契合度与行动选择。这是反馈软件供应商的指南，不是独立的效果证据。
阅读 FeaturAsk 的优先级指南一场独立创始人的讨论描述了分散的功能请求、手工记录，以及改动后通知用户的做法。个别评论只是轶事；部分参与者也在推广工具。
阅读创始人讨论Soloop 手册介绍了提供背景、任务规划、调研、沙盒中的代码工作及结果位置。文档记载的能力，不等于实际执行过本工作表流程。
查看当前 Soloop 手册