Customer Onboarding Plan Template
Four sheets that set the finish line, the clock and the length from the customer's side, then count adoption by named human being.
Free download · No account needed
Value Definition · Kelbrook Distribution · agreed at kickoff
“We know it's working when a depot manager publishes next week's rota on Thursday afternoon without ringing anyone.”
Their words, from the kickoff recording. Every clause below is load-bearing.
| Clause | What it rules out |
|---|---|
| A depot manager | Not their administrator, and not our implementation consultant |
| Without ringing anyone | Not a rota built in a training session, and not one that needed a call to head office |
| Thursday afternoon | Their operating cycle. Rotas go out Thursday so people know their week by Friday |
Two events, two dates
| Our activation event, first rota created | Day 4, by our consultant, in a sandbox |
| Their event, witnessed by D. Farrar | Day 58, by S. Iqbal, unassisted |
| Their own deadline, peak season opens | Day 62 |
Four days of slack. Measured from signature this reads as a four-day onboarding, which is a number nobody should say out loud. Measured against the date they published to their own customers, it is a plan that only just fitted.
Illustrative figures for one fictional workforce scheduling vendor and one of its customers.
Page one has this solved and every part of the answer is set by you. Four phases from pre-kickoff to a thirty sixty ninety review, an owner on every milestone, a defined activation event. Time to first value is measured from contract signature and tracked by cohort, so a slow account cannot hide in an average. It is a good build. Three things in it belong to the customer and get held by the vendor anyway.
The finish line is yours, and your activation event usually happens on day four in a sandbox with your own consultant driving. What the customer would call working is a different event, in their words, with a witness. The clock is yours too. Their date is a real thing in their business, and for a federal customer it is set by statute: the fiscal year ends 30 September whatever your kickoff date was.
And the length is asserted. What decides it is eight customer facts, all knowable in week one. How many systems the data sits in, whether a named admin has time allocated, whether their security review has started, whether the incumbent will release the data. In the UK and EU a customer can require that in a structured, machine-readable format. Each factor costs days you can look up in your own history. Adoption then gets counted by person rather than by account, and the quarterly review inherits something that works.
What's in the pack
Value Definition
The customer's own sentence about what working looks like, taken apart into an observable with a named witness, beside your activation event and its real date.
Readiness Read
Eight customer-side facts asked out loud at kickoff, each with a state, the days it adds, the basis for those days, a mitigation and the side that can act on it.
Onboarding Plan
The length with its arithmetic shown, the comparable onboardings named with their count, the critical path, and what was deliberately moved past the customer's date.
Milestone Tracker
Every milestone carrying a side, a named person and days before the customer's deadline rather than days elapsed since a signature nobody outside your company cares about.
Adoption by Person
One row per human being, with five states that separate never invited from trained and not started from reluctant, because those go to different people.
Onboarding Cohort History
Every past onboarding with its readiness profile, predicted days, actual days, and one sentence on what really cost the time. This is what future plans are derived from.
Readiness Standard
How the eight factors are scored, why a blocker is defined by what stops rather than by how annoying it is, and how to test whether a stated deadline is real.
Escalation Path
Two named people per side per level, agreed at kickoff when nobody is annoyed, with stated triggers instead of somebody's patience running out.
How to use it
- 1
Open in River, or take it blank
Open the pack in River and hand it your handoff and kickoff, or download the Word documents and CSV sheets and fill them in yourself.
- 2
Take the readiness read
Eight questions in the kickoff session. Ask for a name and an allocation rather than a role, and for the date their business actually runs on.
- 3
Derive the length
Base plus each factor's cost from your own history, with the sample stated, then run the plan backwards from the customer's date.
- 4
Count people, not accounts
After first value, check how many humans can do the task alone. One is a state most accounts are in and no account metric shows it.
Frequently asked questions
Is this template free?
Yes. Four Word documents and four CSV sheets, downloaded as a zip, no signup. River is the optional half: it takes the readiness read from your kickoff, derives the length from your history, and writes the value definition. More in the template library and the tool index.
We have no history of past onboardings. Does the length still work?
The read still works and the arithmetic waits. Every factor cost is labelled uncalibrated until you have comparable rows, and the plan says so rather than presenting a guess as a forecast. Eight rough rows from memory, with rough durations, is enough to start deriving instead of asserting.
What if the customer has no deadline of their own?
You record the absence, which is itself the strongest predictor in the sheet. In the worked history two identical customers took nine and thirty-one days to clear the same security review, and the only difference was that one had a real date published to its own customers.
How is this different from the handoff from sales?
The handoff is an input here and this pack never writes one. It carries the deal context, the commitments made on calls and the requirement map. This space starts at kickoff and owns the plan, the finish line and adoption, then hands to the quarterly review.
Why not just use our activation event?
Because it is a thing your product does, chosen by you, and it usually fires on day four in a sandbox with your own consultant driving. Both events are recorded here with both dates. The contrast between them is the most useful line in the document.
Isn't per-person adoption tracking overkill for a B2B account?
It is the difference between activated and safe. One administrator who can do the core task on one day a week reads as green at account level and is one resignation from zero. It also matters at renewal, which is where the risk brief picks it up.
The customer says thirty days. What do we do with a derived fifty-nine?
Show them the components. Eighteen days are their security review and eleven are their data being in three places, and both are things they can change. A total is something to argue about, while a breakdown is something to act on, which is why the plan shows its arithmetic.
Derive the plan instead of declaring it
Take the Word documents and CSV sheets blank, or open this exact pack in River and let it read your kickoff and size the plan first.
Edit with AI