Automated onboarding and discovery

The clock starts when the client grants access. From that point an AI-native MSP's systems, not its technicians, do the work of finding out what the environment contains and getting it into a supportable state.

In an operation that meets this criterion, credential provision triggers a chain that runs without a queue:

• Discovery: identity tenants, endpoints, servers, network devices, SaaS estate, backup targets and licence position are enumerated rather than interviewed out of the client.
• Baseline assessment: findings are compared against the MSP's own standard, and the gaps are listed as work rather than as a report someone has to read and translate.
• Configuration: agents deploy, policies apply, monitoring and alerting bind to the discovered assets, and backup coverage is reconciled against what was actually found.
• Documentation: the environment record is written from the discovery output, which is the same mechanism described under AI-maintained documentation.
• Exceptions: whatever could not be resolved automatically is raised as a specific, actionable item rather than a generic please review.

A technician may well check the output. The criterion is not that no human looks at it. The criterion is that no human builds it. If an engineer is running the discovery script, reading the results into a document, and hand-configuring policies per client, the onboarding is assisted, not automated.

The honest edge cases sit at the boundary of the estate. Line of business applications with no API, on-premises equipment behind a firewall nobody documented, and vendors who will only speak to a person by telephone are all real, and all still consume human time. An MSP that says its onboarding is fully automated except for legacy line of business discovery is describing something we recognise. An MSP that says everything is automated with no exceptions is usually describing a demonstration environment.

Onboarding is where an MSP's marginal cost per client is set. In a traditional shop the first month consumes a disproportionate share of engineering capacity, which is why minimum seat counts exist: below a certain size the onboarding cost never amortises. Automating it changes the shape of the addressable market rather than just the shape of the profit and loss.

It is also the criterion that most reliably predicts the others. The information gathered during discovery is the substrate everything else runs on. Ticket triage cannot enrich against an asset record that does not exist. Documentation cannot stay current if it was never accurate on day one. An MSP with genuinely automated onboarding tends to satisfy several of the remaining criteria as a consequence, which is why we treat a strong claim here as a reason to look harder at the rest of the operation rather than less.

We ask what happens between credential provision and the first supported ticket, and specifically which of the steps above a person performs. Elapsed time is a useful secondary signal: an onboarding measured in hours or days is a different mechanism to one measured in weeks, regardless of how it is described.

We also ask what the technician review actually catches, because the answer distinguishes a check from a rebuild. An MSP whose reviewer signs off on nine environments in ten has automation. An MSP whose reviewer routinely reworks the output has a script.

Screenshots of a run, a redacted exception report, or a walk-through of the pipeline are all acceptable evidence. A description of intended future state is not.