例外
多条评价都指出同一缺陷时
合并成一条、关联到缺陷单，修复后对相关评价一次性上报回复候选。
Velros AI 接手的执行
从各个商店汇总新评价、评分骤降、缺陷提及、回复请求的信号，去重并排出优先级。
评价回复率
评分骤降察觉时长
缺陷提及关联率
在线独立创业者往往把 App Store、Google Play 的评价攒一堆才回头看，等评分掉了才找原因。评价、社交提及、崩溃报告、支持咨询各自堆着，指出缺陷的评价没跟缺陷单挂上，就一直搁着。公开的评分下滑，还会悄悄削掉新用户的进入。
这样的信号，会这样处理。
把真实进来的活儿归拢起来，连每一步依据什么判断，也一并留下来。
-
评价、提及统一汇集
把商店评价、社交提及、支持咨询汇到一条队列。
判断 把同样症状、同一版本的提及看作可合并的候选。为的是把散着的信号收成一条。 -
评分、情绪分类
把新评价按评分和内容（缺陷、抱怨、称赞、求回复）分开。
判断 以评分骤降、缺陷提及作为优先级的轴。骤降和缺陷始终排最上面。 -
回复初稿、缺陷关联
做好回复初稿，以及把提及缺陷的评价关联到缺陷跟踪工具的备注。
判断 把同样症状的评价合并、关联到缺陷单，修复后再上报回复候选。 -
骤降提醒准备
评分快速下滑时，连同原因候选一起上报提醒。
判断 骤降信号连同原因推测立即给人。是公开指标，拖延就是损失。 -
评价跟踪卡
做一张含评价、评分、状态、下一步动作的卡片，作为未结项跟踪。
判断 挂上结案条件（回复已发、缺陷修复已关联），让它不会从队列里消失。
不确定，就不公开回复。
现场真正会卡住的例外，我们提前定好。规则套不上的时候不硬办，连同依据一起交给人。
例外
与事实不符或恶意的评价时
不立即反驳，作为事实核对清单上报，交由人决定应对方式。
例外
要求补偿、退款的评价时
不在公开回复里承诺，分为单独案例，交由人审批处理。
公开回复和补偿，由人确定。
牵扯到钱、合同、个人信息和品牌的执行，只做到草稿为止；发送与敲定，要等人审批之后才动。
-
公开回复发布
是人人可见的对外发言，回退之前由人确认。
-
对外道歉、补偿承诺
是会产生成本与先例的判断，属于人。
-
批量通知、公告
一旦发出就收不回，措辞与对象由人过目。
-
恶意、虚假评价应对
是涉及关系与口碑的判断，由人确定。
-
缺陷严重度、紧急发布判断
涉及资源分配，由人决定。
用什么来确认
看多快察觉、多快回复。
评价回复率
在导入前后实测需要回复的评价中实际回复的比例。
评分骤降察觉时长
在导入前后测量评分开始下滑到察觉所用的时长。
缺陷提及关联率
在导入前后测量指出缺陷的评价被关联到缺陷单的比例。
规则
评价与支持咨询里可能含用户信息，因此仅在必要范围内保存，整理成公开回复中不显露个人信息的形态。
需要人亲自扛着的事变少了。
散落的核对和重复的回复先整理好递上来，员工就能把时间花在复核和例外上，人只看真正要紧的决定。
运营诊断待确认的事都堆到人身上。
评价攒到一起才回头去看，评分掉下来之后才去找原因。
备好的活儿先递上来。
新评价和骤降信号汇进一个队列，连回复都备好，公开发布由人来确认。
评价回复率
评分骤降监测时间
缺陷提及关联率
把这件事托付出去之前，大家会问什么
关于应用商店与评价监测，大家实际上最先确认的那些问题。
公开回复是 Velros AI 直接发的吗？
只准备到回复初稿，实际公开发布由人确认后再执行。
提及缺陷的评价怎么处理？
把同样症状的评价合并、关联到缺陷跟踪工具里的缺陷，修复后再上报回复候选。
对恶意评价怎么应对？
不立即反驳，先把事实整理上报，应对方式由人确定。
