NewActiValet is here. Introductory offer: 25% off your first 12 months when you sign up by December 31, 2026.See it →

The Onboarding Automation Gap Most MSPs Miss

Rodney Hall, COO

Several separate conveyor belts running in parallel with visible gaps between them, not yet joined into one line.

Onboarding stays manual at most MSPs not because automation never arrived, but because it arrived unevenly. The same providers who automate ticket routing and patch management still move a new client through a dozen separate manual handoffs. The gap between those two states is why provisioning keeps eating technician hours even at MSPs that call themselves automated.

Why does onboarding still eat so much technician time?

Provisioning a new client is still mostly manual labor dressed up as process. ManageEngine's MSP Central onboarding guide puts the effort for a typical new client at 40 to 80 hours, spread across licensing, device setup, documentation, and the dozens of small configuration steps that never show up on a sales deck. That range holds steady whether the client is small or large, because the number of systems involved barely changes even as the user count does.

Microsoft 365 is a clear example of where that manual load compounds as a book of business grows. CiraSync's 2026 MSP Onboarding Benchmark found that MSPs managing fewer than 20 client tenants can typically sustain manual contact and calendar sync without major strain, but that fragmentation and recurring support tickets begin to compound between 20 and 30 tenants, and beyond 30 tenants the manual process becomes a measurable drag on technician capacity and margin. Growth does not scale politely past that point. You cross a line where the old manual process stops holding up at all.

What's the difference between automating a task and automating a process?

Most MSPs that say they have automated onboarding mean they have automated pieces of it. A script that creates a mailbox. A workflow that closes a ticket. That is task automation, a single action inside a single tool, and it is genuinely useful. It is not the same thing as process automation, which means orchestrating a sequence of steps across multiple tools and teams without anyone having to manually hand off the next step.

The distinction matters because it explains why onboarding feels unfinished at MSPs that otherwise consider themselves automated. A technician can point to a dozen scripts that save real time, and still spend a full day on a new client because nothing connects the scripts to each other. The PSA ticket closes automatically. The mailbox provisions automatically. The documentation update, the license reconciliation, and the handoff to the account manager still depend on someone remembering that the first two steps finished. Task automation removes effort from individual steps. Process automation removes the person whose job is to remember what comes next.

Rewst's 2026 State of MSP Automation Report, based on a survey of 300 MSP professionals across North America, EMEA, and APAC, lists onboarding a new user end-to-end among its examples of process automation, defined as orchestrating a sequence of steps across multiple tools, systems, and teams without anyone having to intervene. That definition is the point. A new client onboarding touches the PSA, the RMM, the identity platform, and the documentation system in sequence, and process automation means none of those handoffs wait on a technician to remember what comes next. The same report found that operational efficiency was the most commonly cited benefit of automation at 86 percent, with consistency and standardization close behind at 74 percent. Those are exactly the two things a half-automated onboarding sequence cannot deliver, because the gaps between the automated pieces are still filled by a person.

How much of their workload have MSPs actually automated?

The industry-wide numbers back this up. Kaseya's 2026 State of the MSP report, based on responses from more than 1,000 MSPs worldwide, found that 55 percent of MSPs have automated only about a quarter of their workload in the past two years, while 28 percent have automated about half. Only a small minority report automation reaching most of the business. Despite that, 59 percent of MSPs told Kaseya they are satisfied with their current level of automation, which says less about how automated the average MSP actually is and more about how low the bar for satisfaction has settled.

That gap between adoption and satisfaction matters because onboarding is not where the automation that does exist tends to land. The same Kaseya report found that automation is concentrated in monitoring, alert management, security operations, and ticketing, with fewer providers extending it into client onboarding, sales, or broader customer engagement functions. Those internal execution functions are easier to automate because they live inside one tool. Onboarding is harder precisely because it does not.

Why does the expertise gap matter more than the budget gap?

If budget were the obstacle, this would be a simple fix. It is not. Rewst's report found that lack of expertise is the most commonly cited barrier to further automation at 54 percent, while budget ranked near the bottom of the list at 18 percent. MSPs are not failing to automate onboarding because they will not spend the money. They are failing because building a process that spans multiple systems takes a different skill set than writing a single script, and most technical teams were hired and trained for the second job, not the first.

That expertise gap does not shrink as MSPs grow. The same survey found that MSPs in the 10 million to 25 million dollar revenue band cited lack of expertise more often than smaller shops, at 63 percent compared with 50 percent for MSPs between 1 million and 3 million dollars. Getting bigger raises the stakes on a broken onboarding process instead of fixing it, because more clients run through the same unfinished sequence every month.

It also explains why the fix rarely comes from hiring. Adding a technician gives you one more person who can run the manual version of onboarding well. It does not give you a documented, repeatable sequence that the next hire can pick up without months of shadowing someone else. Every new technician who learns onboarding by watching a senior colleague is institutional knowledge staying exactly where it was before you hired, in one person's head instead of two.

What separates the MSPs that actually close this gap?

Rewst's research found that 58 percent of MSPs use a dedicated automation platform rather than relying only on their PSA, RMM, or custom scripts, and that group reports meaningfully different outcomes, including 82 percent who cite consistency and standardization as a core benefit of automation compared with 60 percent of MSPs without a dedicated platform. The platform itself is not the point. What it represents is a team that decided process automation was worth building deliberately, instead of accumulating one-off scripts and hoping they add up to a system.

The commercial upside shows up too. MSPs with a dedicated automation platform were also more likely to report scaling without adding headcount, at 44 percent compared with 36 percent of MSPs without one, according to the same Rewst report. For a COO looking at next year's hiring plan, that is the number that should matter most. Every onboarding step that still depends on one technician's memory is a hidden headcount requirement you have not budgeted for yet.

What should you actually fix first?

None of this requires ripping out your PSA or RMM. It requires mapping your current onboarding sequence end to end, every system it touches and every step a person currently has to remember, and then deciding which of those handoffs can move to a platform instead of a person. Start with the step that happens on every single onboarding regardless of client size, because that is where standardization pays off fastest and where a technician's judgment is adding the least value.

The expertise gap behind all of this is a training problem as much as a tooling one. Forge University builds that capability directly into your team instead of leaving it to whoever happens to have picked up automation on their own, so the next onboarding does not depend on the one person who understands how the workflow was built.

If you are not sure where your own onboarding breaks down between task automation and process automation, Actiforge's stack builder walks through that gap against the tools you already run. The MSPs pulling ahead on automation are not the ones with the biggest budget. They are the ones treating onboarding as a process built once and run consistently, not a checklist for one technician to get through quickly. Browse Actiforge's full product catalog for the white-labeled tools built around that same standard.

See the full stack