通知渠道与规则
通知是一个业务事件——下单、支付失败、请假批准、库存不足——通过一个或多个渠道传递。所有模块通过同一个通知中心发送,因此一套规则决定了谁听到什么,以及在哪里听到。
可用渠道
| 渠道 | 需求 |
|---|---|
| 应用内(铃铛) | 无;始终可用。 |
| 电子邮件 | 有效的邮件设置。先发送测试邮件。 |
| 实时广播 | WebSocket 服务器(Reverb)正在运行。 |
| 网页推送和移动推送(FCM) | 用户必须在浏览器或应用中授予权限。 |
| 短信 | 一个短信提供商和余额;按消息计费。 |
| Slack、Telegram、WhatsApp、Discord | 连接的聊天频道在 智能 → AI 渠道。 |
| Webhook | 另一个系统中的 HTTPS 端点。 |
如何决定一条消息?
- 通道是否已配置?未配置的通道会静默跳过——这不是错误。
- 是否 策略 允许此事件在此通道上发生? (通知 → 策略)
- 该人是否在其偏好中选择了退出?
- 通知是否 强制性?安全警报、支付失败和法律通知忽略选择退出。
交付日志 记录每条消息为何到达或未到达每个人。 自动化规则
自动化规则
良好实践
从狭窄开始。最常见的投诉是通知过多,而不是过少。
- 连接后测试每个通道。
- 将团队警报发送到聊天通道,将客户消息通过电子邮件发送;不要混合它们。
- 电子邮件、应用内、推送、短信、Slack、Telegram、WhatsApp、Discord 和 Webhook,由一个策略决定。
最后更新:11/7/2026

