用户反馈怎么收集、需求怎么排优先级？投票与路线图执行清单
用户反馈收集可以先做三步：给用户一个统一入口，把同类需求集中到一条建议上投票，再把团队确定要做的事项放到公开路线图。排优先级时同时看用户受阻程度、证据和实现成本，不能把“票最多”直接当成“下个版本必须做”。
UserFB 的需求投票与路线图可以承接这三步：免费版包含反馈板和投票，公开路线图与上线通知需要 Pro。本文由 UserFB 同团队运营的不墨博客整理，下面的流程是操作建议，示例不代表真实客户结果。
第一步：只设一个主反馈入口
先把官网帮助区、产品菜单和客服回复都指向同一个反馈板。用户不需要先理解你的部门分工，只要知道在哪里提出问题、在哪里看回复。
提交说明保留三个问题就够了：
- 你原本想完成什么？
- 卡在哪一步，发生了什么？
- 当前怎么绕过，影响了什么？
截图不是必填；需要截图时提醒遮住邮箱、订单和其他个人资料。涉及账号、付款或隐私的问题应走私下支持渠道，不能为了积累票数要求用户公开。
UserFB 的独立链接与 iframe 接法
注册后在控制台创建产品，复制这个产品的公开反馈板链接。只想尽快收集反馈，直接把链接放进“意见反馈”菜单即可。
要把反馈板放进已有网页，可以用 iframe 加载自己的公开反馈板。以下示例里的 YOUR_PRODUCT_ID 是占位符，必须替换为产品实际 ID；它不是访问令牌：
<iframe
src="https://userfb.app/products/YOUR_PRODUCT_ID"
title="产品意见反馈"
width="100%"
height="700"
loading="lazy"
style="border: 0; border-radius: 12px;"
></iframe>
这是嵌入整个公开反馈板的方式。不要在地址后自行拼接 /widget：旧式 /products/产品ID/widget 路径本次核验返回 404。若要右下角悬浮聊天入口，应使用后台“组件集成”生成的脚本，它与本例的整页反馈板是两种入口。
接好后，在自己的页面分别检查桌面、手机和未登录状态：内容是否可见、滚动是否正常、登录后能否提交和投票。父站若配置了 CSP，需要允许 iframe 加载 UserFB；某些浏览器的嵌入登录限制也可能影响流程。建议旁边保留一个“在新窗口打开反馈板”的链接，遇到问题时用户仍能继续。本文核验了公开页面和路径，没有替你的网站完成嵌入后的登录验收。
第二步：先集中问题，再邀请投票
先搜索同类反馈。UserFB 会在输入新建议时提示相似建议，用户可以对已有建议投票，避免同一问题散成多条；这不意味着系统会自动把全部旧反馈正确合并。
管理员每次看新反馈时，完成下面四项即可：
- 写清楚用户要完成的任务，少用只有开发知道的模块名。
- 同一问题保留主要讨论入口；不同场景即使关键词相似，也别草率并成一条。
- 记录影响对象、频率和现有绕行方法。
- 回答当前状态，以及何时会再次评估。
UserFB 浏览反馈板不要求先登录，投票需要登录，每人对同一建议计一票。票数反映参与投票的人，不代表全部用户，也不能证明每个账号背后都是不同的自然人。
可直接复制的评审记录
需求：
目标用户 / 使用场景：
原始反馈链接：
受阻任务及发生频率：
影响证据（访谈、工单或可核实的数据）：
当前替代办法：
预计投入与依赖：
决定：补充信息 / 暂不做 / 纳入计划
负责人：
下次复查日期：
对用户的说明：
例如，假设“导出文件缺列”有 3 票，“更换主题色”有 20 票。若前者阻塞客户交付、后者仍有可接受的现有方案，应先核实导出问题的范围。这是演示如何判断的虚构例子，不是 UserFB 的客户数据，也不是一条普遍适用的票数阈值。
第三步：公开承诺范围，完成后回告
公开路线图只放团队已决定推进的事项。建议采用“计划中 / 进行中 / 已上线”三栏；还在调查、没有投入资源的反馈不要提前放进“进行中”。
按 UserFB 的官方操作说明，在支持该能力的套餐下：
- 在产品设置打开“对外公开路线图”。
- 对决定推进的待处理建议勾选“公开到路线图”，让它进入“计划中”。
- 开始工作时改为处理中，对应“进行中”。
- 真正发布并验证后标记已上线，补上上线说明；通知面向有可用邮箱的投票者和原提交者。
公开时至少写明“解决什么、包含什么、还有哪些边界”。除非团队确认能交付，否则不要给每条建议承诺具体日期。延期时更新原因和下一次检查时间，比让状态一直不动更有帮助。
更新日志可补充版本背景和使用入口；单条需求的上线说明则回答“你关心的这件事现在能怎么用”。两者可以互相配合，但没有经过实际发布验证，不能提前把反馈标成已上线。
每周十分钟检查什么
| 检查项 | 看到什么才算推进 |
|---|---|
| 新反馈 | 有负责人；信息不足的已明确追问 |
| 同类需求 | 用户能找到主讨论，票数没有无故分散 |
| 计划事项 | 有范围、依赖和下次复查时间 |
| 已上线事项 | 有实际使用入口，并检查通知是否到达 |
| 结果 | 原提交者是否成功完成任务，仍有哪些问题 |
“收到多少条反馈”衡量参与，“解决后用户能否完成任务”才更接近价值。不要把没有回复当成满意，也不要把邮件已发送当成用户一定看到了。
开始前可以在 UserFB 套餐页确认免费反馈额度与 Pro 的路线图权限。先让一个产品的入口和回复流程跑起来，再扩展到其他产品，能减少一次性整理大量历史反馈的负担。