Onboarding is where the margin on a new client is won or lost. Do it properly and the next three years are quiet. Do it in a hurry and you spend those years discovering things you should have found in week one, on tickets you cannot bill for.

This is the full sequence, grouped the way the work actually runs. It assumes a small or mid-sized business client with somewhere between fifteen and a hundred and fifty users. If you are taking the client from another provider rather than starting fresh, the credential handover has its own set of problems, and those are covered in the takeover playbook.

1. Before you touch anything

The work that prevents arguments later is all commercial, and none of it is technical. Get it done in the days between signature and kickoff.

Scope written down in plain language, including what is not covered and what is billed hourly
Response and resolution targets agreed, in writing, with the hours they apply to
After-hours definition and what it costs
Named decision maker, named day-to-day contact, and who can approve spend
Billing set up: invoicing address, payment terms, purchase order requirements if they use them
Your own project lead assigned, with the hours blocked in their calendar
Kickoff meeting scheduled with the client's leadership present
Cutover window agreed, in writing, with the client's operational calendar checked against it

Check the client's calendar before you set the cutover. Every business has a week that cannot be disturbed, and nobody volunteers it. Ask what their busiest month is and when they close their books.

2. The kickoff

One meeting, forty-five minutes, with the client's leadership and whoever their staff go to when the printer stops. That second person knows more about the environment than the owner does.

Cover four things:

What happens and when. The phases, the dates, and the one or two moments where users will notice something.
How to reach you, starting now. The portal, the email address, the phone number, and which one to use for what.
What you need from them. Access, a point of contact for each line of business application, and thirty minutes of someone's time during discovery.
What you will bring back. Tell them a written findings report is coming at day thirty. It sets the expectation that the first month produces something, and it makes the follow-on work an easier conversation.

3. Discovery

This is the part people shorten when they are behind, and it is the part that costs the most to skip. Everything you fail to find now, you find later during an outage.The questions we work from are in the IT assessment question bank.

Assets

Every server, workstation, laptop, and tablet, with serial number, purchase date, and warranty expiry
Operating system version and patch level on each
Anything running an unsupported operating system, listed separately
Printers, copiers, scanners, and who holds those leases
Phones and anything else that connects and holds company data

Network

Topology diagram, IP addressing scheme, and VLAN layout
Firewall model, firmware version, and support contract expiry
Switches and access points, with age and end-of-support dates
ISP, circuit type, contract end date, and what the failover is
Wi-Fi coverage, and where the staff say it does not work
Every inbound firewall rule, with an explanation for each one

Identity and licensing

Tenant inventory: user accounts, shared mailboxes, distribution lists, guest accounts
License count against actual headcount, and what is being paid for and unused
Every account with administrative rights, and why it has them
MFA coverage, expressed as a number, not as a yes or no
Conditional access policies, if any exist
Accounts belonging to people who no longer work there

Backup and continuity

What is backed up, where it goes, and how often
What is not backed up, which is usually the thing that matters
Retention policy, and whether it matches any obligation the client has
Date of the last successful restore test, and a restore you run yourself
Recovery time and recovery point the client believes they have, next to the ones they actually have

Applications and obligations

Every line of business application, its version, and who supports it
Vendor contacts and account numbers, including who is authorized to call
Anything running on a machine under someone's desk
Compliance obligations: HIPAA, CMMC, PCI, state privacy law, industry requirements
Cyber insurance policy, and the controls it says they have in place

Read the cyber insurance application. Clients routinely attest to controls they do not have, which means the policy would not pay. Finding that in week two is a service. Finding it after an incident is a lawsuit.

4. Documentation

Discovery produces information. Documentation is what makes it survive the technician who found it. Everything from the previous section goes into your documentation platform as you find it, not in a batch at the end of the month.

Credentials into your vault, with MFA on the vault itself and access scoped to who needs it.
A network diagram someone who has never been on site could follow.
Runbooks for the recurring jobs, particularly anything currently held in one technician's head.
A short page on how this client is different: their quirks, their busy season, who to call after hours, who not to.

The test for whether documentation is good enough is simple. Could a technician who has never seen this client resolve a common ticket at nine on a Monday using only what is written down? If the answer is no, it is notes rather than documentation.

5. Your tooling

Getting your stack onto the environment is mechanical. The part that needs attention is the reconciliation at the end.

RMM agent deployed, checking in, and reporting accurate inventory
Agent count reconciled against the asset list from discovery, with every gap explained
Patch policy applied, with a maintenance window the client has agreed to
Endpoint protection deployed, and the previous product fully removed rather than disabled
Backup agent installed and the first full backup completed and verified
Monitoring alerts routed into your ticketing system, not into an inbox
Email security and filtering in place, with the client told what quarantine looks like
Client, sites, contracts, and users all set up in your PSA
Users able to log into the support portal, and shown how

The reconciliation is the whole point of this phase. Your agent count will not match the asset list on the first pass. The difference is a machine in a closet, a laptop with someone on leave, or a server nobody mentioned. Chase every one of them to a written answer.

6. The security baseline

Set the floor you are willing to support, and get there in the first thirty days while you still have the client's attention and their tolerance for change.

MFA on every account, with each exception documented, time-limited, and signed off by the client
Administrative accounts separated from the accounts people use for email
Stale accounts disabled, and their mailboxes converted or archived
Local administrator rights removed where the client's software allows it
Disk encryption enabled on laptops and confirmed with the recovery keys escrowed
Unexplained firewall rules removed
Password policy set, and the client's own policy document updated to match
A written joiner, mover, and leaver process, agreed with whoever handles HR

Where the client refuses something, write down what they refused and when. Not to build a case against them, but because in two years someone will ask why local admin rights are still in place, and the answer should be a date and a decision rather than an oversight.

7. The people

Every technical box can be ticked and the client can still be unhappy at day thirty, because the only thing most of their staff experienced was a stranger changing things on their computer.

Walk the floor. A morning on site, desk by desk, asking people what is annoying. You will get a better list of problems in two hours than the owner will give you in a month, and the staff will remember that you asked.
Learn who is who. Roles, who the informal fixers are, who genuinely cannot wait when something breaks.
Train them to use the right channel. Users go to whoever helped them last. A short note from the client's leadership, plus you actually being responsive on the official channel, is what changes that.
Tell them before, not after. One page from client leadership before the cutover: what changes, what does not, what needs their attention.

8. Day thirty

Close the onboarding formally rather than letting it fade into ordinary support. Sit down with the client and bring three things.

What you found, fixed, and left open. Written, with the open items dated and owned.
The risk register. Everything that needs money to resolve, with what it costs and what happens if it is deferred. Aging hardware, expiring warranties, unsupported software, the backup gap, the insurance mismatch.
A twelve-month roadmap. The refresh schedule, the renewals, and the projects, laid out by quarter with a budget attached.

Book the first quarterly review before you leave the room. Then do one more thing that has nothing to do with the client: work out what the onboarding actually cost you in hours against what you priced it at. That number is the only way your next proposal gets more accurate.

Where these go wrong

Five failures account for most of the onboardings that run long:

The agent count never gets reconciled. Nobody notices until the unmanaged machine is the one that gets encrypted.
Nobody runs a restore. A green dashboard is a report about a backup, not a test of one.
Scope creeps in week two. The small favor becomes the expectation. Log the request, quote it, and let the client decide.
The owner is the only contact. They do not know what breaks daily, and they are the hardest person to get thirty minutes from.
Discovery is never written up. The findings stay in the technician's notes, and at day thirty there is nothing to present, so there is no follow-on work.

Thirty days is a target, not a promise. What extends it is almost always waiting on someone else: an outgoing provider, a software vendor, a license transfer, an owner who is traveling. Track those separately from your own work, so that when the timeline slips you can show exactly where it slipped and why.