7 SaaS Welcome Email Examples & Best Practices
A teardown of the welcome emails from Supabase, Clerk, Linear, Slack, Apollo, Superhuman, and Manus. The choice each one made and the conditions it needs in your product.
Bonus: three free welcome email templates at the end of this post. Minimal, Checklist, and Team — drop your email in the form at the bottom to grab all three.
Why welcome emails matter more than the rest
Among the emails you send a user in week one, the welcome outperforms everything else. By a lot. And the data on this isn't subtle.
Three benchmark reports, each built on tens of billions of emails by major email platforms, line up on the same conclusion:
In GetResponse's 2024 benchmark built on 4.4 billion emails, welcome emails averaged an 83.63% open rate and a 16.60% CTR.
Omnisend's 2024 report analyzing 24 billion emails found that automated welcome-type flows beat scheduled campaigns by +52% open rate, +332% CTR, and +2,361% conversion rate, with one in two clicks turning into an actual purchase.
Klaviyo's 2026 benchmark across 183,000 customers showed that automated flows drove 41% of email revenue from just 5.3% of total sends, with 18× the per-recipient revenue of regular campaigns.
If you treat the welcome as just another email, you're playing your weakest hand at the moment you have the largest audience. And it's a one-shot moment.
A welcome email is less "email copy" and more the handoff that moves a user from New to Active in week one.
Here's how seven PLG SaaS companies built that handoff, and what you can take from each one.
1. Supabase: a welcome that works without using your name
Supabase is an open-source Postgres-based backend-as-a-service. Most people who sign up are solo developers wiring an app together for the first time. The welcome email is built for that reader.
What stands out is what Supabase left out. No name personalization. The greeting is Hey there, and nothing else. No product pitch. After a one-line promise, a single button (Create Your First Project), and three docs links, the email is over.
The three docs are worth examining: Data API hardening, Row Level Security, Production Readiness. All three are places developers regularly trip in production.
That's a deliberate decision to pull new users into production-thinking on day one. Most welcome emails lead with "here's what you can do." Supabase leads with "here's what you can mess up." For developers, that framing sticks longer than any feature list.
The email is signed by the CEO. Paul, CEO and Co-Founder @ Supabase. For an early-stage SaaS, a founder signature is one of the cheapest ways to earn trust. It tells the user "you can reply directly," and that signal alone is worth more than most copy.
Two conditions make this design work for Supabase.
The first is that the missing personalization is covered by other elements: docs links anchored in the developer's actual workflow, plus a CEO signature that reads as personal contact.
The second is that activation compresses into a single action. There's nothing to choose between. Create Your First Project is the one thing the user is asked to do.
If either condition fails, the same email starts reading as "they didn't bother." Supabase can use Hey there, because the brand is already recognized in the developer community. A newer product using the same greeting gets read as lazy. If brand recognition isn't there yet, name personalization is the safer choice.
2. Clerk: one subject line, one line of code
Clerk is an auth SaaS aimed at React and Next.js developers. The category is crowded, so "plug it in and move on" is the actual positioning. The welcome email reflects that exactly.
Start with the subject line: Welcome to Clerk Jake! 🎉. The recipient's name sits in the subject itself.
Most SaaS welcome emails use first names in the body, if they use them at all. Putting the name in the subject is rarer. The reason it works here is timing. A welcome arrives right after the user has handed over their information, and seeing your own name on the next email reads as confirmation that the signup went through.
Try the same trick in a promotional email and it reads as spam. In a welcome, it fits.
The body leans even more developer-specific. A three-step checklist (Configure, Install, Become your first user) runs down the page, and each step references actual React component names like <SignIn />.
That's a small choice with a real effect. A developer reading a welcome email is usually already in front of an editor. A component name inside the email is something they can copy and paste. Without it, the next step is a docs lookup. Clerk saves that lookup.
The Discord invite is the third detail. Most SaaS products push the community invite to email #2 or #3. Clerk puts it in the welcome itself. For developer-facing products, joining the community isn't networking. It's a retention signal. Users who join Discord once tend to stick around.
All three choices share a common logic: each one only works because the welcome is a one-time moment.
The name in the subject is fine because it follows directly from the user's signup. A line of code in the body is useful because the developer is at an editor. A Discord invite that reads as retention here would read as noise in a re-engagement email three months later.
The catch is that this combination only works for self-serve developers. For a non-technical audience, the same three-step checklist becomes stress instead of guidance, and the Discord invite is a link no one clicks.
3. Linear: when a welcome is allowed to be short
Linear is an issue tracker for software teams. Its positioning is "the tool for teams who care about design and speed," and most users sign up for that aesthetic. The welcome email mirrors the product.
The first thing you notice is the length. There's barely anything to scroll. No greeting, no name.
The opening line is "At Linear, we believe software can feel magical." That's not a product description. It's a manifesto. Three links follow (Linear Method, Linear Guide, Linear Changelog), and the CTA is the lightest possible version: Open Linear. Not "create your first project." Not "set things up." Just "open it."
Linear can get away with this because the product does the welcome email's job in-app. Open the dashboard and you land in a workspace pre-populated with sample issues. Press any shortcut and the product explains itself. The email doesn't have to do the explaining because the product already does it.
This is also the version of welcome that gets mis-copied the most often.
A Linear-style minimalist welcome reads as smug in most products. "At {Product}, we believe software can feel magical." From an unknown brand, the reader's first reaction is "...okay?" Linear can pull that line because the product has earned it. If your product hasn't, skip the manifesto and start with what the thing actually does.
4. Slack: the welcome email is the invite link
Slack's welcome isn't an email to an individual user. It goes to the person who just created a workspace, the team admin. And what Slack wants this email to accomplish is unambiguous: get teammates invited.
Every element is built around that goal. The subject line uses the workspace name instead of the recipient's. The account card at the top puts the workspace name and domain front and center. The email speaks to a team, not to one person.
Then the invite URL is exposed in copy-pasteable form mid-email. Slack knows the admin is going to copy that link and paste it wherever the team actually communicates: a Notion page, a DM, a group chat. Real teams don't get invited through buttons. They get invited through links pasted into the messaging tool the team already uses. The welcome accepts that and puts the link where the admin doesn't have to look for it.
The detail underneath all of this: Slack's internal definition of activation is baked directly into the welcome.
Activation, for Slack, isn't "tried the product once." It's "invited at least one coworker." The welcome is engineered to make that one action as cheap as possible.
This is the question every welcome should answer. What does your product count as activation, and how much distance does the welcome remove from that action?
5. Apollo: when the checklist does the pitch
Apollo is a B2B sales-intelligence product. Sales teams use it to find leads and run outreach. The product bundles several tools, so the welcome has to fit several pieces into a single page.
The first thing to notice is the checklist's structure. The four steps (Find leads, Connect mailbox, Install Chrome extension, Run a sequence) are independent. Skipping step two doesn't block step three. A new user can do step one and close the tab. A motivated user can knock all four out at once. Nothing is forced into a strict order.
The primary CTA appears twice with the same copy and the same URL. Find my first leads sits above the checklist and again below. The reason: a reader who has scrolled to the bottom of a long email doesn't have to scroll back up. It's a familiar tactic, but most welcome emails don't bother.
A subtler observation: each checklist step is doing two jobs at once. It's a feature introduction, and it's a switching-cost plant.
Once a Chrome extension is installed, the cost of uninstalling it is friction. Once a mailbox is connected, the product has a foothold in the user's daily workflow. The welcome isn't asking the user to "try the product." It's asking the user to let the product wedge itself into the tools they already open.
At the bottom is an invite to a live webinar. Self-serve has a ceiling in every complex SaaS, and Apollo doesn't pretend otherwise. The welcome hands the reader a path where a human takes over. It drops the pressure of "the email has to do everything" and redefines onboarding as a longer journey.
The thread connecting all four choices is the same: don't make the welcome feel like a mandate, especially when the product is complex.
Independent checklist steps protect against the user who can only do step one today. A repeated CTA protects against scrolling fatigue. A webinar at the bottom protects against the user who has hit the limits of self-serve. The more complex the product, the more this kind of honesty earns trust.
6. Superhuman: why this welcome is allowed to be this long
Superhuman's welcome runs long. The body spans three sections, and in the middle there's an upsell to the $12/month Pro plan. Putting an upsell in the first email is the opposite of the usual advice.
Superhuman has a specific reason for the length. The product is a bundle.
What the user actually signed up for isn't a single app but a set of three AI tools (Superhuman Go, Grammarly, Coda), each usable on its own. A welcome that introduces just one of them leaves the other two invisible. The user ends up missing the entire point of the bundle.
The price disclosure follows the same logic. Superhuman positions itself at a premium price point intentionally. "This isn't cheap" is part of the brand. There's no reason to hide the number, and showing it early is more honest than letting the user discover it three steps in.
The trap is reading this welcome as "what a polished welcome should look like." It's not.
The email is long because there are three products to introduce, not because someone put in extra effort. A single-product welcome that copies this length will lose most readers before the bottom.
Welcome email length isn't a measure of polish. It maps to the number of entry points the product has to explain. Superhuman has three, so it needs three sections. A single-product app needs one. Stretching the email past that backfires.
7. Manus: selling a category that doesn't have a name yet
Manus is an AI agent platform. The product takes an instruction and actually executes it, sitting somewhere between a chatbot and an automation tool. The category itself isn't widely recognized. Users aren't showing up already knowing what an "AI agent" is, so the product has to explain what it does before anything else.
The welcome takes that challenge head-on. The opening paragraph follows a textbook sales-copy structure: Problem, Agitate, Solution.
It names the pain first: "Most AI tools are like that colleague who's great at brainstorming but never follows through." It then twists the knife. And it slots Manus in: "Manus is different. Think of it as an AI tool that finally executes your ideas."
This structure works for selling a new category. A product description only lands once the reader has a frame for why the product matters in the first place.
The other unusual move is in the footer, which explains the brand name's etymology. "Manus, derived from the Latin word for 'hand', is a general AI agent that turns your thoughts into actions."
That single line ties the brand name to the product value, and it gives the reader a reason to remember the word "Manus." Baking a message into the name itself is a classic technique for a new brand. It's often underrated.
The lesson from Manus: if your category is unfamiliar, write the welcome as a category explanation rather than a feature introduction. You can borrow the PAS frame directly the way Manus did, or write a single paragraph on why the product exists before getting to features.
Applying PAS directly to an already-known category (CRMs, email tools, project management) almost always reads as overblown. "Most CRMs are broken. We're different." sounds like spam to anyone who has seen the same opening from twenty other vendors. PAS only works when the category itself is genuinely unfamiliar.
Three patterns that show up over and over
Seven different choices, but the same three principles keep surfacing when you place them side by side.
First, a single CTA is the default. Supabase and Linear bet everything on one button. Even Clerk and Apollo, which use checklists, are organized so the most important first action sits at the top. List too many things to do, and most readers do nothing.
Second, save the reader a click. Clerk puts component names directly in the body. Slack exposes the invite URL as plain text. Apollo pulls specifics into the email instead of pushing the user toward docs. The fewer times a user has to leave the email to find something, the higher activation tends to be.
Third, the welcome reflects the product's real definition of activation. For Slack, activation is "invite a teammate." For Apollo, it's "run a sequence." For Linear, it's "open the app." The welcome makes that one action as low-friction as possible. The implication is straightforward. You can't design a good welcome email until you're clear on what activation actually means for your product.
The piece most welcome emails leave behind
If the welcome did its job, the user is already inside the product. That's where a different question begins. How do you keep tracking the users who made it in?
Break down what happens after a welcome lands and you get four cohorts:
Users who never open the email
Users who open but don't click
Users who click and land in the dashboard but never take a first action
Users who click and complete a first action (the success case)
Knowing whether a welcome actually drives activation means watching the back half of that funnel. Especially the third bucket, "clicked but not yet activated," and following how that cohort moves over time.
PostAuth is a tool built for that follow-through. It tracks every user, including those who arrived through a welcome email, on a stage board. You can see which stage each user is at, which ones are cooling off, and which ones come back.