K7 Insights
How to Scope an AI Project for Your MSP Clients
Part of Grow Your MSP
Key takeaways
- Start with one client workflow and a person who can explain what a useful result looks like. Paid discovery should leave them with enough information to decide whether to build.
- Write down the systems and users included, along with the work you're leaving out. A request to connect another system changes the scope even when the client calls it a quick addition.
- Agree on acceptance before implementation. Test real work, including missing information and exceptions, and count the time people spend checking the output.
- Give delivery a named owner and hand the finished workflow to someone at the client. Agree separately on the continuing support you're willing to provide.
To scope an AI project for an MSP client, agree on one business workflow and write down how you’ll know it’s finished. Charge for the discovery needed to understand that work before you commit to the build. Then define who delivers it and what support follows. A client asking you to “put AI in our CRM” has started a conversation. You still have to turn that request into work your team can finish. That’s part of growing your MSP without leaving every new promise on the owner’s desk.
What problem is the client actually asking you to solve?
Find the task they want to do better, and have the person who does it walk you through it. A request for a particular AI tool gives you a starting point. You need to understand what the client expects to be different once it’s connected.
During the cybersecurity wave, I got frustrated with how often we’d project our wants onto customers without asking what they wanted. I raised that concern in TopLeft’s September 3, 2026 webinar because we can repeat the same mistake with AI. We arrive ready to talk about our priorities, and the client still hasn’t explained theirs.
Say a sales manager asks for AI in the CRM. Sit with a rep as they prepare for an account call. Where do they look for the last conversation? What do they copy into their notes? What happens when the record is incomplete?
Now you might have a project: help five reps prepare an account brief from the information they’re already allowed to use. You can discuss the data and permissions that task requires alongside the result the manager wants.
Keep asking until the manager can tell you what would make the work worth paying for. “Our reps spend less time preparing, and they’re still prepared” is a useful direction. You’ll need a baseline and an agreed target before it becomes a promise.
What should paid AI discovery deliver?
Paid discovery should give the client a decision they can make: proceed with a defined build, resolve a dependency first, or stop. Give discovery its own scope and deliverables so the client knows what they’re buying even if implementation never happens.
In the same webinar, John Harden argues for charging for discovery, including the work of identifying and prioritizing a use case. He’s right about charging for that work. Sitting with employees and figuring out what a project would require takes time, and the findings have value of their own.
For a single workflow, I’d leave the client with:
- A description of how the task works today, including who’s doing it and a measured starting point.
- A proposed first build, with the users and systems included and the exclusions written beside them.
- The access and data the client must provide, plus unresolved dependencies that could change the plan.
- A proposed acceptance test and an implementation estimate based on what you’ve actually learned.
Agree on the discovery allowance and the point where you’ll review unresolved questions. If the CRM data turns out to be unusable, explain the cleanup required and let the client decide whether to fund it. Don’t let discovery quietly turn into the cleanup project.
This fits the consultation phase of your MSP sales process: understand the situation well enough to recommend the next commitment. You’re allowed to recommend that they spend no more money on this idea.
What does a bounded AI project scope look like?
A bounded scope names the work you’re delivering and the point where it ends. It also makes the assumptions visible. Someone who wasn’t in the sales meeting should be able to read it and understand the promise.
Here’s a hypothetical scope for that account-briefing workflow. The numbers are planning choices for this example; you’d agree on your own after discovery.
| Scope item | Illustrative agreement |
|---|---|
| Business task | Help sales reps prepare an account brief before a customer call. Measure preparation time, including checking and correcting the brief. |
| People included | Five named reps and their sales manager. |
| Inputs | Approved records from one CRM, using each rep’s existing access permissions. The client identifies the records and fields the workflow may use. |
| Output | A draft brief linking back to its source records. The rep checks it before the call. |
| Exclusions | Email and calendar connections, sending messages, changing CRM records, and adding other departments. |
| Pilot | Two weeks after the agreed access and sample records are ready. The sales manager reserves time for the reps to participate. |
| Acceptance | The agreed functional tests pass, and the client reviews the measured result against the preparation-time target set during discovery. |
| Handoff | A short operating guide, a working session with the reps, and a named client owner who can stop the workflow and use the previous process. |
Put the implementation estimate beside that scope. Have the person responsible for delivery check it, including the time for testing and training. If a specialist partner is doing the build, get their estimate and availability before you commit to a date.
The exclusions deserve a conversation. In the webinar, I warned about the next request arriving immediately: you’ve connected Claude to Salesforce, and now the client wants Microsoft 365 added “real quick.”
It’s an understandable request. The client sees another useful thing the workflow could do. You’re the one who has to explain the additional work before your team takes it on.
Write the request down, assess its effect on the cost and schedule, and get agreement before adding it. You can queue it for a later phase. You can also replace part of the original scope if everyone agrees. A friendly yes during a demo shouldn’t rewrite the project for the engineer who wasn’t there.
If you’ve got a client project at this stage, bring the proposed scope to a call. We’ll work through the business promise and who’s responsible for keeping it, including where the engagement ends.
Who owns the work on each side?
Name one delivery lead at your MSP and one decision-maker at the client. Then assign the work each depends on. “The client will provide access” is too vague when nobody knows which person can approve it.
Your delivery lead owns the implementation plan and coordinates any specialist partner. They’re also the person who raises a dependency when it threatens the date. An advisor who found the opportunity can stay involved, but someone with the ability to deliver the build needs to accept that responsibility.
The client’s owner approves the workflow and arranges the people needed to test it. They get the right person to authorize access. In our example, the sales manager also has to give five reps time to try the briefing process. You can’t learn whether it helps if everyone is too busy to use it.
Your vCIO may be well placed to keep those decisions moving. That still leaves a separate question: who’s doing the implementation work, and have they agreed to it?
Put client dependencies on the schedule. If access arrives a week late, revise the plan with the client. Your delivery team shouldn’t discover they’re expected to absorb that week on Friday afternoon.
How do you agree that an AI project is finished?
Agree on acceptance criteria before the build, then test the workflow against them with the client. Include both whether it works as specified and whether it helps with the task you set out to improve.
For the hypothetical account-briefing project, I’d propose these tests:
- Use 20 client-approved sample records covering ordinary accounts as well as incomplete and conflicting information. Agree in advance on what a usable brief must contain.
- Check that each brief identifies the correct account and lets the rep trace factual statements to the source records. Missing information should be called out so the rep can investigate it.
- Test the permissions with the agreed user roles. A rep who can’t access an account in the source system shouldn’t receive its information in a brief.
- Have the five reps complete the task, including checking and correcting the output. Compare that time with the baseline and the target you agreed during discovery.
- Have the client owner stop the workflow and return to the previous process. They need to be able to keep working when it’s unavailable.
Those are recommended tests for this example. The delivery lead and client need to add the cases their actual workflow requires. Twenty samples alone can’t prove how every future input will behave.
Decide what a failed test means before testing starts. A defect against the agreed scope goes back to the delivery team. A new requirement goes through the change process. If the workflow functions but checking its output takes too long, bring that result back to the client and decide whether to revise the approach or stop.
The demo can look great and the time saving can still be zero. Count the checking.
What happens after the client accepts the project?
Hand over the workflow with a named owner and separately agreed support terms. The client should know who to contact when something breaks and how to request a change before you close the project.
For our five-rep pilot, I’d make the handoff a working session. Have a rep produce a brief while the client owner watches. Walk through a missing record and show them where to report a problem. Leave a short guide they can give the next employee who joins.
Write down who owns the accounts and pays the usage charges. Record who can change the workflow. If there’s a partner or vendor in the delivery chain, tell the client where your responsibility sits and who coordinates a problem that crosses that boundary.
Then agree on continuing support. Spell out the hours of coverage and response expectations, what maintenance you’re including, and who will check the workflow after a change to a connected system. Additional users or integrations need a defined approval and pricing path.
You may include a limited period for correcting defects after handoff. State its duration and what it covers. Once that period ends, the client needs a clear route for paid help or an internal owner ready to take over.
Take the next AI request on your desk and write down what “finished” means. Have your delivery lead and the client’s decision-maker read it before anyone quotes the build. That’s one practical step toward an MSP that can grow beyond its owner: your team can see the promise they’re responsible for keeping.
- How long should AI project discovery take?
- Set the time allowance around the questions you need answered. One workflow in one system may need a few focused sessions; several departments and integrations need more investigation. Agree on the people you'll meet and the access the client will provide. Put a review point in the discovery scope so you're making a decision about further work before the allowance runs out.
- What if paid discovery shows the AI project isn't worth building?
- Give the client the findings and your recommendation to stop or change direction. They should leave knowing why the project doesn't make sense and what would need to change. That's a useful outcome of discovery. You haven't committed to an implementation simply because you agreed to investigate it.
- Does an existing managed services agreement cover a new AI workflow?
- Check the actual agreement with the client before you promise coverage. Identify who'll respond when the workflow fails, which maintenance tasks are included, and how additional changes get approved and paid for. A familiar client and a monthly invoice aren't enough to tell your service desk what it's responsible for.
Watch the conversation