用途：把来自应用内组件、NPS 问卷、支持工单、用户访谈、功能投票和流失访谈等多渠道的反馈汇总，识别模式并用于产品决策。核心原则是：不打算处理的反馈就不要收集，否则会损害信任。
主要能力：按类型（Bug、功能请求、增强、可用性、性能）、严重程度（Critical/High/Medium/Low）、出现频率（50+、10-50、5-10、<5）和用户分层（重度用户、新用户、流失用户、企业客户）对反馈分类；用优先级公式 Score = Impact(1-5) × Frequency(1-5) × Strategic Alignment(1-5) 打分，≥40 为高优先级、20-39 为中、<20 为低。还给出 NPS 计算方式（%推荐者 - %贬损者）及参考基准（≥50 优秀、30-49 良好、<30 待改进）。
使用方式：按日、周、月、季度节奏执行——每日查看工单与应用内反馈，每周归纳主题并同步产品团队，每月发 NPS 并更新公开路线图，每季度做 5-10 次用户访谈和流失调研。闭环流程包括确认收到、采取行动、通知提出者、发布公开更新日志，资料中提供了相应邮件模板。
适用场景：产品团队整理反馈、排定路线图优先级、分析流失原因。
限制：资料未提供具体软件的价格、平台或效果数据；工具清单（Canny、ProductBoard、Dovetail 等）仅为列举，未说明集成方式。需注意避免只服务声音大的少数用户、盲目实现所有请求导致功能臃肿，以及忽视沉默流失用户。