Every automation milestone the MSP industry has celebrated so far has been about making a ticket move faster.
Triage in seconds instead of minutes. Dispatch without a coordinator. Resolution notes written automatically. Real improvements, all of them, and all of them still describing a world where a person contacts you, waits, and gets helped later.
The end state is different in kind. The end state is a user who calls at 7:40am, locked out before a client meeting, and hangs up ninety seconds later able to log in. No ticket in a queue. No callback. No technician. The ticket exists — created, documented, verified, closed — but nobody worked it.
That’s the outcome worth building toward, and the reason it hasn’t happened yet isn’t conversational AI or PSA integration. Both of those work. It’s that the last step of that call requires knowing, to a defensible standard, that the person on the line is who they say they are.
Voice gave us the channel. Resolution gave us the action. Identity is the gate between them, and it’s the piece the industry skipped.
Why the phone is where this matters most
There’s an argument that phone is the wrong place to start — that portal and chat are easier channels for automated resolution, being authenticated and text-based.
It’s true and it misses where the value is.
The phone is the channel of urgency. People call when something is broken badly enough that typing feels too slow, which means phone volume is disproportionately made up of the tickets where time-to-resolution actually matters. It’s also the channel of your least self-sufficient users, who generate the most tickets and the most repeat contact.
More importantly, the phone is the only channel where resolution can complete inside the interaction. A portal ticket resolved in four minutes still means the user submitted a form and went to make coffee. A call resolved in ninety seconds means the problem is over before they’ve finished describing it. Those are different products from the user’s perspective, and only one of them changes what your clients think managed IT is.
The phone is also, not coincidentally, the hardest channel to verify identity on — no session, no authenticated context, and a human listening to silence. The channel with the highest resolution value has the highest identity difficulty. That’s not bad luck; it’s the structure of the problem, and it explains why this is the last thing to get built rather than the first.
The full chain
An automated call that resolves has to complete seven steps without a human. Each one is a place the chain breaks.
1. Identify the caller. Number resolves against the PSA to a contact, company, and tenant. Multiple matches get disambiguated in one turn; no match gets flagged explicitly as unverified rather than left blank.
2. Understand the request. Adaptive questioning that narrows as it learns, producing structured fields — category, urgency, scope, affected users — rather than a transcript for something downstream to re-parse.
3. Determine whether it’s resolvable. The agent checks the request class against what it’s permitted to do for this client. Most requests aren’t automatable, and recognizing that immediately is as valuable as resolving the ones that are.
4. Verify identity to the required tier. Narrated push approval to the enrolled device, with callback and approver-attestation fallbacks. The mechanics of doing this on a live call are the fiddliest engineering in the chain.
5. Check authorization. Distinct from step four. Knowing who someone is doesn’t establish they’re permitted to request this. Client-specific approval rules — the ones that live only in senior technicians’ heads — have to be machine-readable for this step to exist at all.
6. Execute. The actual change, scoped to one user, with rollback defined and the blast radius bounded. For credential actions this means issuing a self-service pass rather than transmitting a password.
7. Confirm and document. Verify the change took effect, tell the caller, read back the ticket number, and write the evidence — verification tier, approver, action, outcome — to the ticket as structured fields.
Seven steps, and the industry has shipped one, two, and seven. Three, four, five, and six are where the work is.
What breaks, and what to do about it
Being specific about the failure modes, because “it might get it wrong” isn’t a design input.
The caller isn’t verifiable. New phone, no enrollment, travelling. This is a real fraction of calls, and the answer is a graceful handoff with everything collected so far attached — not an apology and a dead end. The measure of a good implementation is how much value it delivers on the calls it can’t complete.
The request is out of scope. Most calls will be. The agent should recognize this within a few turns and route, rather than attempting a resolution path it can’t finish. An agent that tries everything is worse than one that knows its boundaries.
The action is right but the client’s policy says no. Approval required, service account, regulated environment. This is step five doing its job. It should read as a considered decision on the ticket, not a failure.
The execution half-completes. The password reset succeeds, the confirmation email fails. Every automated action needs a post-action check and a defined rollback, and the caller needs to be told the truth about what state things are in.
Note that in four of these, the correct behavior is to stop. The skill that makes automated resolution trustworthy is declining well, not completing often. A system that resolves 20% of calls and hands over cleanly on the other 80% is worth deploying. One that resolves 40% and fails messily on the rest is not.
Where the volume is
Realistic scope, in rough order of how much of a typical MSP’s phone volume each represents and how ready they are:
- Password resets and account unlocks. The largest single category and the one that fully exercises the identity chain.
- MFA re-enrollment. High volume, higher evidence tier required, same infrastructure.
- Group and distribution list membership. Common, low individual risk, gated almost entirely on authorization rather than identity.
- License assignment. Mechanically simple, needs the authorization policy and the account-status context that stops it reclaiming a seat from someone on leave.
- Mailbox permissions and shared mailbox access. Frequent, and sensitive enough to need approval every time.
- Status and information requests. Trivially safe, no identity gate needed beyond caller matching, and worth automating on day one.
That’s a meaningful slice of phone volume. Not all of it, and the honest framing is that the goal isn’t a service desk with no humans — it’s one where humans spend their day on the problems that are actually interesting.
Why this is the last thing built, not the first
There’s a temptation to look at this chain and start at step six, because executing an action is the demo that impresses people. That instinct produces a system that works in a test tenant and can’t be enabled for a real client.
The dependency order runs the other way. Structured intake makes verification possible, because you can’t step up a caller you haven’t identified. Verification makes authorization meaningful, because approval from an unverified requester proves nothing. Authorization makes execution defensible. And execution without documented evidence is an unaudited privileged action, which is a liability rather than a feature.
Build it in that order and each layer makes the next one cheaper. Build it backwards and you’ll ship a password reset that no client’s security review will approve.
This is why our own resolution capability sat behind a flag long after the underlying action worked. Calling the API was never the hard part. Earning the right to call it was.
That’s the bet Mizo made
The Phone Agent, Intake Agent, and Resolution Agent are built as one chain rather than three products. Caller identification feeds structured intake; intake feeds a verification step whose evidence is written as structured data; that evidence gates what the resolution agent is permitted to do; and every action writes its authorization trail back to the ticket.
The reason it’s one chain is that the handoffs are where this fails. A voice product that emits a transcript and a resolution product that parses it will never complete step four, because verification state is not something you can infer from a conversation after the fact.
Where to start on Monday
- Pull last month’s phone tickets and categorize them. What share are password resets, unlocks, MFA, licenses, permissions, and status requests? That’s your addressable volume.
- Check MFA enrollment coverage per client. That number is the hard ceiling on how much of the above can ever resolve automatically.
- For your top five clients, write down who may authorize identity changes and for which account classes. Step five doesn’t exist without this.
- Confirm your tenants support self-service credential recovery via a time-limited pass. Most do and haven’t enabled it.
- Start with status and information requests — no identity gate, immediate value, and it builds the caller trust you’ll need before you automate anything consequential.
Built by a former MSP operator. The best service desk interaction is the one the client forgets happened, because nothing went wrong and nobody had to wait.