Onboarding Plan Template From Closed-Won to Go-Live

An onboarding plan template is a reusable timeline that turns a closed-won deal into dated phases, milestones and owned tasks, ending at go-live and handoff to customer success. Below is a complete template with six phases, sample durations, milestones and a RACI, plus guidance on adapting it per customer.

The difference between a checklist and a plan is time. A checklist tells you what has to happen. A plan tells you when, in what order, who is waiting on whom, and what the go-live date depends on. When a customer asks "are we on track", a plan lets you answer with a date and a reason, not a feeling.

What goes into an onboarding plan

Every good onboarding plan, whatever the product, contains the same building blocks.

1. Goal and success criteria. One sentence on why the customer bought, plus two or three measurable outcomes that define success.
2. Scope. The modules, seats, integrations and services that were sold, taken from the order form or SOW. Anything outside it is a change request.
3. Phases. Large blocks of work with a start, an end and an exit criterion.
4. Milestones. Zero-duration checkpoints both sides care about, such as kickoff held or data imported.
5. Tasks. Specific actions with one owner, a due date and a side (vendor or customer).
6. Dependencies. Which tasks cannot start until another is done.
7. Roles. Who is responsible, accountable, consulted and informed.
8. Risks and assumptions. What could move the date, and what you assumed when you set it.

The onboarding plan template from closed-won to go-live

The durations below assume a mid-market B2B SaaS deal with one CRM integration and a data import, targeting go-live in about 45 days. Shorten or stretch each phase to match the scope. The task-level version of this template is on our onboarding checklist template page.

Notice the overlaps. Discovery starts before kickoff ends because the intake form goes out with the welcome email. Build starts before discovery fully closes because admin access does not depend on every requirement being final. Overlapping phases is the simplest way to shorten a plan without cutting work.

Phase 1. Handoff and preparation

The clock starts at closed-won, not at kickoff. Many teams lose a week here because the implementation lead finds out about the deal late or has to chase sales for context. Ask for a structured handoff note on the day the deal closes, covering what was sold, promised dates, stakeholders and risks. Create the project and send the welcome email within two business days.

Phase 2. Kickoff

Kickoff has three jobs. Confirm the goal and success criteria in the customer's own words, walk through the plan and the date, and agree who does what. Leave the meeting with names next to every customer task. Send the notes and the updated plan the same day.

Phase 3. Discovery

Discovery collects everything you need to configure the product. The faster way is to send structured intake forms before the workshops, so meetings are spent on decisions rather than on gathering basic facts. Close the phase with a written requirements summary the customer signs off.

Phase 4. Build and integrate

This is usually the longest phase and the one most often blocked by the customer side: an export that is not ready, an IT approval that takes longer than planned, an API credential nobody can find. Track these as customer tasks with dates, and raise any blocker older than a week with the sponsor.

Phase 5. Validate and train

User acceptance testing should use the customer's real data and real workflows. Train admins first, then end users by role. Record sessions so new users joining later have something to watch.

Phase 6. Go-live and handoff

Go-live is a milestone, not the end of the plan. Agree a short hypercare window, check usage against the success criteria, then hand the account to customer success with a written note and a joint call.

Choosing milestones that mean something

Milestones are the moments you report to the sponsor, so pick ones that reflect real progress rather than activity. "Configuration started" says little. "Customer data live in product" tells everyone that the hardest technical work is behind you. A good milestone is binary (it either happened or it did not), visible to the customer, and tied to an exit criterion. Five to eight milestones are enough for most plans. More than that and the sponsor stops reading them, fewer and long stretches of the project pass without a clear checkpoint.

Add one milestone that is about value, not delivery, such as the first report produced or the first workflow completed by a real user. It keeps both teams focused on the outcome the customer bought, not only on finishing tasks.

RACI for the onboarding plan

A RACI matrix removes most "I thought you were doing that" moments. R is responsible (does the work), A is accountable (signs off), C is consulted, I is informed.

How to adapt the template to each customer

A template is a starting point. The plan you share with a customer should reflect what that customer bought. Read the SOW or order form and adjust:

• Modules. Remove tasks for modules not in scope, add tasks for each purchased add-on.
• Integrations. Each integration usually adds requirement, credential, mapping and testing tasks. A HubSpot, Salesforce or Pipedrive connection each has its own setup steps.
• Seats and teams. More teams means more training sessions and more roles to configure.
• Target date. Work backwards from the go-live the customer needs, then check whether the critical path fits. If it does not, say so at kickoff, not in week five.
• Stakeholders. Add approval tasks for legal, security or procurement if they appear in the deal notes.

This adaptation step is where implementation teams spend the most time per new customer, and it is the step that customer onboarding software with SOW parsing can automate. OnboardingCustomers reads the pasted SOW or the closed-won deal, picks out the products, integrations, seats, dates and stakeholders, and builds the phased plan with two-sided tasks in seconds. You review it, adjust anything specific, and publish it to the customer portal.

Risks and assumptions worth writing down

Every timeline rests on assumptions. Write them into the plan so that when one turns out to be wrong, the date change is explained rather than argued about. Common ones include:

• The customer project lead can spend a few hours a week on the project.
• The data export is available in a standard format without custom work.
• Security review follows the customer's standard process and starts in week one.
• API credentials for each integration are provided by a set date.
• No new modules or teams are added during onboarding.

For each risk, record the owner and what you will do if it happens. Keep the list short, five to eight items, and review it in the weekly call.

Keeping the plan alive after kickoff

Plans go stale quickly. A customer misses a date, a new stakeholder appears, scope grows. Three habits keep the plan useful.

1. Move dates, do not hide them. When a task slips, update it and let dependent tasks shift. Show the new go-live date with the reason.
2. Review weekly. A fifteen-minute review of overdue tasks and blockers with the customer project lead prevents most surprises.
3. Log changes. Out-of-scope requests go into a change log with a decision. That protects the date and the margin.

Teams that run many onboardings at once usually move from spreadsheets to dedicated client onboarding software once they need reminders, a customer portal and a health view across all projects.