What Is a Fatal Error in Call QA? Definition, Examples and How to Write One
The short answer
A fatal error is a critical breach that sets the whole QA evaluation to zero, no matter how well the rest of the call went. It is also called an auto-fail or a critical error. It exists because some failures cannot be averaged away: a compliance breach is not offset by a friendly tone. [SRC001] [SRC003] [SRC004]
Common examples
- Sharing or changing account details before the caller was identified. [SRC003]
- Missing a required disclosure. [SRC003] [SRC004]
- A data-protection breach, such as reading card data aloud. [SRC004]
- Dishonesty, or promising something the company cannot deliver. [SRC003]
- Profanity or abusive conduct. [SRC003]
Which of these count as fatal is your decision. Your compliance team should own the wording.
Fatal error vs a low score
A low score reflects many small misses and points to coaching. A fatal error is one specific event. A criterion rating measures performance against a behaviour, while a critical flag records whether a defined event happened. Do not let a low rating trigger a whole-score failure unless the documented rule says so. [SRC002]
A five-test bar for what qualifies
Because a fatal error overrides everything else, it should be hard to qualify. One useful test says a candidate must pass all five: [SRC001]
- Objective. It either happened or it did not.
- Evidence-checkable. You can point to the lines in the transcript that prove it.
- Unambiguous. Two reviewers always agree.
- Severe. One breach has real consequences, such as regulatory exposure or a privacy risk.
- Within the agent's control. If a system outage made the step impossible, the failure belongs to the process.
Anything that fails a test belongs in the weighted section instead. [SRC001]
How to write a fatal rule
A useful rule states the trigger, where it applies, the evidence needed to confirm it, any exceptions, the score treatment and who owns the rule. Avoid broad labels such as "poor compliance". Use an observable condition. [SRC002]
For example: "Trigger: account balance stated before the identity check was completed. Applies to: all inbound and outbound collections calls. Evidence: transcript lines showing the balance before the check. Treatment: evaluation scores zero and goes to a supervisor." Adapt the wording to your own process.
What this means for AI call QA
Under automated scoring, one wrong fatal result costs more trust than several missed ones, because it makes every other score look arguable. Verify each fatal criterion against calls your reviewers have already scored before it goes live, and require every fatal score to trace back to evidence in the transcript. Give each criterion an appeal route. [SRC001]
CallPulse keeps fatal criteria separate from the weighted score, scores every call against the criteria you define, and works in Hindi, English and Hinglish. For a regulated example, see AI call QA for BFSI collections and BFSI call QA in India.
Where to go next
Fatal items sit alongside weighted criteria on a scorecard. See the call center QA scorecard template for how to build the rest, and why sampling fails for why rare events like these are missed in small samples.
FAQ
What is a fatal error in call QA?
A fatal error is a critical breach that sets the whole QA evaluation to zero, however well the rest of the call went. It is also called an auto-fail or critical error. [SRC001] [SRC003] [SRC004]
Are fatal error, auto-fail and critical error the same thing?
They are often used for similar ideas, but programmes define them differently. Some fail a category, some fail the interaction, some zero the score. Write the consequence into your scorecard guidance instead of assuming. [SRC002]
How many fatal criteria should a scorecard have?
Few. One source suggests most teams should be able to justify five or fewer. A long list usually means a weighting problem, and those criteria belong in the weighted section. [SRC001]
How should AI call QA handle fatal errors?
Treat them as separate from the weighted score, tie each fatal score to evidence in the transcript, and verify each criterion against calls your reviewers have already scored before it goes live. [SRC001]
Sources
Evidence map
- A fatal error or auto-fail sets the whole evaluation to zero regardless of the rest of the call.
Evidence: SRC001, SRC003, SRC004 - Typical fatal criteria are missed required disclosures, sharing details without identity verification and data-protection breaches.
Evidence: SRC003, SRC004 - A fatal criterion should be objective, evidence-checkable, unambiguous, severe and within the agent's control.
Evidence: SRC001