Customer onboarding process flowchart

What the customer onboarding process is

Customer onboarding is post-sale delivery: everything between a signed contract and a customer who is live, trained and getting what they paid for. It is worth separating from the two processes it is most often confused with. Vendor onboarding is intake, checking and approving a supplier you are about to pay. Employee onboarding is an internal joiner process. Customer onboarding runs the other way round: the money is already committed and the promise has already been made, so the work is to deliver it before the sponsor who bought it loses patience or moves on.

The flow below crosses five lanes. Sales appears twice and only twice, at the handover and again when the customer goes quiet, which is roughly the right amount of sales involvement after a deal closes. Onboarding or implementation owns the middle of the process. Finance owns account creation, billing setup and any credit or KYC check your organisation requires. Support appears once, at the end, because that is genuinely when they take the account on. The Customer lane is the one worth reading closely: it holds the three points where the customer, not you, controls the flow, namely providing data and system access, approving go-live readiness, and confirming at 30 days whether the success criteria were met.

Two decisions and one branch carry most of the delivery risk. 'Data migrated correctly?' has a remediation loop rather than a single pass, because migrations rarely land first time and an honest process shows the retry. 'Go-live readiness approved?' is a real go/no-go: a no-go returns the account to configuration, data and training work instead of quietly moving the date. And the stalled-customer path is drawn rather than assumed, running from no response to a chase by the sales account owner and, if there is still no contact, to a paused and flagged account. Every onboarding team has these accounts; few have anywhere defined to put them, so they sit in someone's inbox.

What this flowchart covers

In this template

• Five swimlanes (Customer, Sales, Onboarding / Implementation, Finance, Support) across six phases: Sales handover, Kickoff and plan, Account and billing, Configuration and migration, Training and go-live, and Adoption and support.
• The hand-off from deal to delivery: contract signed, the account passed from sales to onboarding with a handover pack, a kickoff where success criteria are agreed, and an onboarding plan published with named owners on both sides.
• Finance setup with a real fork: 'Credit or KYC check required?' skips the check where it does not apply, and 'Compliance checks cleared?' either releases the account or holds it pending evidence, then re-tests once that evidence arrives.
• The stalled-customer path: 'Customer provided data and access?' sends a silent account to 'Re-engaged after sales chase?', which either rejoins the main flow or ends at a paused and flagged account instead of an open task nobody owns.
• Configuration and migration with a validation loop: configure the system and integrations, migrate and load the data, then 'Data migrated correctly?' either moves on to training or returns the load for correction and a recheck.
• User and administrator training, a go/no-go readiness decision held in the Customer lane, go-live on production, a review of the kickoff success criteria at 30 days, and handover to the support and account team.

When to use this template

• You are standing up or rewriting an onboarding and implementation function and want the sequence and hand-offs settled before anyone writes the playbook.
• Accounts stall after signature and nobody can say whether the delay sits with your team, with finance or with the customer.
• Sales and delivery disagree about what was promised, and the handover needs to be a step in the process rather than a forwarded email thread.
• Time to go-live or time to first value is a reported metric and you need to see which lane is holding each account at each stage.
• You are bringing new implementation or customer success staff up to speed and want one page rather than a long written procedure.

How it works

1. Match the lanes to your delivery teams

   Rename Customer, Sales, Onboarding / Implementation, Finance and Support to the teams that exist in your company. Smaller organisations usually merge implementation and support into one lane, or run onboarding out of customer success. Delete a lane rather than leaving it empty, and keep the Customer lane even though it holds only three nodes, because it is the clearest way to show how much of the critical path you do not control.

2. Define what the sales handover must contain

   Turn 'Hand over account to onboarding' into a checklist: signed scope, what was actually promised during the sale, anything already agreed as out of scope, named contacts and decision makers on the customer side, the target go-live date and any commercial deadline behind it. Decide whether sales stays on the account through kickoff, and say so on the chart, because an unstated answer usually means nobody.

3. Write the success criteria as measurable statements

   'Agree success criteria' is only useful if the output is testable at 30 days. Replace vague goals with statements that name a number, an owner and a date, such as a stated volume processed in the system by a given week, or a named team using it as their system of record. These are the same statements the 'Review success criteria at 30 days' step reads back, so vague ones cost you twice.

4. Set the finance trigger and the hold rules

   Record what makes 'Credit or KYC check required?' a yes in your organisation, for example contract value, invoiced payment terms, a new legal entity or a regulated sector, and note who decides. Then state what a hold actually means in practice: whether configuration work continues while the account is held, who tells the customer, and what evidence releases it. Take that wording from your own policy rather than this template.

5. Agree the migration test before the migration

   Fill in what 'Data migrated correctly?' checks: record counts by object, control totals on the money fields, and a sample the customer inspects themselves. Name who signs it off, which should be the customer rather than the team that ran the load, and set a limit on how many correction cycles run before the go-live date is formally revisited.

6. Fix the go/no-go criteria, then publish a versioned copy

   List the readiness criteria in advance, name who chairs the review and confirm that the customer holds the decision. Add your own stall thresholds to the chase branch, such as days without a reply before escalation and before the account is paused. Then share the chart with sales, finance and support for comment and keep it under version control, so the diagram and the written playbook do not drift apart.

Frequently asked questions

How long should customer onboarding take?

It depends almost entirely on whether data migration and integrations are in scope. A self-contained account with no migration can be live in one to two weeks. Add a data migration and a single integration and four to eight weeks is realistic; multi-system implementations with security review run longer. The useful measure is not the end-to-end figure but how long each lane holds the account, because most overruns are waiting time rather than working time, and the largest single block is usually waiting on customer-owned tasks such as data extracts and admin access. Measure the hand-offs before trying to compress the work.

What should the sales-to-onboarding handover include?

Enough for the delivery team to avoid asking the customer questions the customer has already answered. That means the signed scope, what was promised verbally during the sale, anything explicitly excluded, the commercial terms that affect delivery such as billing start date, the named sponsor and day-to-day contacts, the technical environment the customer described, and any deadline the customer has committed to internally. Put it in a structured form rather than a narrative email. The commonest failure is the promise made in the last week of a quarter that never reaches the person who has to deliver it.

What do you do when a new customer goes quiet during onboarding?

Decide the thresholds in advance rather than case by case. This flowchart routes an unresponsive account from 'Customer provided data and access?' to a chase by the sales account owner, who has the relationship and usually the sponsor's mobile number, and then to a paused and flagged state if there is still no contact. Pausing explicitly matters for two reasons: it stops the account from consuming implementation capacity that is silently reserved for it, and it creates a record of why the go-live date moved. Agree what pausing means commercially, since billing has often already started.

How is customer onboarding different from vendor onboarding or employee onboarding?

They share a word and almost nothing else. Vendor onboarding is intake: due diligence, risk tiering and bank detail verification before a supplier can be paid, with the burden of proof on the vendor. Employee onboarding is an internal joiner process covering contracts, equipment and access. Customer onboarding is post-sale delivery, where you are the one with something to prove and the customer already has a signed contract and an expectation. The practical consequence is that customer onboarding has no gate you can simply refuse to open: if it stalls, the flowchart needs a defined pause and an escalation, not a rejection.