Most MSPs know what their answering service costs. It’s a line item, it’s a few hundred to a few thousand dollars a month, and it’s been in the budget so long that nobody questions it.
That number is the smallest part of what you’re paying.
The real cost arrives the next morning, in your queue, in the form of tickets like this:
Subject: Computer issue Company: (blank) Contact: (blank) Description: Caller says computer not working. Call back.
Somebody on your team now has to figure out who called, which client they belong to, what they meant, and how urgent it is. That work is invisible on every report you run, and it happens on a meaningful percentage of your inbound volume.
Where the ticket comes from
The mechanics are worth spelling out, because they explain why the output is so poor and why it isn’t the answering service’s fault.
An after-hours or overflow call routes to a third-party service. The operator is not technical — they can’t be, at that price point, and they’re answering for dozens of businesses in rotation. They ask two or three scripted questions, type what they hear, and send an email to your service address.
Your PSA receives an email from the answering service’s own domain. Since that domain isn’t mapped to any client, the ticket lands unattributed: no company, no contact, no configuration, no agreement. A catch-all.
Every downstream mechanism you own is now degraded. Priority rules can’t fire without a company. SLA clocks can’t compute against the right agreement. Routing rules that depend on client or contract don’t apply. Similar-ticket matching pulls from the wrong pool because it has no tenant to scope to. Even your AI triage, if you have it, is reasoning from a five-word description with no context attached.
The problem isn’t that the answering service writes bad tickets. It’s that a non-technical human relaying a message by email is structurally incapable of writing a good one.
Counting the real cost
Four costs, roughly in order of size.
Attribution labor. Someone reads the ticket, searches the phone number against contacts, guesses at the company, maybe calls back to ask who they are. Call it five to ten minutes on the ambiguous ones. Multiply by your catch-all volume and it’s frequently more hours per month than the invoice buys.
Delay. A ticket that arrives at 9pm and can’t be triaged until a human attributes it at 8am has burned eleven hours of clock. If the underlying issue was urgent, you didn’t know, because urgency was one of the things the operator couldn’t assess. Some of these tickets are a server down at a client who now spends a night offline.
Distorted metrics. Catch-all tickets pollute everything downstream. Response times measured against tickets with no agreement. Client-level volume reports missing the calls that came in by phone. Dispatch load calculated on a queue where a chunk of tickets have no client attached. Decisions get made on this data.
Client experience. Your client called their IT provider and spoke to someone who didn’t know their name, didn’t know their company, couldn’t answer anything, and promised a callback. That’s the interaction they remember, and it’s the one that shapes the renewal conversation — regardless of how good your technicians are the next morning.
The invoice is the only one of these five you can see on a P&L.
Why nobody has fixed it
Because the alternatives were all worse.
Staffing the phone overnight means paying a technician to sleep next to a phone that rings twice. The math has never worked for a mid-sized MSP, and the technicians hate it, which is its own cost in a market where retention is the binding constraint.
Sending calls to voicemail is honest but slower, and it converts a call into a message that still requires attribution the next morning.
Pushing clients to a portal works for the organized ones and fails for exactly the users who generate the most tickets. People with a broken computer call. They have always called.
So the answering service persists — not because anyone thinks it’s good, but because the option set was bad. That’s the thing that changed.
What a voice agent changes
The comparison that matters isn’t voice AI against your best dispatcher. It’s voice AI against a non-technical operator reading a script, and against that baseline the gap is not subtle:
- It knows who’s calling. The number resolves against your PSA before the conversation starts. Company, contact, tenant, history. The operator never had this and never could.
- It asks the right follow-ups. How many users affected, is it a full outage, what changed recently. Technical questions the operator couldn’t evaluate the answers to.
- It writes a structured ticket. Company and contact populated, category assessed, urgency and impact captured as fields. Your priority matrix, SLA clocks, and routing rules all work, because the ticket has the attributes they read.
- It closes the loop. The caller gets a ticket number before hanging up, which is the single thing most likely to stop them calling back an hour later to check.
- It doesn’t scale in cost. A call surge that would swamp a rotation is a concurrency setting.
And it can escalate. A genuine emergency at 2am should still reach a human — the difference is that it reaches them with an attributed, described, prioritized ticket rather than a message to call someone back.
The honest limitations
Three, and any vendor who doesn’t volunteer them is selling.
Callers from unknown numbers are still unknown. Mobile, home line, new employee — the agent can collect carefully and flag the ticket as unverified, but it can’t manufacture identity. See Caller ID Is Not Authentication for why that’s a feature rather than a gap.
Resolution during the call is gated on verification. A voice agent that can’t complete step-up verification can take excellent tickets and can’t resolve them. That ceiling is set by your clients’ MFA enrollment as much as by the vendor.
Some callers want a person. A distressed user at 2am on a major outage should get one quickly, and the transfer path needs to be good rather than an afterthought.
None of these make the comparison close. The answering service has every one of these limitations too, plus it doesn’t know who’s calling.
Running the numbers for your own shop
The calculation is simple enough to do on a whiteboard:
- Monthly answering service invoice.
- Catch-all tickets per month × average minutes to attribute × loaded hourly rate.
- After-hours tickets that waited until morning × the ones where waiting mattered.
- Voice agent cost at your call volume.
Most MSPs I’ve walked through this find line two alone exceeds line one, and that’s before assigning any value to lines three and four. The invoice was never the expensive part.
That’s the bet Mizo made
Mizo’s Phone Agent identifies the caller from PSA data before it says hello, asks technically informed follow-ups, and writes a fully attributed ticket with company, contact, category, urgency, and impact as structured fields — then hands it to the Intake Agent and Triage Agent so priority and routing fire on the same footing as any daytime ticket.
The design goal was never to eliminate human contact. It’s that the first ten minutes of a catch-all ticket’s life — the archaeology of figuring out who called and what they meant — is work that should never have existed.
Where to start on Monday
- Count last month’s catch-all tickets. In most PSAs that’s tickets with no company or a company matching your answering service’s domain.
- Sample ten and time how long attribution took. Multiply out. Compare to the invoice.
- Pull your after-hours tickets and find the ones where the delay had consequences. Those are the expensive ones.
- Call your own after-hours line as a client would. The experience you get is the experience they get.
- Deploy voice automation on overflow and after-hours first. That’s where the comparison is an answering service rather than your best dispatcher, and it’s the easiest win you’ll get this year.
Built by a former MSP operator. Nobody ever renewed a contract because the answering service took a good message.