A new user signed up three days ago. They haven’t touched the product since. No error. No complaint. Just silence.
This is the onboarding drop-off problem, and it doesn’t solve itself with a better welcome email. It solves when the workflow behind onboarding is designed to move people forward, automatically, based on what they actually do.
This guide documents onboarding workflow examples across five product types, then covers the mechanics of building a workflow, the mistakes that kill conversion, and how AI changes what’s possible. Use it as a reference, not a template. Your users, your product, your workflow.
Hyper is an AI onboarding agent for SaaS that does 1-on-1 screen-sharing calls with users, seeing their screen, controlling their browser, and guiding them via real-time voice. We study onboarding systems extensively, and these examples draw on that analysis.
What an Onboarding Workflow Is
An onboarding workflow is a structured sequence of steps, triggers, and actions designed to move a new user from signup to a defined outcome. The outcome varies by product: first project created, first report generated, first teammate invited. But the structure is consistent.
Every onboarding workflow has three components:
Triggers: Events or conditions that start a step. Triggers can be time-based (user signed up 24 hours ago), event-based (user completed account setup), or behavioral (user hasn’t logged in for 3 days).
Actions: What happens when a trigger fires. Sending an email, showing an in-app message, unlocking a feature, assigning a Customer Success task, or initiating a live onboarding session.
Conditions: Logic that routes users to different paths. A user who works in healthcare gets a different setup checklist than a user who works in e-commerce. A user who has already completed step 3 skips the email prompting them to complete it.
An onboarding workflow is different from an onboarding checklist. A checklist is a static list. A workflow is a system with logic. Checklists show users what to do. Workflows respond to whether they did it.
For a deeper overview of the onboarding structure underneath these workflows, see SaaS user onboarding.
Five Onboarding Workflow Examples
1. Self-Serve SaaS (No Sales Touch)
Context: A product management tool. $49-$299/month. Users sign up, configure on their own, and pay without speaking to anyone.
The workflow:
- Day 0, on signup: Welcome email with one action. Not “explore the app.” One specific thing: “Create your first project.” In-app empty state with a single CTA pointing toward the same action.
- Day 0, action completed: User creates first project. Trigger fires. In-app tooltip sequence introduces task creation. A follow-up email that evening: “Add your first task or invite a teammate. Either one.” Two options because two different users define value differently.
- Day 1, no action: User signed up but hasn’t created a project. Email: three sentences. Restates the value proposition. One link back to the product.
- Day 3, no login: User hasn’t returned. Short email. No pressure, no list of features. One line: what they were trying to do. One line: the specific thing they haven’t done yet.
- Day 7, activated: User has created a project, added tasks, logged in three or more times. Email introduces a secondary feature. The primary onboarding is complete.
- Day 7, not activated: User hasn’t reached the activation milestone. Email offers two things: a link to a 10-minute walkthrough video, and a “talk to us” link. Soft human handoff.
What makes this work: The workflow differentiates between users who act and users who don’t. It doesn’t send everyone the same sequence on the same schedule. Activated users get expansion prompts. Stuck users get help.
2. Enterprise SaaS (Sales-Assisted)
Context: A revenue intelligence platform. $50,000+ ACV. A sales engineer is involved. Implementation spans 30-90 days.
The workflow:
- Day 0, contract signed: Automated welcome email to all stakeholders, with personalized onboarding timelines per role. CRM updated with an onboarding stage record. Internal kickoff task assigned.
- Week 1: Kickoff call. Customer Success team presents a joint success plan: what does “successful onboarding” mean for this account specifically? Milestones documented and shared.
- Week 2-3: Technical setup. Data source connections, permission configuration, user provisioning. Each step tracked in the platform. Trigger: if any setup step is incomplete after 5 business days, an automated flag surfaces to the Customer Success manager.
- Week 4: First value milestone. The customer runs their first analysis or generates their first report. If this milestone isn’t hit by day 28, an escalation task is created automatically.
- Week 6-8: Secondary onboarding. Training sessions for end users who weren’t in the initial setup calls. Role-based workflows introduced.
- Day 60: Health check. Automated survey to stakeholders. Score below threshold triggers a Customer Success review.
What makes this work: Human attention is allocated by signal, not by schedule. Automation surfaces the right accounts at the right time. The Customer Success manager spends time on accounts that need it, not on accounts that are progressing on their own.
3. Freemium (Free Tier to Paid Conversion)
Context: A design collaboration tool. Free plan available. Paid plans at $12-$45/user/month. Conversion from free to paid is the primary onboarding goal.
The workflow:
- Day 0, signup: Welcome email with one goal: create something. Not “explore the features.” Not “read the docs.” Something they can share with someone else, because sharing creates a network effect and exposes the paywall organically.
- Day 1-3: In-app prompts tied to feature usage. When a free user tries to use a paid feature, the upgrade prompt is contextual: “You’re trying to do X. That’s a Pro feature. Upgrade to unlock it.” The moment of friction is the moment of conversion intent.
- Day 7: Email. No feature list. One specific thing the user has done in the product. “You’ve created 4 designs this week.” One sentence about what they could do on the paid plan.
- Day 14, free user: Usage-based trigger. If the user has been active (3+ sessions per week), they’re offered a 14-day trial of the paid plan with no credit card required.
- Day 14, inactive user: If they haven’t logged in for 7 days, a re-engagement email with a specific example of something they built. One question: “Are you still trying to solve [original use case]?”
- End of trial: Three emails over the final 4 days of the trial. First: what they’ve done during the trial. Second: what they’d lose on downgrade. Third (day of expiry): upgrade CTA with urgency, no discounts.
What makes this work: The free-to-paid conversion doesn’t happen through persuasion. It happens by engineering the moment when the user hits a wall doing something they already want to do.
4. Trial-Based SaaS (Time-Limited Trial)
Context: A customer data platform. 14-day free trial, no credit card required. Conversion is the entire game.
- Day 0: Welcome email with a trial countdown visible in the header. Not intimidating. Informational. The user knows where they stand.
- Day 0-1: Onboarding checklist. 5 items maximum. Each one moves the user toward their first report. Progress is visible. Completion unlocks something small (a template, a saved view, a dashboard).
- Day 3: Behavioral check. Users who have completed 3+ checklist items get an email encouraging them to connect a second data source. Users who have completed 0-1 items get an email asking one question: “What’s getting in the way?”
- Day 7 (halfway): Email with a concrete data point from their trial. “You’ve connected 2 data sources and built 1 dashboard.” If they haven’t connected a data source yet: “Day 7. You have 7 days left. The fastest path to seeing value is connecting your first data source. It takes 4 minutes.”
- Day 11: Upgrade prompt. Not aggressive. “You have 3 days left. If you’d like to keep your dashboards and connected sources, here’s how to upgrade.” Make the cost of not converting concrete.
- Day 14: Trial expiry. One email. Short. The data they’ll lose if they don’t upgrade. One button.
What makes this work: Every communication is anchored in the user’s actual activity. Generic emails at fixed intervals treat all users the same. This workflow differentiates based on what users have done and what they haven’t.
5. Team-Based SaaS (Multi-User Accounts)
Context: A project collaboration platform. Pricing by seat. The buyer signs up, but value is delivered only when teammates join.
The workflow:
- Day 0, admin signup: Welcome email with one goal: invite at least two teammates. Value is explicit: “This product is more useful with your team. Invitations take 30 seconds.”
- Day 0, in-app: Invite prompt is the first screen after account creation. Not buried in settings. Not optional-feeling. Prominent, with a pre-filled email form.
- Day 1, no invitations sent: Email to admin: “You haven’t invited anyone yet. Most teams invite 3-5 people in the first 24 hours. Here’s a one-click invite link you can paste into Slack.”
- Day 0, teammate joins: Email to the new team member. Separate from the admin flow. Shorter. Contextual: “Your colleague invited you. Here’s what they’ve set up. Here’s what you can do next.”
- Day 3, team active: If 3+ users are active, send an email to admin with a summary of team activity and a prompt to set up a shared workspace or project template.
- Day 3, low team engagement: If only 1 user is active, email to admin: “Your team hasn’t fully joined yet. Here’s a template for announcing the rollout internally.” Give them a tool to solve the problem.
- Day 14, admin active, low team adoption: Flag for human follow-up. Low team adoption at day 14 is the strongest predictor of churn in team-based products. The workflow creates a task for review.
What makes this work: The single-user and multi-user paths are treated separately. Onboarding a team is a different problem from onboarding an individual. The workflow accounts for that.
Building Your Workflow: The Core Decisions
Before writing any triggers or actions, three decisions determine the shape of your workflow.
What is the activation milestone? Every workflow needs a north star: the specific action that means “this user is on track.” For the examples above it’s “first project created,” “first report generated,” “team member joined.” Define yours precisely. Not “used the product.” The one thing.
How do you segment early? Role, use case, company size, and referral source all predict which path a user should take. The more personalized the path, the higher the activation rate. Collect the minimum data at signup to enable meaningful segmentation.
What is the failure mode you’re designing around? For self-serve: user never comes back after day 1. For enterprise: implementation stalls at technical setup. For freemium: user stays on free indefinitely. For trial-based: trial expires before the user reaches value. For team-based: admin activates but team doesn’t. Build the workflow around preventing your specific failure mode.
Common Workflow Mistakes
Treating all users as one cohort. A user who has completed 80% of setup and a user who hasn’t logged in since signup are in different situations. Sending them the same email on the same day is a mistake. Segment by behavior, not just by time elapsed.
Too many steps before first value. Every extra step in the path to first value reduces the number of users who reach it. A user who has to complete 8 steps before seeing the product deliver anything is going to drop off. Ruthlessly cut anything that doesn’t directly contribute to the activation milestone.
Drip sequences that ignore behavior. An email sequence timed to day 1, day 3, day 5, day 7 is better than nothing. But it’s also sending day 5 emails to users who activated on day 1 and day 1 emails to users who are genuinely confused and need something different. Behavioral triggers replace scheduled sequences in any workflow that’s serious about conversion.
No definition of “stuck.” What does it mean for a user to be stuck? No login in 48 hours? Completed setup but hasn’t run a report? The workflow needs a definition and an action attached to it. “Stuck” without a response is just data.
Onboarding ends at activation. A user who activates and then plateaus is not a retained user. The workflow should continue into secondary onboarding, introducing the next feature or workflow after the first activation milestone is hit. See sample onboarding process for a fuller structure.
Adding AI to Your Workflow
The five examples above all involve static interactions: emails, in-app messages, tooltips. They can be improved significantly by injecting an AI onboarding step at the moment when users are most likely to get stuck.
The pattern: when a user triggers a “stuck” signal (no activation at day 3, incomplete setup at day 7, low trial engagement at the midpoint), the workflow initiates a live onboarding session rather than sending another email.
Hyper joins the user in a 1-on-1 screen-sharing call: seeing their screen, taking control of the browser to demonstrate next steps, and walking them through the product via real-time voice. No scheduling. No waiting for a Customer Success manager to be available. The AI session fires when the signal fires, at any hour, in any language.
What this changes in practice: the “human handoff” step in most workflows is constrained by headcount and availability. A Customer Success team can handle a limited number of sessions per day. AI removes that constraint. Every user who hits the stuck trigger gets a session. Every trial that’s about to expire gets a walkthrough. Every enterprise account that’s stalling at technical setup gets support.
The onboarding checklist is the mechanical layer. The AI session is the intervention when the mechanical layer isn’t enough.
The Workflow Is Only as Good as What Happens When It Fails
Most onboarding workflows are optimized for the happy path. User signs up, completes setup, activates, continues using the product. The happy path is not where you lose users.
You lose users at the gaps. The user who starts setup and stops at step 3. The trial user who logs in twice and goes quiet. The enterprise account whose implementation stalled because one integration wasn’t working and nobody followed up.
The workflow’s job is to make those gaps visible and do something about them automatically. Every stuck signal needs a response. Every failure mode needs an action attached to it.
If you’re building this system and want to understand what AI can add to the intervention layer, talk to Hyper. We’ll show you what a live onboarding session looks like in practice.
Part of Hyper’s editorial guide to SaaS onboarding. Research covers 46+ tools in the onboarding, adoption, and Customer Success space. March 2026.