How should you track onboarding milestones?

Last updated 19 August 2026

Track a handful of milestones defined by customer outcomes rather than internal steps, and record when each one moved rather than only whether it is done. A milestone that has not moved in two weeks is the signal worth acting on, and completion percentages are structurally incapable of showing it.

What makes a milestone worth tracking?

Three properties. It is observable — someone outside the project could confirm it without asking. It is the customer’s — it describes something true for them, not an internal step completed. And it is load-bearing — reaching it unlocks the next phase, so its absence explains why everything after it is waiting.

Most plans fail the second test. “Configuration complete”, “training delivered” and “kickoff held” are all things you did, and a customer reading them learns nothing about whether they are closer to the outcome they bought.

Why is completion a poor measure of progress?

Because completion only moves one way, and stalls do not register in it at all. A plan that finished 60% of its work in the first fortnight and has done nothing since reports 60% every day, indefinitely. The number is reassuring and the project is dead.

Recording when each milestone last moved fixes this at no extra cost, because the data already exists — something either changed today or it did not. Sorting a portfolio by time-since-movement produces a working list of exactly the accounts that need attention, which is not something a completion percentage can ever generate.

How should milestone states be defined?

State	Means	Whose move
Not started	Nothing has begun, and nothing is preventing it	Yours
In progress	Someone is actively working on it now	Yours
Blocked	Work cannot continue until a named person does something	Theirs, or a third party
Done	Observably true, confirmable without asking	—

The distinction that earns its keep is blocked versus not started. Collapsing them is the most common modelling mistake in onboarding tracking, and it hides the entire category of delay that actually causes slips.

Should the customer see the same plan?

Yes, and it changes the dynamic more than it changes the reporting. When the plan is shared, a blocked milestone with the customer’s name against it is visible to their own stakeholders, and it gets escalated by someone with standing to escalate it.

It also removes the weekly status email as a separate obligation. That email is the first thing dropped in a busy week, and a busy week is exactly when a project is most likely to be stalling.

What should you review across all accounts?

One list: every milestone that is blocked or has not moved in two weeks, with the account, the owner and the reason. It should be short. If it is long, the problem is not tracking — it is that too much is in flight for the size of the team, which is a capacity conversation rather than a process one.

Common questions

How many milestones should an onboarding plan have?

Few enough to hold in your head — commonly four to seven. Past that they stop being milestones and become a task list, and the value of a milestone is precisely that it is coarse enough for an executive to read without explanation.

What makes a good milestone?

It is observable, it belongs to the customer, and reaching it changes what is possible next. "Kickoff held" fails the third test; "first team using it in live work" passes all three, because nobody can fake it and everything downstream depends on it.

Should milestones have dates?

Target dates, yes; committed dates, only for the ones you control. Attaching a hard date to a milestone that depends on the customer’s security team creates a number everyone knows is fictional, and one fictional date discredits the rest of the plan.

How do you handle a milestone that is blocked?

Give it a state of its own rather than leaving it "in progress". Blocked and not-started look identical in most tools and mean opposite things — one needs a nudge to a third party, the other needs someone on your team to begin.

Who should see the milestone plan?

Both sides, in the same view. A plan the customer cannot see makes you the sole reporter of progress, which means every status update is a task you own and a chance for the wait on their side to stay invisible.