Ownsteps

Ownsteps / Guides

MSP client onboarding checklist: what to document in the first 30 days

Reviewed .

The first month with a new managed-services client is when most of the documentation debt is created. You are busy fixing things, the client is sending requests, and the knowledge sits in one technician's head. Six months later someone else takes the ticket and has to rediscover how the firewall is reached, who may approve a password reset, and which backup job matters.

This guide gives a checklist you can copy and run for every new client, a short worked example, and a test at day 30. It works in any document tool or ticketing system.

What this checklist covers (and what it does not)

It covers what a second technician needs to take over the client without calling the first. It does not replace your PSA, RMM or password manager. Keep secrets in the password manager and write down only where they live and who may unlock them. For how to structure client procedures in general, see IT documentation for MSPs.

Client onboarding checklist

CLIENT ONBOARDING: [client name]
Owner: [account technician]    Start date: [date]    Review at: day 30

1. SCOPE
- Services in the agreement (e.g. helpdesk, patching, backup monitoring)
- What is explicitly out of scope
- Support hours and response targets

2. PEOPLE AND AUTHORITY
- Primary contact and backup contact
- Who may approve: new users, leavers, purchases, password resets
- How approval is given (email, ticket, call) and where it is recorded

3. ACCESS (names and locations only, never the secrets)
- Admin portals: where each is, which account type you use
- Where credentials are stored and who can unlock them
- MFA: who holds the second factor for shared admin accounts

4. INVENTORY
- Users and devices (or the system that holds the list)
- Servers, network gear, cloud tenants, domains and certificates with renewal dates
- Line-of-business applications and their vendors

5. BACKUP AND RECOVERY
- What is backed up, where, how often
- Who is notified when a job fails
- Last successful restore test (date, what was restored)

6. REPEAT PROCEDURES (one runbook or SOP per item)
- New user, leaver, password reset, new device, VPN or remote access
- Anything this client does differently from your standard

7. ESCALATION
- Client's after-hours contact
- Vendor support numbers and contract IDs (not logins)
- What counts as an emergency for this client

8. DAY-30 HANDOVER TEST
- A second technician completes two real tickets using only these notes
- Gaps found -> fixed in this document the same week

The two parts that save the most time later are people and authority (so nobody resets the wrong person's password on a convincing email) and the day-30 handover test, which turns documentation from "we wrote something" into "someone else could use it".

Example: a 20-person accounting firm

A structure example. Replace the systems and names with your own.

  1. Scope: Helpdesk 8:00 to 18:00, patching, Microsoft 365 administration and backup monitoring. Out of scope: the accounting application's vendor support and printers bought outside the agreement.
  2. Authority: The office manager approves new users and leavers by email to the helpdesk address. Password resets for partners need a call-back to a number already on file, not one in the request.
  3. Access: Microsoft 365 admin and the firewall are reached through named technician accounts; shared credentials live in the team password manager, vault "Clients". The second factor for the shared break-glass account is held by the service manager.
  4. Inventory: 22 laptops and 3 shared printers in the RMM; the domain renews each March; the tax software vendor's support contract number is in the contract notes.
  5. Backup: Microsoft 365 mailboxes and the file server are backed up nightly. Failures email the service desk queue. A test restore of one mailbox folder was completed on day 21.
  6. Procedures: New-user setup (with the firm's own licence and group choices), leaver account closure, and "partner laptop replacement", which differs because partners keep local tax files.
  7. Escalation: The office manager's mobile number for after-hours; an emergency means no one can reach the file server or email at all.
  8. Day 30: A second technician creates a new user and closes a leaver from the notes alone, and finds the licence group is wrong in step 4 of the new-user procedure. It is fixed that week.

Keep it usable

Procedures with screenshots

Many repeat procedures are clicks in a web admin portal: creating a user in Microsoft 365, adding a licence, adjusting a rule in a cloud console. A screenshot of each screen shows what the portal looks like for this client. Ownsteps is a Chrome extension that records webpage clicks, takes a screenshot at each, and builds an editable step-by-step guide on your computer. You can edit titles, delete detours, black out private areas and export Word, PDF, HTML or Markdown. It does not capture desktop applications, terminals or remote sessions, so steps in an RMM agent or on a server console need manual notes. Client screens often include names, tenant IDs and email addresses; check each screenshot before it leaves your team and see the redaction checklist.

Related templates

For an incident-style procedure with a stop condition and rollback, use the IT runbook template. For filled-in examples, see SOP examples. When a technician moves on, the employee handover document covers what to hand over.

Review checklist