例外
同一缺陷在多个渠道被重复上报时
合并成一条，并保留全部原文链接，让多少人遇到看得见。
从各个渠道汇总功能请求、缺陷、抱怨、重复的信号，去重并排出优先级。
对在线独立创业者来说，反馈从 Intercom、Discord、Slack、邮件、缺陷跟踪工具同时进来，同一个缺陷在多个渠道被重复上报，先修哪个每次都得重新翻一遍。紧急缺陷被功能请求淹没，或者反过来，没人回复就消失的反馈越积越多。散着的反馈，既难复现，也难判断优先级。
这样的请求，会这样处理。
把真实进来的活儿归拢起来，连每一步依据什么判断，也一并留下来。
-
反馈统一汇集
把多个渠道的功能请求、缺陷、抱怨汇到一条队列，并附上原文链接。
判断 渠道不同，但同样的症状、请求就看作可合并的候选。为的是把重复收成一条。 -
类型分类
打上功能请求、缺陷、易用性抱怨的标签，并标注可复现性。
判断 先把缺陷和请求分开。因为处理路径和紧急度不同。 -
重复合并、复现备注
把同一件事合并，做好复现步骤备注与请求整理初稿。
判断 把同样的功能、症状合并成一条，但保留原文链接，让谁在何时提过可追溯。 -
优先级候选整理
按频次、影响信号附上排序候选，上报给人。
判断 排序只做到候选。实际优先级确定交给人。 -
反馈跟踪卡
做一张含反馈、类型、状态、下一步动作的卡片，作为未结项跟踪。
判断 挂上结案条件（修复、采纳、明确搁置），让它不会没人回复就消失。
拿不准，就不断定优先级。
现场真正会卡住的例外，我们提前定好。规则套不上的时候不硬办，连同依据一起交给人。
例外
功能请求与缺陷混在一条消息里时
把缺陷开为主案例，把功能请求分为单独案例，两个都保持存活。
例外
分类模糊时
不硬确定标签，留作需人确认，但一旦复现就立即作为缺陷上报。
路线图和优先级，由人来定。
牵扯到钱、合同、个人信息和品牌的执行，只做到草稿为止；发送与敲定，要等人审批之后才动。
-
公开路线图采纳
会成为对外承诺，难以收回，由人确定。
-
发给反馈者的对外答复
是带品牌口吻的措辞，由人审批后再发送。
-
优先级确定
先修哪个，由人而非代码来定。
-
缺陷严重度、紧急应对判断
是涉及资源分配的判断，属于人。
-
功能请求接受、拒绝的告知
会影响关系，由人确认。
用什么来确认
看分类和合并有多快。
请求、缺陷分类时长
在导入前后实测从反馈受理到类型分类的时长。
重复反馈合并率
在导入前后测量被合并为同一件的反馈比例。
无回复反馈条数
在导入前后测量没人回复而留着的反馈条数。
规则
反馈里可能含用户姓名、联系方式、截图中的个人信息，因此仅在必要范围内保存，对外公开或登记缺陷时整理成不暴露个人信息的形态。
需要人亲自扛着的事变少了。
散落的核对和重复的回复先整理好递上来，员工就能把时间花在复核和例外上，人只看真正要紧的决定。
运营诊断待确认的事都堆到人身上。
反馈散在各个渠道里彼此重复，先修哪个还得人每次重新翻一遍。
备好的活儿先递上来。
反馈汇进一个队列，连分类和合并都备好，人只处理优先级判断和例外。
请求、缺陷分类时间
重复反馈合并率
未回应反馈条数
把这件事托付出去之前，大家会问什么
关于功能请求与缺陷分类，大家实际上最先确认的那些问题。
重复反馈怎么合并？
把同样功能、症状的反馈合并成一条，并保留原文链接，让谁在何时提过可追溯。
优先级是 Velros AI 定的吗？
只按频次、影响信号附上候选排序，实际优先级确定由人来做。
会直接答复反馈者吗？
只做到整理与答复初稿，对外答复的发送由人确认后再执行。
