Your Voice Agent Shouldn't Spell the Caller's Name Back to Them
There’s a moment on a demo call that tells you whether a voice agent was designed by someone who has run a service desk.
The caller says their name. The agent repeats it back, letter by letter, and asks them to confirm the spelling.
It’s technically correct. Every speech-recognition best-practice guide recommends it. And for an MSP, it’s the wrong answer — because the person calling is a managed client whose name, company, phone number, and last six tickets are already in your PSA. Asking them to spell their name announces that you don’t know who they are.
That’s the gap nobody talks about in voice AI. The technology is largely solved: the voices are natural, latency is configurable, interruption handling works. What isn’t solved is the design layer sitting on top of it — the decisions about what the agent should assume, when it should ask, and when it should get out of the way. Those decisions are where a voice agent either earns its place on your main line or gets quietly switched off after three weeks of complaints.
Here’s what we’ve learned building one.
Verified and unverified callers are two different products
Nearly every design mistake in MSP voice AI traces back to treating all callers the same.
A caller whose number matches a contact in your PSA is a known quantity. You have their name, their company, their tenant, their history. The agent should open by confirming identity, not collecting it — and then spend the call on the only thing it doesn’t know, which is what’s broken.
A caller with no match is genuinely unknown, and now the careful collection everybody builds by default is exactly right: name, company, callback number, spelling confirmation, the works.
Same agent, two entirely different conversations. Most implementations pick one script and apply it universally, which means they’re either rude to strangers or insulting to clients. The verification state of the caller should change the conversation, not just a database lookup behind it.
Three cases worth handling explicitly:
- One clean match. Greet by name, confirm the company, move on. No readback.
- Several contacts on one number. Common with shared lines and reception desks, and equally common when the same person appears under two companies after an acquisition. The agent should name the candidates and let the caller choose. This takes one turn and prevents a misrouted ticket.
- No match at all. Collect carefully, then transfer to a human rather than dead-ending. And flag it.
That last flag matters more than it sounds. When an unverified call creates a ticket, the ticket should carry an explicit marker — verified by caller ID: no — so the technician who picks it up knows the company and contact fields are unconfirmed rather than merely blank. Downstream automation needs the same signal. A ticket that looks incomplete and a ticket that is known to be unverified deserve different handling, and only one of them is safe to route automatically.
Whether to transfer is a judgment call, not a config flag
The standard implementation makes “transfer unverified callers to a human” a per-tenant setting. On or off.
It’s a reasonable starting point and it’s wrong in the long run, because the actual decision depends on things a boolean can’t see. An unknown caller reporting a site-wide outage should reach a human immediately. An unknown caller asking a billing question can be captured and queued. The same verification state, two correct answers.
The direction worth building toward is one where the model weighs urgency, scope, and caller state together and decides — with guardrails, and with the option to force a transfer for tenants who want it. That’s harder than a flag, especially inside a multi-step agent flow, and it’s the difference between automation that handles your edge cases and automation that hands them all back to you.
Ask the next question, not the next question on the list
Scripted intake asks every question every time. It’s why phone trees are miserable.
If a caller says “I need my password reset,” the agent should not then ask whether the issue affects other users. It knows. Password resets are single-user by construction, and asking anyway signals that nobody is listening — which is precisely the complaint your clients already have about the answering service you’re replacing.
Good intake narrows as it learns. Each answer should eliminate branches of the question tree, so a simple request takes three turns and a complex one takes seven. This is prompt design and conditional logic, not model capability, and it is the single highest-leverage thing you can tune after go-live. Listen to twenty recorded calls and you’ll find four questions that should never have been asked.
The same goes for the caller who front-loads everything: “Hi, it’s Dana at the Westside office, the printer on the second floor is jammed and I’ve already tried restarting it.” That’s a complete intake in one breath. The agent’s job is to confirm and close, not to march back through its checklist.
The transcript arrives after the ticket does
This is the architectural detail that catches teams by surprise, and it’s worth understanding before you buy anything.
Voice platforms generate the full transcript after the call ends and deliver it by webhook. But a good agent creates the ticket during the call, so it can read the ticket number back to the caller before they hang up. Those two facts are in direct tension: your ticket exists, and your richest source of context does not exist yet.
If your pipeline starts processing the moment the ticket is created, it triages on partial information — and the urgency signals that live in tone and phrasing, the “this is the third time this week” said with an edge, arrive too late to matter. Worse, if your platform blocks reprocessing to prevent duplicate work, the transcript may never get picked up at all.
There are two defensible answers. Wait a few seconds at the start of processing for the transcript to land. Or collect enough structured data during the call — urgency, scope, affected users, description — that the transcript becomes enrichment rather than a dependency. Both work. What doesn’t work is discovering the race condition in production, when tickets have been triaging on half their context for a month and nobody can explain why priority accuracy is worse than it was manually.
Ask any voice vendor how they handle transcript timing. The answer tells you whether they’ve run this at volume.
The details that decide whether it stays on
A few things that look cosmetic and aren’t:
- Turn delay. The pause between the caller finishing and the agent responding is configurable, and the default is usually too long. A half-second of dead air reads as a bad connection. Callers start talking again, and now you’re recovering from an overlap that never needed to happen.
- Interruption handling. If the caller keeps talking, the agent stops. Non-negotiable. Any agent that talks over a frustrated user has generated a complaint, not a ticket.
- The caller with an open ticket. “I’m calling about the thing from yesterday.” The right outcome is a note on the existing ticket, not a new one. Most implementations create a duplicate, and your dedupe process inherits the mess.
- Off-topic input. People will ask your intake agent about the weather. Guardrails handle the obvious cases; the rest you find by reading transcripts and adding rules for what real callers actually do.
What this actually replaces
Be clear-eyed about the alternative. Most MSPs route after-hours and overflow calls to a third-party answering service staffed by non-technical operators who ask two or three questions and email the result into the PSA. That email becomes a catch-all ticket with no company, no contact, and a five-word summary.
Someone on your team then spends the first ten minutes of that ticket’s life figuring out who called and what they meant.
A voice agent that identifies the caller from their number, resolves the tenant, collects structured detail, creates a properly attributed ticket, and reads back the number clears that entire step. The bar isn’t perfection. The bar is the answering service — and the answering service has never once known who was calling.
That’s the bet Mizo made
Mizo’s Phone Agent is built on the design principles above: caller identification from PSA data before the conversation starts, disambiguation when a number maps to several contacts, explicit verification flags on every ticket it creates, and adaptive questioning that stops asking once it knows. It hands off to the Intake Agent with structured data rather than a transcript to be parsed later, so triage starts from facts instead of guesses.
The goal was never a voice that sounds human. It was a call that ends with a correctly attributed, properly prioritized ticket — and a client who never had to spell their own name.
Where to start on Monday
- Pull ten catch-all tickets created by your answering service last week. Time how long each took to attribute to the right company and contact. That number is your baseline.
- Check what percentage of your inbound calls come from numbers already in your PSA. For most MSPs it’s north of 80% — that’s the share of calls that should never require identity collection.
- Call your own after-hours line and listen to what your clients hear. Take notes on every question that a system with your PSA data shouldn’t have needed to ask.
- Before evaluating vendors, write down your transfer policy: which callers, which situations, which hours. If you can’t state it, no configuration screen will save you.
- Deploy on overflow and after-hours first, where the comparison is an answering service rather than your best dispatcher.
Built by a former MSP operator. The fastest way to test a voice agent is to call it yourself, at 9pm, and pretend your printer is on fire.