The stages of AI adoption for MSPs

An MSP can have technicians using AI every day and still see no change in the business. A faster email helps the person who sent it. It does not tell the owner whether the service desk can take on more work or whether the documentation got better.

What one person does with a tool and what changes in how the business runs are different decisions. Giving a technician a drafting tool takes one level of preparation. Connecting an AI workflow to the systems that manage customer environments takes a much higher one.

It is useful to think in stages for a single workflow rather than for the whole company. The same MSP can be at stage 4 with ticket notes and at stage 1 with everything else, and that is a perfectly reasonable place to be.

Stage 1: Is there a problem?

The workflow runs without AI, and leaving it that way can be the right choice. A template the technician fills in may already be cheap, predictable, and easy to maintain.

Start with this one workflow. How often does it run? How long does it take? What goes wrong? Who can judge whether the output is correct?

Here is an illustration with assumed numbers. Say your service desk closes 1,500 tickets a month and a technician spends 5 minutes on each resolution note. That is 125 hours a month, most of one full-time technician. If AI drafts the note and the technician still spends 2 minutes checking it, you get back about 75 hours, not 125. The review time does not go away, so put it in the baseline from the start. Also count what vague notes already cost you: the next technician repeating a diagnosis because the last note did not say what was tried.

If the task has little volume or no meaningful cost, leave it for later. You probably have workflows with a higher payoff.

Move on when you can state the problem in one sentence and you have a baseline you measured rather than guessed.

Stage 2: Help one person

One technician uses AI to draft the resolution note from the ticket history, then checks the draft, corrects it, and saves it through the usual process. The workflow stays under that person’s control.

At this stage, find out what the tool gets wrong while only one person depends on it. Does the draft imply that a suggested fix was performed? Does it leave out a remaining issue? Does it turn “the user will test tomorrow” into “the user confirmed resolution”? That last kind of error is the one that ends up in front of a client.

The tool should run in an approved workspace, with permissions limited to this purpose. If you have not settled how customer data may be processed – what your client contracts allow, and whether the AI vendor keeps or trains on the data – start with sanitized tickets before touching real ones.

Do a simple check: how many drafts, how many needed corrections, what kind of corrections, and how long the review took.

Move on when, after a meaningful number of drafts, corrections are rare and minor, and checking a draft is reliably faster than writing the note by hand.

Stage 3: Make it a team standard

The team writes the method down: the prompt, skill or template, the procedure, and examples of acceptable notes. The instructions say what to include, which facts to keep exactly as recorded, and what to do when information is missing.

The test is whether a new person can follow the instructions, find the right inputs, and judge the result without the original author’s unwritten knowledge. If good results still need that person standing nearby, the team does not have a shared method yet.

The reference material needs an owner. An outdated escalation procedure can be applied the same way every time and still be wrong. Each source needs someone responsible for it and a way to tell which version is current.

Move on when a technician who did not build the method gets notes of the same quality.

Stage 4: Connect it to your systems

Now an event starts the workflow instead of a person. When an eligible ticket reaches review, the system assembles the inputs, generates a draft, and puts it in a review queue. The reviewer approves or rejects the draft. Failures go back to the manual process.

First decide whether to build or buy. Your PSA vendor may already offer a drafting or summarization feature. Turning it on moves part of the maintenance to the vendor, but you get their defaults and their limits. Building your own on an AI model’s API gives you control over inputs and instructions, and it means you, or a contractor, own every part of it. A 10-person MSP without a developer should be honest about which of the two it can support.

Either way, you have added engineering and operating responsibilities. Someone has to notice when inputs are missing, when credentials expire, or when a product update changes the output. Someone has to decide which records the workflow can read and which actions it can take.

That last decision matters most once a workflow touches customer environments. Drafting a note needs read access to one ticket. A workflow that runs scripts through your RMM, changes configurations, or closes tickets writes to systems your clients depend on. Keep write actions behind human approval until the read-only version has a track record. Give the workflow its own credentials with the minimum permissions, so you can revoke them without breaking anything else.

Before you extend the workflow, decide who can pause it and when, what happens to work already in the queue, and how normal manual service resumes. Test those paths. If the time saved appears only while someone watches the system continuously, the integration may not be worth its cost.

Move on when the workflow has run through a full month of normal ticket volume, failures were caught and handed back to people, and you have tested pausing and resuming at least once.

Stage 5: Decide where the value lands

This is where the opening question comes back: can the service desk handle more work, and is the documentation better? An automated workflow pays off in one of a few ways, and it helps to know which one you are counting on.

• Margin: if most of your contracts are flat-fee per user or per device, saved hours go straight to margin.
• Capacity: the same team takes on more clients before you hire the next technician.
• Quality: better notes mean fewer repeated diagnoses, fewer escalations, and clearer client reports.
• A service you can sell: a faster response commitment or better reporting, with a scope you can explain, deliver, and support. Your own before-and-after numbers are what make it credible in a sales conversation.

Contract type changes the math. On time-and-materials or block-hour contracts, faster work means fewer billable minutes. There, the value has to come from capacity, quality, or a repriced service.

Do not assume margins rise because you automated a workflow. The automation needs maintenance, and AI has a running cost. Drafting one note from one ticket history is a single model call, and that cost is usually small next to the technician’s time. An agent that plans, calls tools, and retries can make many calls per ticket, and at volume the cost adds up quickly. Track the cost per ticket from the first day, next to the time saved, so you see the trend before the invoice shows it.

Start small

Choose one workflow. Write down how it works today and measure the baseline. Decide whether it is a problem worth automating. If it is, assign an owner and take it through the stages, moving on only when each test is passed.

Before you promise clients faster response times, run a pilot and make sure you can deliver them reliably and profitably.