Read the telephony provisioning context
- 1
Telephony setup is the authoritative provisioning surface for the organization.
- 2
The description points administrators to queues, agents and routing after provisioning.
- 3
Trunks and Phone Numbers separate provider connectivity from dialed identities.
- 4
Provider, default and status fields reveal whether a trunk can carry calls.
- 5
Queues and the other Telephony pages are the next layers once trunks and numbers exist.
Telephony troubleshooting begins at Setup → Service → Telephony. Trunks establish provider connectivity; Phone Numbers establish dialed identities; and the row fields expose provider, default selection and status. The empty demo2 list illustrates the base rule: without organization provisioning, softphone, call routing and recording behavior are not expected to appear, so investigating an agent or route first would skip the failing layer.
Confirm an active trunk and assigned number, then move outward in call order: browser microphone permission and agent binding, presence and queue eligibility, inbound-route synchronization, call-register evidence, recording delivery, transcript and insight generation. Record the call identifier and exact timestamps when escalation is necessary, but redact numbers, contact identity, recordings and transcript text. Each layer leaves separate evidence; fix the earliest missing or failed one rather than recreating downstream configuration.
Telephony problems in xMatix usually have short explanations, because each stage of a call leaves visible evidence: provisioning shows on the setup screens, routing shows a sync status, and every call — even a failed one — leaves a record in the register. This page works through the common symptoms in the order they occur in a call's life. Everything here presumes the base condition: telephony behaves only where your organization has it configured.
No softphone — the Calls surface is missing or dead
Check in this order:
- Is telephony provisioned at all? An administrator should open Setup → Feature Hub → Service → Telephony. Empty trunk and number lists mean the organization has no telephony yet — nothing downstream can work, and the fix is provisioning, not settings.
- Is the trunk enabled? A disabled trunk switches the softphone off for everyone bound to it.
- Is this user set up as an agent? Where agents are managed explicitly, a missing or inactive entry on the Agents screen leaves that user without a softphone while colleagues have one.
- Is the microphone allowed? A softphone that connects but carries no audio is almost always browser microphone permission or the wrong input device.
Incoming calls don't ring me
Assuming colleagues do get calls:
- Your availability. Only an Available agent is offered queue work — check the status in the Calls drawer. If the drawer has pinned you Offline and won't let you change it, your live call feed is disconnected; that pinning is deliberate (ringing a dead session helps nobody). Reload the workspace and let it reconnect.
- The route doesn't point at you. A number routed to a queue rings one member of the queue's agent pool; if you are not an active member of that resource group, it will never be you. A number routed to a specific person or an AI-agent identity rings no one else at all — by design.
- Check what the call became. Every inbound call leaves a register row from its first ring. Find it and read the status and queue: a Missed row that names a queue tells you routing worked and staffing didn't.
Callers show as bare numbers
The ring popup says "Unrecognized number" when no contact or account carries the calling number. Matching compares the tail digits of the number against every phone field on contacts, then account phone numbers — so formatting and country-code differences are already forgiven, and the practical fix is data: put the number on the contact, and the next call matches. Two contacts sharing a number will match as one of them; matching picks a candidate rather than presenting a choice.
No recording, or no transcript and insights
- The player only renders when a recording exists. Its absence means recording is not enabled for your organization, the file hasn't arrived yet (recordings are delivered after the call ends), or the call never connected — nothing records on a missed call.
- Insights need a transcript. Call insights are generated from the call's transcript; without transcription there is nothing to analyze. If the transcript arrived late, Refresh on the insights panel regenerates against it.
A route shows a sync error
Routes must be pushed to the telephony infrastructure, and the Routing screen shows each route's sync status with the failing error text. Use the route's re-sync action; opening the screen also re-drives anything pending automatically. Until the push lands, calls on that number follow the previous behavior or the organization-wide fallback — noisy, not lost. A sync error that persists across re-syncs is worth raising with xMatix support, quoting the error text shown on the route.
Supervisor can't listen to a call
Three gates, all deliberate: only connected calls can be monitored (nothing to hear on a ringing one); you cannot monitor while on your own call; and the token to join is minted per call, so a call that ends between click and connect fails with "the call may have ended" — pick a live one. An access-required notice instead of the console means the supervise-telephony permission is missing; see The supervisor console.
Common questions
Everyone's phone rings for every call — is that broken?
No: that is the fallback working. Calls ring the whole organization when the number has no active route, or the routed target couldn't take the call (queue with nobody available, inactive agent). The system fails open — toward noise — rather than dropping calls. Author routes for each active number and staff their pools, and the broadcast stops.
A call connected but shows the wrong agent — how?
The answering agent is stamped when the call is answered, and queue assignment names whoever the routing model selected. If a different person picked the call up on the organization-wide fallback, the stamp follows reality, not the plan — read it as evidence about staffing, not a data bug. Supervisor monitoring is the one join that never affects attribution.
Where do I see errors for calls that failed outright?
In the call register: failed calls end in the Failed status like any other terminal state, keeping their timings and parties. Cross-reference the supervisor console's completed-today list for the day's picture, and the Routing screen's sync column when failures cluster on one number.