Onboarding a Client in 30 Days

Before Day One

The onboarding starts the day the agreement is signed, not the day the first agent is installed. Three things happen that week: the client names one person who can approve access, you name one person who owns the onboarding, and the two of them put a thirty-minute call in the diary for every Friday of the month. The shared checklist goes to the client on that first call so they can see what is coming and what you need from them.

Week One: Discovery and Access

The goal of week one is that you can see everything and change nothing. Collect the credentials for every system into your password manager under the account, and record who gave them to you and when. Inventory what is actually there rather than what the proposal assumed: endpoints, servers, tenants, domains, line-of-business applications, and whoever still has admin rights from three IT providers ago.

• Global admin on the identity tenant, held by you, with MFA enforced on it the same day.
• Domain registrar and DNS access, because the day you need it will be an outage.
• A list of every vendor the client pays for IT, with the renewal dates.
• The people list: who is a user, who is a decision maker, who is leaving.

Friday: walk the client through what you found. Most first-week calls include a surprise, and it is better delivered as a finding than discovered later as a fault.

Week Two: The Stack

Deploy your tools, in the order that lets the next one work: RMM agent first, so you can see the machines; then endpoint protection, so you are not deploying into an unknown state; then backup, with a test restore before you call it done; then the documentation platform, filled from week one's inventory. Every device that does not take the agent goes on a list with a reason, and that list is a Friday agenda item, not a surprise at the end of the month.

Do not fix things in week two beyond what the tools need. The client asked for a plan, not a flurry.

Week Three: The Cleanup

Now the changes. Remove the previous provider's tools and accounts, and the shared admin accounts that always turn up. Bring patching to a baseline and say what that baseline is. Put MFA on the accounts that lacked it, in the order that upsets the fewest people: admins first, then finance, then everyone, with a message from the client's own approver a day ahead. Every change gets a ticket, because the ticket is how the desk learns the account in week four.

Week Four: The Handover

The onboarding is finished when the desk owns the account, and the handover meeting is where that happens. The project engineer walks the desk lead through the documentation, the open items, the people, and the three things about this client that will generate tickets. The desk lead signs off, or names what is missing. Then the client gets a closing call: what was found, what was fixed, what is on the list for the next quarter, and how to reach the desk.

1. Documentation reviewed by somebody who did not write it.
2. Every device accounted for: covered, excluded with a reason, or scheduled.
3. The first quarterly review booked, with the week-one findings as its first agenda.
4. The onboarding project closed in the PSA, so its hours stop landing on the account.

What Goes Wrong

Onboarding overruns for two reasons, and both are decided in week one. The client's approver is too busy to approve, so access arrives in week three and everything slides. And the owner on your side is also the engineer doing the work, so the Friday calls stop when the work gets busy. Name a different owner, keep the Friday call even when there is nothing to report, and the month stays a month.