starter.wiki搜索⌘KEN

决策地图

消息与通知：把送达、触发和对话分开处理

邮件、通知与实时沟通有不同的可靠性、合规和产品边界。

Recommendation

事务邮件从专用 API 开始，营销和产品内通知在用户规模与分群需求明确后再扩展。

先判断这是事务通知、营销沟通还是实时协作；不同目标不应共用一条发送策略。

打开起始决策

范围

用这条边界避免在错误层级解决相邻问题。

包含

  • Application-triggered and broadcast email delivery
  • SMS and browser or device push delivery
  • In-product notification inboxes and embedded text or realtime media interactions
  • Customer-support ticket and service workflows
  • Producer-side outbound webhook delivery

不包含

  • Cross-channel lifecycle journey orchestration, which belongs to Product
  • Internal queue transport and background execution, which belong to Infrastructure
  • Complete meeting products that are not embeddable communication infrastructure
  • Incident status communication
16

重要工具

这些工具代表此决策领域内不同路线；请先打开相关任务页面，再将任何工具视作默认。

决策顺序

先完成基础归属判断，再增加专门能力。

  1. What initiates the communication and who receives it?

    Separate application-triggered delivery from campaign sends, then identify recipient, consent, sender, and unsubscribe or opt-out requirements.

    Transactional Email Email Marketing Programmable SMS

  2. Does the message leave the product or live in the product interface?

    Push reaches a user agent through a push service, while an in-app notification owns rendered product UI and user state.

    Push Notifications In-App Notifications

  3. Is the interaction an alert, a product conversation, a support case, or realtime media?

    Choose the record and protocol that match the participants, response model, agent workflow, and media requirements.

    In-App Notifications Embedded Product Chat Customer Support Platforms Embedded Realtime Audio & Video

  4. Is the recipient another software system?

    Use the Webhooks decision for producer-side event subscriptions and external HTTP delivery, not for internal work execution.

    Outbound Webhook Delivery

23

决策分组

每个任务都对应一个独立的用户决策，而非产品功能标签。

45

常见混淆

这些边界避免相邻任务被压缩成一个泛泛的候选清单。

Transactional Email and Marketing Email are treated as one generic email-delivery decision.
Product-triggered one-to-one email and audience broadcasts have different intent, infrastructure, and unsubscribe operations.
Push Notifications and In-App Notifications are treated as the same surface.
Push is delivered through a user-agent push service; an in-app notification is rendered and stateful inside the product.
Embedded Product Chat is treated as a synonym for customer support.
Embedded Product Chat is a product feature built around conversation channels; Customer Support is built around agent-managed cases and service workflow.
Webhooks, queues, and background jobs are treated as interchangeable asynchronous infrastructure.
Webhooks deliver subscribed events to external endpoints; queues transport internal messages and background jobs execute work.
1456

暂缓引入

不要在产品真正需要之前引入专门系统。

The product sends only application-triggered email and has no audience or campaign program.

Campaign segmentation, consent, deliverability, and automation operations are not yet active.

The product does not require a persistent inbox, embedded conversation, or realtime media.

These Tasks add product UI, state, moderation, participant, or media operations that channel delivery alone does not require.

37

Starter Stack

查看这些决策如何出现在完整应用起始方案中。

官方资源

支撑此分类边界的标准与一手文档。

StandardW3C Push API
StandardW3C WebRTC
Official documentationGitHub: About webhooks

来源

此决策地图使用的主张级参考资料。

  1. 1
    Message Streams API

    Postmark · Accessed Official

  2. 2
    Push API

    W3C · Accessed Official

  3. 3
    Introduction to Inbox

    Novu · Accessed Official

  4. 4
    Chat channels

    Stream · Accessed Official

  5. 5
    Tickets API

    Zendesk · Accessed Official

  6. 6
    About webhooks

    GitHub · Accessed Official

  7. 7
    WebRTC: Real-Time Communication in Browsers

    W3C · Accessed Official