Co-Managed IT Discovery: Agree Responsibilities Before the Proposal
Co-managed IT discovery should establish what the customer's internal team will own, what the MSP will own and how work moves between them. Ask about the desired outcome, current operating gaps, decision rights and service handoffs before preparing a proposal. Shared work needs explicit responsibility, not an assumption that both teams will handle it.
This proposed sales-discovery framework helps MSP owners evaluate co-managed opportunities. It is not a legal allocation of responsibility or a technical access plan. Qualified service, security and commercial reviewers should approve the final arrangement.
Understand why the customer wants a shared model
The buyer may need specialist capability, coverage, management support or capacity for a project. Ask which problem it wants the MSP to solve and what its own team intends to retain. Do not assume the customer wants a complete replacement simply because it is considering outside help.
ConnectWise's responsibility-matrix guidance discusses roles in MSP and MSSP environments. Its educational framing is useful: define the responsibilities relevant to the relationship, then use the appropriate agreement and expert review for your situation.
Ask how the buyer will recognize a successful shared service. The answer should guide the scope and working model, rather than merely the number of people or tools in the proposal.
Explore the handoffs that can fail
| Discovery area | Questions to resolve |
|---|---|
| Intake and triage | Where does work enter, and who decides its first owner? |
| Escalation | What evidence transfers with an issue, and who accepts it? |
| Changes | Who approves changes and coordinates customer impact? |
| Access | Who authorizes the required access and reviews its scope? |
| Communication | Who updates users and leadership when several teams are involved? |
| Exceptions | Who resolves work outside the agreed service boundary? |
Use a recent real workflow as a discussion aid. Ask the customer how it handled the work, where it waited and who made the decision. Avoid diagnosing an unverified problem simply to create a reason to sell.
Separate coordination from technical authority
A service coordinator can maintain the next action and customer update without having authority to approve a technical change. An internal IT manager can remain the customer decision owner while the MSP provides an agreed specialist service. Make those distinctions visible.
NCSC's MSP selection guidance includes access, privilege and contractual exit considerations. Treat those as topics for proper review, not details to leave until after the customer signs.
Do not request credentials during an initial sales conversation. Record the need for an approved access process and involve qualified people at the appropriate stage. Sales should understand the dependency without taking over its technical implementation.
Check whether the operating tools can support the model
Ask where tickets, decisions and documentation will be recorded. Each organization may need its own systems, but the shared workflow should have an agreed reference for status and responsibility. Avoid making the customer repeat information because each team assumes the other has it.
Confirm what can actually be integrated or shared under the available access and licensing arrangements. Do not promise a seamless system connection before the qualified team has validated it. A manual accepted handoff can be safer and more useful than an unreliable automation.
Illustrative example: both teams assume the other owns updates
Imagine an internal IT team escalates a server issue to its MSP. The MSP investigates while internal IT handles a related user issue. Each assumes the other is updating the business contact, so the customer receives no clear status.
Discovery can prevent this by agreeing who coordinates communication when work is shared. The technical teams retain their responsibilities, while a named operating owner maintains the customer-facing next step. The proposal then describes the actual working relationship instead of relying on a broad collaboration promise.
Make exclusions and dependencies discussable
Ask which activities require a separate scope, which customer inputs must be available and how urgent exceptions are handled. Explain the process for requesting additional work. Have the commercial and service owners review the language together.
A boundary should help the customer understand the relationship, not surprise it during a difficult incident. If a requested arrangement cannot be supported responsibly, say so and discuss a narrower or different option.
Validate readiness before committing to a start
Have delivery review the proposed scope, technical assumptions and customer dependencies. Confirm that the internal customer team has accepted its part. A salesperson should not promise an onboarding date based only on an available calendar slot.
Preserve unresolved questions as named actions. If the customer changes the division of work during negotiation, revisit the affected technical and commercial decisions. Do not let an earlier approved proposal become a different service through informal comments.
Use a controlled first review after launch
Once the agreed service starts, review a sample of handoffs, exceptions and customer updates. Confirm the documented responsibilities match how the teams actually work. This is a proposed operating check, not evidence that every co-managed model needs the same review frequency or staffing ratio.
Test the boundary with a familiar work scenario
Before presenting the final proposal, walk through an ordinary request with the customer's IT lead. For example, ask who receives a new employee request, approves the access, completes each task and confirms completion. Then discuss an after-hours exception using the actual proposed service boundary. If both parties expect the other to act, document the gap and resolve it before promising coverage. This is a commercial responsibility exercise, not permission to perform technical work. Keep the agreed outcome in the scope review so the sales conversation and service agreement remain aligned.
Escencion manages sales for MSPs and MSSPs, including discovery and opportunity follow-through. Discuss your sales process. Your team validates co-managed technical scope, approves commitments and delivers the technical service.
