MSP automation that drafts the routine work and leaves each change to a technician

What is MSP automation, and what does it cover?

MSP automation is software that takes the routine, repeatable work of a managed service provider off your technicians’ desks: sorting new tickets, building the checklist when a client hires someone, pulling patch figures into a monthly report. A joint advisory from the cybersecurity authorities of the US (CISA, NSA and FBI), the UK, Australia, Canada and New Zealand describes MSPs as businesses that deliver, operate or manage information and communications technology services for their customers under a contract, such as a service level agreement. Each system on this page reads from the tools you already run, does one defined job and leaves a record of what it did.

Two kinds of step usually sit inside one system. A rule, such as “a ticket from this client that mentions the firewall goes to the network queue”, is process automation: the same input always gets the same result. Reading something a person wrote, such as an email describing a problem in their own words, is AI automation: a model turns it into a category and a summary.

The five systems below are what we would build for an MSP. Our custom software page covers how we build in general, and our AI automation page goes deeper on the reading steps.

Why does automation at an MSP need tighter access?

An MSP’s tools reach into many client networks at once, and that is what makes MSP automation different from automation inside a single company. The joint advisory says MSP services “usually require both trusted network connectivity and privileged access to and from customer systems”, and it warns that “threat actors can use a vulnerable MSP as an initial access vector to multiple victim networks”. A script with broad rights across every client is exactly the kind of account an attacker would want to find.

So the design starts from the advisory’s own advice:

• Its own accounts, kept small. Each system gets accounts of its own in each tool it touches, with only the rights its job needs. The advisory’s advice is to “apply the principle of least privilege”.
• Multifactor sign-in. The advisory says MSPs “should also implement MFA on all accounts that have access to customer environments and should treat those accounts as privileged”. Where a tool supports it, the system’s accounts use it. Where a tool only offers API keys, each key carries the narrowest rights the tool allows and is stored outside the code.
• No shared admin credentials. The advisory says “Do not reuse admin credentials across multiple customers”, so a system that works for several clients holds a separate credential for each one.
• Records kept long enough to matter. The advisory recommends that organizations “store their most important logs for at least six months”, because “It can be months before incidents are detected”. Every run the system makes is logged, and your proposal sets how long the log is kept.

This is how we would build software that sits next to your clients’ systems, and you review the access plan before anything connects.

What would each system take off your desk?

Each system takes a task your team repeats and gives the routine part to software, with a person checking the result:

• Ticket triage: reading each new ticket, deciding its category and urgency, and typing the first reply.
• Onboarding and offboarding: working through a checklist in several tools when someone at a client joins or leaves, and keeping track of who signed off each step.
• Patch and asset reports: exporting device data client by client and pasting it into a report.
• Quarterly business review drafts: gathering a quarter’s tickets, projects and renewal dates before a review meeting.
• Quotes: counting seats and devices, then pricing them line by line from your price book.

What changes is where your technicians’ hours go. The judgment stays with them: which ticket is really urgent, whether an account should be disabled today, what a client is told.

How would ticket triage with a drafted reply work?

A new ticket arrives by email, through a client portal if you run one, or as a phone call a dispatcher has typed up. The system reads it next to that client’s contract and service levels, then does three things. It sorts the ticket by category and urgency under rules you write, suggests the queue or technician it should go to, and drafts a first reply in your firm’s voice. The dispatcher sees the suggestion and the draft side by side, fixes whatever is wrong and sends it, or sends it as written.

The rules are yours. If every ticket from a client that reports a server down goes straight to the top of the queue, that rule is written into the system and applied the same way each time. The reading is the AI part: a model turns “my email keeps asking for a password since this morning” into a category and a one-line summary. When it can’t tell what a ticket is about, it says so and holds the ticket for a person to sort, with a note on what it was unsure of.

A sales enquiry that lands in the support inbox can be spotted the same way and passed to whoever handles new business.

What happens when a user or a whole client leaves?

Offboarding is where small slips turn into open doors. The advisory lists “disabling user accounts when personnel transition” among the practices it recommends, and it adds a warning for customers: “disabling MSP accounts can be overlooked when a contract terminates.” The same risk runs both ways. Someone leaves a client and their account stays live; a client leaves you and your tools keep their access.

An onboarding and offboarding checklist system turns each of those events into tasks. The input is a request or a form that names the person, the start or end date and the systems involved. Each event becomes a task list across your tools, with a sign-off, a name and a time against every step. Where a tool allows it and your rules say so, the system can carry out a step itself, such as disabling an account on the end date, but only after a technician has approved that step on an approval screen.

When a whole client leaves, the checklist covers your side of the exit: every account your firm holds in their environment, every monitoring agent and every stored credential, each marked as removed by the technician who removed it. The advisory tells customers to “disable MSP accounts that are no longer managing infrastructure”. A record showing you did it before the client had to ask is a good way to close a contract.

New starts run the same way in the other direction: the accounts, the device, the group memberships and the welcome email, each a task with a name and a date next to it.

Can patch and asset reports build themselves?

Mostly, with an account manager reading each one before it goes out. The advisory tells customers to make sure they “understand their MSP’s policy on software updates” and to “request that comprehensive and timely updates are delivered as an ongoing service”. A client who follows that advice will want to see the updates, and the monthly report is where they see them.

A patch and asset report system reads device data from your RMM, client by client, through its API where there is one and from scheduled exports where there isn’t. It builds the report in your format: devices covered, updates applied, devices that missed updates, and devices that have stopped checking in. Devices missing updates are flagged to a technician before the report is drafted, so the report can say what was done about them. The account manager reads it, adds a line of context and sends it.

Some clients hold this data to a stricter standard. The Department of Defense’s CMMC rule lists data on the configuration or vulnerability status of a contractor’s in-scope assets among its examples of Security Protection Data, and for Level 2 and Level 3 assessments it puts the services of a provider that handles that data inside the contractor’s assessment scope. If you serve defense contractors, a report system built for them is planned around that rule, with your compliance lead involved from the start. Our IT services industry page sets out what the rule says.

How would review drafts and quotes come together?

If your account managers hold quarterly business reviews, most of the preparation is gathering: the quarter’s tickets by category, the projects finished and still open, the contract terms and the renewal dates. A review draft system reads those from your ticketing tool and your project notes and writes a first draft in your format, with the figures filled in and the questions it couldn’t answer left as notes. The account manager edits it into the review that client actually needs.

Quotes work the same way from the other end. The input is a count of seats and devices, the services the client chose and your own price book. The output is a draft proposal with line items, in your layout, for the salesperson or the owner to check and send. You set the prices; the system applies them. When a price changes in the book, the next quote carries the new figure, and the system never prices anything your book doesn’t.

Neither system talks to a client by itself. A draft becomes a review or a quote only when someone on your team has read it and sent it.

How does a technician stay in charge?

Every MSP automation system we would build carries the same four controls, because a desk that can’t see what its software did soon stops trusting it:

• An approval queue. Any step that changes something in a client’s environment waits until a technician approves it. Steps that only read and draft, such as building a report, can run without one.
• Holds with a reason. When the system is unsure, or an item breaks one of your rules, it holds the item and writes a note saying why, so whoever picks it up knows where to start.
• A run record. Each run is written down: what came in, what the system did, who approved it and when. The advisory tells customers to verify, through audits, “that MSP accounts are being used for appropriate purposes and activities”. The run record is what that audit would read.
• A pause switch. One switch stops the system, and the work goes back to your team’s usual routine until you turn it on again.

These controls are there for the day something goes wrong: you can see it, stop it and find the cause.

Will it connect to the PSA and RMM tools you already use?

Usually, and the proposal says exactly how. Where a tool has an API, the system connects through it with its own account. Where it doesn’t, or the API doesn’t reach the data the job needs, the system reads scheduled exports or a shared mailbox instead. We name every connection before the build starts, and if a connection we need isn’t possible, you hear that before you approve anything.

If your tickets live in a PSA, triage writes its suggestions back to the ticket, so your team works in the screen it already knows. If your devices report into an RMM, the report system reads from it and changes nothing there unless a step in your proposal says it may, behind an approval.

Requests from your website can follow the same path. If your PSA accepts new records through its API, a sales or support request from your site can arrive there as a record, so nobody retypes it. Our MSP website design page covers the forms that send those requests. Who looks after each connection once it is live is written into your proposal.

Should you build MSP automation or buy an add-on?

Buy first, if something you can buy does the job. If your PSA or RMM has automation of its own, a setting or an add-on you already pay for may cover a task on this page. When an off-the-shelf tool already does what the process needs, we tell you to buy it. Our guide to building or buying software sets out how to weigh the two.

Custom MSP automation earns its place in a few cases:

• The work crosses tools that don’t share data with each other.
• The rules are yours alone: they come from your contracts, your service levels and your clients.
• The controls matter: an add-on can’t keep the approval steps and run records you need.
• Nothing covers the task: the job that costs the most hours isn’t one any tool you can buy handles.

If you aren’t sure where to start, start with the task your team repeats most. Our guide to what to automate first walks through how to pick one.

What do we need from you, and how does it start?

An MSP automation build needs three things from you, mostly:

• Access: accounts for the system in each tool it reads from or writes to, set up by your team with the rights the proposal lists.
• Examples: past tickets, reports and quotes your team considers right, so there is something real to test against.
• A person: a dispatcher, technician or service manager who maps the work with us and checks the results in testing.

It starts with a 15-minute call with Nicolas Perez or Noah Alvarez, our co-founders, and if we aren’t the right fit, we say so on the call. If it fits, a written proposal sets out the scope, how each system would run and its cost, and nothing starts until you approve it.

We formed Midnite Systems in 2023. Our office is in Valencia, California, and we work remotely with businesses across the US. The custom software cost page sets out how prices sit across the market. To start, book a 15-minute call.