Email courses for SaaS onboarding

What a fixed course is for, and what it is not for

A five-day course runs on the calendar. It sends day three on the third day whether the user has logged in once or forty times, which makes it the wrong mechanism for activation. If a user has not completed the first meaningful action, the useful email is the one that notices and says so, and that email has to be triggered by the absence of an event, not by a date.

What a calendar course does that a trigger cannot is teach the model. Most products worth paying for are built on one idea the user has to hold before the features make sense: that time is tracked against outcomes rather than tasks, or that a document is really a database. No trigger can detect that a user has not understood the idea; they look identical to one who has and is busy.

So run both. The triggered sequence handles activation, in response to events, with the dignity of noticing. The course teaches the idea, in order, and is written once and left alone. Treating the course as the activation sequence is what produces five emails describing five features to somebody who has not opened the product since Tuesday.

What the five days should teach

The concept, then the consequence of the concept, then the one place people go wrong with it. Not the interface. A tour of the interface ages out within two releases and is, worse, addressed to somebody already inside the product, which the reader of email three frequently is not.

Day one gives them the smallest complete use of the idea, done today, in the product, in under five minutes. Track one hour. Write one document. Log one deal. It must produce something they can look at, because a user who has produced nothing has nothing to return to.

The middle days each take one consequence of the idea, with the feature that serves it mentioned in passing rather than as the subject. The difference matters: "here is the report that shows you where the week went" is about the user, while "introducing custom reports" is about the release notes.

Day four is where people go wrong, and in most products this is the same mistake every time: using the new tool to do the old process. Naming it plainly is the single most useful email in the sequence, and it is the one that support will recognise instantly, because they answer it every day.

The objection your users arrive with

They do not want to learn a tool. They wanted a thing done, they signed up under mild time pressure, and every minute spent understanding your product is a minute not spent on the work it was supposed to help with. This is why feature tours are ignored: they ask for an investment before anything has been returned.

The way through is for every email to be usable in the product in the time it takes to read it. Five minutes, a visible result, and nothing that requires setting anything up first. A course that requires the user to configure something before day two is a course that lost most of its list on day two.

The second objection belongs to the person who did not choose you. One person signed up and four were added, and those four are reading about a product they did not select and may resent. Written for them, the course explains why this exists and what it replaces rather than assuming enthusiasm. The team member who understands the point is the one who stops the account churning when the champion leaves.

What the sign-up has to say, since there is usually no opt-in page

Your users did not visit an opt-in page. They created an account, and consent to be emailed a course is not the same thing as consent to receive the service, however convenient it is to treat them as one. Keep them separate: joining the course is its own deliberate choice, offered in one place rather than bundled into the terms, and it starts when the user clicks the link in a confirmation email instead of at the moment the account was created.

That click is also the consent record. It carries a timestamp, it was made by whoever actually reads the mailbox, and it is the one thing that tells the person who wanted the course apart from the four colleagues an administrator imported on a Tuesday afternoon. A form submission proves a browser sent you a string; a confirmation proves somebody read the address it was sent to.

That separation is operational as well as legal. A user who unsubscribes from the course must still receive password resets and billing failures, and one list doing both jobs is how that goes wrong. Which legal basis applies to you differs by jurisdiction and by whether your users are consumers or businesses, and your own advice governs.

What the sign-up moment has to make clear:

• That the course is separate from the service, and declining it changes nothing about the account.
• How many emails, over how many days, and that it ends.
• That a confirmation email is sent first, and that the course starts after its link is clicked rather than at sign-up.
• What arrives after it: product updates, a newsletter, nothing at all.
• That transactional mail continues regardless, because it has to.
• An unsubscribe link in every course email that stops the course and only the course.

What the day-six email asks for

Ask what stopped them. One question, answerable by reply, from a real person with a real address: what got in the way this week. For a trial that is about to expire it is worth more than a discount, because the answer tells you which of the five days failed, and no analytics event distinguishes a user who did not understand from one who was busy.

The upgrade ask belongs in the same email, second, stated plainly with the price and what changes. A user six days in knows whether they want it. What they usually do not know is what happens to the data they have created if they do nothing, and saying so removes the anxiety that makes people abandon a trial rather than decide about it.

Whatever you do, do not put the whole weight of the trial on one email at the end. The five days either taught the idea or they did not. The last email collects the answer; it does not rescue the week.