Choose the first useful result before choosing the send times
An onboarding email should help someone finish a task they came to your product to do. Begin with an observable first result. For the fictional BriefBoard app used throughout this guide, that result is creating and sharing a project brief. Signing in is a step on the way; it does not establish that the person has received value.
List the points where a person may stop: an empty workspace, an unfinished brief, or uncertainty about the trial. Give the email the same language and destination as the product. A reminder that opens the dashboard and makes the customer find the missing step again adds work. Fix recurring product friction alongside the messages, using the onboarding content guide to explain the task in the interface.
Define triggers and stop conditions for three messages
The timing below is illustrative. A daily workflow and a monthly reporting tool need different windows. Use your own completion times and support conversations to choose a delay. Evaluate eligibility again immediately before handing a message to the sender; a customer may have upgraded or completed setup while the job waited in a queue.
For these optional onboarding messages, require the appropriate marketing permission and honor unsubscribe, complaint, and bounce suppression. Keep verification, password resets, receipts, and other necessary service messages in separately defined flows. Loops explicitly treats welcome and onboarding emails as marketing in its signup guide. Check the rules that apply to your audience and provider rather than treating account creation as blanket permission for promotions.
| Message | Candidate trigger | Skip or stop when |
|---|---|---|
| Welcome | Signup committed; contact is eligible | Account removed, permission absent, suppression active, or this welcome already sent |
| Unfinished setup | 24 hours after signup; first brief still not shared | First brief shared, account closed, permission withdrawn, suppression active, or reminder already sent |
| Trial approaching its end | 48 hours before the current recorded trial end | Already paid, trial cancelled/expired, reminder already sent for this trial, or contact ineligible |
Email 1: welcome them into one concrete action
Use the welcome email to orient the person and offer a small next step. Avoid listing every feature or asking them to book a call, follow social accounts, and start a project at once. The example assumes the actual product supports saving an unfinished brief and offers a monitored reply address.
All sample copy in this guide is original and fictional. Replace every placeholder, destination, timing, and policy statement with your verified product behavior. The example.com URLs are placeholders, not live BriefBoard services. Add your sender details and required preference and business information in the sending system.
Subject: Create your first project brief
Hi {{first_name}},
Welcome to BriefBoard. Start with one project: add the goal, deadline, and the files your client needs. You can save a draft and finish it later.
Create a brief: https://example.com/app/briefs/new
If you get stuck, reply and tell us which step you reached.
— The BriefBoard team
Manage onboarding email preferences: {{preferences_url}}Email 2: help with the unfinished step
Send this only while the activation condition remains incomplete. The copy should identify a useful next action without implying that someone has failed. If the person already has a draft, link to that draft after authentication; otherwise link to the appropriate starting state. Avoid putting a permanent authentication token in a marketing URL.
A single behavior-based reminder is enough to start learning. If people repeatedly reply that they cannot upload a file, improve that step before adding more reminders. Measure the first useful result using the activation guide, rather than defining success as an email click alone.
Subject: A small first brief is enough
Hi {{first_name}},
You can start with just a project goal and deadline. Add the remaining details when you have them, then share the brief when it is ready.
Continue your brief: {{authenticated_resume_url}}
Is something blocking you? Reply with the step you are trying to finish.
— The BriefBoard team
Manage onboarding email preferences: {{preferences_url}}Email 3: explain exactly what happens when the trial ends
A trial reminder needs an accurate date, time zone, next charge or access change, and a clear action. Render those facts from current billing state. The fictional example below assumes a trial with no automatic charge and read-only access afterward. A card-required trial that renews automatically needs different, accurate copy including the applicable charge and cancellation route.
Do not create urgency by inventing a deadline or saying data will disappear when it will remain available. A trial extension should update the schedule and cancel the obsolete reminder. Where a service or legally required billing notice is necessary, classify and implement that notice separately from an optional marketing sequence.
Subject: Your BriefBoard trial ends on {{trial_end_date}}
Hi {{first_name}},
Your trial ends on {{trial_end_date}} at {{trial_end_time_and_zone}}. After that, you can read existing briefs, but creating or editing briefs requires a paid plan.
This trial will not charge you automatically. To continue editing, review the available plans and their current prices.
Review plans: https://example.com/account/plans
You can also export your existing briefs from account settings. Reply if you need help before the trial ends.
— The BriefBoard team
Manage onboarding email preferences: {{preferences_url}}Make sending resilient to retries and changing account state
Keep sending credentials on the server. Save the signup and a pending email event together, then let a worker process committed events. Record a stable identity for each intended message, such as welcome/account-id or trial-end/trial-id. Atomically claim work so two workers do not both decide it is unsent. Recheck account state, permissions, and suppression before sending.
Use the provider’s idempotency option when supported and retain your own durable send ledger. Resend documents a 24-hour idempotency window, so that feature alone cannot prevent a duplicate job replayed days later. Retry temporary failures with bounded backoff, respecting provider instructions; do not keep retrying invalid addresses or suppressed contacts. For an ambiguous timeout, reconcile the original attempt before issuing a new message identity.
- Test duplicate signup events, two workers, and a timeout after the provider accepts a message.
- Test activation, upgrade, cancellation, and a trial extension while an email is queued.
- Test unsubscribe and bounce suppression before delivery, plus every link in a signed-out session.
- Use test recipients or a sandbox first; confirm sender authentication and a working reply address before enabling the flow.
Measure product progress and revise one message at a time
Keep eligible accounts, queued messages, provider acceptance, delivery events, clicks, completed briefs, and paid conversions as separate counts. A delivered message is not proof that a person read it. A click is not proof they completed the task. Choose a fixed observation window and compare product completion among comparable signup groups; describe small samples honestly.
Start by checking whether the reminder reaches the right person at the right state. Then change one hypothesis, such as the destination or first-task explanation. Email timing cannot repair a broken save action. Keep newsletters and later campaigns separate so a new customer can understand what they subscribed to. The downloadable copy pack includes the three templates and a launch checklist.