Most onboarding plans are long task lists. Dozens of steps, a kickoff deck and a project tracker that turns green one row at a time. The trouble is that a task list tells you what has been done, not whether the customer is getting closer to value. An account can tick off twenty tasks and still be weeks away from using the product for real work.
A better approach is to track a handful of checkpoints that actually predict time to value. Quivly's Onboarding at Scale page uses a default journey with five milestones: workspace provisioned, core integration live, first value event, team trained and health review. This post takes each one in turn and covers what it means, the exit criteria, who owns it, the signals that it is slipping and what to do when it does. If you want to measure the overall result, pair this with our guide on how to measure time to value.
Why Milestones Beat Task Lists
A milestone is a change in the customer's state, not a piece of work your team completed. "Sent the SSO setup guide" is a task. "The customer's users can log in through SSO" is a milestone. The difference matters because only the second one tells you the account has moved forward.
Good onboarding milestones share four traits:
- They are observable. You can confirm them from product, integration or CRM data rather than from someone's memory of a call.
- They have exit criteria. Everyone agrees in advance what "done" looks like, so there is no debate about whether a milestone is complete.
- They have one owner. Several people may contribute, but one person is accountable for moving the account through each checkpoint.
- They have an expected timing. Without a target window, you can't tell the difference between an account that is on pace and one that is stuck.
Quivly describes this as an onboarding blueprint: the milestones, the sequence and the expected timing, defined up front. Every new account is tracked against it, and deviations are flagged as they happen.
Checkpoint 1: Workspace Provisioned
The first checkpoint is simple to describe and surprisingly easy to stall on. The customer's environment exists, the right people have access and the account is configured for how they plan to use it.
Exit criteria
- The workspace or tenant is created and configured for the customer's plan and use case.
- Authentication is set up, including SSO where the customer requires it.
- The admin and the first set of users have been invited and have logged in at least once.
Owner: usually the onboarding manager or CSM, with the customer's IT admin as the key contact.
Signals it's slipping: invitations sent but not accepted, only the champion has logged in, or SSO configuration is waiting on someone in the customer's IT team.
What to do: most provisioning stalls are about people, not technology. Identify who on the customer side owns access and reach them directly. Quivly tracks engagement at the contact level, not just the account level, so it can detect when a stakeholder such as the IT admin hasn't been activated and trigger outreach to that person specifically.
Checkpoint 2: Core Integration Live
For most B2B products, value depends on data flowing in from the customer's own systems. This checkpoint is reached when the integration that matters most is not just configured but running in production.
Exit criteria
- The core integration is connected with production credentials, not a test account.
- Data is arriving on schedule and the customer has confirmed it looks right.
- Any field mappings or custom configuration are documented.
Owner: a solutions engineer, implementation lead or forward-deployed engineer, with the CSM kept informed.
Signals it's slipping: the integration was started but never completed, data stopped arriving after an initial sync, or the customer is waiting on an internal security review.
What to do: separate simple stalls from technical blockers. If the customer simply hasn't connected the integration, a short guided email with step-by-step instructions is often enough. If something is actually broken, route it to a technical owner quickly with full context. Quivly's onboarding page describes both paths: personalised guidance for common issues and integration troubleshooting workflows that loop in technical resources fast. For more on running the technical side of a rollout, see our implementation-to-adoption handoff playbook.
Checkpoint 3: First Value Event
This is the checkpoint that matters most, and the one most often left vague. The first value event is the first time the customer gets a result they bought the product for. It is product-specific, so you have to define it yourself.
How to define it
- Start from the purchase reason. What did the customer say they needed during the sales process? The first value event should be the first concrete instance of that outcome.
- Make it an event, not a feeling. Pick something your product records, such as a first report shared, a first workflow run or a first automated action completed.
- Keep it small. The first value event is not full adoption. It is proof that the product works for this customer.
Exit criteria
The defined event has happened in production, triggered by the customer's own users, using their own data.
Owner: the CSM or onboarding manager.
Signals it's slipping: integrations are live but nobody has done anything with the data, activity is limited to your own team running demos inside the customer's workspace, or the champion is the only active user.
What to do: move from instruction to hands-on help. Offer a working session where the customer completes the first value event with you, using their own data. If you track time to value, this is usually the event that marks the end of the clock. Our guide to measuring time to value covers how to choose the start and end events consistently.
Checkpoint 4: Team Trained
One person reaching value is a good start. Adoption depends on the wider team. This checkpoint is reached when the people expected to use the product have been enabled and have started using it on their own.
Exit criteria
- Training sessions have been completed for each team or role in scope.
- A meaningful share of invited users are active after training, not just during it. Agree on the target with the customer.
- Power users or internal champions have been identified for ongoing questions.
Owner: the CSM, often with help from an enablement or training lead.
Signals it's slipping: training was attended but logins dropped off afterwards, entire teams have never logged in, or usage is concentrated in one department when the deal assumed several.
What to do: look at who is missing rather than at overall usage. A team that has never logged in needs a different response from a team that logged in once and stopped. Targeted in-app messages or short role-specific sessions usually work better than repeating the full training. For enterprise accounts, check that each key stakeholder group, such as power users and the executive sponsor, is actually engaged.
Checkpoint 5: Health Review
The final checkpoint closes the onboarding phase formally. It is a structured review, with the customer, of where the account stands against the goals agreed at the start.
Exit criteria
- The account has been reviewed against the success metrics agreed during kickoff.
- Open risks and gaps are documented with owners.
- The next set of goals is agreed, moving the account from onboarding into ongoing adoption.
Owner: the CSM, with the customer's champion and ideally the executive sponsor.
Signals it's slipping: the review keeps getting rescheduled, the sponsor declines the invite, or there is no agreed set of success metrics to review against.
What to do: treat a review that won't get scheduled as a risk signal in its own right. Bring data rather than opinions, covering which milestones were hit, when, and what usage looks like now. A health review that ends with clear next goals is the cleanest possible handoff from onboarding to the rest of the customer lifecycle.
How to Catch Slipping Milestones Early
Defining the five checkpoints is the easy part. The harder part is noticing when an account falls behind while there is still time to fix it. A few practices help:
- Set time thresholds per milestone. Decide how long an account can sit at each checkpoint before it counts as stuck. Quivly supports stuck-account detection with configurable time thresholds.
- Watch velocity, not just status. An account moving slowly through early milestones is a risk even if nothing is technically overdue. Quivly scores new accounts for risk based on activation velocity.
- Use different blueprints for different segments. An SMB account and an enterprise rollout should not share timings. Quivly lets teams define separate blueprints by segment, product line or use case, and assigns new accounts to the right track automatically.
- Match the intervention to the milestone. A provisioning stall needs a nudge to the right person. An integration failure needs a technical owner. Quivly triggers the configured intervention for each milestone, whether that's an automated email, a CSM task with context or a route to a solutions engineer.
- Revisit the blueprint. Your first version will be wrong in places. Quivly notes that most teams refine their blueprint over the first 60 days as they see where accounts commonly stall.
Quivly's onboarding page reports that teams using it see 40% faster time to first value, a 55% reduction in onboarding drop-off and a 30-day average reduction in time to activation. The common thread is tracking milestones against a defined blueprint instead of waiting for someone to notice a stall.
FAQ
Fewer than you think. Five well-defined checkpoints with clear exit criteria are more useful than a long list of tasks. You can still keep a detailed task plan underneath, but report progress against the milestones.
A task is work your team completes, such as sending a guide or running a session. A milestone is a change in the customer's state that you can observe, such as users logging in or data arriving from an integration.
The first value event, because it is the point where the customer gets the outcome they bought. The earlier checkpoints are prerequisites for it, and the later ones turn it into broader adoption.
The checkpoints can be the same, but the timings, owners and exit criteria usually differ. Enterprise rollouts often involve more stakeholders and security steps, so they need longer windows and contact-level tracking. Want to see where your new accounts are stalling right now? Learn how Quivly's Onboarding at Scale tracks every account against your milestones and triggers the right intervention the moment one falls behind.
