Operations

MSP client onboarding checklist: the first 30 days done properly

Every MSP client onboarding checklist promises a smooth first month. Most of them are really a list of forms. The estates that turn into unprofitable contracts are rarely lost at the sales stage: they are lost in the first 30 days, when unknown devices, inherited misconfigurations and unspoken expectations quietly become your problem. Here is how to onboard a new client estate so that does not happen.

Onboarding is where the margin is decided

The economics are simple. Every device you did not know about, every server nobody mentioned, every backup job that has been failing since before you arrived becomes a reactive ticket later. Reactive tickets are the most expensive kind of work an MSP does, and an estate you never properly baselined generates them for the entire life of the contract.

Industry surveys put a typical onboarding at 40 to 80 hours per client. That sounds like a lot until you compare it with the alternative: an engineer discovering, mid-incident and six months in, that the "backed up" file server was never in any backup job. The hours get spent either way. Onboarding is just the version where you choose when.

Before day one: agree what good looks like

The technical work goes wrong when the commercial groundwork is missing, so settle four things in writing before an agent touches a machine:

• Scope and exclusions. Which sites, devices and applications are covered, and, just as importantly, which are not. The printer nobody owns will find you otherwise.
• Response targets. Realistic SLAs by priority, plus the escalation path when something breaches them. Vague promises made in a sales call become disputes in month three.
• Access and offboarding the old provider. Domain admin credentials, Microsoft 365 global admin, firewall logins, DNS registrar, backup consoles. Get them transferred, tested and rotated. The outgoing MSP's accounts should be disabled on a date everyone has agreed.
• A named contact on each side. One person who can approve changes, and one engineer who owns the onboarding end to end.

Week one: deploy agents and trust nothing on the spreadsheet

The handover document says 47 devices. It is wrong. It is always wrong. Machines get bought outside procurement, old servers keep running because nobody is brave enough to switch them off, and the finance director's home laptop has a VPN profile nobody remembers creating.

So the first technical job is discovery, not configuration. Roll your monitoring agent out to everything you can reach, then reconcile what reports in against what you were told exists. The gap between those two lists is your first deliverable to the client: most of them have never seen an honest inventory of their own estate, and showing them one builds more trust in week one than any slide deck.

While the agents check in, capture the boring but vital facts per device: OS version and support status, hardware age, disk health, local admin accounts, and which machines are servers in function even if they are desktops in form factor. That last category is where future incidents live.

Baseline the risk: patching, protection and backups

With the inventory real, baseline the three things most likely to hurt you later.

Patching. Record the current patch level of every device before you change anything, so you can show movement. Expect the Windows side to look better than it is and the third-party side to be worse than anyone admits: browsers, PDF readers and conferencing tools sit outside Windows Update and are usually months behind. We covered why in our guide to third-party patching for MSPs.

Endpoint protection. Do not ask whether antivirus is "installed". Ask, per device: is it running, is it up to date, is real-time protection actually on, and when did it last report in? Inherited estates routinely contain machines where the AV is present but disabled, expired or pointing at a management server that no longer exists.

Backups. List every backup job, confirm each one has succeeded recently, and check the coverage in both directions: jobs that are failing, and machines that matter but appear in no job at all. A green console means very little on its own, as we argued in why a green tick is not a restore. If you do nothing else in week two, run one test restore.

A practical MSP client onboarding checklist

Condensed into one list you can lift into your PSA as a project template:

1. Contract signed, with scope, exclusions and SLAs explicit.
2. All credentials transferred, tested, rotated and stored in your documentation system.
3. Previous provider's access disabled on an agreed date.
4. Monitoring agents deployed to every reachable device.
5. Discovered inventory reconciled against the handover list; the gap reported to the client.
6. Patch, endpoint protection and backup baselines captured and dated.
7. Critical gaps (unsupported OS, unprotected machines, unbackuped servers) raised with the client in writing, with a remediation plan.
8. Alerting tuned before go-live, not after.
9. Service desk live: users know how to raise tickets, and the client portal or email route is tested.
10. 30-day review booked in the calendar before onboarding ends.

Point eight deserves a sentence more. Switching a monitoring platform on across an unfamiliar estate with default thresholds will bury your team in noise for a fortnight, and a noisy first fortnight teaches technicians to ignore the new client's alerts. Tune thresholds against the baseline you just captured; our piece on alert fatigue covers how to do that without missing real incidents.

The 30-day review closes the loop

Onboarding ends with a short, honest review meeting: here is what we found, here is what we fixed, here is what remains and who owns it. Bring the dated baseline and the current numbers next to each other. Clients rarely remember the individual tickets from their first month, but they remember being shown, in plain numbers, that their estate is measurably safer than when you arrived. That meeting is also where the first quarterly business review gets booked, which keeps the relationship proactive from the start.

Where this fits with Helios

Most of the checklist above is discovery and baselining, which is exactly the work a platform should be doing for you. Deploy the Helios agent across a new estate and the inventory, patch status, endpoint protection state and backup job health arrive in one view as devices check in, so the baseline snapshot is a report you export rather than a spreadsheet you build. Helio, the AI layer, then investigates the anomalies it finds in an unfamiliar estate rather than simply alerting on them, which matters most in exactly this period, when your team does not yet know what normal looks like for the client.