Onboarding a New Client Estate

Onboarding sets everything that follows. Done in a week under commercial pressure, it produces a noisy estate and a documentation gap that persists for years.

The commercial decision in “Onboarding a New Client Estate” is stronger when it rests on consistently recorded delivery effort rather than memory. An MSP can use the original source to relate time to clients, projects and recurring tasks, while keeping service quality, contractual scope and customer outcomes as separate measures.

For an independent operational benchmark, compare the local practice with official ITIL resources; the important test is whether the control remains proportionate, documented and recoverable when the usual technician is unavailable.

Before the agent

Agree the six answers from the questions note: scope, approvals, hours, billing, out-of-scope, exit.

Get them written and signed off.

This is the part that gets skipped when the client wants to start Monday, and it is the part that costs most later.

Discovery first

Find out what is actually there before deploying anything.

Its own note covers the methods.

Deploying agents to the machines you were told about and then discovering a third more is the normal experience, and the gap is where the problems live.

Agent deployment

In waves, not everywhere at once.

Start with a representative sample: an office machine, a laptop, a server.

Watch the alert volume from those for a week before widening, which is the cheapest tuning opportunity you will get.

Tuning before scale

The sample will generate noise. Fix it at ten machines rather than at three hundred.

Assign the client to a profile, record the exceptions, adjust thresholds.

Then deploy to the rest.

Reversing this order is the commonest onboarding mistake and it is entirely avoidable.

Documentation as you go

Every quirk discovered during deployment gets written down immediately.

The machine that cannot reboot, the application that breaks on update, the user who works nights.

Written at the time it is discovered, not at the end, because the end never arrives.

The baseline

Record what the estate looked like on arrival: patch levels, hardware age, backup state, security software.

Dated, with figures.

This is both your starting point for improvement and your evidence of what you inherited, which matters when something fails in month two.

Setting client expectations

Tell them the first month will surface problems that existed before you arrived.

Say it before you find them.

A client told in advance treats early findings as value; a client told afterwards suspects you caused them.

The thirty-day mark

Its own note covers the review.

At minimum: alert volume, outstanding exceptions, the baseline against current state, and what the client should know.

What to check

Does onboarding have a written sequence, or does it vary by technician?

Is discovery done before agent deployment?

Do you tune on a sample before rolling out?

And do you record a dated baseline of the inherited estate?

The point

Tune on a sample of ten machines rather than on three hundred.

Reversing that order is the commonest onboarding mistake.

Underlying all of this

Everything in this collection reduces to four habits: tune until every alert is read, verify rather than assume at every stage from ring one to script execution, treat the console as the privileged system it is, and know what each client costs you. None needs a better platform, and a provider doing all four runs a quieter service than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the appearance of control substituting for control. An unread alert queue looks like monitoring. A compliance percentage that excludes pending reboots looks like protection. A script that reports success looks like automation. In each case the provider believes a risk is handled and it is not, which is worse than knowing it is open.