Every voice AI agent gets some calls wrong. A question nobody taught it. A transfer to the wrong desk. A caller who asked for a person and didn't get one.
What decides whether that becomes a support ticket is who finds it first. If your customer finds it, it's a complaint. If your team finds it, fixes it and mentions it, it's service.
The short answer: once a week, clear the calls that need a person, read the flagged calls, fix the cause in a draft, and tell the customer what changed. It takes about 20 minutes per customer, because nobody has to listen to recordings.
(Searchers call this an AI receptionist. We call it a voice AI agent, because it does more than answer.)
Last reviewed: November 12, 2026.
Why review calls every week?
Because problems repeat. A question the agent can't answer on Monday gets asked again on Tuesday. One fix covers every caller after it.
- It keeps tickets small. A gap found in a review is a five-minute fix. A gap found by an annoyed customer is a call, an apology and the same fix.
- It keeps customers. Customers rarely cancel over one bad call. They cancel when the same thing keeps happening and nobody seems to notice.
- It gives you something to say. "We fixed three things this week" is a reason for a customer to stay that no price cut can match.
Who should run it: you or the customer?
Either, and it's worth deciding per customer.
- Your team runs it for customers who pay for a managed service, or who aren't comfortable editing the agent. From your partner portal you can log in as any of your customers' users and see exactly what they see.
- The customer runs it when they want control. Everything below happens in their own portal, and staff without admin rights can still work the inbox and read Insights.
Run it yourself for your first few customers either way. You'll learn what the next ones will ask.
The weekly review, step by step
Pick a day and keep it. Monday works: the weekend's calls are in, and fixes are live before the week gets busy.
- Clear Attention required. It lists calls that need a person: callback requests and calls that ended without what the caller wanted. Return the callbacks first. Close each one when it's handled, and add an internal note if the team needs context.
- Check the clean-resolution rate. Insights shows the share of analyzed calls that resolved with no issue. Compare it with last week. A drop points you to what changed.
- Read "Recent calls worth a look". Insights lists the newest flagged calls, each with a one-line summary of what went wrong. Red dots are calls where the agent did the wrong thing; start there.
- Open each call. The call card has the summary, the recording, the transcript and every tool the agent used: what it looked up, which calendar it checked, where it transferred. Most causes are visible in the transcript in under a minute.
- Look at the top reasons. "Why calls didn't resolve" ranks the week's failure reasons with their counts. Fix the top one first. One fix there usually covers more calls than three fixes further down.
- Fix it in a draft, test it, publish. More on that below.
What does each failure reason mean, and what fixes it?
Insights sorts every flagged call into a reason. Each one points to a different fix.
| Reason Insights shows | What usually happened | The fix |
|---|---|---|
| Didn't have the answer | Callers asked something the knowledge base doesn't cover | Add the page, document or text that answers it |
| Missed an answer that was available | The answer is in the knowledge base but buried | Give it its own short source with a clear title |
| Knowledge base article wasn't clear enough | The right source was found but too thin | Rewrite it with the detail callers ask for |
| Gave the wrong information | A source is wrong or out of date | Correct it, and turn on weekly refresh for web pages |
| Sent to the wrong place | A transfer went to the wrong person or queue | Check the transfer destinations and their descriptions |
| Didn't take the needed action | It should have transferred or looked something up | Say in the instructions when to act, or write a scenario |
| Didn't hand off when asked | The caller asked for a person and wasn't transferred | Make sure that person is a transfer destination, then test the request |
| Got stuck repeating itself | The same question went round in circles | Tighten the instructions, or put the steps in a scenario |
| Misread what the caller wanted | The request was misunderstood before routing | Add examples of how callers phrase it |
| Request couldn't be fulfilled | Nothing the agent could do | Often no fix; if it's common, it may be a service the customer should offer |
Two more things to check while you're in there:
- Names it heard wrong. If the transcript mangles a staff name, product or street, add it to the names the agent listens for.
- Names it said wrong. If it mispronounces one, add a pronunciation rule. The transcript keeps the right spelling.
How do you fix it without breaking something else?
Change it in a draft, never on the live agent.
- Edits are drafts. Changes to the agent go live only when someone presses Publish. Calls already in progress keep the version they started on.
- Test before you publish. Type the caller's question into the test panel, or call the draft from the browser. Use the exact words from the flagged call.
- Undo in one click. The last 10 published versions can be restored, so a bad change costs a minute.
- Or just ask. With Ask Your Agent, you can ask why a call went the way it did, or ask for the change in plain words. It drafts it for you to test and publish.
Knowledge has its own draft and publish, and one knowledge base can serve several agents. A fix there reaches every agent that uses it.
What should you tell the customer?
Something short, every week or two. What you saw, what you fixed, what's next:
This week Greer couldn't answer two questions about parking validation. We added the answer, so callers get it now.
Once a month, open Insights with them: calls handled, transfers, what callers wanted and when they call. It's the clearest case for the service they pay for.
How do you run this across many customers?
- Start where the risk is. Newly launched customers and customers whose agent changed this week go first.
- Use the customer's own view. Log in as one of their users from your partner portal to check a call or a setting, then fix it there.
- Reuse what you learn. A missed question at one dental practice is probably missing at the next. Add it to their knowledge before their callers ask.
- Send us what you can't fix. Submit an issue from your partner portal, with the call's audio attached, and follow its status there.
The weekly review checklist
| Step | Do this | Done when |
|---|---|---|
| 1 | Clear Attention required | Every callback is returned and closed |
| 2 | Check the clean-resolution rate | You know if it went up or down, and why |
| 3 | Read Recent calls worth a look | Every red-dot call is opened |
| 4 | Find the cause in the transcript | Each flagged call has a reason you agree with |
| 5 | Fix the top reason first | The fix is in a draft |
| 6 | Test with the caller's own words, then publish | The draft answers the flagged call right |
| 7 | Tell the customer | They know what changed |
Want to see a customer's review in your own portal? Book a demo.
FAQ
How often should a provider review a customer's voice AI calls?
Every day for the first week after launch, then once a week. Customers with a high call volume or a recent change may need two reviews a week for a while.
How long does a weekly call review take?
About 20 minutes per customer. Each call has a summary and a transcript, so you only play a recording when the text doesn't explain what happened.
Do I need to listen to every call?
No. Start with the calls that need a person and the calls Insights flags, then the top failure reasons. Calls that resolved cleanly can wait.
What's the most common reason calls go wrong?
It varies by customer, and Insights ranks the reasons for each one. Fix the top reason first, then check whether it drops the next week.
What if a fix makes things worse?
Restore the previous version. The last 10 published versions can be brought back in one click.
