The First Thirty Days With a New Client

The first month determines the shape of the relationship and the noise level for years. It is also the only period when the client expects disruption.

The commercial decision in “The First Thirty Days With a New Client” is stronger when it rests on consistently recorded delivery effort rather than memory. An MSP can use the detailed explainer 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.

Week one

Agents on a representative sample.

Watch the alert volume and categorise it.

Do not act on everything — most of it will be noise, and acting on noise sets an expectation you cannot sustain.

Record the baseline: patch levels, backup state, hardware age, security software.

Week two

Tune against what week one produced.

Assign the profile, record the exceptions.

Deploy to the rest of the estate.

Begin the documentation: five headings, filled as things are found.

Week three

Reconcile: agents against directory, against the client's count.

Chase the gaps.

Start on the inherited problems in priority order — unsupported systems, failed backups, missing patches.

Tell the client what you are finding, as you find it.

Week four

The review: alert volume, coverage, the baseline against current state, outstanding exceptions.

A written summary to the client: what we found, what we have fixed, what remains, what needs a decision from you.

That document is the single most valuable thing produced in the first month, both as evidence of value and as a record of what you inherited.

What to tell the client in advance

The first month will surface problems that existed before you arrived.

Alert volume will be high initially and will fall.

Some things will need their decision, and you will ask early.

Said before you start, these are reasonable. Said afterwards, they sound like excuses.

The temptation to fix everything

An inherited estate will have a long list of defects.

Fixing all of them in month one consumes the margin for the year and sets an expectation of unlimited remediation.

Prioritise, present the rest with costs, and let the client choose.

The handover inside your own team

Whoever onboarded knows things the service desk does not.

A structured handover at day thirty, with the documentation as the artefact.

Skipping it means the knowledge stays with one person, which the documentation note covers.

What to check

Does your onboarding have a thirty-day review?

Is there a written baseline of the inherited estate?

Does the client receive a summary at the end of month one?

And is there a handover from onboarding to the service desk?

The point

The first thirty days is when tuning is cheapest and the client still expects disruption.

It sets the noise level for years.

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.