What should a lifecycle email do in week one?

What should a lifecycle email do in week one?

Get one person to one real outcome. Not a tour, not a feature list, not a welcome from the founder. Week one exists to move somebody from signed up to having done the thing your product is for, and every email should be judged against that single test.

Most week one sequences fail because they are organised around the product rather than around the person. Email one explains what the product is. Email two lists features. Email three offers a demo. None of those helps somebody who logged in, did not know what to do first, and closed the tab.

So this is about what those emails should actually contain, and what has to be true before you write any of them.

Why does week one matter more than the rest of the sequence?

Because intent decays fast and never comes back to its original level. Somebody who signed up had a reason on that day. A week later the reason is still true but the urgency has gone, and no email can manufacture urgency that has already dissipated.

The practical consequence is that week one is the only part of your lifecycle programme where you are working with the person's own motivation rather than against their indifference. That is an enormous advantage and most sequences waste it on introductions.

It also means the rest of the sequence is a different job. Weeks two onward are about habit and expansion, which are real but slower. If week one fails, nothing downstream rescues it, because you are then emailing someone who has already concluded the product was not for them.

How many emails should week one contain?

Three at most, and two is often better. The number people choose is usually five or six, and the extra ones exist because somebody had more things to say rather than because the reader needed more prompts.

Three has a natural shape. One immediately, to get them to the first action. One a couple of days later, responding to whether they did it. One near the end of the week, offering help from a person. That is a complete week and it does not feel like a campaign.

What makes the difference is not the count but whether each email has a job you can name. If you cannot say in one sentence what a given email is trying to make happen, it is filler, and filler trains people to stop opening.

What should the first email actually say?

One action, with the link, and nothing else competing with it. Name the thing that will make the product make sense, and make doing it as close to one click as you can manage.

The temptation is to include resources, a help centre link, a video and a calendar invitation, on the reasonable theory that different people want different things. What that actually produces is a reader who has to choose, and choosing is exactly the work you are supposed to be removing.

Write it as though you were replying to a person who asked what to do first. That framing kills most of the bad instincts automatically, because nobody answering that question in a real conversation would open with a paragraph about the company's mission.

What should trigger each email?

Behaviour, not the calendar, wherever you can manage it. An email that arrives on day three regardless of what happened is guessing. An email that arrives because somebody did or did not complete the first action is responding.

The minimum viable version is a single branch: did they do the first thing or not. If yes, the next email is about the second outcome. If no, the next email is about the obstacle, and it should ask rather than assume.

That one branch is worth more than an elaborate scoring system, and it is achievable with almost any tooling. When I built the CRM path for Kismet Health into HubSpot through Zapier, the value was never in sophisticated logic. It was in the data being reliable enough that simple logic could be trusted.

What should you never put in a week one email?

An upsell, a survey, or a feature announcement. All three ask the reader to give you something before the product has given them anything, and all three are common.

The upsell is the worst because it answers a question nobody asked. Somebody who has not yet had a good outcome cannot evaluate whether they want more of it. Asking early reads as impatience and it sets the relationship up as transactional.

Surveys are subtler. A satisfaction question in week one measures whether your onboarding worked, which you can already see from behaviour, and it spends the reader's goodwill on data you do not need yet. Save the asking for when there is something to ask about.

How do you write for someone who has not used the product yet?

Describe the outcome in their language, not the interface in yours. A person who has not used the product has no mental model of your navigation, so instructions that reference screen names are meaningless to them.

The fix is to lead with what they will have when they are done. Not "go to the integrations tab", but "connect the tool your team already uses, which takes about two minutes, and then your data will be in one place". The instruction can follow the outcome. It should never replace it.

Collect the language rather than inventing it. The words people used in your signup form and your support inbox are the words that will land, and they are almost never the words in your product. That is the same discipline that makes a website persuasive, which I have written about in what counts as activation in your SaaS.

What does success look like at the end of week one?

A defined proportion of new signups reached one named outcome. You do not need a sophisticated metric. You need a single event you can point at and say that somebody who did this has understood the product.

Defining that event is the hard part and it is where most lifecycle programmes are quietly broken. If nobody can name the moment, the emails cannot be aimed at anything, and the reporting becomes about opens and clicks, which measure the email rather than the outcome.

The length of your trial changes the shape of this too, because a seven day window and a thirty day window need different week one urgency. I have gone through that tradeoff in how to choose a free trial length.

When should a human send the email instead?

When the signup matters enough that a real reply would change the outcome. At low volume that is everyone, and founders who personally email every new signup in week one learn things no analytics dashboard will tell them.

The signal to automate is when you are writing the same message repeatedly. Until then, the manual version is not a stopgap, it is research, and it is producing the copy you will eventually automate.

Across more than 70 projects for more than 25 clients over more than six years, the best lifecycle sequences I have seen were transcriptions of what a founder had already been sending by hand. The worst were designed in a workshop before anyone had sent a single one.

What should you do next?

Name the one outcome that makes your product make sense, and write it down as a sentence a customer would recognise. If you cannot do that today, stop working on email and work on that, because everything else depends on it.

Then write two emails. One that asks for that action, one that responds to whether it happened. Send them manually for a fortnight before automating anything, and keep the replies, because the replies are the specification for version two. If you already have a longer sequence running, it is worth checking it against this standard, which I have set out in more detail in how to build an onboarding email sequence for trial users.

If you want a second opinion on what your week one outcome should be, reach out. It is usually one step earlier in the product than the team expects.