Vendor-neutral guide · 9 min read

An MSP client onboarding checklist: from discovery to steady state

Written by the 247connect Marketing Team

Shape of the topic

A structured template with owner column and dates, an exception register and an approval stamp.A structured template with owner column and dates, an exception register and an approval stamp.
One template, many owners: sections, owners, dates and exceptions are what turn a document into an operating standard.

In short

The first weeks of a managed service relationship set the pattern for everything that follows. An MSP that skips discovery and jumps straight to deploying agents ends up managing an estate it does not fully understand, with documentation gaps that surface later as missed escalations or repeated questions to the client. This checklist sets out the sequence a thorough onboarding follows: discovery and audit, documentation, monitoring rollout, escalation paths, a defined first 30 days, and a clean handover to steady-state support.

Key takeaways

  • Discovery should happen before any tooling is deployed, not alongside it, so the rollout is built on an accurate picture of the estate.
  • Documentation created during onboarding is the single asset that determines how quickly future tickets get resolved.
  • Agent and monitoring rollout should be staged and validated, not pushed to every device at once.
  • Escalation paths need to be agreed and tested with the client before the first real incident, not discovered during one.
  • The first 30 days should have a defined structure with checkpoints, rather than drifting straight into business as usual.
  • Handover to steady state should be an explicit event with a named point of accountability, not an assumption that onboarding has quietly finished.

Discovery and audit

Before any agent is installed or any monitoring configured, the MSP needs an accurate picture of what it is taking on: how many devices, what operating systems and versions, what line-of-business applications are in use, what the network topology looks like, and what existing security controls, or gaps, already exist. Skipping this step means building a service on assumptions rather than facts, and those assumptions tend to surface as surprises during the first major incident.

Discovery should also cover the client's existing documentation, contracts and licences, since taking over management of software or hardware without knowing what is actually licensed or under warranty creates both cost and compliance risk almost immediately. Where the client has no existing asset register, building one is part of this phase, not a task deferred to later.

  • Full device inventory: hardware, operating systems, patch levels, warranty status
  • Network topology: routers, switches, firewalls, wireless, VPN and remote access configuration
  • Software and licensing: line-of-business applications, licence counts, renewal dates
  • Existing security posture: antivirus, backup coverage, MFA usage, prior incidents
  • Existing contracts and SLAs the client already holds with other vendors

Documentation

Everything found during discovery needs to be written down in a form the whole support team can use, not held in one engineer's head. This includes network diagrams, credential storage in a proper password manager rather than a spreadsheet, named contacts on the client side for different types of decision, and a summary of any known quirks or fragile systems that need careful handling.

Documentation created at onboarding tends to be the most complete it will ever be, because the person doing the discovery has just looked closely at everything. Investing properly in it here, rather than treating it as paperwork to catch up on later, pays back every time a ticket is raised by someone who was not part of the original onboarding.

  • Network diagram covering all sites and remote connections
  • Credentials stored in a shared, access-controlled password manager, never a spreadsheet
  • Named client contacts for technical, billing and emergency decisions
  • A living document of known issues, fragile systems and workarounds

Agent and monitoring rollout

Deploying monitoring and management agents should be staged, starting with a small pilot group of representative devices, validating that alerts, patching and remote access all function as expected, before rolling out to the full estate. A rollout pushed to every device simultaneously makes it hard to isolate the cause if something goes wrong, and a single misconfigured policy can then affect the whole client at once.

Alert thresholds should be tuned during this phase rather than left at default, since a monitoring platform that fires too many low-value alerts trains the support team to ignore it, which defeats the purpose of having it. Attended and unattended remote access should be configured according to the access policy agreed with the client, with named operator accounts and session logging in place from day one rather than added later.

Escalation paths

Escalation paths need to be defined and agreed with the client before they are needed, covering who is contacted for a routine ticket, who is contacted for a major incident, and what the client's own internal escalation chain looks like for decisions the MSP cannot make alone, such as authorising unplanned spend or approving downtime.

It is worth testing this path once during onboarding with a low-stakes scenario, confirming that contact details are correct and that the client's nominated decision-maker actually responds within the expected window. Discovering during a live outage that the named contact left the company months ago is an entirely avoidable failure.

The first 30 days

The first 30 days should have a defined structure rather than drifting straight into ordinary ticket handling: a week one check-in to confirm monitoring is working and documentation is complete, a two-week review of ticket volume and any unexpected findings from the estate, and a 30-day review comparing actual experience against the agreed SLA and scope.

This period is also when gaps in the original discovery tend to surface, additional devices found, undocumented systems discovered, or scope questions that were not anticipated. Building in scheduled checkpoints means these are caught and addressed early, rather than accumulating quietly until the client raises them as complaints.

  • Week one: confirm monitoring and agent coverage, verify documentation is accessible to the full support team
  • Two weeks: review ticket volume and early findings against the original discovery
  • 30 days: formal review against agreed SLA and scope, sign-off from the client sponsor

Handover to steady state

Onboarding should end with an explicit handover, not a gradual, unannounced shift into business as usual. This means naming the account owner responsible for the client going forward, confirming that the support desk has everything it needs without relying on the onboarding team, and formally closing out any outstanding onboarding tasks.

A short handover document, summarising what was found, what was configured, and what remains open, gives the steady-state team a clear starting point and avoids the common failure of onboarding knowledge staying with the person who did it rather than being transferred to whoever supports the client day to day.

Best-practice checklist

  1. 1. Complete a full discovery audit before deploying tooling

    Inventory devices, network topology, software licensing and existing security controls first.

  2. 2. Build or update the client's asset register

    Capture every device and licence found during discovery in a proper register, not a temporary note.

  3. 3. Document network topology and credentials

    Store diagrams and credentials in shared, access-controlled tools the whole team can use.

  4. 4. Pilot the agent rollout before full deployment

    Validate alerts, patching and remote access on a representative sample before rolling out fully.

  5. 5. Tune monitoring thresholds

    Adjust default alert settings so the team is not trained to ignore low-value noise.

  6. 6. Agree and test escalation paths

    Confirm contacts and response times with the client before a real incident, using a low-stakes test scenario.

  7. 7. Run structured 30-day checkpoints

    Hold week one, two-week and 30-day reviews against the discovery findings and agreed SLA.

  8. 8. Formalise handover to steady state

    Name the ongoing account owner and produce a handover summary of findings and open items.

  9. 9. Confirm remote access configuration matches policy

    Set up named operator accounts and session logging before day-to-day support begins.

Common pitfalls

  • Deploying monitoring and management agents before discovery is complete, missing devices or misconfiguring policies
  • Leaving documentation in one engineer's head rather than in shared, accessible tools
  • Rolling out agents to the entire estate at once instead of piloting on a representative sample
  • Never testing the agreed escalation path before a real incident forces it into use
  • Letting onboarding drift into steady state without a formal handover or named ongoing owner

What to measure

Metrics for MSP client onboarding checklist
Devices covered by monitoring at day 30Target 100% of discovered estate
Documentation completeness at handoverTrack against an internal checklist, target 100%
Escalation path tested during onboardingTarget yes for every new client
Tickets in first 30 days traced to discovery gapsTrack and review, aim to reduce over time
Formal handover completed with named ownerTarget 100% of onboarded clients

Select any column heading to sort.

Frequently asked questions

Why should discovery happen before deploying monitoring agents in MSP onboarding?
Deploying tooling before discovery means building the service on assumptions rather than an accurate picture of the estate. Discovery first ensures the rollout covers the right devices, respects existing configurations, and avoids conflicts with tools already in place.
How long should MSP client onboarding take?
This varies with estate size, but a structured first 30 days with defined checkpoints at one week, two weeks and 30 days is a reasonable baseline, with formal handover to steady-state support occurring at or shortly after the 30-day review.
Should agents be deployed to the whole client estate at once?
No. A staged rollout starting with a pilot group of representative devices allows alerts, patching and remote access to be validated before full deployment, making it far easier to isolate and fix problems if something is misconfigured.
What should be tested before onboarding is considered complete?
Escalation paths should be tested with a low-stakes scenario to confirm contacts are correct and response times are met, monitoring coverage should be verified against the full device inventory, and documentation should be checked for completeness by someone other than who created it.
What does a good handover to steady-state support look like?
It names an ongoing account owner distinct from whoever ran onboarding, produces a short summary document of findings and open items, and confirms the support desk can operate without depending on the onboarding team for basic information.
What is the biggest documentation risk during MSP onboarding?
Documentation being the most complete it will ever be at the point of discovery, then never being kept current afterwards. Building it thoroughly during onboarding and tying future updates to existing processes, such as changes and tickets, prevents it going stale.

Sources

Independent, standards-body and peer-reviewed material. None of these sources is affiliated with 247connect.

Putting it into practice

This guide is deliberately product-neutral. If you want to see how one implementation handles these requirements — attended and unattended access, named operator accounts, AES-256 encryption, audit logs and fixed pricing — the reference pages on this hub document 247connect in detail, and the product itself lives at 247connect.cloud.

What is 247connect?See a worked example

More best-practice guides