AI Agent for MSP Phone Intake: Which Calls to Send It First

Every MSP that evaluates an AI phone agent reaches the same question within the first ten minutes: which calls do we actually send to it?

Part of our guide to AI agent for MSPs.

It sounds like a configuration detail. It isn’t. It decides what you pay, how fast your team trusts the agent, and whether your clients notice the change as an improvement or a disruption. And the answer is different for a shop taking 20 calls a day than for one taking 400 a week.

Over the last few weeks I’ve walked through this decision with a range of MSPs. Here’s how they’re making it, and what I’d recommend.

The routing decision lives in your phone system

First, a point that surprises people: the AI agent doesn’t decide which calls it gets. Your phone system does.

Your PBX, whether that’s 3CX, Dialpad, a hosted Fusion setup, or something else, already knows the time of day, the caller ID, whether the queue is full, and how long someone has been waiting. You use those same conditions to forward calls to the agent. The agent answers whatever reaches it and can transfer back to a human number you configure.

That’s good news. It means you can start small, change scope with a routing rule instead of a project, and roll back in minutes if something goes wrong.

The four starting points

1. After-hours only

This is the most common first step, and for good reason. After-hours calls today usually go to voicemail, an answering service, or whoever drew the short straw on the on-call rotation. Almost anything is an improvement.

One MSP I spoke with wants to replace its after-hours IVR and voicemail with a conversational agent, but still needs genuine emergencies to page the on-call tech through their alerting tool. That’s the right shape: the agent handles intake, verification, and ticket creation for everything, and escalates the small number of true emergencies.

Best for: shops where after-hours coverage is a rotation or a voicemail box. Low risk, high visible value.

2. Overflow

Calls go to the agent only when your team can’t pick up: every line is busy, or a caller has waited past a threshold. One MSP handling roughly 300 to 400 inbound calls a week chose this as their test. It’s a good fit for larger desks because it exercises the agent on real daytime calls without taking any calls away from technicians who are free.

Best for: busier desks with predictable peaks, such as Monday mornings, patch nights, or an outage at a large client.

3. New issues only

Some MSPs want the agent to handle new problems while existing ticket follow-ups go straight to a person. This usually comes up as a cost question: if you pay per call, why pay for “any update on my ticket?”

It’s worth thinking twice before splitting this way. Status calls are often the easiest calls to automate well. A verified caller asks about their ticket, the agent reads back who has it and where it stands, and adds a note that the client called. That’s a call your technicians would otherwise have to stop what they’re doing to answer. Also, callers don’t pre-sort themselves. A “status call” often turns into a new issue halfway through.

Best for: shops that want to limit volume while they learn. Revisit within a month.

4. The whole support line

One MSP sends nearly every call to the agent: new tickets, status checks, general questions. It’s the most ambitious option and the one that removes the most interruptions. It’s also the option where caller experience matters most, because every client hears the agent.

Best for: shops that have run one of the other options first and trust the results.

Forecast your volume, then test the forecast

The most common mistake in scoping an AI agent for MSP phone intake is guessing the call volume.

One MSP estimated about 100 calls a month. After forwarding, the real number was closer to 400. Nobody had been counting the calls that went to voicemail, rang out, or were answered by whoever was nearest and never logged. Another shop estimated 20 to 25 calls a day, but realized mid-conversation that because they route almost everything, the real number was probably higher.

Before you choose a plan:

• Pull call detail records from your PBX, not ticket counts. Many calls never become tickets.
• Split by time of day. After-hours volume is often a small fraction of total volume, which makes it an easy, cheap starting scope.
• Count abandoned and voicemail calls. They’re the calls you’re currently losing, and they’ll show up once something answers them.
• Run a test number for a week or two before moving your main line. One MSP is doing exactly that, then pointing their main support number at the agent once they’re comfortable.

Things to settle before any call reaches the agent

Who gets transferred, and to where. VIP contacts, callers who ask for a person, and genuine emergencies should reach a human. Decide the number, and decide what happens if nobody answers it.

Which queue voice tickets land in. One MSP set their Level 1 queue as the default for phone-created tickets so their normal routing rules take over from there. Pick a destination that fits your existing flow.

What happens with existing ticket numbers. If a caller gives a ticket number, the call should add a note to that ticket, not open a new one.

How verification works. Status readbacks and anything touching an account should only happen for verified callers. Caller ID is not authentication.

How you’ll review calls. Ask for call logs and recordings from day one. One MSP flagged a missing call log as the first thing they’d need to diagnose dropped calls. You can’t tune what you can’t see.

What voicemail looks like. If the agent takes a message, the ticket should include who called, their number, and the issue, not just an audio file. That’s the gap one MSP hit with a previous tool, and it’s why they never put it in front of clients.

A sensible 30-day path

1. Week 1: Test number only. Your team calls it with realistic scenarios, including angry callers, vague callers, and callers who give the wrong company name.
2. Week 2: Route after-hours calls. Review every call the next morning.
3. Week 3: Add overflow during business hours.
4. Week 4: Look at the numbers: calls handled without transfer, ticket quality, escalation accuracy. Decide whether to expand to status calls or the full line.

How Mizo’s Phone Agent fits in

Mizo’s Phone Agent answers whatever calls your PBX forwards to it: after-hours, overflow, or the full line. It identifies and verifies the caller against your PSA, opens a complete ticket in the queue you choose, adds notes to existing tickets when a caller gives a ticket number, reads back ticket status to verified callers, and transfers to a human when the caller or the situation calls for it. You don’t need to replace your phone system. You change a forwarding rule.

For a deeper look at the call flow, see inside the Mizo Phone Agent.

👉 Call a test line configured for your own PSA before you route a single client call. Book a demo.

FAQ

Should an MSP route all calls to an AI phone agent?

Not on day one. Start with after-hours or overflow, review real calls, and expand once you trust the results. Most shops that go to the full line get there in a few weeks.

How do I estimate call volume for an AI phone agent?

Use call detail records from your PBX, including abandoned and voicemail calls, rather than ticket counts. Then validate with a test number or after-hours routing before choosing a plan.

Do I need to replace my phone system?

No. Your PBX decides which calls to forward based on time of day, queue status, or caller ID. The agent answers what it receives and can transfer back to your team.

Should status calls go to the AI agent?

Usually yes, once callers are verified. Status readbacks are simple, frequent, and interrupt technicians. Restricting the agent to new issues saves money but leaves easy wins on the table.