Lifecycle
Free onboarding email sequence writer for product activation
By Charles Summers · Updated · Free, no signup
Short answer
This builds an onboarding email sequence whose shape is computed from two things: how long your onboarding window is, and how much work the product demands before it does anything useful. Send times are fractions of the window rather than fixed days, so a five-day trial gets a different calendar from a thirty-day one. Setup-heavy products get an extra email addressed to whoever does the technical work. Every email carries a suppression rule, one call to action, and the specific reason it exists.
Use the onboarding email sequence writer
What does this tool actually do?
This builds an onboarding email sequence whose shape is computed from two things: how long your onboarding window is, and how much work the product demands before it does anything useful. Send times are fractions of the window rather than fixed days, so a five-day trial gets a different calendar from a thirty-day one.
It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.
The window sets the calendar, and most sequences ignore it
Almost every onboarding sequence you will find published uses fixed days: day 0, day 1, day 3, day 7. That works for exactly one window length, and the moment your trial is five days or your onboarding window is a quarter, the calendar is wrong in a way nobody notices because the emails still send. A five-day trial receiving a day-7 nudge is sending persuasion to an expired account. A ninety-day enterprise onboarding running out of emails by day seven leaves eighty-three days of silence at the exact point implementation stalls.
The fix is to schedule in proportions rather than dates. The first email belongs at zero, while the signup confirmation is still the top item in the inbox. The obstacle email belongs at roughly a tenth of the window, which is a couple of hours into a two-day trial and three days into a month. The decision email belongs at around 85 percent, far enough from the end that a reply can still be answered by a human before the window shuts. This tool computes those points from the number you give it, and switches from days to hours when the window is short enough that days are the wrong unit.
Proportional scheduling also exposes send density, which is the number people skip. Six emails across a fourteen-day trial is three a week, which is defensible. Six emails across a four-day trial is more than ten a week, which is not, however good the copy is. Divide the number of emails by the window in weeks before you write a word. If the answer is above about four, you are not running an onboarding sequence, you are running a pressure campaign with educational subject lines, and the unsubscribes will arrive from exactly the people who were still evaluating.
One activation action, and how to find yours honestly
An activation action is the single thing a new account does that separates the users who stay from the users who vanish. It is almost never signing up, rarely a feature, and usually a moment where the product holds something of the user's: a connected data source, an invited colleague, a first real record, a saved configuration they would have to rebuild elsewhere. The sequence exists to cause that one event. Every email that teaches something else is competing with the email that matters.
Finding it is a data exercise with a well-known trap. Take your retained cohort and your churned cohort from the same signup month, list what each did in week one, and look for the behaviour with the widest gap between them. That gives you a correlation, and correlation is where most teams stop and start writing. The trap is that motivated users do more of everything, so the action you found may be a symptom of intent rather than a cause of retention. The cheap test is to make that action dramatically easier for half of next month's signups and see whether retention moves, not whether the action rate moves.
Be suspicious of anything requiring more than one sitting, and of composite actions. "Set up their workspace" is not an activation action, it is a project. "Connected one data source" is an activation action because it is binary, observable in your own database, and you can write a subject line about it. If you cannot express the thing in six words and query it in SQL, the sequence has nothing to aim at and will default to a feature tour, which is the state most onboarding sequences are already in.
The feature tour deserves its own warning because it feels responsible. Sending five emails covering five features distributes your attention evenly across things the user values unevenly, and it implicitly asks them to learn your product rather than solve their problem. New users are not trying to understand your software. They are trying to find out whether the thing they hoped would happen is going to happen, quickly enough to justify the tab.
Complexity decides who has to act, not just how much to explain
The useful distinction between a simple self-serve product and a setup-heavy one is not difficulty, it is who does the work. In a simple product the person who signed up can reach value alone, in one session, at a laptop. In a complex self-serve product they can still do it alone but not in one sitting, so the sequence has to survive an interruption and re-enter cleanly. In a setup-heavy product the person who signed up frequently cannot do the work at all, because it requires an API key, a DNS record, a database credential or an admin permission they do not hold.
That third case breaks any sequence written as if the recipient is the actor. The evaluator reads an email saying "connect your warehouse", forwards it to a data engineer with no context, and the thread dies in a queue. The sequence needs an email whose explicit job is to be forwarded: short, addressed to the technical owner, containing the scope of the request, the time it takes, and the permission required. Written well it is the highest-leverage message in the flow, and it is missing from almost every onboarding sequence because the tool sending it only knows one email address.
- Self-serve simple. Compress. Fewer emails, earlier decision point, and no education beyond the one action. The risk is over-mailing a user who was going to activate in ten minutes anyway.
- Self-serve complex. Add a rescue email at around a third of the window for accounts that started and stopped. Partial progress is the strongest buying signal you will get and the easiest to waste.
- Requires setup. Add the forwardable partner email early, and a human-assist offer at the midpoint. Offering to do the setup on a call is not a sales tactic here, it is the cheapest way to remove a dependency you do not control.
- Any complexity, long window. Windows past three weeks need a usage-pattern email in the middle, because the failure mode changes from "never started" to "started and drifted", and those need different copy.
- Any complexity, very short window. Under about five days, schedule in hours and cut the proof email. There is no room for a case study between signup and expiry.
Suppression is the difference between a sequence and a nuisance
The single most damaging onboarding email is the one that arrives after the user has already done the thing it is nagging about. It tells them, accurately, that your product does not know what they did, which is a strange thing to admit in a message advertising how well you track their work. Every email in a sequence needs a written suppression rule expressed as a condition on your own event data, and the rule for most of them is the activation event itself.
Time-triggered and behaviour-triggered sends should coexist rather than compete. Run the calendar as the backbone, then let events interrupt it: activation exits the sequence into a different flow, partial progress swaps the next email for the rescue version, and total inactivity after the obstacle email means the account is probably a tyre-kick and deserves fewer sends, not more. Build the exits before the copy, because retrofitting suppression to a live flow is how people end up mailing customers who upgraded three weeks ago.
Judge the sequence on activation rate within the window, not on opens. Open rate on onboarding mail has been unreliable since Apple began pre-fetching images on behalf of Mail users, which inflates the figure for exactly the consumer-heavy audiences most likely to be on iPhones, and does so unevenly enough that comparing two sends is guesswork. Click-to-delivered survives better. Activation rate survives best, because it is the outcome you actually wanted and it is recorded in your database rather than in a pixel.
One more measurement point worth building early: a holdout. Withhold the sequence from a small slice of signups and compare their activation rate to everyone else. Many onboarding flows take credit for users who were always going to connect their data on day one, and without a holdout you will never know which emails did work and which just arrived nearby. The holdout is also the only argument that survives contact with someone who wants to add a sixth email.
Numbers worth knowing
| Metric | Typical | What it means |
|---|---|---|
| Send density ceiling | about 4 emails a week | Divide emails by window length in weeks before writing. Past this, unsubscribes come from evaluators who had not finished evaluating, which is the worst possible group to lose. |
| Trial-to-paid conversion | roughly 5% to 25% | The spread is mostly opt-in versus opt-out trials, not copy quality. A card-required trial converts several times higher on a much smaller top of funnel, so the two numbers are not comparable. |
| When activation happens | usually the first session | For self-serve products the majority of accounts that ever activate do so on day one. That is why the obstacle email lands early and why late education is a rescue, not onboarding. |
| Onboarding open rate | high but unreliable | Triggered mail to a fresh, expectant audience reports well, then Apple Mail Privacy Protection pre-fetches images and inflates it further. Use activation rate inside the window instead. |
| Holdout size | 5% to 10% of signups | Enough to measure incremental activation without materially costing you conversions. Without it, the sequence claims every activation that would have happened anyway. |
Mistakes that quietly cost you results
- Fixed day-0 / day-1 / day-3 / day-7 timing regardless of window length
- Schedule as fractions of the window instead. A day-7 email into a five-day trial is persuasion sent to an expired account, and a sequence that runs out by day seven abandons a ninety-day implementation at the point it usually stalls.
- A feature tour with one feature per email
- This spreads attention evenly across things users value unevenly, and asks them to learn your product instead of getting their result. Aim every email at the one action that predicts retention and let the rest of the product be discovered.
- No suppression rule, so the sequence keeps teaching an action the user already completed
- Write the exit condition before the copy: activation moves the account into a different flow, partial progress swaps in the rescue email. Nagging someone about work they already did advertises that your product is not watching.
- Addressing the setup email to the person who signed up
- In a product needing an API key or admin permission, the evaluator often cannot do the work. Write one short email designed to be forwarded, containing the scope, the time required and the permission needed, and say so in the subject line.
- Reporting the sequence on open rate
- Image pre-fetching by mailbox providers makes opens non-comparable between sends and between audiences. Report activation rate inside the window against a holdout, which is the number that decides whether the flow deserves a sixth email.
What does the output look like?
This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.
Frequently asked questions
How many onboarding emails should the sequence have?
It depends on the window, not on a best-practice number. This tool derives the count from window length and complexity, then divides by the window in weeks to show your send density. Four a week is roughly the ceiling before evaluators start unsubscribing mid-evaluation. A fourteen-day self-serve trial usually lands on five emails; a thirty-day setup-heavy onboarding lands on seven, because there are more failure points to catch and more calendar to cover.
What if I do not know my activation action yet?
Compare your retained and churned cohorts from the same signup month and find the week-one behaviour with the widest gap between them. Then treat it as a hypothesis rather than a finding, because motivated users do more of everything and the action may be a symptom of intent rather than a cause of retention. The cheap confirmation is to make that action much easier for half of next month's signups and watch whether retention moves, not whether the action rate moves.
Why does the sequence change when I mark the product as requiring setup?
Because the person receiving your emails may not be able to do the work. A setup-heavy product adds two emails the other modes do not get: a short forwardable message written for whoever holds the API key or admin permission, and a human-assist offer at the midpoint. It also drops the generic education email, since explaining features to someone waiting on a colleague is noise.
Should these be time-based or behaviour-triggered?
Both, in that order of authority. Run the computed calendar as the backbone so no account falls into silence, then let events interrupt it: completing the activation action exits the sequence entirely, partial progress swaps the next send for the rescue version, and no product session at all after the obstacle email should reduce frequency rather than increase it. Each email in the output carries the suppression condition it needs.
Does the recipient role change anything, or is it just merged into the copy?
It changes the setup branch. The tool reads the role for technical signals and rewrites the partner email accordingly: a technical signup gets an email that assumes they hold the credentials themselves, while a non-technical signup gets one explicitly built to forward, with the scope and permission spelled out so the request survives being pasted into a ticket with no context.
Related free tools
- Newsletter Subject Line Tester Lifecycle
- SMS Marketing Copywriter Lifecycle
- Push Notification Writer Lifecycle
- Webinar Funnel Calculator Growth
- Schema Markup Generator SEO
Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.