SnDSentNDeliveredStart an inquiry

Every new signup gets the same emails on the same schedule.

We plan and build onboarding in your email or messaging tool so it reacts to what people do in the product. If someone finishes setup early, the reminders stop. If they get stuck, the next message can focus on the step they are actually stuck on instead of whatever was scheduled for day three.

Start an inquirySee an onboarding example

Set up

Turn an undefined customer moment into a working path

Build

The customer journey exists in your product, but not in the messaging yet.

Set up starts by turning the pieces you already have into a path with explicit decisions, exits, and measurement.

Customer success onboards the big accounts by hand. Everyone else gets a welcome email.

which parts of what your CS team does could reach every new account, and which parts should stay with a person.

Nobody has agreed on what “activated” means.

the first thing new customers do that tells you they are likely to stick around, and whether your tools can see it.

The product knows what happened. The email tool doesn’t.

which product signals the messaging needs and where those signals need to go.

After the welcome email, it’s up to whoever remembers to follow up.

the smallest useful path from signup to the next customer action the onboarding should support.

Already have onboarding running but it’s messy, overlapping or hard to trust? See Fix.

A first version your team can explain and keep using.

What’s included depends on what we agree to take on. A Set up project can include:

  • The customer behavior the onboarding is built around
  • The product signals or fields the messaging needs
  • Lifecycle messages when copy is included
  • A measurement plan
  • Notes on how it works, so your team can change it later

Decision rule

Example logic

IF account created

AND first shared task incomplete

THEN continue onboarding

UNTIL first shared task is complete

Start with the customer action, then build the automation around it.

  1. 01

    Pick the behavior the onboarding is for

    For onboarding, that might be finishing setup, publishing something, inviting a teammate, connecting an integration or using the feature that makes the product valuable.

    We agree on the behavior and how we will judge it first, so the automation has a job beyond “send the next email.”
  2. 02

    Check whether the messaging tool can see what it needs

    We identify the customer actions, account fields, client-approved consent rules and exclusions the journey depends on.

    If an important signal is missing, we spell out what needs to reach the email or messaging tool before building around a guess.

  3. 03

    Build the path

    We build the agreed entry rules, branches, timing, messages, exits and suppressions in the platform.

    If lifecycle-message writing is part of the project, we write those messages. Newsletters and broader brand copy aren’t part of it unless separately agreed.
  4. 04

    Test the paths customers can actually take

    We check what happens when someone progresses early, gets stuck, should be left out, reaches the goal or comes back through the journey later.

What we need from your team

  • Access to the systems in scope
  • Available product or customer signals
  • Existing lifecycle assets that matter to the path
  • Someone who can approve the decisions

What we own in the engagement

  • Lifecycle logic and recommendation
  • Implementation inside the agreed scope
  • QA of the paths we change
  • Documentation and handoff

We won’t hide a product-engineering project inside an automation project.

Automation can only react to what it can see. If your product knows someone finished setup but your email tool never hears about it, nothing downstream can respond. We’ll spell out exactly what needs to get there and work with your developer on it.

No developer time right now? Tell us early. We can start by looking at what your tools can already see and whether a useful first version is possible without new engineering work.

The goal happens in the product, not the inbox.

If the onboarding exists to help more new accounts finish setup, reach first value or use an important feature, that is what we should measure. Opens and clicks can help explain what happened, but they are not the customer outcome.

Stop the welcome series once the work is done.

See how a behavior-based onboarding path can stop reminders when the customer reaches the goal on their own.

See the onboarding example

Not sure what should happen after signup?

Tell us what customers get today and where they tend to get stuck. We’ll write back with what we’d look at first.

Start an inquiry