Practical guide

A mobile phone is silent: check the app journey before moving the number again

Last materially reviewed 2026-09-28

Quick answerInvestigate device, notification and connection conditions before assuming a completed port must be repeated.
What to know

Compare the visible symptoms

Does the call appear in history? Does the app receive calls while open but not while the phone is locked? Does behaviour differ on approved networks? These distinctions help the authorised administrator narrow the problem without exposing customer information or collecting unnecessary device data.

What to know

Use current supported guidance

CloudTalk’s mobile help identifies application state, notifications, operating-system behaviour and connectivity as relevant checks. Follow guidance for the actual device and version. Do not assume every manufacturer supports the same calling integration or that desktop behaviour transfers unchanged.

What to know

Keep security boundaries intact

Do not disable organisational security policies or grant new permissions casually to make a demonstration succeed. If the required configuration conflicts with device policy, ask the responsible administrator to assess an approved route. A mobile-app issue is not evidence that another port request should be filed.

What to know

A fictional isolation

Calls reach history and the desktop colleague, while one mobile device stays silent when locked. The team focuses on the supported mobile configuration and notification path. It does not disturb the working carrier order or the entire inbound flow to address one endpoint.

What to know

Record the state that changes the outcome

Use a compact comparison: app open or backgrounded, screen unlocked or locked, approved connection in use, and whether the call appeared in history. Record the device and app version only as far as needed for legitimate support. Change one authorised condition at a time so the result remains interpretable. A successful call after several simultaneous changes does not identify which change mattered. If the supported solution needs a permission or device-policy exception, leave that decision to the responsible administrator. Do not repeatedly reinstall or reset the application before preserving relevant evidence. Once the expected mobile behaviour is observed, note any remaining limitation and the agreed alternative. The purpose is reliable staff coverage, not making a single demonstration look successful at any cost.

Continue when useful

Next: Device readiness

Supported operating systems and real working conditions matter more than a successful demonstration on one computer.

Open Device readiness →

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 mobile inbound diagnosis — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28
  2. CloudTalk mobile troubleshooting — Merchant documentation · help.cloudtalk.io · Merchant-controlled · checked 2026-09-28