Client onboarding is a product, and it has users
Its users are your own commercial, legal and support teams. Nobody treats them like users.
Onboarding a new client is usually described as a project: it has a start, an end, and a spreadsheet.
Treat it that way and you rebuild it from scratch every time, because a project that ends leaves nothing behind except a client who is live.
Its users are internal
The people who move through the onboarding track every week are commercial, legal, product, technology, operations and support. They are users: they have a journey, they get stuck in the same three places, and they work around what frustrates them instead of reporting it.
Once you accept that, the whole product toolkit applies — the flow has steps that can be measured, abandonment that can be found, and an interface, even if that interface is a shared sheet and four chat threads.
The repeated exception is the roadmap
Every onboarding has exceptions. What matters is which ones repeat. An exception that shows up in one client out of thirty is a negotiation. The same exception on the fourth client in a row is a missing feature, and continuing to handle it by hand is a decision to pay for it forever.
Governance is not the opposite of speed
Approvals get a bad reputation because they are usually undefined: nobody knows who approves, so everyone waits for everyone. Defined approvals — this person, this scope, this deadline, this fallback — are faster than no approvals, because waiting on an unnamed decision has no deadline at all.
What it looks like when it works
The measure is not how fast one client goes live. It is whether the thirtieth client goes live without anyone being a hero.
