简要回答
用户大会的反馈只有送到能采取行动的人手上才有用。先按类型分类，把每类转给指定负责人，决定哪些转为行动，并告诉提供意见的人结果如何。
这件事要在编写问卷之前就规划好，因为问题的设计决定了意见能否分流。活动负责人协调整个流程，产品和服务方面的决定仍由各自负责的团队作出。
收集意见之前先定好分流路径
| 反馈类型 | 例子 | 负责人 | 常见行动 |
|---|---|---|---|
| 产品需求 | 希望增加报表功能 | 产品负责人 | 记入产品待办清单并回复状态 |
| 产品缺陷或支持 | 描述反复出现的故障 | 支持团队或客户成功团队 | 与未结个案核对并联系客户 |
| 服务或客户账户 | 回应慢、联系人不清楚 | 客户成功负责人 | 由客户经理跟进 |
| 内容与议程 | 希望增加实操时间 | 活动负责人 | 用于下一届议程设计 |
| 场地与后勤 | 音响、座位、餐饮、指示牌 | 活动负责人或项目负责人 | 纳入供应商与场地复盘 |
| 行为或安全 | 描述严重事件 | 指定的行为事务联系人 | 在问卷流程之外处理 |
用便于分流的方式收集
把意见转化为行动
不要承诺超出负责人能做到的事
大会是客户关系中情绪较高的时刻。一句“会开发某功能”的回复，可能被客户引用多年。
回复发出前先统一措辞：已收到、已记录、审核中、已列入计划、不列入计划。涉及产品路线的任何说法，须由产品负责人批准。
与客户形成闭环
- 活动后尽快向所有参会者发出摘要，说明听到了什么、正在做什么。
- 对提出严重问题的客户逐一联系，并记录联系情况。
- 展示来自反馈的下一届议程调整，让大家看到自己的意见有用。
- 向管理层分别汇报决策者和使用者的情况，因为两者的结论常常不同。
实例演示 · 虚构示例
虚构的库存软件用户大会
机构与数字均为虚构，仅作说明。
虚构的库存软件公司 Stok Mudah 在400名代表的大会后收到190份问卷。意见里混杂着产品需求、对支持服务的不满，以及对午餐排队的抱怨。
活动负责人为每条意见标注类型和负责人，发现约三分之一的使用者提到报表功能的缺口，而决策者提到的是响应时间。产品团队同意审核报表需求并在约定日期前回复状态，支持团队跟进具名个案，午餐问题则交给场地复盘。发给参会者的摘要邮件说明哪些正在审核，没有承诺任何日期。
可直接使用
反馈行动登记表
复制此表，每个主题加一行。在大会后的固定日期与各负责人一起审阅。
| 主题 | 类型 | 提出者（人数、群体） | 负责人 | 决定与理由 | 回复措辞与日期 | 状态 |
|---|---|---|---|---|---|---|
| 简短描述 | 产品、服务、议程、场地或行为 | 人数及决策者或使用者 | 姓名 | 采取行动、审核、暂缓或不采取行动，附理由 | 已收到、已记录、审核中、已列入计划或不列入计划 | 未结或已结 |
自己处理，还是寻求外部协助？
以下情况，团队通常可以自行处理
- 听众不多，每条意见都能读完。
- 产品和客户成功团队已有处理反馈的惯例。
- 一个人就能协调登记表和回复。
以下情况，外部策划协助更有价值
- 反馈要分给产品、支持、活动和管理层，各自的时间表不同。
- 决策者与使用者意见不一，报告需要把两者分开呈现。
- 对客户的回复需要跨团队协调，措辞才能一致。
需要把反馈变成有人负责的行动清单？
会议项目负责人可以在问卷之前定好分流表，与您的团队一起把意见归类为主题，管理行动登记表，并准备供负责人批准的回复措辞。产品和服务方面的决定仍由您的团队负责。
主办方常见问题
客户应该多久收到回复？
在问卷开放前先在内部约定日期，并告知受访者。常见做法是活动后尽快发出简短摘要，之后再逐一回复。
反馈应该匿名吗？
这取决于您是否想回复。先决定，在表格上说明，并照此执行。匿名回答无法逐一跟进。
决策者和使用者意见不一致怎么办？
分开报告。这种分歧往往是最有价值的发现。
谁决定产品团队开发什么？
由产品团队决定。活动团队提供整理好的依据，并保持登记表更新。
相关资源
内容记录: 草稿。根据所引用资料撰写，并经自动规则检查；尚未经过独立审阅。