Before co-managed IT onboarding, a tool deployment can look like a completed service. After a proper handover, your desk and the client's IT person can demonstrate how agreed work reaches whoever must act. I'd make that demonstration the acceptance check. An installed agent doesn't establish a working shared service.
I'd cut seamless onboarding from the sales promise until the team can show the client's part of the job. A signature isn't a handoff. Agree what each team owns, then test that arrangement before telling users that ordinary support has started.
Make the Sold Service the Starting Point
Have the delivery lead compare the accepted scope with the internal IT team's expectations. Resolve any mismatch with the sponsor before deploying tools or granting production access. A client contact can help with discovery without having authority to approve a wider service.
Name the MSP onboarding lead and the client's IT lead. Give both a route to someone who can settle decisions beyond their authority. The project needs a way to clear a blocked decision when neither delivery lead can make it alone.
Erick Simpson recommends explaining support during onboarding and agreeing when ordinary service commitments begin. Keep that as his practitioner suggestion. For a shared environment, I'd record the interim support arrangement beside the planned handover so users aren't left between teams.
Don't turn the kickoff into approval for every later change. Keep the accepted scope available to the engineers and record new decisions where the work happens. If a responsibility changes, have the right client approver confirm it.
Use a Shared Checklist With Observable Results
Put the checklist in the onboarding project rather than a separate presentation. Give each action an owner from the relevant team. Attach the result that will let both sides check whether it is ready.
| Onboarding Work | Who Confirms It | Evidence for the Handover |
|---|---|---|
| Scope and Interim Support | The MSP onboarding lead and client sponsor | Both teams agree the work being transferred and who supports users during the project. |
| Environment Check | The technical lead with the client IT lead | Material differences from discovery are recorded and assigned. |
| Approved Access | The access owner with the client approver | Named people can perform the agreed work within their authorized permissions. |
| Tooling Changes | The tooling owner with the client IT lead | Management scope and approved configuration changes are documented. |
| Shared Request Route | The desk lead and client IT lead | A test request reaches its recipient with enough information to act. |
| Monitoring Response | The service lead and responsible client contact | The relevant notification reaches the team assigned to respond. |
| Exceptions and Review | The onboarding leads with the sponsor where needed | Open limits have an approved treatment and a named next owner. |
| Service Start | The desk lead and client approver | The accepted support arrangement and start date are communicated. |
Keep client exceptions visible instead of forcing every item into a completed status. A partial start needs explicit approval and a support arrangement for what hasn't transferred. The desk shouldn't have to infer the limit from an engineer's private notes.
The model calls for a standard technology stack and training the team on it. If a retained client tool conflicts with that approach, make it a technical and commercial decision. Don't quietly promise a permanent exception or remove existing coverage just because your agent is ready.
Prove That Work Can Travel in Both Directions
Picture a client retaining routine support while your MSP handles agreed specialist escalations. Ask the internal IT lead to submit a clearly identified test request through the chosen route. Have the receiving technician confirm that it arrived with the information needed for the agreed work.
Then send a result back through the same working arrangement. Have the client's IT lead open it and identify the next task. Sending a message isn't proof the recipient can see the case or act on it.
Record where the exercise failed and give the correction to a named person. Repeat the affected check after the correction. The exercise should establish the workflow without requiring an unapproved production change.
Nick Clift describes discussing a shared request process with customers and supporting it with training and documentation. He also describes a client with a fixed process that required custom work from the MSP. His account is a reason to inspect the client's actual constraints before assuming your preferred route can be imposed.
I'd cut a duplicate request channel if it creates work nobody has agreed to watch. First check who uses it and what must replace it. A cleaner diagram of the process won't help if staff keep sending work to the unattended route.
Show Who Responds After the Tool Detects Something
The model uses RMM automation as its default NOC arrangement, with residual alerts reaching the desk. In a shared environment, apply that model to the work you've actually accepted. Confirm what remains with the client and how relevant findings pass between teams.
Use an approved test method for the notification route. The receiving team needs to identify the affected service and know what response is covered. A successful installation doesn't answer either question.
Check that the person receiving the work has the authority and access to act. Where they need another team's decision, test that escalation too. Keep the route consistent with the service commitment rather than relying on whoever happens to notice the notification.
Marketing can't staff an unassigned response. Don't describe monitoring as a complete service unless delivery can explain what happens after detection. Have the service lead settle that gap before the wording reaches users.
Use the Meeting to Resolve Work
Brian Largent describes recovering stalled co-managed project work by tracking it in the provider's system and reviewing progress and ownership weekly. He recommends taking repeated missed commitments to client leadership. That's his operating account, not proof that a calendar invitation fixes a client's management.
If you use that weekly rhythm, bring the blocked decisions to it. Give the person who can decide enough information to choose the next action. Save the decision against the project so the absent technician can follow it later.
I'd cut the second status deck when it repeats a project record both teams can already use. Confirm the client's access before dropping the alternative. A shorter update only helps if the people doing the work can still find what they need.
Count Readiness Where the Work Is Recorded
Count accepted checks and unresolved exceptions in the onboarding project. Group open exceptions by the responsibility they affect, so a large completed-task total can't conceal a broken support route. Record who approved any remaining limitation.
Have the MSP service lead and client approver agree the acceptable unresolved-check limit before judging the handover. Keep that number and the mandatory conditions in the acceptance record. A count above their agreed limit would make me withhold the handover, even if the deployment report looked complete.
After service starts, count work returned because the receiving team lacked information. Read those cases to establish whether the handoff was unclear or something unrelated caused the problem. A lower count doesn't prove the onboarding caused the improvement.
Use the next shared onboarding to demonstrate the request route with the internal IT lead. Resolve failed checks or record the authorized limitation before confirming the start. Then tell users how to get the service the two teams have shown they can deliver.
mspoutpost.com/articles/co-managed-it-onboarding-prove-the-shared-handoff
Written by Owen Gallagher
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.