Disabled Doesn't Mean Gone: Where Your Client-Specific Rules Actually Live
A license request comes in. Your automation checks the tenant, finds an unassigned seat on a disabled account, reclaims it, and closes the ticket in under a minute.
Textbook. Except the disabled account belongs to someone on medical leave who returns in six weeks, and now you’ve quietly deleted their mailbox.
This is the failure mode that should worry you about automated resolution, and it has almost nothing to do with model quality. The agent did exactly what it was told. The problem is that “this account is disabled” and “this account is safe to reclaim” are different facts, and only one of them was written down anywhere.
Every MSP runs on hundreds of rules like this. Almost none of them live in a system.
The rules that exist only in people
Ask a senior technician to list the things they know about your top ten clients that a new hire would get wrong. You’ll get a list like this within five minutes:
- This client requires written approval from their office manager before any username or email address change.
- That client’s CFO gets escalated regardless of what the priority matrix says.
- This account is disabled for travel security, not termination — don’t touch the license.
- That site’s backup jobs fail every Sunday night on purpose. Don’t create a ticket.
- This client’s “urgent” means urgent. That client marks everything urgent.
None of these are in your PSA in a structured field. Some are in a private note on one ticket from fourteen months ago. Most are in a person.
The industry has a comfortable name for this — tribal knowledge — that makes it sound like a documentation problem. It isn’t, quite. Documentation debt is about procedures nobody wrote down. This is about exceptions to procedures, which is worse, because exceptions are precisely what a well-behaved automation will steamroll. An agent that follows your documented process perfectly will violate every undocumented exception with total confidence.
Your standard operating procedures tell an agent what to do. Nothing in your stack tells it when not to.
Two failures that look different and aren’t
The medical-leave license reclamation is one shape. Here’s the other.
A ticket arrives asking to change a user’s email address. Your dispatcher knows this particular client requires admin approval first, so before the ticket goes to the queue, they open it and paste a private note: check with their office manager before making identity changes. Every time. Manually. For years.
Same underlying problem. Institutional knowledge about a specific client, held by a specific person, applied by hand at the exact moment it’s needed. It works right up until that person is on vacation, or leaves, or the volume grows past what one dispatcher can personally review.
Both failures share a root cause: there is no place in the standard MSP stack where per-client operating exceptions live in a form that both humans and software can read. IT Glue and Hudu hold documentation about infrastructure. Your PSA holds the ticket. Neither has an obvious home for “here is how this client is different.”
Where to actually put it
The good news is that you probably already have the field, and you’re not using it.
Most PSAs offer a free-text notes field at the company level — separate from ticket notes, separate from documentation, attached to the client record itself. In HaloPSA it runs to roughly 8,000 characters, which sounds small until you write in it: that’s around a thousand words, or fifty to a hundred short instructions. That is more than enough to hold every exception your team currently carries for a given client.
The pattern that works:
- One notes field per client, not per ticket. The tempting shortcut is a per-ticket rule that fires on every ticket for every client. It floods your queue with notes that are irrelevant 95% of the time, and techs learn to ignore them — which defeats the entire purpose.
- Write instructions, not prose. “Requires office manager approval before username or email changes” is actionable. “This client is very security-conscious” is not.
- The agent reads the field and surfaces only what’s relevant. On a password reset ticket, the identity-change rule appears as a private note. On a printer ticket, it doesn’t. Relevance filtering is what keeps the mechanism trustworthy.
- Keep it human-readable. The same field should be useful to a technician who opens the client record directly. If it degrades into a config format only the agent parses, your team stops maintaining it.
This is deliberately unglamorous. It’s a text field. But it converts a category of knowledge that was previously unautomatable into something an agent can honor — and it does so without a new platform, a new integration, or a migration.
The part that compounds
Here’s where it gets genuinely interesting, and it’s an idea that came from an MSP rather than from us.
If an agent is reading the client notes field, it can also write to it.
When a ticket surfaces a new exception — a technician adds a note saying this client always wants their branch offices contacted before a firmware push — that rule currently dies on that ticket. But an agent that just processed the ticket is in a position to recognize a durable client-level rule and propose adding it to the company notes, with a human approving the addition.
Do that for six months and the exception knowledge that used to leave with your senior technician accumulates in a field instead. Every ticket makes the next ticket for that client safer. You get a context layer that grows from operations rather than from a documentation project nobody has time for.
The same logic applies to the disabled-account problem. A structured note attached to a deactivated user — on medical leave through November, do not reclaim license — costs the offboarding technician ten seconds to write and prevents an entire class of automated mistake. Think of it as commenting your code. The information exists in someone’s head at exactly the moment it’s cheapest to record, and nowhere thereafter.
What this means for how you sequence automation
There’s a practical ordering consequence here that’s worth stating plainly.
Read-only agents — triage, classification, similar-ticket matching, resolution research — are safe to deploy against incomplete context. Worst case they make a suboptimal suggestion and a human corrects it.
Write agents, and especially agents that touch identity, licensing, and access, are not. The cost of an automated action that violates an unwritten client rule is not a wasted minute; it’s a deleted mailbox, an unauthorized password reset, or a compliance conversation. Before you enable those, the exceptions need to be somewhere the agent can see them.
The sequence that works: deploy the read-only agents first, use them to surface where your clients differ, capture those differences in the client notes field, and only then turn on the agents that act. Most MSPs try to do this in the opposite order and then conclude that AI resolution isn’t ready. Frequently the agent was ready. The context wasn’t.
And it’s worth naming the human side of this too. The most thoughtful objection we hear about automated resolution isn’t accuracy — it’s accountability. When an agent resolves a ticket, who owns the outcome? A supervisor who has spent years building a culture where technicians own their tickets end to end is right to worry that automation erodes it. Requiring a logged confirmation on sensitive actions — a note in the ticket naming who verified the approval — costs almost nothing and keeps ownership where it belongs. That, too, is a rule that has to live somewhere the agent can read.
That’s the bet Mizo made
Mizo’s agents read client-level context before they act. The Resolution Agent checks per-client handling rules and surfaces them on the ticket rather than assuming your documented process applies universally, and the Documentation Agent captures new exceptions as they emerge so the context layer builds itself from real tickets.
That design reflects a conviction: the hard part of MSP automation was never the reasoning. It’s that the knowledge required to reason correctly about a specific client was scattered across private notes, Teams threads, and the memory of whoever has been there longest.
Where to start on Monday
- Pick your three most operationally unusual clients. Ask your senior tech and your dispatcher, separately, to write down every exception they apply for each. Compare the lists — the differences are your risk.
- Find the company-level notes field in your PSA. Confirm the character limit and who can edit it.
- Write the exceptions in as imperative instructions, one per line. Ten minutes per client.
- Add a step to your offboarding process: when an account is disabled for any reason other than termination, record why and until when.
- Before enabling any agent that writes to identity, licensing, or access, re-read those notes and ask whether an agent following your documented process would violate any of them.
Built by a former MSP operator. The rule you’re most confident everyone knows is the one your newest hire is about to break.