RTFM-IT-Services-LLC {{COMPANY_NAME}} Client Onboarding
This skill is the source of truth for how {{COMPANY_LEGAL_NAME}} takes a signed client from "Closed Won" to steady-state managed service. The first 30 days decide whether the client feels the relief they were sold or starts wondering what they signed. Run this the same way every time.
Onboarding is also where {{COMPANY_NAME}} protects itself: the environment gets documented as-found before anything changes, and the paper gets verified before any work starts.
Defaults you must review: the specific numbers in this skill are shipped example defaults from a working MSP. Review and replace them with your own before anything goes client-facing.
How This Skill Divides Work With Its Siblings
- msp-sales hands off here at pipeline stage 7. Discovery notes (headcounts, device counts, pain points, promises made) are the onboarding inputs. Read them before the kickoff.
- msp-legal owns the paper gates below. If a gate fails, work does not start.
- msp-pricing owns the onboarding project price. Onboarding and migration are always billed separately at break-fix rates, never absorbed into the monthly. If the project was not quoted before signature, quote it now before scheduling work.
- msp-brand governs every message a client sees, including the welcome email below.
- msp-helpdesk is where the client lands at day 30: priorities, targets, and intake.
- msp-qbr picks up the roadmap seeded by the 30-day review, roughly 90 days in.
Gate Zero: Before Any Work Starts
Verify all of these. A missing gate is a stop, not a note.
- Countersigned MSA plus a signed Service Order (or SOW) on file for this client. Verify against the actual signed documents, not memory. (If your Service Order template is not yet finalized, whatever paper this client actually signed governs.)
- Onboarding project approved. Scope and price per msp-pricing, at break-fix rates. If the fee was waived or discounted under the bundle discount, the signed SOW must state the percentage and the signed Service Order must carry the clawback. A waiver that exists only in an email fails this gate.
- Regulated data check. Education, healthcare, financial, or legal clients: the DPA or BAA gate applies before {{COMPANY_NAME}} touches regulated data. If regulated data is in scope (student records, health information, financial data, and the like) and the DPA or BAA addendum is not signed, or you have not yet built one, escalate to the owner and msp-legal before deploying anything that touches that data. State privacy law and sector-specific regulation may also apply; that determination runs through msp-legal.
- Certificate of insurance sent if the client requested one.
- Discovery notes in hand from msp-sales: the counts the price was built on.
The 30-Day Runbook
Four overlapping phases. Days are targets, not law; the sequence is the law.
Phase 1: Kickoff and Access (Days 1 to 5)
- Send the welcome email (template below) within one business day of signature.
- Create the client in your PSA (ticketing) system: contacts, sites, agreement, billing setup matching the Order.
- Hold the kickoff call. Agenda: introduce the team, confirm the main point of contact and an emergency contact, agree communication channels, walk the credential list, set expectations for the next four weeks, confirm any scheduled downtime windows.
- Collect credentials (checklist below). Everything goes into the password vault immediately. Never store credentials in tickets, email threads, or loose documents.
- Establish how their staff will reach the help desk from day one, even while setup is underway.
Credential and access collection checklist:
- Their email and productivity platform admin (create a {{COMPANY_NAME}}-controlled admin, confirm a client-owned break-glass admin exists too)
- Domain registrar and DNS host
- Email security or spam filter portal, if any
- Firewall and router admin
- Switches and wireless access points
- ISP account numbers and support PINs, per site
- Backup platform
- Server and NAS local admin accounts
- Line-of-business applications, plus vendor support contract details and account numbers
- VoIP portal, printer and copier vendor, alarm and camera systems, as applicable
- Software license keys and any prior password manager export
- Previous IT provider contact, if a handoff conversation is possible
Phase 2: Deploy and Discover (Days 3 to 10)
- Deploy the RMM agent to every managed machine. Coordinate timing so nobody gets interrupted.
- Roll out your endpoint protection (EDR/AV) platform to managed computers. Account-only users have no managed endpoint; nothing deploys to their personal devices.
- Macs in the fleet: enroll in your Mac device management (MDM) platform per what was sold.
- Document the environment as found, before changing it. Asset inventory (RMM sweep plus a manual pass for what agents cannot see), server roles, backup status, patch levels, security posture. This baseline is protective in two directions: it proves what {{COMPANY_NAME}} inherited, and the MSA's ransomware cost allocation carries a negligence carveout, so a dated record showing the starting condition and {{COMPANY_NAME}}'s diligence matters if anything ever goes wrong.
- Test a backup restore. "Backups are running" is not the same as "backups restore." If there are no working backups, that is an urgent finding: tell the client in plain terms and quote the fix as a project immediately.
- Printer inventory: record every printer (make, model, connection type). Business-class networked printers go on the Managed Printer line (msp-pricing). Flag consumer-grade, inkjet, or USB-attached units as nonstandard: excluded from the monthly, best-effort hourly only, with a written replacement recommendation (a ~$300 business laser costs less than three nightmare tickets). Confirm vendor warranty status on covered printers so the liaison commitment is deliverable.
Phase 3: Stabilize and Harden (Days 8 to 20)
- Remove the previous provider's access: their RMM agents, their admin accounts, their remote access tools. Document what existed before removing it.
- Rotate shared and admin credentials into the vault.
- Enforce MFA on admin accounts at minimum; roll MFA to user accounts per what was sold.
- Set the patching policy and maintenance windows in the RMM.
- Check email security basics (SPF, DKIM, DMARC) and fix what is broken.
- Deploy ZTNA if it was sold.
- Remediate the backup gaps found in Phase 2.
Phase 4: Document, Review, Hand Off (Days 20 to 30)
- Finish the documentation set: network map, license inventory, vendor contact list, and the agreed process for adding and removing users.
- Tune monitoring so alerts are meaningful. An alert nobody acts on trains everyone to ignore alerts.
- Verify billing matches reality: the user and device counts now known versus the counts on the Order. Deltas go to the Change Order conversation (msp-legal and msp-pricing), raised plainly and early. Undiscovered devices are normal; silently absorbing them breaks the margin.
- Announce the help desk to the client's staff: how to reach support, what to include, what to expect (per msp-helpdesk).
- Hold the 30-day review with the owner or main contact: what was found, what was fixed, what remains as a risk, and a first sketch of the roadmap. This meeting seeds the first QBR.
Definition of done: all agents deployed and reporting, backups verified by a test restore, prior provider access removed, credentials vaulted, documentation set complete, billing counts verified, staff knows how to get help, 30-day review held.
When Discovery Diverges From the Deal
- Counts differ from the Order: raise it in the 30-day review at the latest. The fix is a Change Order, not a quiet subsidy and not a surprise invoice.
- Client declines a recommendation (MFA, a backup fix, replacing an end-of-life machine): get the refusal in writing. If you have not yet built a Risk Acceptance Waiver template, a plain confirmation email ("You have asked us not to X; our recommendation remains X because Y") is the minimum record. Flag the pattern to msp-metrics at review time.
- Prior provider is hostile or unreachable: document every attempt and every finding, change all credentials early, and keep the client informed in neutral language. Never badmouth them to the client.
Welcome Email Template
Apply msp-brand. Plain English, warm, no em dashes.
Subject: Welcome to {{COMPANY_NAME}}
Hi [First name],
Welcome aboard. We are glad to have [Company] with us, and we are ready to take IT off your plate.
Here is what happens next:
- Kickoff call. [Name] will reach out today to schedule a short kickoff, ideally this week.
- Getting set up. Over the first couple of weeks we will install our management tools on your computers, check your backups and security, and gather the account details we need. We will coordinate timing with you so nobody gets interrupted.
- Your new help desk. Starting [date], when something breaks or anyone has a question, email {{SUPPORT_EMAIL}} or call {{PHONE}}. That is the fastest way to reach us.
You do not need to prepare anything right now. We will bring a short list to the kickoff and walk through it together.
Thanks for trusting us with this.
[Name] {{COMPANY_NAME}} {{TAGLINE}} {{DOMAIN}} · {{INFO_EMAIL}} · {{PHONE}}
Setup Decisions
Values below are the shipped example defaults from a working MSP. Decide your own before this goes live.
- Client-facing support intake address. The example default is a single primary support address ({{SUPPORT_EMAIL}}) with an alias ({{SUPPORT_ALIAS_EMAIL}}) that also opens a ticket, and only the primary address gets printed in client-facing templates. Choose your own primary and alias addresses and update the welcome email and every other template accordingly.
Standing rule, unchanged: the 30-day arc and phase timing above are internal rhythm, not a client promise. Do not commit dates in writing beyond what the onboarding project scope states.