Which emails does my SaaS need, and how do I plan onboarding from signup to paid?

People sign up for your product, click around for a few minutes, and never come back. The natural reaction is to add emails: a welcome email, a feature tour, a tips series, a reminder every other day. Within a few weeks, a new user can get 3 emails on their first day, including one asking them to do what they did an hour ago.

Onboarding emails that ignore what users do lead to unsubscribes, spam complaints, and replies like "why are you telling me to do what I did yesterday?" Many onboarding programs fail because of missing data rather than weak copy. If your app can't tell your email system that a user succeeded, your emails keep nudging people who no longer need a nudge.

Start with 3 emails:

1. A welcome email on day 0.
2. A nudge toward your activation event, the action that tells you a user is likely to stick around.
3. A second nudge, at least 3 days after the first.

Send the nudges only to users who haven't reached the activation event yet. Give each email a single goal and an exit condition, measure whether the nudges lift activation, and only then add more emails.

How should I choose the activation event for my onboarding emails?

An activation event or milestone is an action in your product that predicts whether a user sticks around and converts. For a project management tool, it might be creating a project and inviting a teammate. For a scheduling tool, it might be the first meeting booked through a shared link. Every onboarding email should move users toward that event.

Ideally, pick the event from data. Compare what retained users did in their first week with what churned users did, and look for the action that separates the 2 groups. Facebook's growth team, for instance, found that adding 7 friends in the first 10 days correlated with long-term retention.

If you don't have enough users for a reliable comparison, look for the core action of your product performed more than once: a single project could be a test, but a third project is a strong signal someone is using your product.

The activation event isn't always the last step of your setup flow. A user can finish every setup screen and never come back, while another skips setup and still finds the value. Aim your emails at the action that predicts retention, wherever it falls in your setup flow.

If you don't know what makes users stick, ask them. Email users who activated and users who left, and ask what they were trying to get done. With a small user base, you can read every reply and follow up on the most useful ones.

How should I plan my onboarding program from signup to paid?

Build the program around 3 stages. Each stage starts and ends with an event your app sends, rather than after a set number of days.

Give every email 1 goal and 1 exit condition. The goal is the single action the email asks for, such as connecting a data source. The exit condition is the event that makes the email unnecessary: when a user connects a data source on their own, the reminder to do it never goes out.

Resist the urge to pack 5 features into one email in the hope that one of them sticks. An email with 1 clear action is easier to act on. When one email can't fit everyone, improve your segmentation, so each user gets the email that matches what they're trying to do.

Your app needs to send at least 3 events for the program to work: signed up, activated, and upgraded. Without an activated event, your email system can't tell who already succeeded, and the nudges keep going out to people who don't need them.

Once you have enough signups, keep a holdout group to find out whether your emails work: a random share of new users, such as 10%, who get the welcome email but none of the nudges. After a few weeks, compare the activation rate of both groups. If the nudges don't lift activation, rewrite them before you add more.

Compare activation rather than open rates, since open rates aren't accurate: some inboxes open every email to scan it or to protect the recipient's privacy.

Which emails should my SaaS send, and which should I build first?

Every SaaS sends 2 kinds of email:

1. Transactional emails respond to something the user did.
2. Lifecycle (or marketing) emails move users from one stage to the next.

Build the transactional emails first, before you launch, followed by the welcome email and 2 nudges toward your activation event. The lifecycle email to build next depends on where users drop off:

• If most users never activate, improve the nudges before you build anything else.
• If users activate but don't pay, build the upgrade and trial-ending emails.
• If users pay and then cancel, build retention emails that ask what changed.

At an early-stage startup, start small and focus on the key moments. A few emails that fire at the right time are easier to measure and maintain than a 12-email sequence.

Send transactional and lifecycle emails from separate subdomains, such as auth.example.com and hello.example.com, so complaints about a nudge are less likely to delay a password reset. Onboarding nudges are closer to marketing than to transactional email, so give them an unsubscribe link. Recipients who can't find a way to opt out are more likely to mark your email as spam.

Should I trigger onboarding emails on behavior or send them on a schedule?

A scheduled drip sends every user the same email on the same day: day 1, day 3, day 7. A behavior-triggered email goes out when a user does something, or doesn't. Drips are simpler to set up, but they ignore what users do, which is how people end up with instructions for a step they finished yesterday.

A hybrid approach combines time and behavior: time is the clock, and behavior is the gate. Each step waits up to a set number of days for the target event. If the event arrives, the user skips ahead to the next stage. If the time runs out, the nudge goes out.

A fixed schedule works while you can't send events from your app yet, such as in an early prototype. Keep it to 3 or 4 emails, and switch to behavior as soon as you can track your activation event.

Some products can't see what users do at all, such as self-hosted or open-source tools. Keep their emails general, and time them around milestones most users reach, such as the end of their first week.

How many onboarding emails should I send, and how far apart?

Keep onboarding emails at least 3 days apart. Emailing more often raises the risk of unsubscribes, and you can't nudge a user who has unsubscribed.

• Don't interrupt active users. Send the welcome email about an hour after signup rather than the moment someone creates an account, so it doesn't land while they're exploring your product.
• Send in the user's time zone. Capture the time zone at signup, from the browser, and schedule each email for a set local time, such as 9 a.m. An email sent at 3 a.m. sits under a pile of newer mail by the time the user wakes up.

Products people need a few times a year, such as a tax tool or an event ticketing app, don't fit a weekly cadence. Keep their emails focused on the value, and time them around the moments users need the product, such as the weeks before a filing deadline.

How should I keep automated emails from piling up on new users?

A new user can be in your onboarding sequence, on your newsletter list, and in a sales sequence at the same time. Each team's emails make sense on their own, but together they add up to 3 emails in a day from the same company.

List every automated email a new user can receive, from every team, including:

• Transactional emails
• Onboarding nudges
• Product announcements
• Newsletters
• Sales follow-ups

For each email, note its trigger, its exit condition, and who owns it. A shared template library gives you a single place to review all of them.

A diagram of your lifecycle makes gaps and overlaps easy to spot. A whiteboard or wireframing tool works, and so does a Mermaid chart, a diagram written as text, which an AI assistant can generate from your list and which you can keep next to your code.

Once you can see every stream, decide which ones pause during onboarding. Product announcements and newsletters can often wait until a user activates.

When a user hasn't logged in or clicked an email after several nudges, more emails rarely bring them back, and they raise the risk of spam complaints.

Send one last plain email that asks what was missing, then stop: "Hey, it's Sam from Example. You haven't used Example since you signed up, so we won't email you again. Was something missing?" The replies that come back often point to what your product lacks.

How should I personalize onboarding emails by role, use case, or signup source?

A designer and a developer sign up for different reasons, and a single generic track serves neither of them well. Store what you know about each user as attributes, such as their role, use case, language, and signup source. Your onboarding can then branch on each attribute, or run a separate track for each group.

The simplest way to learn what users want to achieve is to ask: 1 question at signup, or a plain-text email that asks what brought them to your product. While your user base is small, you can answer each reply yourself. At scale, an AI agent can sort the replies and draft answers for your team to review.

Where someone signed up says a lot about what they need first:

• Referral: The user already knows someone who uses your product, so point them to the team or workspace they can join.
• Switch from a competitor: Lead with how to import their data.
• Marketplace or integration: Start from the integration they installed rather than your general feature list.

Using what a user did in your product makes an email relevant, as long as it feels helpful. Before you send one, ask yourself whether it reads like someone watching over your shoulder or like a trusted partner who knows your account and wants to help. "You created 3 projects this week. Here's how to share them with your team" helps. "We noticed you visited the pricing page 4 times" doesn't.

To send onboarding emails in each user's language, store the language at signup, from the browser or the account settings, and keep a localized version of each template. Fall back to your default language when a translation is missing.

How should I write onboarding emails for a developer tool or API?

Developers sign up to get something working, so write each onboarding email like a short tutorial: 1 goal, the steps to reach it, and the code to copy.

• Get straight to the point. Skip the feature tour, and lead with the next step.
• Format commands and code as code, so developers can copy them as they are.
• Link to a setup file for AI coding assistants. Many developers hand setup to an assistant. A single markdown file, such as a setup.md, gives the assistant everything it needs to integrate your product.

For API products, the activation event is usually the first request in production. A successful test request shows interest, but a production request shows the integration is live. Nudge developers who got a test request working but haven't gone live, and tell them what changes between the 2, such as API keys or domain setup.

Which onboarding emails should I send a new B2B customer after the deal closes?

Once the customer signs the contract, onboarding emails should come from the people the customer already knows, such as their account executive or their customer success manager. You can still automate the emails: send them from the customer success manager's name and address, and route replies to their inbox.

A key email after a deal closes is the invitation to a kickoff call. Make it clear the call isn't a box to tick but the start of a working relationship, and say plainly what the customer gets out of it: "I can't help your team get results if I don't know what you're trying to achieve."

When a customer success manager reaches out personally, send the automated onboarding emails from them too, or pause the emails for that account, so the customer doesn't get the same advice twice from 2 senders.

Sales and customer success teams need to see which emails a customer received. Most CRMs (customer relationship management tools) offer a BCC address: copy it on an email, and the CRM logs the email on the customer's record. For automated emails, a better option is your email provider's webhooks, which notify your app of each email event, such as delivered, opened, or clicked. Log each event as an activity on the customer's record.

Which emails should I send users after onboarding ends?

Once a user reaches the habit or converted stage, onboarding ends, and the user moves on to regular product updates and retention emails.

Let users choose which emails they get. Subscription topics, such as "Product updates" and "Tips", let users turn off one kind of email without unsubscribing from everything. When usage drops, a retention email that asks what changed often teaches you more than a discount offer.

Onboarding email checklist

1. Pick your activation event, from data if you have it.
2. Send signed up, activated, and upgraded events from your app.
3. Build and test your transactional emails before you launch.
4. Send the welcome email about an hour after signup.
5. Add 2 nudges that only go out when the activation event is missing.
6. Give every email 1 goal and 1 exit condition.
7. Keep onboarding emails at least 3 days apart, and send them in each user's time zone.
8. List every automated email a new user can receive, with its trigger, exit condition, and owner.
9. Send users who never engage one last email asking what was missing, then stop.
10. Measure activation against a holdout group before you add more emails.

Other details to keep in mind

An email can bring your product back to mind, but it can't fix a product that doesn't deliver. If users activate and still leave, look at the product before you add more emails.

AI products come with their own onboarding challenges:

• Fake signups. Free credits attract disposable and bot signups, which raise your bounce rate and your costs. Check addresses with an email verification service and rate limit signups before the welcome email goes out.
• Long-running jobs. A user waiting on a video render or a large analysis needs a fast transactional email when the result is ready.
• Usage alerts. Credit and usage alerts can drive upgrades, but they can turn into spam. Send 1 alert per threshold, then switch to a digest.
• Generated content. When your product emails content its users generated, check that content for abuse first. Your domain's reputation pays for anything sent from it.

If you expect a spike of signups at launch, warm up your sending domain ahead of time, as covered in how to warm up a new domain.

How should I run my onboarding emails with Resend?

FAQ

What is an activation email?

An activation email asks a new user to take the step that gets them to your activation event, such as connecting a data source or inviting a teammate. The email only goes out if the user hasn't taken that step yet.

Should I pause onboarding emails on weekends and holidays?

For work tools, often yes. A nudge sent on a Saturday competes with the rest of the weekend's mail by Monday morning, so hold it until the next workday. For consumer products, weekends can be when people have the most time, so check when your users are active in your product.

Should I ask for a first name at signup just to personalize emails?

No. Every extra field at signup adds friction, and a first name in the greeting matters less than an email about the step the user is stuck on. Ask for a name when your product needs one.

Should I turn on open and click tracking for transactional emails?

No. Open tracking adds an invisible image to each email, and click tracking rewrites links to go through your provider first. Inbox providers can read both as signs of marketing email. Turn tracking on for the subdomain that sends your onboarding and marketing emails, where you use the data, and keep it off for login codes and receipts.

Should I treat personal-email signups differently from work-email signups?

Often, yes. A work address can signal a team that needs a sales-assisted track, while a personal address can signal someone trying your product on their own. Many people sign up for work tools with a personal address, so ask about the team when it matters instead of relying on the domain alone.

What's the difference between customer onboarding and user onboarding?

User onboarding gets each person to the activation event in your product. Customer onboarding gets a whole account, often a company after a sales deal, to the outcome it paid for, with a kickoff call, a rollout plan, and a customer success manager. One customer can include dozens of users, each going through their own user onboarding.

Sources

• Resend, Wait for Event, accessed October 30, 2026
• Resend, Open and click tracking, accessed October 30, 2026
• Resend, Do you need to add an unsubscribe link to all of your emails?, accessed October 30, 2026