When a voice agent gives a wrong answer: setting up an incident process

The short answer

When a voice agent gives a wrong answer — quotes an old price, sends a caller to the wrong address, gives advice on a forbidden topic — the question should not be "who is to blame?" but "how many callers did it affect, and how do we stop it happening again?". That needs a six-step incident process: log the incident, contain the impact immediately, find the root cause, fix it, retest, and inform the affected customers.

The process must be written in advance, because the moment an error is found is usually a moment of pressure: a complaint has come in, a manager is asking, and the agent is still taking calls. This article sets out the steps, severity levels and an incident card.

What counts as an incident

Not every small defect is an incident. An incident is a case where the agent gave a caller wrong or harmful information, broke its boundary, or dropped a call unexpectedly — and it could happen again. For example, the agent mishearing a name once is a defect. The agent quoting an old price all day is an incident.

Severity levels

1. 1HighRisk of financial, health or legal harm; personal data revealed wrongly; an emergency call not handed over. Immediate response.
2. 2MediumA wrong price, condition or timescale; an error affecting many callers. Same-day response.
3. 3LowA single error with small impact and no customer complaint. Fixed in the weekly cycle.

Step 1: log

Wherever the incident is found — a customer complaint, an operator's signal, a transcript review — it is logged in one place. The log records: when, which call(s), what the agent said, what it should have said, and who found it. Attach evidence from the transcript — "it seems it said the wrong thing" is not enough to find a root cause.

Step 2: contain the impact

Before finding the root cause, stop the error continuing. The options depend on severity: temporarily remove the wrong answer from the knowledge base, mark the topic as "hand over" in the scenario, or at high severity temporarily route that call type straight to people. This step should be taken within hours, sometimes minutes.

Step 3: root cause

• Knowledge base: the answer is outdated, incomplete or wrong
• Boundary: the agent answered a topic it should not
• Hearing: the question was misheard
• Similar answer: the agent picked a close but different answer
• Scenario: the instructions conflict or are missing
• Integration: an external system supplied wrong or stale data

Identify the cause by looking at the transcript and at the version of the knowledge base in use at the time. Once one cause is found, check whether similar topics have the same problem.

Steps 4 and 5: fix and retest

The fix must match the root cause: a knowledge problem is fixed in the knowledge base, a boundary problem in the scenario, an integration problem in the system. After the fix, make test calls with the question that caused the incident and several variants of it. Only lift the temporary restriction from step 2 once the tests pass.

Step 6: informing people

If customers received wrong information, identify them — from the call log and transcripts — and give them the correct information. For example, if an old price was quoted, the company must decide how to treat those customers: honour the old price, or explain the correct one. That is a business and sometimes legal decision, not a technical one.

Internal communication matters too: operators need to know what happened so they give the right answer when those customers call.

The incident card

• Number and date, severity level
• What happened — one or two sentences, with a transcript reference
• Impact — how many calls, over what period
• Containment — what was done and when
• Root cause and fix
• Test result
• Customer and internal communication
• The change made to prevent a repeat

Illustrative example: a price change

Not a real customer case. A fitness club changed its monthly membership price and updated the website, but not the spoken version in the knowledge base. For two days the agent quoted callers the old price. Operators raised a signal after reception heard members say "they told me a different price on the phone".

Containment: the price question was immediately marked "hand over". Root cause: the price was stored in two places and one was not updated. Fix: the spoken version was updated and a "knowledge base" step was added to the price change process. Transcripts showed 17 callers had heard the old price; the club decided to honour it for their first month.

Roles: who does what

During an incident, decisions must be made quickly, so roles are written in advance. At minimum three: the person who logs the incident (an operator or the quality lead), the person who decides on containment (the team lead — reachable out of hours for high severity), and the person who decides on customer communication (the customer service director). In a small team one person may hold several roles, but the names must be written down.

The monthly incident review

Once a month, look at all incident cards together. A single incident shows a cause; several show a pattern: if three incidents share the root cause "information stored in two places", the problem is in the process, not in individual answers. The review should end with one or two process changes — a new rule, a new check step, a new owner.

Common mistakes

• Fixing the error in one answer and not looking for the root cause
• Skipping containment — the agent keeps giving the wrong answer
• Not identifying the affected customers
• Not informing operators
• Not logging incidents — a recurring pattern stays invisible

Limits

An incident process does not eliminate errors; it reduces their impact and makes repeats harder. For incidents involving personal data, local law may require notification or recording — establish this with a lawyer in advance. Decisions about compensating customers are business policy.

The incident trail in Vexvon

In Vexvon AI Call Center every call's recording, full transcript, summary and extracted fields stay in the panel — that is where the evidence for steps 1 and 3 comes from. Because the knowledge base is shared with the chatbot, one fix works in both calls and chats. The scenario is changed in the panel, and a difficult topic is passed to a live operator; with routing rules, certain calls can be temporarily sent straight to people, and the rule is checked in the simulator beforehand.

Preventing errors is covered in voice AI hallucination, and the knowledge base format in voice agent knowledge base.

First step

Write a one-page incident process: severity levels, who logs, who decides on containment, who informs customers. Have it ready before the first incident. More articles are in the reliability & pilots section; to set up the process together, get in touch.