How to Build a Shared Customer Onboarding Plan Both Sides Use

Every customer onboarding has two teams working from two plans. Yours lives in a spreadsheet you update on Fridays. Theirs lives in an email thread with three people copied. The plan the CEO sees in a QBR is a third version, reconstructed by the CSM the night before.

A shared onboarding plan collapses that into one plan both sides work from. Here is how to build one that actually holds up past week two.

What is a shared onboarding plan and why does it fail?

A shared onboarding plan is a single project workspace that vendor and customer both see and edit, with tasks assigned to named individuals on each side, phase transitions gated by prior work, and a go-live date that recalculates when any dependency moves. That definition matters because most plans that call themselves "shared" break on one of three points.

• The customer never opens it. Sending a link once at kickoff and never routing nudges to email means the customer defaults back to Slack and inbox.
• Ownership is a team, not a person. "IT" is not an owner. "Dev Mehra, IT" is an owner. Team-level ownership is how a rollout stalls for eleven days because nobody thought the task was theirs.
• The plan is a report, not a system. If the plan only gets updated before status calls, it is decorative. It has to be the source of truth or it produces nothing but false confidence.

Fix those three and the plan becomes an operating system. Miss any one and it decays inside a month.

How do you structure the phases?

Four phases fit almost every mid-market SaaS rollout. Add a fifth only if security review is a genuinely gated activity for your deals.

The gate is the important column. If a phase can end without a specific artifact from the customer, the phase is not really gated and slip will hide inside it.

Who owns each task, exactly?

Every task has one vendor-side owner and, when relevant, one customer-side owner. Both are named individuals with real accounts, not shared aliases.

• Vendor-side owner. Usually the implementation manager, sometimes a solutions engineer or a data engineer for migration work. Owes the customer a completion or an escalation, never silence.
• Customer-side owner. The person doing the work on their end. This is often a mid-level operator (RevOps analyst, sales enablement lead, IT admin), not the exec sponsor. The exec sponsor is the escalation path, not the owner.
• Vendor-side accountable. The named IM or CSM who owns the plan overall. One per account, no exceptions.

If your onboarding process does not force customer-side owner assignment in kickoff, add that step and refuse to end the kickoff without it. This one change moves go-live dates left by roughly a week on average because the customer starts running work the day after kickoff instead of the week after.

How do you keep the go-live date honest?

The go-live date is the number the CFO and CEO on both sides watch. Most implementations lie about it, not deliberately, but because the mechanism used to update it is manual.

Do this instead: model the plan as a directed graph of tasks with dependencies. The go-live date is the earliest date the last go-live task can complete given today's state. When any upstream task slips, the projected date shifts, immediately.

Three rules make this work in practice.

1. Every task has a duration and a dependency. Not "Q3." Not "when data is ready." A number of days and the specific upstream task it waits on.
2. The projection updates on task movement, not on status meetings. If a customer-side task went two days late yesterday, the go-live projection today reflects two days of slip, even if nobody has run the report.
3. Slippage is visible to both sides. When the projection moves, both the vendor account team and the customer sponsor see it. Do not hide slip until QBR.

Customers who see the honest number early respond faster than customers surprised in week ten. The pattern is consistent across mid-market implementations.

What tasks should always be on the plan?

Templates lie. Every rollout is a little different. But eight tasks should appear on nearly every mid-market plan, or you are underestimating.

• Kickoff meeting with named owners assigned
• Success criteria written and signed off by exec sponsor
• Data audit of source systems, on the customer side
• Field mapping review, vendor-led with customer input
• Sandbox environment provisioned and validated
• SSO or SCIM configured with the customer's IT
• Admin training completed with attestation
• End-user training or self-serve enablement launched

If any of these is missing from your template, you are relying on tribal knowledge to remember them. That works until the implementation manager who remembers them takes a vacation.

How do you handle rollout for enterprise deals?

Enterprise onboarding is not just a longer mid-market onboarding. Three things change materially.

• Security review is a phase. DPA, SOC 2 evidence, subprocessor list, penetration test summaries. Add a phase between Kickoff and Data with its own gate, or security review will silently consume weeks.
• Change management is a workstream. Enterprises have internal change advisory boards. Add scheduled review points and a task for "customer CAB submitted."
• The plan has multiple customer-side leads. IT, procurement, business owner. Each with their own tasks and their own escalation path. One customer-side lead does not work at 500 seats and above.

The rest of the mechanics are the same. Two-sided ownership, gated phases, honest projection. It just gets longer.

What does a working weekly review look like?

One meeting. Thirty minutes. Same day every week.

• Attendees. Vendor IM, customer-side lead, exec sponsor when the account is drifting.
• Agenda. Every task overdue, every task due this week, projected go-live vs baseline.
• Output. Any drift longer than three days gets a named escalation. Any task without an owner gets one assigned in the meeting.

If the weekly review runs past 30 minutes, you are doing the work of the week in the meeting instead of confirming it. The plan should be current before the meeting, not updated during it.

The mistake to avoid

The most common failure mode is treating the shared plan as a document you send the customer and then work around. The plan has to be the operating layer for both teams, not a copy of an internal system that the customer occasionally sees. That means the customer's tasks are in the plan, ownership is named on both sides, the projection moves on real events, and the weekly review confirms decisions rather than producing them. Everything else is a slower spreadsheet.