Consider an illustrative customer who begins a loan application on a phone while travelling home. The first page loads. A photograph is requested, the connection drops, and the application silently resets. The customer has not rejected the service; the service has rejected the conditions in which they are trying to use it. By the time they reach a branch, agent or call centre, the digital journey has created more work rather than removed it.
This is one operational consequence of the mobile internet usage gap. The GSMA’s 2026 State of Mobile Internet Connectivity report, Figure 4 estimates that, in Sub-Saharan Africa in 2025, 66% of the total population lived within mobile-broadband coverage but were not connected to mobile internet. A further 9% were outside coverage. The usage gap is covered non-use, not everyone who is offline, and this regional estimate is not a figure for the whole continent. Device affordability, skills and relevant content all matter. For organisations already offering digital services, the finding also sharpens a practical question: can a person complete a task under the conditions in which the service is actually used?
This does not make every organisation responsible for closing a continental connectivity gap. It does mean product, operations and service leaders should stop treating connectivity as an external condition that begins and ends with a network operator. Their own design choices determine how much data a task needs, whether a session survives interruption, whether a shared device creates risk, and whether a person can get help without starting from zero.
Coverage is not the same as a completed journey
It is tempting to read mobile-connectivity figures as an access problem that sits outside the product. The distinction between coverage and use is more useful. A person may live within reach of mobile broadband yet choose not to use mobile internet regularly because a suitable device is unaffordable, data is expensive, confidence is low, content is not useful, or a previous attempt to use a service ended badly.
For a bank, utility, government agency, health programme or growing software business, that difference changes the appropriate success metric. Downloads, registrations and page views say little about whether people can complete a payment, submit evidence, receive a decision or correct a record. A well-covered market can still produce a high abandonment rate if an app insists on a fresh login after every interruption, sends a multi-megabyte update over mobile data, or assumes a person has a private device and an uninterrupted hour.
In the same GSMA primary regional table, the remaining 25% of Sub-Saharan Africa’s population was connected in 2025. These categories use the report’s subscriber-based measure: the connected population accesses mobile internet on its own device, rather than counting every instance of access through a borrowed phone. The report separately considers additional users on shared or borrowed devices. Its estimates can also be revised between editions. The figures should not flatten different national and local conditions or be used to infer why a particular customer abandoned a service. They do show why technical reachability alone is an inadequate product success measure.
A completed journey is the unit that matters. Product teams need to know where people stop, what they have already spent in data and time, whether their work is saved, and what alternative channel can resolve the task. That turns “mobile-first” from a visual preference into a service commitment.
The expensive parts of a small interaction
A common design error is to focus on the size of the final transaction and overlook the cost of reaching it. A customer may be asked to download a large application before they can check eligibility, update it before they can make a payment, upload a high-resolution image, repeat identity checks after a timeout, then wait for a confirmation that never arrives. Each step may look minor on a reliable office connection. Together, they turn a simple action into an uncertain and expensive attempt.
Bandwidth is only one constraint. Entry-level handsets have limited storage and memory. A family may share a device. A user may move between language contexts, lose a SIM card, change a handset, or rely on a trusted agent for help. A feature that assumes permanent local storage or a single, private account can exclude the people it intends to serve, while a one-time password sent to a phone may not be a sufficient recovery route when the device is unavailable.
This is not an argument for stripping services down until they are unsafe or inaccessible. Security controls, document checks and informed consent remain necessary. It is an argument for making each control proportionate to the decision and recoverable when the ordinary path fails. An identity check should explain its purpose and preserve a route to assistance. A document upload should accept the quality needed for verification, not merely the largest file a design tool can render. A payment confirmation should be durable enough to support a dispute.
Data cost is part of the service price. If an organisation has carefully priced a public fee, loan repayment or subscription but ignores the data, device and retry burden required to use it, it has not measured the full cost to the customer. That burden is especially material where the service is meant to reach lower-income users, small traders, rural customers or dispersed field teams.
Build for interruption without normalising failure
Offline-first is sometimes presented as a technical ideology. It is better understood as a question about the minimum useful work that can survive a disrupted connection. Some functions need real-time confirmation: a high-value transfer, a fraud block or a capacity check. Others do not. A field officer can capture a visit, a customer can prepare a claim, or a small business can enter stock information before a connection returns — provided the system records what happened and makes synchronisation visible.
The architecture should make the state of work clear. Has the information been saved only on the device, queued for synchronisation, received by the service, or accepted into an authoritative record? A user needs an answer that does not rely on guesswork. Operations teams need an audit trail that can reconcile a later submission with an earlier attempt and prevent accidental duplication.
That distinction is also a governance issue. Local storage can make a workflow more resilient, but it does not automatically make it private or secure. Sensitive information on a shared or lost device needs suitable encryption, session handling, expiry rules and a recovery process. Synchronisation needs conflict rules: if a field record and a central record are both changed, which is authoritative, who can resolve the difference, and how is the decision recorded?
Graceful degradation is designed, not improvised. A responsible service can state which tasks work in low-connectivity conditions, which must wait for verification, what happens when a task cannot continue, and where a person can receive help. That is more trustworthy than a digital channel that presents every function as available until it fails at the last step.
Assisted channels are part of the product
Many institutions describe an agent, branch, call centre or community intermediary as a costly fallback to be reduced. In practice, these channels often carry the most consequential work: resolving an identity mismatch, explaining an unfamiliar process, dealing with an exception, or helping a user whose device and connection cannot sustain self-service.
The question is not whether every task should be handled by a person. It is whether the assisted channel has enough context to finish the work safely. If a customer arrives with a reference number after an interrupted mobile session, can the officer see the status without asking them to begin again? If an agent captures information on behalf of a user, are permissions, receipts and corrections clearly recorded? If the digital system is unavailable, does the team know which limited actions it may take and how to reconcile them later?
This is where many otherwise capable platforms lose trust. Their digital and human channels are built as separate products. The customer must repeat a story, the agent has no visibility of the previous attempt, and the organisation cannot identify whether a failure came from the network, the interface, the underlying workflow or its own support process.
African service environments offer useful design assets here, not merely constraints. Mobile-money agents, local branches, call centres and field networks can provide a practical bridge between self-service and complex cases when their role is designed deliberately. The aim is not to force every interaction through an agent; it is to make the transition between channels accountable and low-friction.
Measure resilience where users feel it
A more useful review combines technical and operational evidence. Measure successful completion by network condition and device class where this can be done without intrusive profiling. Record resumed sessions, failed uploads, duplicate submissions, time to confirmation, assisted-channel transfers and unresolved exceptions. Watch for the point at which a customer abandons a process, then test whether the underlying cause is data cost, unclear language, a broken handover or a control that does not fit the risk.
Test the real service, not the demo. Put a representative journey on an entry-level handset, restrict the connection, interrupt the session and attempt recovery through the channel a user would actually use. Define success before the test: no lost work, an intelligible status, an authorised recovery path, and a record that can be reconciled. A prototype that succeeds only on office Wi-Fi has not yet demonstrated operational readiness.
The mobile channel is an operating decision
The mobile internet usage gap cannot be solved by product design alone. Handset affordability, relevant local content, skills and network investment remain wider ecosystem questions, as the GSMA’s connectivity report notes. But organisations should not use that fact to excuse services that make ordinary conditions unnecessarily punishing.
The most practical starting point is one high-volume journey where an incomplete mobile interaction creates avoidable cost: a payment, application, registration, claim or field-data submission. Map the exact point at which work is lost or transferred. Then decide which state can be saved locally, which evidence needs immediate verification, what the user should see after interruption, and how an assisted channel can continue the case without weakening security.
Xelius helps organisations research service journeys, design resilient workflows and build data and software systems that work across real device, connectivity and support conditions. The right first engagement is usually the mobile process whose failure is already creating repeat contacts, abandoned applications or manual reconciliation.
A mobile service earns trust when it treats a disrupted connection as a normal operating condition rather than a user error. That choice affects adoption, cost to serve and the institution’s ability to keep a promise once a person has started a journey.
