Call problems
Diagnosing calls that fail, sound wrong, or where the AI behaves unexpectedly.
Calls are not being answered
- Confirm the number is activeCheck it appears under Owned Numbers and is not pending compliance.
- Check your plan statusA lapsed subscription or exhausted call allowance stops calls being taken.
- Verify opening hoursA call outside your configured hours is handled differently — see after hours.
- Ring it yourselfFrom a phone that is not connected to your account.
The AI is not behaving well
Usually because: It cannot find an answer in your business information and keeps re-asking.
Fix: Read the transcript to find the exact question. Add that answer to your knowledge and set an escalation trigger so the same case reaches a person next time.
Usually because: Letter-by-letter and digit sequences are the hardest thing for any speech system, particularly on a noisy line.
Fix: Where possible let customers supply these another way — a proof upload link or a follow-up message. See proof uploads.
Usually because: Usually it did not — check the call quality panel.
Fix: If it shows the interruption was handled and a stale reply cancelled, SIMCOAI stopped correctly. If interruptions are genuinely high, review speech settings in voices and speech.
Usually because: First-reply latency above about 2.5 seconds feels sluggish to a caller.
Fix: Check the figure on the call. A very large knowledge base or a slower premium model are the usual causes — compare a few calls before changing anything.
Usually because: No trigger existed for that topic.
Fix: Add it explicitly. Complaints, safety, medical, legal and payment topics escalate by default; anything specific to your business you must add.
Usually because: Cancelling, moving and booking are recognised as three distinct requests, but a caller who is vague about which one they mean can be misread.
Fix: Read the transcript for the caller's exact wording. If the request genuinely was ambiguous, that is a real product limit worth reporting; if the wording was clear and it was still misread, report it with the transcript and timestamp.
Usually because: Spoken digits and spoken times share a lot of the same words, so this used to be a real confusion.
Fix: This is specifically handled today — a code being read back should not be treated as a new time. If you see it happen, it is a regression worth reporting with the transcript.
Poor audio quality
Audio problems are usually carrier or caller-side, not AI-side. Note the time and number, check whether it affects all calls or one, and check the status page before assuming a fault.
A callback request was not logged
Asking to be called back creates a real, trackable escalation record — it should never just be acknowledged and then dropped. If a caller says a callback was promised but nothing appears under Escalations, check the transcript for the exact phrase used and report it with the call time; treat it as a fault, not something to work around.
If the problem is somewhere else
- Wrong or missing availability offered — see Bookings.
- A transfer to a person failed or went to the wrong place — see Call transfers.
- Calls outside opening hours behaving oddly — see Voicemail and after hours.
- The voice itself sounds wrong or keeps changing — see Voices and speech.
A repeatable incident method
Use the same order for every fault so configuration, account and platform causes are not mixed together.
| Stage | Question | Evidence to keep |
|---|---|---|
| Scope | One user, one number, one workflow, or every customer? | Affected and unaffected examples |
| Time | When did the last success and first failure occur? | UTC times and request or call identifiers |
| Change | What configuration, release, credential or billing state changed? | The exact change and its owner |
| Dependency | Does the status page or dashboard health view show a wider issue? | Status snapshot and observed behaviour |
| Recovery | Can traffic use a safe previous route while investigation continues? | Rollback action and verification result |