Plan a welcome email sequence for SaaS, stores, or newsletters, with example messages, timing, eligibility checks, and tests before sending.
A welcome sequence helps a new subscriber know what to do next. For a SaaS product, that may be creating a first project. For a shop, it may be understanding the product range. For a newsletter, it may be knowing what will arrive and how often.
Start with the promise made at signup. Every follow-up should help fulfill it. Timing and message count depend on the product and audience; the examples below are starting points to test. The welcome sequence is the first of the lifecycle flows in AI email automation.
| Starting point | Useful first message | Check |
|---|---|---|
| Account created | One setup action | Whether email verification should happen first |
| Email verified | Welcome and a direct product link | Avoid duplicating the verification email |
| Newsletter subscription | What to expect and one useful example | The recipient's consent and chosen topics |
| Store signup | Products, guidance, or the promised offer | The offer's real terms and expiration |
Brew can start flows from custom backend events or supported integrations such as Supabase and Clerk. Use the selected trigger's schema and actual ID.
| Starting timing | Job | Eligibility when due | |
|---|---|---|---|
| Welcome | After signup or verification | Help create the first project | New account |
| Setup help | Day 2 | Show one short example | Has not activated |
| Next step | After activation | Introduce the next useful action | Has activated |
| Trial reminder | Before the trial deadline | Explain what happens next | Still in trial and unpaid |
| Check-in | After a suitable interval | Offer help | Still eligible and permitted to receive it |
Write each email around one action. Use a real destination URL, a clear subject, and a reply address someone monitors. Avoid generic urgency and claims about results you have not measured.
For a newsletter, the first message can deliver the promised resource, name the expected cadence, and show a representative article. A later message can explain topic preferences or introduce the author. A newsletter does not need a SaaS-style activation funnel to justify a second email.
For a store, deliver the promised offer first, then provide useful buying guidance. State exclusions and expiration accurately. A purchase may make the remaining discount reminders irrelevant, so include purchase state in your eligibility checks.
Decide what should prevent each message: activation, purchase, an expired offer, account deletion, unsubscribe, or a changed plan. Then implement that rule in the system that actually reads current state.
In a Brew event-triggered flow, a condition on payload.activated reads the original event. A condition on contact.activated reads the current Brew contact field when the node executes, including after a Wait. Declare and sync the field, then put the condition before each reminder that depends on it. A contact update or later event does not automatically cancel an earlier run.
For eligibility that depends on unsynced account data or a particular purchase, schedule a check in your application. Read the authoritative record when the message is due, then fire a separate eligible-reminder event only if the rule still matches. See Build an Automation.
Describe the trigger, audience, desired action, and tone in Brew. You can also start with a public example in the flows gallery. Treat its timing as inspiration, not evidence that the same schedule will work for your audience.
Review the generated graph and every email. Confirm the links, sender, personalization fallbacks, and domain purpose. A verification message and a promotional onboarding message can have different requirements. The FTC guide explains the US primary-purpose test; Gmail's sender requirements cover sending requirements.
Test a signup, a repeated event, missing personalization, and an ineligible recipient. For contact conditions, update the synced field during the wait and confirm the reminder is skipped; test missing fields too. For application-scheduled reminders, activate or purchase before the check and confirm no reminder event is fired. Check unsubscribe handling and delivery outcomes too.
Publish only after the messages and eligibility checks are reviewed. Track the action the sequence is meant to help, such as a completed setup or a first order, alongside delivery and click data. Keep the messages that help people take that action and revise the rest.
For implementation examples, see building onboarding from Cursor and trial conversion from product events.
