IT Process Automation for MSPs: Start From Tribal Knowledge, Not Flowcharts

Ask the owner of a 30-person MSP to describe how a new-user onboarding works, and you’ll get a confident answer. Ask the three technicians who actually do it, and you’ll get three different answers. All of them are partly right.

That gap is why IT process automation has been so hard for MSPs. Every automation tool of the last fifteen years assumed you could start with a clean process definition and turn it into a workflow. Most small and mid-sized MSPs don’t have that definition. They have tribal knowledge, a few SOPs in IT Glue or Hudu that were accurate two years ago, and a senior tech who just knows.

The good news: that assumption no longer has to hold. Language models can now read the work your team already does and turn it into a process you can govern and automate. That changes where IT process automation starts.

The process maturity ladder

A useful way to think about this is a ladder. Every process at your MSP sits on one of these rungs, and different processes sit on different rungs at the same time.

1. No procedure. Reactive and ad hoc. Whoever picks up the ticket figures it out.
2. Tribal knowledge. People know how to do it, but it isn’t written down. It walks out the door when they do.
3. Documented SOPs. Written in your documentation platform. Often incomplete, often stale.
4. Modeled processes. Someone turned the SOP into a workflow in an automation tool. This requires a person who understands both the process and the tool.
5. AI-assisted process discovery. The process is extracted from SOPs, PSA ticket history, and how technicians actually resolve tickets.
6. Adaptive execution. The process is defined, but steps can adjust at runtime based on context, with human approval where it matters.
7. Agentic execution. An agent decides the next action from the ticket, the client’s context, the tools it’s allowed to use, and your documented knowledge.
8. Straight-through automation. Event, condition, action. No judgment needed, no human in the loop.

Traditional IT process automation lived on rungs 4 and 8. You either modeled the process by hand, or you wired a simple trigger to an action. Everything between rung 2 and rung 4 was your problem.

Why the jump from rung 2 to rung 4 kept failing

Moving a process from tribal knowledge to a modeled workflow needs two skills in one room: someone who knows the process, and someone who can build the automation. At most MSPs those are different people with different priorities.

The technician who knows the process is busy on tickets. The person who can build the workflow, if you have one, doesn’t know that one client needs their own approver for license purchases, or that another client’s shared mailboxes are always created by a specific tech because of a past incident.

So the workflow gets built from the official version of the process, misses the exceptions, and breaks on the first ticket that isn’t standard. The team stops trusting it and goes back to doing it by hand.

There’s a second problem. Small MSPs often don’t know their own processes well enough to write them down at all, let alone to write a good prompt for an AI agent. “Just tell the AI what to do” fails for the same reason “just document it” failed.

What’s different now: discovery from real work

The step that used to be manual, getting a process out of people’s heads, is the step AI is now best at.

An agent with access to your PSA and documentation can:

• Read your existing SOPs in IT Glue, Hudu, SharePoint, or Confluence and identify which ones describe repeatable work.
• Mine ticket history to see how a request type is actually handled: which steps, which tools, which approvals, how long, and by whom.
• Spot the exceptions that never made it into the SOP. The client-specific rules, the “don’t touch this server on Fridays,” the approver who isn’t the primary contact.
• Capture new knowledge while work happens, by asking a technician the one question it needs answered instead of asking them to write a document from scratch.

This is the shift. You don’t start IT process automation by drawing a flowchart. You start by letting the system observe the work and propose the process, then a human corrects it.

We covered the documentation side of this in your knowledge base is the ceiling on your AI. The point here is that the ceiling can now rise on its own as the agent learns from tickets.

Human-managed processes are a valid first rung

Not every process should go straight to full automation. One of the most useful patterns we see is a human-managed process: the steps are defined and tracked, a person executes them, and the system makes sure nothing gets skipped.

This has three advantages:

• It costs almost nothing to run. No inference cost per step, no integrations required on day one.
• It’s where governance starts. Once a process is defined and tracked, you know who did what and when. That’s the foundation for audits and QA.
• It shows you what to automate next. If the same manual step runs 40 times a month and never varies, that’s your next automation, with the data to prove it.

A process that starts human-managed can move up the ladder one step at a time: first approvals get routed automatically, then data gets prefilled, then the routine cases run end to end and only the exceptions reach a person.

Where agents fit, and where rules still win

Agentic execution isn’t a replacement for every deterministic workflow. A good rule of thumb:

• Use straight-through rules when the input is structured and the decision never changes. A backup success alert with no time logged gets closed. Always.
• Use an agent when the request arrives in plain language, the right action depends on context, or the exceptions matter more than the happy path. “Can you set up Sarah like we did for Mike last month, but she needs access to the finance share” is an agent problem.
• Use human approval gates for anything that changes access, money, or security posture, at least until the agent has a track record.

The two approaches are converging. The best IT process automation for MSPs will mix them in one process: deterministic where it can be, agentic where it has to be, and human where it should be. Our comparison of agentic AI and RPA goes deeper on the trade-offs.

A practical way to start

1. Pick five request types by volume. Pull a month of tickets and group by intent. Password resets, new users, license changes, shared mailbox access, and software installs are common winners.
2. Place each one on the ladder. Be honest. Most will be on rung 2 or 3.
3. Let the system draft the process. Feed in the SOPs you have and the ticket history for that request type. Review the draft with the technician who does the work most often.
4. Run it human-managed first. Track every step for two weeks. Note which steps never vary.
5. Automate the steps that never vary. Keep approvals on anything sensitive. Expand from there.

How Mizo approaches IT process automation

Mizo is built around this ladder rather than around a workflow builder:

• It connects to your PSA and documentation platforms (IT Glue, Hudu, SharePoint, Confluence) and pulls your existing SOPs into a process map.
• It learns from how your team resolves tickets, including client-specific rules, and asks technicians targeted questions to fill gaps instead of asking for documents.
• Each ticket is classified by intent at intake, and the matching process runs with human-in-the-loop approval gates you control.
• Every decision is written to the ticket with the reasoning behind it, so you can see what the agent did and why.

There’s no automation engineer to hire and no flowchart to maintain. Learn more on our IT process automation page.

👉 Want to see which of your processes are ready to automate? Book a demo and we’ll map a month of your tickets onto the ladder.

FAQ

What is IT process automation for an MSP?

It’s the automation of repeatable IT work, such as user onboarding, license changes, and access requests, across your PSA, Microsoft 365, RMM, and documentation tools. For MSPs it also has to handle per-client exceptions.

Do I need documented SOPs before I can automate?

No. Documented SOPs help, but an AI agent can now draft processes from ticket history and technician input. A human reviews the draft before anything runs automatically.

How is IT process automation different from RPA?

RPA replays fixed steps and breaks when inputs change. Modern IT process automation for MSPs combines fixed rules for structured inputs with agents that read context for everything else.

Which processes should an MSP automate first?

High-volume, low-risk requests with stable steps: password resets with identity verification, license assignments, shared mailbox access, and new-user setups for clients with a consistent template.