How to create a customer onboarding process
How to design a customer onboarding process around the sales-to-delivery handover: what must be true before implementation accepts an account, and which two gates the customer holds.
A customer onboarding process runs from a signed contract to a customer getting what they bought, and its real subject is the handover between the team that sold the work and the team that delivers it.
The short version
- Make the handover a gate rather than an announcement; only one of the two holds.
- Put the customer in a lane because they hold two of the gates, not because they are slow.
- Success criteria belong at kickoff, because that is what a 30-day review compares against.
- A no-go that only moves the go-live date is a delay wearing a decision's shape.
- Compliance holds on the account are normal; design the loop instead of escalating each one.
Onboarding fails at the transfer, not inside it
Nothing in customer onboarding is technically difficult, and it overruns anyway. The reason is structural: the process spans two internal teams who meet at one step, and most onboarding documents treat that step as an announcement. Sales closes, a channel is created, implementation starts reading. What was promised in the room, who inside the customer can decide, which integration was assumed to exist: none of it is a condition of anything, so none of it has to be true before the next step begins.
Delivery must be able to refuse the account, and somebody senior has to say so in advance. That permission turns the handover pack from a courtesy into a set of conditions: a countersigned scope and a named contact who can approve are either present or they are not, and it gives the map a point at which the process stops and waits. Without one, an onboarding map is a to-do list with arrows, and an overrun is a condition that lived in someone's head and got skipped without anyone deciding to skip it.
The example below puts the customer in a lane of their own, and that is the second thing worth copying: a decision drawn in somebody else's lane cannot be answered on their behalf. "Customer provided data and access?" is where the process stops, its "No response" branch handing the account to "Re-engaged after sales chase?" instead of to a close. "Go-live readiness approved?" answers "No-go" back into "Configure system and integrations" rather than moving the date.
Signed contract to real usage
Customer onboarding across five lanes, the first of them the customer's own: the lane that decides when everything else may proceed.
The handover is the whole risk
A signature, a handover, a kickoff that agrees success criteria, then a published plan with owners: four rows, of which "Hand over account to onboarding" is the second. Most of what overruns later is traceable to what that row did or did not carry.
A hold is not a rejection
The lane columns fill in and Finance takes the account for four rows. "Credit or KYC check required?" sends the ones that do to "Compliance checks cleared?", which can answer "Hold," and "Hold account pending evidence" returns to that same decision on "Evidence received".
The gate the customer holds
"Customer provided data and access?" is where the process stops working on the customer's behalf, with "No response" handed to sales to chase. Then configuration and migration, and "Data migrated correctly?" sending failures to "Correct errors and reload data" for a recheck.
No-go sends work backwards
Training, then "Go-live readiness approved?", which the customer holds: "Go" proceeds, "No-go" returns to "Configure system and integrations". After the 30-day review comes "Handover to support and account team"; the only failure ending is "Onboarding paused and flagged", reached on "No contact".
How it works
Write down what delivery is accepting
List the conditions implementation needs before it takes the account: countersigned scope, a named contact who can approve, environment and integration prerequisites, and every commitment made during the sale. Anything on that list which cannot be checked is not a condition, it is a hope: either make it checkable or remove it.
Separate your steps from the customer's
Walk the flow twice. Mark first which steps the customer performs, then which decisions only the customer can answer: the second list is short, usually two entries, and it is the one that stops everything. Against each, write what happens when no answer arrives, because that is the route you will use.
Type the steps as rows and wire them by number
Each row in the Box text column becomes a box. Put the row numbers a step leads to in the Line to column, comma separated. Because the connections are numbers rather than drawn lines, renaming a step or reordering the sheet leaves the flow intact: that is the difference between a map you edit and a map you redraw.
Put the customer in the Vertical lane column
Owners go in the Vertical lane column and phases in the Horizontal lane column, and the column does not care whether the owner is on your payroll. Put a Decision row in the customer's lane and the diagram states on its face that the answer is not yours to give, which is a harder thing to talk past in a kickoff than the same sentence in a plan.
Draw every refusal as a labelled branch
Each question takes Decision in the Shape column, both its destinations in Line to, and its branch words in Line text in the same order, so no arrow leaves a diamond unlabelled. A backward row number is how a loop is written: a failed migration check returning to the correction step, a no-go returning to configuration.
Send it for approval, then share the link
Route the finished chart for approval, then send its link to the account team and to the customer's named contact. An approval record on a plan that leaves the company answers the question they ask first (is this agreed, or somebody's draft) and it dates the revision the kickoff worked from.
Mistakes to avoid
Handover by channel invite
Adding implementation to a thread is not a transfer of accountability. Until someone has confirmed what they are accepting, the sale's assumptions stay in the salesperson's memory and resurface as scope arguments in week three.
Answering the customer's gate for them
A partial extract arrives and "Customer provided data and access?" gets ticked, because the alternative is stopping. The gate then certifies nothing, and the missing fields resurface in migration as a data problem, not an intake one.
Moving the date instead of deciding
If a readiness decision can only defer, it is not a decision. The useful answer to not ready is a route back to specific work (configuration, migration or training) with the date recalculated from where the work restarts.
No path for a customer who goes quiet
Accounts that stop responding do not close themselves; they sit in a pipeline consuming attention and forecast. Draw an explicit paused and flagged state, so an account is either progressing or visibly parked.
Create your own customer onboarding map
Open the example as your own chart, set what implementation must have before it accepts an account, and rename the lanes to your teams.
Related guides
Frequently asked questions
What should a sales-to-delivery handover include?
Six things, all of them checkable: the countersigned scope, the commercial terms that affect delivery, a named customer contact with authority to approve, every commitment made during the sale including the verbal ones, the technical prerequisites the solution assumes, and whatever was already agreed as out of scope. The last two are the items usually missing and the two that produce week-three scope arguments. Make the pack a condition of the handover rather than a document produced after it.
How long should customer onboarding take?
Not in weeks, and a number quoted without its conditions is a number you will miss. Two of the decisions here belong to the customer ("Customer provided data and access?" and "Go-live readiness approved?"), so any date is a forecast conditional on both. Publish it that way: the date, the two answers it depends on, and what happens if they do not arrive, since a "No response" branch moves the date rather than absorbing the delay. Customers told which of their answers holds the date tend to give it sooner.
Should the customer see the onboarding plan?
Yes, and the same plan you work from rather than a summary of it. A plan the customer can read is the only form in which the claim that their own steps sit on the critical path is believed, and it turns the go-live readiness conversation into something negotiated in advance rather than delivered as a surprise. Name their contact against the rows they own and publish the dates those rows carry, and the two answers only they can give stop arriving late by default.
What is time to value and how is it measured?
Time to value is the elapsed time from signature to the customer getting the outcome they bought, measured against criteria agreed at kickoff rather than against go-live. Go-live is a milestone in your process; value is an event in theirs. Pick one observable thing per customer (a live transaction volume, a report finance actually uses, a queue answered by the new system) and check it at 30 days. Without that check the process cannot tell you whether it worked.