The situation
Managed service providers sold and provisioned the AI add-ons. Now clients are asking the next question: how do we actually use this? Licence dashboards show low and uneven use. The service desk receives tickets that are not really technical faults (the assistant gave a wrong answer, it cannot see a SharePoint site, a manager wants to know whether staff may paste client data into it) and has no runbook for them.
There is a commercial opportunity in answering that question, and a reputational risk in answering it badly. An MSP that announces an “AI adoption service” without the skills to run it will find out on its best clients. The safer route is to define the service jointly, test it on one client, and only then decide whether to offer it more widely.
How the joint service works
Who owns the client. You do. The client relationship, licences, tenant administration and first-line support stay with you. I am introduced to the client by name as the specialist delivering the enablement work.
Who contracts. You contract with your client for the service; I contract with you under a partner agreement covering the pilot package and any later work. Client confidentiality and data terms flow down through that agreement.
Who delivers what. You provision, configure and support the platform. I deliver workflow enablement and integration: choosing workflows with the client team, checking that the data and permissions those workflows need are in place, coaching staff, building small integrations where scoped, and measuring results. Your consultants shadow the first pilot so they can run the next.
How specialists are approved. If a client needs something outside my scope, such as a security review, I name a specialist and their basis, and they start only with your and the client’s written approval.
How payment works. I invoice you on the contract day rate or for the scoped pilot package. You set the client price. Terms, including cancellation, are agreed in writing first.
The signature deliverable, illustrated
The escalation plan is the part MSPs most often lack. Illustrative example, not taken from a client:
| Tier | Handled by | Typical issues | Route onward |
|---|---|---|---|
| 1 | Your service desk | Access, licence assignment, “the assistant cannot see this site” | Tier 2 if not a permission or licence fault |
| 2 | Your trained consultant, using the pilot playbook | Poor answers on a known workflow, prompt patterns, which data may be used | Tier 3 for workflow redesign or integration faults |
| 3 | Dipankar, within agreed hours | Workflow redesign, connector or integration defects, new workflow requests | Platform vendor for product defects |
| Vendor | Platform vendor support, raised by you | Product bugs and service incidents | — |
The joint service boundary sits alongside it: a one-page statement of what the service includes, what it excludes and who answers for each part.
How acceptance is judged
The client’s pilot is accepted against measures agreed at the start: active use in the chosen workflows, time or quality changes against the baseline, and staff confidence. The service itself is accepted by you at the review: did the package, escalation plan and your team’s readiness hold up on a real client? A decision to stop is a valid result.
Ownership and handover
After the pilot, your service owner owns the offering, the playbook and the escalation plan. The client owns its workflows and internal champions. My role reduces to the third tier on agreed terms, or ends, as you choose.
When to choose something else
If you have a single signed project, see AI delivery partner for agencies and consultancies. For platform-specific readiness work, see Microsoft 365 Copilot adoption enablement or AI tool rollout and adoption support. All partner routes are on the partners overview.