How it worked before
At the MSP where I helped build the Projects team, onboarding started with sales. Sales was responsible for capturing the client’s requirements. The project manager picked it up from there, met with the client, and kept the work moving by creating tickets or reaching out directly to whoever could get a piece of it done.
What stood out to me was that nobody’s delivery duties were separated or assigned. The work landed on whichever support staff could be reached, which took them away from their own work and made everything take longer. Worse, it left gaps that nobody could see until after onboarding had been declared complete. By then they weren’t onboarding problems any more. They were support problems, with a client already wondering what they were paying for.
The first thing I standardized
Not a tool, and not a template for its own sake. I standardized what information was gathered, at which stage, and who was accountable for it.
That one decision did three things. It made sure the information the rest of the work depended on was actually collected, instead of discovered missing halfway through. It gave the project manager something solid to plan from, so everything after it could be set up properly. And it changed how we looked to clients: a company that asks the right questions at the right time looks like a company that can support you.
What support got out of it
Support had been inheriting clients they knew very little about. Now they received proper documentation of everything they needed to know about the customer: how many people, the types of devices and services they had, and exactly what we were managing for them. The handoff stopped being a guess.
The pushback
There was less than you might expect. I’d spent a long time as a support provider before this, and the plan was grounded in that experience, so it was hard to argue with.
Most of the change landed on sales. They had to do a little more groundwork up front, rather than saying whatever closed the deal. Those sales had been hurting the company in more ways than one: promises the rest of us then had to keep, on information nobody had gathered.
Clients noticed the difference. They were far happier, because they could see that the money they were paying was getting real care and support.
Onboarding timelines came down by more than 25%. The case study has the rest of what changed: standard statements of work, a mapped handoff, and a set cadence with the people signing.
If I walked into the same mess tomorrow
I wouldn’t start by fixing anything. For the first couple of weeks I’d get familiar with how things work and how they’ve been going. I’d talk to the key people in sales, projects, and support and ask where they see the gaps and the friction. Then I’d look at how the pieces actually fit together, as opposed to how they’re meant to.
Only then would I decide what to standardize first. Last time it was the information. Somewhere else it might be something different, and the only way to know is to listen first.
Why it’s a foundation fix
In Foundation Layer terms, slow onboarding looks like a delivery problem at L4. The cause sits lower: no defined operation for moving a client from signed to supported (L1), and nobody able to see what was known, what was missing, or who owned the next step (L3).
If your onboarding runs on whoever happens to be free, that’s the kind of work I do.