GuidesActivation and time to value
SaaS onboarding email sequence: triggered by what the user has done
An onboarding email sequence for an app installed from an app store: triggered by product state, not day number, with when to stop and how to measure.
In short: The right onboarding email sequence for an app installed from an app store is not a day 1, day 3, day 7 drip. It is three emails, each sent when the merchant sits in a known state: installed but not set up, set up but no result yet, first result but no second visit. Each one names the single missing step, comes from a person, and is cancelled the moment the product event it asked for happens. Measure it by replies and by that event, not by open rate.
Why should onboarding emails follow product state instead of the calendar?
A day-based drip assumes every merchant is in the same place on day 3. They are not. One merchant installed, connected their store and launched a program in twenty minutes. Another approved the OAuth screen and closed the tab. "How to create your first campaign" on day 3 is wrong for both: patronising for the first, generic for the second.
The product knows exactly where each merchant stopped. Your own events tell you whether setup finished, whether the first result happened, and whether they came back. An email sequence that reads those events can say the one thing that is true for that merchant right now, and it can stay silent for merchants who are already moving.
Time-based drips also never stop. A merchant who finishes setup on day 1 still gets the day 5 setup reminder, and learns that your emails are not worth opening.
The three states and the email for each
I work from the same install-to-result path as the guide on Shopify app onboarding. For email, three states matter, and each has one email.
| State | How you know | What the email says | When it goes |
|---|---|---|---|
| Installed, no setup | Install recorded, no setup-complete event | "You stopped at this step. Here is what it does and the one screen to finish it." | 24 hours after install with no setup event |
| Set up, no result | Setup-complete event, no activation event | "Your program is live. Nothing has happened yet because of this. Here is the fix." | 3 days after setup with no result event |
| First result, no return | Activation event fired, no session since | "Here is what happened in your store since you last looked." | 48 hours after the result with no app open |
The delays are still part of the trigger, but they count from the last event, not from install. If the median merchant finishes setup 40 minutes after install, a merchant who has gone 24 hours without it is stuck, and that is the moment to write.
Activation here means the first real result in the merchant's business, such as the first affiliate joined or the first referred order tracked, measured over about 14 days. The guide on SaaS activation rate covers choosing that event. The first on-screen result in session one is time to first value, a different number, and it needs no email.
What should each email say?
Email 1, installed but no setup. Name the exact step they stopped at. Not "finish setting up your account". "You connected your store but have not created a program yet. It is one screen, and a default commission is already filled in." One link, straight to that screen. One sentence on what happens after. Nothing else.
Email 2, set up but no result. This is the hardest one to write and the most valuable. The merchant did the work and nothing visible happened. For an affiliate app, the program exists but no affiliate has joined because the signup page is not linked from anywhere a customer would see it. The email has to say why nothing has happened and the one action that changes it: "Your program is live, but your customers have not seen it yet. Add the link to your order confirmation email. Here is the two-minute version." This is the email that moves activation, because it addresses the gap between setup and the first real result.
Email 3, first result but no return. Show them the result, with real data from your database. "Your first affiliate, Priya, joined on Tuesday and has shared her link twice." If you cannot pull real data into the email, do not send this one. A generic "check your dashboard" is worse than silence.
Rules that hold for all three:
- Plain text, or close to it. One column, no header image. It should read like a message from a person, because it is one.
- One link and one ask per email.
- The subject line states the situation. "Your program is live but hidden" beats "Tips to get started".
- End with a question the merchant can answer in one sentence, so a reply is the natural response.
Who should the email come from?
A named person with a real inbox, and replies go to that inbox. For a small app that is the founder. For a larger one it is whoever runs customer success. Not "The Team" and not a no-reply address.
Merchants reply to people, and replies are one of the two measurements you want. An email from someone who will read the answer is also written differently.
I started in customer success before I moved into product design, and if I ran that inbox again, the replies to these three emails are the ones I would read first every morning. They describe where onboarding is broken in the merchant's own words.
When should the sequence stop?
The sequence stops for a merchant the moment the event it is asking for happens. The setup email is cancelled when the setup event arrives. The result email is cancelled when the activation event fires. That cancellation is the first thing to test before launch: fire the event in a development store and confirm the queued email is dropped. Check the condition at send time, not at queue time, so the merchant who finishes setup 23 hours after install never sees the 24-hour email.
Three more stop conditions:
- Uninstall. Shopify's
app/uninstalledwebhook, in the words of its webhook topic reference, "occurs whenever a shop has uninstalled the app." Stop everything on receipt. Whether to send one human email asking why is covered in the guide on reducing Shopify app uninstalls. - A reply. If the merchant answered, a person owns the thread now. Pause automated sends to that store until the thread is closed.
- The end. Three emails, then silence, unless a new state begins. A merchant who sat through all three without moving will not be moved by a fourth.
How do you wire the triggers?
You need three things: the events, a way to get them to the email tool, and the exit logic.
The events are install, setup complete, the activation event, and an app-open event. Record them against the store, not the staff user.
To get them to the email tool, forward only the events the sequence needs. If you use PostHog, its destinations send events to other tools as they arrive, and the webhook destination "enables you to send events to any HTTP endpoint," with filtering by "event types, properties, or any SQL statement." So setup_completed and first_affiliate_joined can go to Customer.io, Klaviyo, or a small worker you wrote.
The exit logic lives either in the email tool, as a goal event that removes the merchant from the flow, or in your worker as a check at send time. A flow with no exit is the common mistake.
What do deliverability and the law require?
Google's email sender guidelines require SPF or DKIM from every sender. Anyone sending more than 5,000 messages a day to Gmail accounts must also set up DMARC, support one-click unsubscribe on marketing and subscribed mail, and keep the spam rate in Postmaster Tools below 0.3%, with Google advising under 0.1%. Your onboarding sends share a domain with your marketing sends, so meet the bulk-sender bar once.
The FTC's CAN-SPAM compliance guide applies to messages whose "primary purpose" is commercial. An email telling a merchant their program is live and what to do next sits close to the transactional or relationship category, but the FTC says "the law views these categories narrowly," so I treat onboarding email as commercial: a valid postal address, a working opt-out, opt-outs honoured within 10 business days, and the opt-out mechanism kept working for at least 30 days after sending. The guide puts the penalty at up to $53,088 per email. If you send to merchants in the EU, the UK or Canada, check the local rules as well. I have not covered them here.
How do you measure an onboarding email sequence?
Not with open rate. Apple's Mail Privacy Protection, as described in Apple's own support guide, downloads remote content "in the background when you receive a message" and hides the recipient's IP address from senders. The tracking pixel loads whether or not a human read the email.
Two numbers instead:
- The event the email asked for. The share of stores that received email 1 and fired the setup event within 48 hours, against a holdout that got no email. The same for email 2 and the activation event, and email 3 and the return session. Compute it in your product analytics, where the store ID join is clean, not in the email tool.
- Reply rate, and what the replies say. A low reply rate with every reply saying "I don't know where to put the link" is a product finding, not an email finding.
Keep a 10% holdout of new installs that gets no sequence for a month. If activation is the same with and without the emails, the emails are not doing anything and the fix belongs in the product. The guide on time to value covers that side.
Click rate is a fair secondary signal: it says the link was found, not that the step was done.
Where to start
- Write the three emails in plain text, each under 120 words, each with one link and one question.
- Confirm your product sends install, setup complete, activation and app-open events per store, with the store ID on each.
- Forward only those events to your email tool, and set the goal event that exits each merchant from the flow.
- Fire each event in a development store and confirm the queued email is cancelled.
- Set up the holdout, route replies to a person, and review the event rate and the reply themes every Monday.
Frequently asked questions
How many onboarding emails should a SaaS send?
Three, each tied to a state the merchant can be in: installed without setup, set up without a result, a result without a return visit. A merchant who moves through the product quickly should receive none of them. The count that matters is emails sent to merchants who needed them, not emails in the sequence.
Should onboarding emails come from a no-reply address?
No. Send from a named person with a real inbox and route replies to that inbox. Replies are one of the two ways you measure the sequence, and the merchant's reply is the most specific description of what blocked them that you will get.
Should I still send a welcome email straight after install?
Yes, but keep it to a receipt: one line on what the app will do, one line on who to reply to if stuck. The merchant is inside the product at that moment, so the welcome email is not where onboarding happens. Do not count it as part of the sequence or measure it as one.
Is open rate useless for onboarding emails?
For decisions, yes. Apple's Mail Privacy Protection loads remote content in the background when a message arrives, so the pixel fires without a human reading. Use the in-product event you asked for and the reply rate instead, and treat clicks as a secondary signal.