例外
顺序或邀请条件不确定时
不擅自邀请，标注需确认，交由人定顺序。
从各个渠道汇总候补报名、邀请顺位、内测反馈、上手提问的信号，去重并排出优先级。
在线独立创业者手里，候补申请只是在申请表里堆着，邀请没有顺序，凭记忆想到谁发谁。申请、邀请、内测反馈、引导问题散在表单、邮件、Discord、Slack 里，谁在何时被邀请、来了什么反馈都没留下。没人打理的候补名单只会吊高期待，却接不上真正的参与。
这样的信号，会这样处理。
把真实进来的活儿归拢起来，连每一步依据什么判断，也一并留下来。
-
申请、顺序汇集
把表单、邮件申请汇到一条队列，去重后排出顺序。
判断 用邮件、申请标识把同一个人归并。一个人报了多次，顺序也只算一个。 -
邀请对象分类
按顺序、条件（邀请码、优先分组）把邀请候选分开。
判断 按顺序和邀请条件来分。为的是凭标准而非凭记忆去邀请。 -
邀请、引导初稿
做好邀请引导、顺序说明、引导问题答复的初稿。
判断 只做与顺序、条件相符的引导初稿。发送与授权交给人。 -
内测反馈整理
把各渠道反馈汇起来，按功能、缺陷分类整理。
判断 渠道不同，但同样的反馈就合并，归入功能、缺陷。接到功能请求、缺陷分类的流程上。 -
参与跟踪卡
做一张含申请人、顺序、邀请状态、下一步动作的卡片，作为未结项跟踪。
判断 挂上结案条件（接受邀请、明确拒绝），让它不会在名单里被搁着。
顺序不确定，就先缓发邀请。
现场真正会卡住的例外，我们提前定好。规则套不上的时候不硬办，连同依据一起交给人。
例外
一个人报了多次或请求追加邀请时
把同一申请人归并，避免重复邀请，追加邀请交由人审批处理。
例外
内测反馈牵涉个人信息、账号访问时
不擅自作答，标注需要本人核实，上报给人。
邀请和访问权限，由人确定。
牵扯到钱、合同、个人信息和品牌的执行，只做到草稿为止；发送与敲定，要等人审批之后才动。
-
邀请发送
是开放访问的动作，对象与时点由人确认。
-
访问权限授予
是难以回退的访问判断，由人确定。
-
批量邀请、通知
一旦发出就收不回，措辞与对象由人过目。
-
内测条件、范围变更
会影响全体参与者，由人审批。
-
优先、特别邀请
关系上下文由人而非代码知悉。
用什么来确认
看邀请有没有接上参与。
邀请转化率
在导入前后实测收到邀请的申请人中真正参与的比例。
内测反馈回收率
在导入前后测量被邀请的参与者中留下反馈的比例。
引导问题响应时长
在导入前后测量从早期问题受理到答复的时长。
规则
申请与邀请过程中会处理邮件这类个人信息，因此须告知收集目的、仅在同意范围内使用，访问授权在人确认之后再处理。
需要人亲自扛着的事变少了。
散落的核对和重复的回复先整理好递上来，员工就能把时间花在复核和例外上，人只看真正要紧的决定。
运营诊断待确认的事都堆到人身上。
候补报名只在表单里越堆越多，邀请没有顺位、想起谁就发给谁。
备好的活儿先递上来。
报名和顺位汇进一个队列，连邀请说明都备好，发送由人来确认。
邀请转化率
beta 反馈回收率
上手提问响应时间
把这件事托付出去之前，大家会问什么
关于候补名单与内测运营，大家实际上最先确认的那些问题。
邀请是自动发出的吗？
只准备到顺序与邀请引导初稿，实际邀请发送与授权由人确认后再执行。
内测反馈汇到哪里？
把各渠道反馈汇到一条队列，按功能、缺陷分类，接到功能请求、缺陷分类的流程上。
顺序是怎么定的？
按申请时点和邀请条件排出顺序候选，实际邀请顺序由人确定。
