← Ajit Pandey · Blog

What an MSP Should Automate First (and What to Leave)

Search for "MSP automation" and you will find long lists of tools and features. What you will rarely find is a plain answer to the question an owner actually has: of everything my team does by hand, what should I automate first?

This post gives one. It is a way of choosing, not a product list, and it works whether you build the automation yourself, buy it, or have someone build it for you.

What MSP automation actually means

The MSP automation work described on the home page is about connecting the tools a managed service provider already runs: RMM and monitoring platforms, MSP systems, CRM and API workflows, Microsoft 365, Active Directory and networking. The stated goal is fewer repetitive tickets and consistent, repeatable operations.

Notice what that describes. It is not a new tool replacing your tools. It is the work between them: a person reads an alert in one screen, retypes it into a ticket in another, looks up the client in a third, and then changes something in a fourth. Every one of those handoffs is a place where time leaks away and mistakes creep in.

That gives us a useful rule. Automate the handoffs first. Leave the judgement calls to people.

A simple test for what to automate first

Before picking a task, score it against five questions:

Question Good first candidate Poor first candidate
How often does it happen? Many times a week A few times a year
Are the steps always the same? Yes, written down as a checklist Depends on who is doing it
Can it be undone? Yes, or it only reads and drafts No, it deletes or overwrites
Can you measure it today? You can count the tickets or minutes now Nobody has ever counted
Does one person own the outcome? Yes Nobody is sure

A task that scores well on all five is a strong first project. A task that fails the third question (it cannot be undone) is not a first project, however painful it is.

1. Turn alerts into useful tickets

One of the first handoffs to look at is the one between monitoring and the ticket queue. An alert fires, someone notices, and someone creates a ticket. Automating that link is tempting, and it is also where a careless automation can do the most damage, because it can flood the queue faster than a person ever could.

Google's Site Reliability Engineering book, in its chapter on monitoring, sets a standard worth borrowing. It says "Every page should be actionable," and that "If a page merely merits a robotic response, it shouldn't be a page." It also warns that people can only react with urgency a few times a day before they become fatigued. That chapter is written about paging engineers, not about MSP tickets, so treat it as a design principle rather than a rule for your service desk. But the principle carries over directly: if every alert becomes a ticket, your technicians will learn to ignore tickets.

So the useful automation is not "create a ticket for every alert." It is closer to this:

Each of these reads and writes ticket text. None of them touches a client's systems, which makes this a safe place to start.

2. Standardise user onboarding and offboarding

New starters, role changes and leavers produce requests whose steps are usually the same every time. That makes them a natural second target, especially for the Microsoft 365 and Active Directory side of the work.

It helps to know what the underlying tools require, because it shows how much of the job is a fixed checklist. Microsoft's documentation for creating a user through the Microsoft Graph API lists the properties that are needed at a minimum: whether the account is enabled, a display name, a mail nickname, a password profile and a user principal name. It also lists a least-privileged permission for the call, User.Create, and says to use a higher-privileged permission only if your application needs it. That is a useful design hint. An automation that only creates users should hold only the permission to create users.

Offboarding has the opposite risk. Microsoft's documentation for the Active Directory Disable-ADAccount cmdlet describes it as disabling an Active Directory user, computer or service account, and it supports -WhatIf (shows what would happen without running the command) and -Confirm (prompts before running). Those two switches are a hint about how to design the workflow: preview first, confirm second, act third.

A sensible shape for this automation:

  1. A named person at the client submits or approves the request.
  2. The automation prepares the changes and shows them for a technician to review.
  3. A technician approves, and the automation performs the steps in a fixed order.
  4. Every step is logged against the ticket.

For offboarding, one design option is to disable an account rather than delete it, so that it can be re-enabled if the request turns out to be a mistake. That is a design choice, not a universal rule, so agree it with each client.

3. Take the typing out of routine tickets

Once alerts and accounts are under control, look at the ticket queue itself. Language-heavy, repetitive work such as reading a new ticket, suggesting a category, asking for missing details and summarising a long thread suits AI well. We covered this in detail in What an AI Service Desk Can (and Can't) Do for an MSP. The short version is that AI suggests and drafts, and a technician stays responsible for what is sent.

4. Automate the reporting nobody enjoys

Monthly client reports can be a time sink: pull figures from several systems, paste them into a document, and tidy the formatting. A script that gathers the same fields from the same sources every month and fills a template is a low-risk automation, because it only reads data and writes a draft. The technician or account manager still reviews it before it reaches the client.

One caution: a report generator will faithfully reproduce whatever your source data says. If your ticket categories are inconsistent, the report will be inconsistent. Cleaning up categories is slow work, but it pays off whether or not you automate anything.

What to leave alone, at least at first

How to know it worked

Do not rely on a vendor's claims, and do not rely on ours. Measure your own work:

If the numbers do not move, change the automation or drop it. A small automation that clearly works is worth more than a large one nobody trusts.

Where to go from here

Pick one task from the table above, write down its steps as a checklist, and decide in advance who approves what. If you want to talk through automating a specific workflow between your RMM, monitoring, ticketing or Microsoft 365 tools, the home page describes this kind of work and links to a way to schedule a consultation.

Sources

All pages were read on 17 October 2026.