The failures that have nothing to do with how well it talks

Tool timeouts, duplicate events, partial success, integration outages, stale state, restarts. The ways an AI receptionist goes wrong that have nothing to do with how well it talks, and what each one should do instead.

Vendor comparisons in this category argue about voice quality. Almost every way an AI receptionist actually harms a business is a state-machine problem instead: a timeout, a duplicate event, a partial success, a stale record. None of them is audible on a demo call.

Seven ways it goes wrong without the model being wrong

Each has a defined behaviour rather than a default.

• A tool times out. Neither success nor failure — routed to a person, because both wrong answers are expensive.
• The same webhook arrives twice. Replayed, not re-executed, so one caller cannot become two appointments.
• A multi-step action half-completes. Not reported as complete.
• An integration is down. A clean failure, said out loud on the call.
• A record is stale. Caught by comparing timestamps rather than trusting the record.
• The process restarts. State is re-read rather than trusted from memory.
• A connector cannot be read back. Never reaches "verified", however clean the response.

Failures become tests, or they are not finished

Every defect this product has hit is recorded with what was seen, how to reproduce it, and the regression test that now covers it. An entry claiming a test it does not have is worse than an open entry, so a check verifies the named file exists and fails the build if it does not — which has itself caught two entries naming paths that could not be resolved.

What we will not claim

No uptime figure, no reliability percentage, no accuracy rate. A rate needs a denominator and ours would be too small to mean anything; publishing one would be the same category of claim this page is about.

A real one: four businesses holding one phone number

Releasing a pooled number cleared the pool record but not the previous holder’s, so each time a number was recycled it gained another claimant. A visitor built a receptionist, was given a number, rang it from their own phone, and reached a different company. Nothing about the model was wrong and no call quality metric would have shown it. The fix was to enforce exclusivity in the primitive rather than by convention, refuse an unrecognised number instead of guessing, and repair every existing claim — and the regression test that would have caught it now runs on every build.

What this page will not claim

This describes how Balaay behaves when things go wrong, not how often they go wrong. We have no volume to compute a rate from and will not publish one until we do.

Related pages

• What is an AI receptionist?
• What an AI receptionist does
• AI phone receptionist
• AI answering service
• After-hours answering
• AI appointment booking
• How this category is priced
• vs an answering service
• vs a human receptionist
• vs voicemail
• vs a virtual receptionist
• AI front desk
• AI call handling
• Call Truth
• Action receipts
• Verified actions
• False completion
• Business Twin
• Website to receptionist
• Pre-flight testing
• All industries
• Pricing

Explore Balaay

In summary

The failures that have nothing to do with how well it talks — Tool timeouts, duplicate events, partial success, integration outages, stale state, restarts. The ways an AI receptionist goes wrong that have nothing to do with how well it talks, and what each one should do instead. Balaay is an AI receptionist for businesses that run on calls. It learns the business from its website, answers the phone, takes the next step, and shows what it did.

Loading interactive experience…