Customer onboarding process flowchart
Customer onboarding process flowchart with swimlanes for customer, sales, onboarding, finance and support, from contract signature to steady-state account.
How it works
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.
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.
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.
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.
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.
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.