10 · 运营与持续使用 · 发给谁
供应商离职了，券还发到他的微信
用户运营管的是发给谁。身份规则跟解决方案架构师，不另存永久 Excel。满减和券谁先算，不归他。
按群发：微信群里所有人都收到同一张券。离职的、别的供应商、总部的人混在一起。
按有效身份发：只发给仍绑定且未停用的供应商账号。解绑当天从名单消失。
用户运营对「发给谁」负责
账号、门店、供应商、会员不是一份可以随时导出的名单。用户运营的特点是名单和身份生命周期绑在一起。离职、解绑、停用必须在下一次触达前生效。他和解决方案架构师定的身份规则一致，不在表格里另存一份永久名单。永久名单会在第二天过期，而且没人知道。
触达要有目的和退出。订货提醒发给店长，不发给所有看过系统的人。供应商的对账通知发给当前绑定的人。发送记录能查到谁收到了、谁因为停用被排除。排除原因要能解释，否则业务会以为系统漏发。
券和消息不是越广越好
发错人的成本在企业场景里是串货、串价和投诉。用户运营要求活动方给出筛选条件：哪些门店、什么状态的会员、是否排除已停用。条件写进活动单，不能只说「老客」。老客没有定义，就会变成全库。他拒绝使用从系统导出后再人工转发的名单，因为转发切断了停用。
离职后仍收到券
一位供应商业务员离职，微信仍在群里，有人按群发了结算券。对方截图问价格。用户运营改为只从绑定关系取人，解绑由采购在系统里完成，发券任务读取当天的绑定。群仅作口头提醒，不作为发送名单。补救是使那张误发的券失效，并记录失效原因。之后每次发送前有一步预览人数，人数和绑定人数不一致就不能发。
预览人数是这个岗位的闸门，不是额外报表。用户运营每次发送后抽查三个应该收到的人和一个不应该收到的人。应该收到却没有，检查绑定；不应该收到却收到了，立刻停任务并失效内容。只看发送成功的总数，发现不了发错人。发错人在企业名单里比少发更难收回。供应商更换联系人时，旧联系人从发送池消失的时间要写在规则里。当天消失和月底同步，差别是整整一个月的价格外泄。这个差别不能靠大家自觉退群解决。发送名单生成后，他把条件留在任务里，而不是只留最终人数。人数无法复盘，条件可以。下次有人说漏发，他能重放条件看到当时为何排除。条件里出现手工加人，他会要求写原因和期限。
手工加人一旦没有期限，就会变成永久特权，绕过身份停用。他把发错人的处理写成固定动作：停任务、失效内容、通知范围、补发正确对象。四步少一步，群里只会看到道歉。道歉不能让已收到的价格消失，失效和范围说明才可以。他把名单条件交给活动运营复用，不让人手再筛一次。复用同一条件，发券和发通知才不会一个排除停用、一个漏掉停用。两边条件不同，错误一定出现在更热闹的那场活动。名单条件里不允许写「微信群里的人」。群只作口头提醒。