Practical guide

A caller says the number does not work: locate the boundary

Last materially reviewed 2026-09-28

Quick answerFirst distinguish a call that never reaches the platform from one that reaches it but does not ring the intended person.
What to know

Start with a precise symptom

Ask the authorised reporter for the time, destination and observable result through your controlled support process. Did the caller hear an error, wait, reach the wrong greeting or leave a message? Keep customer identities and call identifiers private; a public screenshot is not an appropriate diagnostic record.

What to know

Check whether the platform saw it

CloudTalk’s guidance distinguishes missing inbound traffic from calls visible in history that fail later in the route. This is a useful diagnostic boundary, not a universal proof of cause. Check the relevant time zone and number before comparing observations.

What to know

Change one relevant layer

A carrier-reachability issue is not necessarily repaired by changing a greeting. A call that reaches history but not an agent may warrant review of hours, route and availability. Preserve the current configuration and escalate with precise evidence rather than making several speculative changes at once.

What to know

A fictional escalation

One outside network reports an error while an internal-platform call succeeds. The team records both results and raises the external reachability evidence with the provider. It does not declare the problem imaginary because a different call path worked.

What to know

Prepare a concise provider escalation

Describe one reproducible or well-evidenced symptom before listing theories. State the affected number through the provider's secure support process, the observation time and zone, the originating path where known, and whether corresponding inbound activity appeared in the platform. Add the expected route and any relevant recent change. Keep a working comparison separate from the failing case so the provider can see the distinction. Do not publish recordings, caller identities or account access details in an open forum. Ask what additional evidence is needed and assign one person to the conversation. Multiple staff opening overlapping tickets can obscure which instruction is current. Preserve the provider's response as a hypothesis or confirmed finding according to what it actually establishes, not as an automatic resolution.

Continue when useful

Next: External reachability

Different originating networks can expose a routing issue that an in-platform call never exercises.

Open External reachability →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. CloudTalk inbound diagnosis — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28
  2. CloudTalk external reachability — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28
DIAGNOSE BEFORE CHANGING

Find the first missing observation.

Observed symptomBoundary to investigateUseful guide
Outside caller cannot connect; no call in historyExternal delivery and number statusExternal reachability
Call appears but the intended team does not ringHours, route and availabilityMissing-call diagnosis
Recording exists; expected email is absentNotification delivery, not necessarily voicemail captureMessage delivery
Call connects but audio is poorDevice and connection conditionsAudio quality

Planning distinctions, not remote diagnosis or a substitute for provider support.