An onboarding agent is only as good as the agenda you give it, and the agenda is only as good as its milestones. Milestone design is where onboarding strategy actually lives: choosing the few states that genuinely predict a retained account, sequencing them, and defining how each is confirmed rather than assumed.
What makes a milestone real?
Three tests. Predictive: retained accounts hit it early and churned accounts didn't, derive candidates from your own cohort data, working backward from retention, not forward from your feature list. Observable: it's a state the agent can verify on the account, integration live, first real workflow completed on the user's own data, teammates active, not a feeling. Causal-ish: reaching it plausibly creates value rather than merely correlating with motivated users (the classic trap: "visited five times" predicts retention because motivated users do both; making someone visit five times creates nothing). Most products end up with three to five real milestones. More than that and you've written a feature checklist wearing a milestone costume.
How do milestones become an agenda?
Sequence by dependency and energy. Dependency: what technically unlocks what, the data source before the report, the roles before the team invite. Energy: front-load one visible win into the first session, because early proof buys patience for the duller configuration ahead, and spread the rest across short sessions over days, matched to real attention spans. Attach to each milestone its confirmation ("run one report on your own data, together") and its fallback (what the agent does when the account stalls before it, wait, nudge, or escalate, decided in advance, not improvised). That, in total, is the agenda: milestones, sequence, confirmations, fallbacks.
Why confirmation beats inference
Analytics-inferred activation is a guess about comprehension: the event fired, but did the user understand what happened, and could they do it again? An agent that works the milestone with the user witnesses it, performed, on real data, with questions answered along the way, and the difference shows up two ways: the activation metric stops flattering (no more milestone-shaped accidents), and the completion state per account becomes an early-warning system CS can act on ("stalled before milestone two, day four" beats any login-frequency heuristic).
Iterating the agenda
Milestone design is a quarterly loop, not a launch decision: read where covered accounts stall, which questions cluster at which milestone, and which "activated" accounts still churned, that last group means your milestones are measuring the wrong thing. Prune ruthlessly; every milestone that doesn't predict retention is stealing session time from one that does. (Disclosure: agenda-driven milestones are the spine of Skippr's onboarding agent; the design discipline above is yours to keep regardless.)
Questions buyers actually ask
How many milestones should onboarding have?
Usually three to five real ones. If your list is longer, some entries are tasks, sequence them under milestones rather than promoting them.
Should milestones differ by segment?
Yes, an admin's milestones aren't an end user's, and a small team's aren't an enterprise's. Segment the agenda wherever the retention math differs.
What confirms a milestone?
Observed performance on the account's own data, not an event log alone. If the agent can't verify it, redesign the milestone until it can.
Watch it onboard someone
Onboarding either happens on the user's own screen or it does not happen. Fifteen minutes is enough to see which one you are buying.