CR-02 Field guide / Client relationships
Client onboarding after go-live: the first 90 days
The first live support request tests the handoff better than a welcome email. The next 90 days need a service owner, a short evidence register and a place for unresolved work to go.
For Service manager, Tech lead, Account management, Service desk & technicians
On this page
Make the go-live boundary explicit
Record the services now active, exclusions, work still owned by the outgoing provider or client, and the route for urgent help. Resolve any disagreement between the sold scope and the delivery handoff before it becomes a surprise invoice.
Adam Hannemann's first-90-days article treats observation and communication as continuing work after launch.[1] His onboarding article also discusses a repeatable handoff.[2] Use the first month to check what the desk can actually support, the second to fix selected causes, and the day-90 conversation to agree the ongoing arrangement. Serious access, recovery or service failures need action when found, regardless of the checkpoint date.
Post-go-live evidence checklist
For every row, record a status, safe evidence reference, check date, owner and next action. The check below describes the evidence to obtain; it does not authorize a production change.
| Check | Evidence to obtain |
|---|---|
| Support route | A user can reach the agreed channel; urgent requests reach the right queue. |
| Service hours and escalation | Desk, client and after-hours contact understand who owns each window. |
| Sold scope | Included work, exclusions and outstanding project items match the handoff. |
| Registrar ownership | Client's authorized representative confirms the registrar account owner and renewal responsibility. |
| DNS ownership | Record the DNS host, change authority and support route; verify access through the approved process. |
| Administrative access | Authorized support staff can use the approved access method for systems in scope. |
| Emergency access | Technical owner completes an approved verification and records result, date and secure reference, never secrets. |
| Line-of-business support | Record application owner, vendor contact, support entitlement and escalation hours. |
| Critical dependencies | Map the business process to its application, identity, network and hosting dependencies. |
| Backup responsibility | Identify protected systems, exclusions, retention and who acts on failures. |
| Restore evidence | Obtain a recent authorized restore-test record with scope, result and unresolved failures. |
| Recovery handoff | Service team can find the recovery instruction and accountable owner. |
| Licence true-up | Reconcile purchased, assigned and billed quantities; explain mismatches and renewal dates. |
| Agent inventory | Reconcile expected assets with RMM/security/backup coverage and check-in age. |
| Stale or duplicate agents | Confirm whether each suspect record is retired, offline or duplicated before removal. |
| Documentation | Another technician can find ownership, support and dependency records. |
| Monitoring handoff | A controlled, authorized test reaches the responsible queue with a receiving owner. |
| User impact | Check the outcome of the first significant fixes with affected users. |
Emergency access is especially easy to mistake for a box already ticked. Microsoft recommends regular validation that authorized staff can use Entra emergency accounts.[3] Follow the current vendor guidance and the client's approved procedure; a register should hold the verification result and restricted evidence reference, not passwords, recovery codes or authentication material.
For agent inventory, NinjaOne documents Contact Time as time since agent communication with the device server.[4] That is a check-in signal, not proof that an endpoint is disposable or that every protection tool works. In NinjaOne, Datto RMM or another RMM, verify the available fields in your version and reconcile against the expected asset list. Keep removal decisions separate from the inventory review.
First month: inspect the actual support route
Read the first real requests. Could the technician find the application owner? Did the client know which work was included? Was a restore-test record present, or only a successful backup-job status?
Group repeated contacts by affected work. "Finance export stalls after the update" gives the technical lead something to investigate. "Finance calls too often" gives them a label without a cause.
Keep unknowns visible. A missing vendor support contact gets a discovery owner; it should not disappear into a general documentation score. Store actions in the onboarding project or service queue in your PSA. Autotask, ConnectWise PSA and HaloPSA are examples; use the fields your version provides for owner, due date, status and receiving queue.
Second month: fix causes and check the result
Separate service corrections from new project work and standards exceptions. For a fictional remote-access problem, deploying a configuration is only the change step. Confirm the affected users can complete their normal work and record the result.
Track stabilization effort separately from expected recurring service. A busy first month may contain one-time discovery, but a weekly manual workaround can also be a recurring cost hiding under "onboarding". Check which it is before using that month in a staffing or profitability review.
An exception needs a reason, safeguards, decision-maker and review date. Lack of a client response leaves the decision open; it does not create acceptance.
The working discipline
Automate before you hire
Standardize the post-go-live evidence list and automate reminders for missing checks and approaching handoff dates. Technical and service owners still verify access, restore outcomes, client impact and acceptance; a completed task flag cannot stand in for that evidence.
Review the sequence →Worksheet / Usable takeaway
Day-90 handoff record
- Active arrangement: [services / hours / support route].
- Checks still unknown: [evidence needed / owner / due date].
- Service corrections: [outcome tested / remaining impact].
- Exceptions: [reason / safeguards / authority / review date].
- Recurring work: [service owner / queue or standard reference].
- Roadmap decisions: [business reason / dependency / cost basis].
- Client decision: [accept arrangement / accept with open actions / resolve gap].
- Next review: [date or event].
Transfer remaining work to a receiving owner who accepts it. The post-go-live sheet includes this checklist, so the evidence can travel with the handoff instead of staying in a guide tab.
Sources
The first 90 days after MSP go-live
Mastering MSP client onboarding
Microsoft: emergency access accounts
NinjaOne: devices search columns
Source notes: Oct 2026. See method and evidence notes.