登录账号和 Lark 身份之间没有任何绑定字段。它们靠名字字符串匹配连在一起:
| 实测 | |
|---|---|
| 登录账号 | 47 人 |
| 名字能解析到邮箱 | 47 / 47 —— 这个组织确实全通 |
notify=true | 只有 12 人 |
「47/47 通」不是设计对了,是运气好。靠的是 5 月手工整理的一份表,加上名字碰巧对得上
(还专门为此建了 recipient-aliases.json 处理 傅丰凯 ↔ 傅丰恺 这类)。
| 情形 | 后果 |
|---|---|
| 管理 tab 新邀请一个人 | 他不在 org-members.json 里 → 静默收不到任何消息。登录正常、页面正常,只是消息不来 —— 而没有任何地方会告诉他 |
| 别的组织(acme) | 根本没有 org-members.json → 一条 DM 都发不出去 |
| 有人改名 / 用了别的写法 | 掉出匹配 → 静默失联,要靠人再往 aliases 里补一条 |
| 5 月那份表会过期 | 它不是自动同步的。members_sync 同步的是 control.db → runs.db,不碰这份表 |
不会。身份绑定是「前提」,不是「原因」。它只是让消息送得到,不决定该发几条。
| 要让销售真的收到更多,需要 | 现状 | |
|---|---|---|
| ① | 身份绑定 —— 知道这个人的 Lark 是哪个 | 靠名字碰运气 |
| ② | 路由三档 —— 68% 无归属的客户,推给会议组织者 | 没做。量主要来自这条 |
| ③ | notify 放开 —— 现在 47 人只开了 12 个 | 白名单卡着 |
三件叠起来才有量,单做 ① 一条消息都不会多。
反过来说:没有 ①,②③ 做了也送不到 —— 所以它得先做,只是别指望它自己产生效果。
我们上周做的 user_mail_connections 就是「每人一行的外部账号」——
user_channels 是同一套东西,连 UI 位置都该在一起(用户设置弹窗里,邮箱旁边)。
| 选项 | ||
|---|---|---|
| 管理员代填 | 在邀请成员时填对方的 Lark 邮箱。会填错、会过期,而且错了没人知道 —— 就是现在这个模式的翻版 | ❌ |
| 自助绑定 + 送达确认 | 销售自己填工作邮箱 → 系统去 Lark 查 open_id → 发一条确认消息 → 他在 Lark 里点确认 → 绑定成立 | ✅ |
⭐ 关键是那句确认:「绑定」的定义是「消息真的送到了」,不是「填了个邮箱」。
这和邮箱连接是同一条原则 —— 「已连接」是一个动词的结果,不是一个存下来的形容词。
飞书日历那次停摆一个多月,就是因为状态是存下来的而不是当场问出来的。
| 序 | 做什么 | 为什么在这 |
|---|---|---|
| 1 | 身份绑定(user_channels + 自助绑定 + 送达确认) | 你指出的这条。②③ 的前提,不做它后面都送不到 |
| 2 | 路由三档 + 送达落库 | 量的真正来源。落库同期做,否则改完不知道有没有改对 |
| 3 | 统计 tab 加「送达」 | 把失败摆在领导已经会去的地方 |
| 4 | 拆两层 + Teams 骨架 | 结构清理。user_channels 天然就是投递层的数据基础,①做对了这步会顺很多 |
| 5 | 通知粒度 + 管理 UI | 放开 notify 前先有粒度,否则一放开就被静音 |
上一版 ① 是「路由三档」—— 你这一问把更底下的一层挖出来了,它得排前面。