Picture your current onboarding board on a Tuesday morning.
Fourteen items ticked. Two in progress. Nothing red.
And the go-live date just moved for the third time.
How does a checklist show green while a project runs three weeks late? Because the checklist is only tracking half the work. Every item on it is something your team does. The items that are actually holding the project up – the security review nobody started, the data export sitting in someone’s downloads folder, the configuration decision waiting on a person who has been in back-to-back meetings since Thursday – are not on the board at all. They live in a follow-up email.
So here is a complete checklist. Thirty-eight items, six phases, and an owner marked against every single one.
Count the owners when you get to the end. Twenty-five of the thirty-eight items need the customer to do something. Your team cannot finish two thirds of your own onboarding process.
That is not a complaint. It is the design constraint everyone builds around and nobody writes down.
How to read this checklist
Three owner markers:
- You – your team can complete it without the customer lifting a finger.
- Customer – nobody on your side can do this, ever. You can make it easier, faster and harder to forget. You cannot do it.
- Both – it needs a conversation, a decision, or a session with people from both sides in it.
Each item has a “done when” condition, because half the arguments about whether onboarding is on track are actually arguments about what “done” means. “Data migration – in progress” has been true for eleven days.
This is a superset, not a prescription. A self-serve product with a two-day setup will use maybe twelve of these. A regulated enterprise deployment will need all thirty-eight plus a few of its own. Cut what does not apply, but cut it deliberately, and cut it before the project starts rather than in week five when it becomes inconvenient.
If you are designing the underlying process rather than running it, start with our guide to building a customer onboarding process. This checklist assumes the process exists and you want to know what belongs in it.
Phase 0: Before the handoff
The four weeks after the contract is signed are decided in the two weeks before it.
| # | Item | Owner | Done when |
|---|---|---|---|
| 1 | The value milestone is written in one sentence | You | Someone who was not in the sales cycle can read it and know exactly what the customer needs to accomplish |
| 2 | Signed scope and commercial terms are attached to the account | You | The onboarding team can see what was actually sold without asking the AE |
| 3 | Sales handoff note: goals, promises made, known risks | You | It names at least one thing the customer is worried about |
| 4 | An executive sponsor is named on the customer’s side | Both | You have a name, a title and the reason they care |
| 5 | The onboarding start date is agreed | Both | It is in both calendars, not implied by the contract date |
Item 3 is the one that gets skipped and the one that costs the most. A handoff note that only lists what was sold is a copy of the order form. The valuable part is the informal commitments: the integration someone said would “probably be straightforward,” the timeline the buyer promised their own boss, the competitor they nearly picked instead.
If your handoff note has no risks in it, it is not a handoff note. Every deal has something. Ask the AE the question directly: what is the thing that could make this customer unhappy in month two?
Items 1 to 5 are a compressed version of a bigger topic. If this phase is where your projects lose their first two weeks, our guide to the sales-to-onboarding handoff covers the nine fields that need to cross and the twenty-minute meeting that gets them across.
Item 4 matters more than it looks. A project with a named sponsor survives a reorganisation on the customer’s side. A project without one is one calendar invite away from being deprioritised, and you will find out six weeks after it happened.
Phase 1: Prep, before the kickoff
Target: two to three business days. If it regularly takes longer, something is being rebuilt from scratch that should be a template.
| # | Item | Owner | Done when |
|---|---|---|---|
| 6 | Stakeholder map: project owner, decision maker, sponsor, technical contact | You | Four names, not four job titles |
| 7 | Intake form sent | You | It is a form in a shared workspace, not an attachment or a list of questions in an email |
| 8 | Intake form completed | Customer | Every required field answered, including the awkward ones about internal deadlines |
| 9 | Draft plan built and adjusted for this customer | You | It is specific enough that the customer will want to change something in it |
| 10 | Access, credentials and environments requested | You | The request states exactly what you need and who typically provides it |
| 11 | Security, legal or procurement review started, if needed | Customer | A ticket number exists, with a named reviewer |
| 12 | Kickoff scheduled with the right people in the room | Both | The decision maker has accepted, not just the project owner |
Item 8 is your first real signal. How the intake form comes back tells you more about the next eight weeks than anything in the sales cycle did. Returned in two days with thoughtful answers means an engaged project owner. Returned in nine days with three fields filled means you should adjust the plan now, while it is cheap.
Item 11 is the quiet timeline killer. Security review is almost never on the vendor’s checklist because the vendor cannot do it, and it routinely adds three to six weeks. Ask about it in the sales cycle. Put it on the plan on day one. A review that starts in week one runs in parallel with everything else. A review discovered in week four runs alone, with everyone watching.
Item 9 deserves a note on how you show up. Do not arrive at the kickoff with a blank plan and a promise to build it together. Arrive with a real draft, populated with what the intake form told you, and let the customer correct it. People edit far more readily than they create, and a draft they have corrected is a plan they own.
Phase 2: Kickoff
One live session. The customer should leave having changed something about the plan.
| # | Item | Owner | Done when |
|---|---|---|---|
| 13 | The value milestone is confirmed in the customer’s own words | Both | Their sentence and yours describe the same outcome |
| 14 | The plan is reviewed and adjusted live | Both | At least one date or task changed during the call |
| 15 | One named owner per workstream | Both | No workstream is owned by a department |
| 16 | Escalation path agreed on both sides | Both | You know who to call, and they know who to call, before anyone needs to |
| 17 | Go-live date set | Both | It is a specific date, with an agreed rule for how it can move |
| 18 | Absences and capacity crunches in the next eight weeks are named | Customer | Holidays, quarter-end, audits, launches, parental leave |
| 19 | The next three check-ins are booked | Both | Invites are accepted before the call ends |
Item 13 is worth slowing down for. Ask the project owner to describe what success looks like in their own words, and write it down verbatim. When their sentence and your sentence describe different things, you have found a scoping problem in week one instead of week seven. It happens more often than anyone expects, particularly when the person on the kickoff was not the person in the sales cycle.
Item 18 is the highest-value question nobody asks. “Is anyone on your side away, or unusually busy, in the next eight weeks?” It takes fifteen seconds and it routinely surfaces two weeks of hidden timeline. A plan built without it is a plan that will slip for reasons everybody already knew about.
Phase 3: Build
The longest phase, and the one where the ownership split is most lopsided. Six of these nine items depend on the customer.
| # | Item | Owner | Done when |
|---|---|---|---|
| 20 | Technical prerequisites delivered: DNS, SSO metadata, API keys, allowlisting | Customer | Verified working in your environment, not just sent |
| 21 | Data export produced in the agreed format | Customer | The file passes your validation, first attempt or third |
| 22 | Data imported and checked by the customer | Both | The customer has looked at their own records and confirmed they are right |
| 23 | Integrations connected and tested in a real workflow | Both | A real record moved end to end, not a test ping |
| 24 | Configuration decisions made | Customer | Every open decision has an answer, including the ones they were hoping to defer |
| 25 | Internal process changes agreed on the customer’s side | Customer | Their team knows what changes about their own working day |
| 26 | Admin training delivered | You | The admins have completed a task in their own environment, unaided |
| 27 | End-user training scheduled and attended | Customer | Attendance is above the threshold you agreed at kickoff |
| 28 | Pilot or UAT run with real data | Both | The customer signs off on the result in writing |
Item 25 is the one that never appears on vendor checklists and causes more failed onboardings than any technical item on this list. Your software works. Their process has to change to use it, which means someone on their side has to tell colleagues to work differently. That conversation is not on your plan, you cannot schedule it, and if it does not happen your product goes live into an organisation that carries on doing what it did before.
Put it on the checklist anyway. Ask about it directly at the kickoff: who tells your team that this changes how they work, and when? Naming it makes it visible. Leaving it off makes it inevitable.
Item 24 is where most calendar time disappears. Configuration decisions look like small questions and behave like large ones, because a question that seems trivial to you (“which approval flow do you want?”) can require three people on their side to agree on something they have avoided agreeing on for two years.
The fix is to front-load them. Put every decision the customer will have to make into the intake form in phase 1, before the kickoff, so they can start the internal arguments early. A decision that arrives in week five costs you two weeks. The same decision asked in week one costs you nothing, because it runs alongside the technical setup.
Phase 4: Go-live
| # | Item | Owner | Done when |
|---|---|---|---|
| 29 | Go/no-go check against written criteria | Both | The criteria were written before the week of go-live, not during it |
| 30 | Cutover executed | You | The old process is switched off, or a date is set for switching it off |
| 31 | The value milestone is actually completed | Customer | The specific thing they bought your product for has happened once, with real data |
| 32 | Internal announcement sent to their end users | Customer | Their people know it is live, what changes, and where to get help |
| 33 | Support path explained: who, which channel, what response time | You | A named person and a channel, not “reach out anytime” |
Item 31 is the only item on this list that actually matters, and it is the one most commonly marked complete by inference. Setup finished, training delivered, no open tickets, so onboarding must be done. But nobody checked whether the customer ran the payroll, shipped the campaign, or closed the deal in the system.
Go and confirm it happened. If the value milestone is “first payroll run,” look at the payroll run. Everything else on this list is scaffolding around that one event.
Item 32 is the difference between a live account and a used one. If nobody at the customer tells their team the new system exists, you have a successful implementation and no adoption. Draft the announcement for them. Send it to the project owner as something they can paste into Slack with their name on it. It takes you ten minutes and it removes the last excuse.
Phase 5: The first 30 days
Onboarding is not finished at go-live. It is finished when the customer no longer needs you standing next to them.
| # | Item | Owner | Done when |
|---|---|---|---|
| 34 | A second and third active user on the customer’s side | Customer | Three named people have used the product independently in the last seven days |
| 35 | Post-go-live review: what broke, what took longer than planned | Both | Written down within two weeks, while it is still accurate |
| 36 | Handover to the ongoing owner, with the customer introduced | You | The customer has met them live, not by email |
| 37 | Customer effort score captured | You | Asked once, immediately, one question, on a 1 to 7 scale |
| 38 | Onboarding marked complete against a written definition | You | The definition existed before this account started |
Item 34 is the most reliable churn predictor on this list. A single-user account is one job change away from being a cancellation. If only the project owner has logged in thirty days after go-live, that is a red account regardless of how well the implementation went, and you should treat it as one.
Item 37 asks about effort, not satisfaction. “How easy was it to get started?” predicts retention better than “how happy are you,” partly because people are polite about happiness and specific about difficulty. We go deeper on this and the rest of the measurement question in our guide to onboarding KPIs.
The ownership test
Now count your own checklist. Not this one. The one your team actually uses.
How many items on it can only be completed by the customer?
If the answer is zero or close to it, your checklist is a record of your team’s work rather than a record of the project. It will keep showing green while the project slides, because the things that make projects slide are not on it.
The split on the list above is 13 items yours, 11 the customer’s, 14 shared. Two thirds of the work needs someone who does not work for you, is not paid to prioritise your project, and has a day job that has not got any smaller since they signed the contract.
Which reframes the whole exercise. Your onboarding process is not primarily a delivery process. It is a mechanism for helping somebody else’s employee do work for you, on time, without a manager, while nobody is watching them.
Design for that and the completion rate moves. Design for your own workflow and you will keep discovering three-week delays on Tuesday mornings.
Five rules for the customer-side items
The eleven Customer items and fourteen Both items are where onboarding actually lives. Five things make them get done.
Make every customer item smaller than one sitting. “Prepare your data for migration” is a project. “Export your contact list as CSV using this two-minute walkthrough” is a task. If an item cannot be finished in one uninterrupted half hour, split it. People start tasks they believe they can finish and postpone tasks they suspect they cannot.
Assign to a person, never to a company. “Customer to provide SSO metadata” is assigned to nobody. “Priya, IT – SSO metadata, by Thursday” is assigned to Priya. Get the names at kickoff and use them on every item.
State the consequence, not the deadline. A due date says a date has passed. A consequence says what it costs. “Data export due Friday” produces nothing. “If the export lands after Friday, the pilot moves to the 24th and go-live moves with it” produces an export, because now the project owner has something to take to their own colleague.
Show them the whole list, not the next task. When the customer can see all thirty-eight items, their eleven, and how the sequence fits together, they can plan around it and chase their own people. When they only ever receive the next request by email, they cannot see what is coming, cannot batch their work, and have no idea which of your requests is holding up the go-live date.
Automate the chase and reserve the human for the stall. A reminder three days before a due date, an escalation to the project owner three days after: neither needs a person. Your CSM’s time is worth spending on the item that is genuinely stuck, not on writing the fourth “just circling back” email of the week.
The same five rules apply to the information you ask the customer for, except that there the timing matters as much as the wording. The client onboarding questionnaire guide splits those requests into three waves so the first one comes back in days.
Which brings up where the list should live.
Where the checklist should live
A checklist you can see and the customer cannot is a to-do list with extra steps.
The moment two thirds of the items belong to somebody outside your company, the list has to be somewhere they can open it, see their own items, see the dates, and see what happens next. That rules out your internal project tool. It also rules out email, which turns a structured list into thirty-eight fragments arriving in a random order over eight weeks.
What works is one shared workspace per account: the plan, the intake form, the resources for each phase and the conversation in one place, on one link, with the customer’s items marked as theirs. Both sides read the same list. Progress is visible without a status meeting to establish it, and engagement becomes observable, which means a stall shows up as a data point instead of as a surprise. We cover the trade-offs against internal project tooling in our comparison of onboarding workspaces and project tools, and the signals worth watching in how to track customer engagement during onboarding.
Valuecase is built around exactly this split: a customer-facing Space per account holding the shared plan with owners on both sides, intake forms that feed the plan directly, automated reminders on the customer-side items, and a portfolio view showing which accounts are moving and which have gone quiet. If you are running more than a handful of onboardings at once, our guide to scaling onboarding covers how that portfolio view changes where your team spends its hours.
What to cut
A checklist that grows every quarter and never shrinks stops being used. Twice a year, go through it and cut:
- Items that have never once been blocked. If something has been completed on time by every customer for a year, it is part of how your team works, not a project risk worth tracking.
- Items that exist to reassure an internal team. Status confirmations, CRM field updates and handoff acknowledgements are real work, but they belong in your own systems rather than on the plan the customer is looking at.
- Items with no observable “done when.” If nobody can say what finished looks like, the item will sit at “in progress” until someone gets tired of it.
- Duplicates created by a bad month. Something went wrong once, someone added a check, and the check outlived the reason. Ask why each item is there. Two or three will have no answer.
Then run the ownership count again on what is left. If cutting made the list more internal, you cut the wrong things.
Start here
Take your existing checklist and do one thing this week: put an owner marker on every item.
You will find items nobody owns. You will find items assigned to “the customer” as an entity. And you will probably find that the things that made your last three projects late are not on the list at all, because your team could not do them, so they never got written down.
Add them. Then give each one a named person, a date, and a sentence saying what it holds up.