How to create a customer onboarding process

A worked example, stage by stage

1. 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.

2. 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".

3. 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.

4. 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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

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.