作为产品方与用户之间沟通的桥梁，平台用户反馈系统的良好搭建至关重要。
用户反馈旨在能将用户的想法传递给产品方并进行处理后满足用户需求或功能迭代，也可通过反馈的数据分析进行产品迭代优先级排序。
产品部分功能体验差（BUG、功能不足……）：暴躁的用户、难受又不忍离去的用户——及时处理，挽留用户；
产生功能需求（如：突发奇想；真实需求；看到别的产品有该功能，但又被沉没时间成本束缚……）：资深用户、付费用户——沟通反馈，KOL挖掘；
需要平台方帮助（引导、投诉）：产品萌新、领域小白、受气的宝宝……——平易近人，增加融入感，一副大哥罩着你的样子。
反馈前，用户找到反馈入口，准备提交反馈或直接由FAQ终止反馈；
反馈中，用户提交反馈内容，包含故障时间、问题所在、图片上传、联系方式等；
反馈后，产品方进行处理并对用户反馈进行终结，还可以以此作为建立社群的一个流量入口。
反馈方：
轻松找到反馈通道；
反馈过程通畅无阻；
反馈后能问题可被快速解决。
关键痛点：各平台反馈入口深度参差不齐；反馈流程周期长；问题泥牛入海。
被反馈方：
收集用户需求；
处理流程高效简单；
可以获得产品迭代思路。
关键痛点：问题筛选过程复杂、处理流程滞后。
从反馈前中后三个步骤展开分析现阶段的用户反馈系统都涉及哪些功能，需要达到什么效果。
1. 反馈前
在用户进行反馈前，排除产品结构需求，要尽可能降低反馈入口深度。如果实在无法实现降低深度也可以将入口位置尽可能的符合用户使用经验，比如：反馈放在【我的】-【帮助】下面。
除此之外，在用户反馈前可通过FAQ的形式进行“反馈过滤”，节省人工成本。
2. 反馈中
除了接通人工客服外，反馈主要以填写表单的形式进行，一般都具备以下功能：
文字填写：最基础的反馈方式；
图片上传：截图或拍照的形式更方便用户表达，产品方也能更快的解析问题所在；
联系方式：手机号、邮箱的留存方便客服人员进行问题跟进及回访。
除了以上基础功能外，还有一些方式可以帮助用户更清楚地表达，如：
支持语音输入；
故障时间选择，微信中的反馈系统具备此功能，可以帮后台进行问题定位，也可以分析出问题时间段。
3. 反馈后
反馈后系统提醒是有必要的，给用户时间预期可要比客服联系后说“久等了”效果更好。除此之外，也可以放社群链接或问卷调研，当然这里要注意问卷调研中要考虑用户的负面情绪。
三、产品方处理流程
用户反馈后通常需求会经过信息收集——需求过滤——分类后分别对接客服、产品、测试（——评审/开发）——回复用户——闭环反馈这几个步骤结束整个反馈流程。
产品方处理流程可用下图进行表示：
管理员作为与用户接触的唯一出口，判断需求后分别进行反馈，待确认解决后进行用户回复，当用户有反复疑问时，就可能会出现反馈不及时的现象。
在一些To B产品的反馈流程客服作为一个对接角色将需求反馈后直接由技术人员对接，这样可以大大提高效率。
四、简单问题复杂化
上文提到的反馈功能可以满足基本的用户反馈处理流程，客服的人工筛选时间及对接时间是否可以等到进一步优化，我觉得可以“简单问题复杂化”，也可以说繁琐问题功能化，从功能优化上进行效率提升。
功能前提：
反馈前用户需进行问题分类选择操作，可采用多级分类，但一级分类必选，且分类表述需要明确、清晰。如：BUG、引导、功能建议、投诉等；
产品方管理员在后台可对需求反馈类别进行选择，类似于权限设置，如：管理员A（测试）只选择接受BUG反馈；
可设置反馈消息推送，实时反馈，当然为了避免非客服人员受用户频繁反馈打扰，提供推送时间段、频次选择。如：产品经理可接受功能建议，设置为每周一次反馈；
反馈可在管理员中互相推送。考虑到用户对问题的判断力不足，当一级分类选择错误推送至错误的管理员处时，管理员可将问题推送至相关人员处。
对于反馈量少的产品没这个必要，毕竟还是存在一定开发成本的，但对于大反馈量，可在需求筛选和人员安排方面有效解决问题。
小结
文中基本囊括了现在一般的反馈产品功能，也提出了对于反馈处理过程上的功能建议。自主开发用户反馈系统可以很小也可以很大，还是要看真正的需求是什么，现在也有几款用户反馈第三方平台，腾讯吐个槽接入简单、功能齐全，还是比较期待的。
