The Phone That's Serving a Customer

There is a particular kind of failure that happens to fully digital businesses in Nigeria, and it has nothing to do with the software being badly built. A field officer stands in front of a pharmacy owner who's ready to place an order right now, today, and the app needs a live connection to confirm the SKU list, and the signal in that particular stretch of road has been dead for forty minutes. The order doesn't get placed. Not because anyone did anything wrong — the officer is competent, the pharmacy owner is willing, the product exists — but because the system quietly assumed a condition that Lagos, on an ordinary Tuesday, simply doesn't guarantee.

Offline-first gets discussed most often as an engineering pattern, a way of architecting an app so it keeps functioning without a live connection. That framing is fine as far as it goes, but for a commercial team (sales, bookings, referrals, field reporting) it's less an engineering question than a management one. The question isn't whether your app was built with offline sync in mind. It's which pieces of the actual work have to keep functioning when the signal drops, the power goes, or the one phone with the relevant app installed is currently being used to serve the person standing in front of it. A business can be completely digital and still be fragile in exactly this way, and the fragility shows up not as a dramatic outage but as a string of small, invisible failures — a booking that couldn't be recorded, a visit that couldn't be proven, a payment that never got reconciled — each one individually explainable and collectively expensive.

I want to be clear about what this essay isn't. There's already a case, made elsewhere, for why AI systems built for Nigeria can't assume clean connectivity: that's a model-architecture argument, about how an AI product itself has to be designed. This is a narrower and more practical question: how does a commercial team's actual day-to-day workflow — the enquiry, the booking, the referral, the order — survive the same conditions.

The moments that create value, and what each one needs

Every commercial process, stripped down, is a sequence of moments where value gets created or lost: an enquiry gets captured, an appointment gets confirmed, a referral gets recorded, an order gets placed, and eventually the loop closes with delivery or payment. The useful exercise is going through that sequence and asking, honestly, of each moment: does this specifically need a live connection right now, or can it wait.

Capturing an enquiry almost never needs to be live: a name, a number, an interest, written down or tapped into a form, can sync whenever a connection reappears. Confirming a booking is trickier, because a confirmation implies a promise, and a promise made on a disconnected device is a promise the business hasn't actually verified it can keep. Recording a referral sits closer to the enquiry end: capture it locally, reconcile later. Placing an order depends entirely on what's actually at stake; a small reorder from a trusted partner can wait for sync, a first-time order against limited stock probably shouldn't be confirmed as final until the system can check itself. None of these answers are universal. The point is that somebody has to sit down and answer them deliberately, moment by moment, rather than letting the app's default behaviour — usually "everything needs the network" — answer them by accident.

Small on purpose

Once you know what has to survive a dead connection, the instinct that follows is usually to store as much as possible locally, just in case. Resist it. A local record kept on a field device should hold only what's needed to complete the transaction it's for — not a full customer history, not everything the business might someday want, just enough to finish this booking or this order. Every extra field stored locally is a field that can go stale, get duplicated, or sit unprotected on a phone that gets lost, borrowed, or sold secondhand at the end of its life, which happens to devices in this market more often than anyone likes to admit.

What matters more than the data itself is the state each record carries. Pending, confirmed locally, synced, needs review, cancelled — five honest labels, understood the same way by everyone using the system. The discipline this enforces is simple and easy to underrate: nobody promises a customer a slot that only exists on one disconnected phone, because "confirmed locally" is visibly, deliberately not the same thing as "confirmed." A field officer who understands that distinction won't tell a member their appointment is locked in until it actually is. A field officer working off a system that doesn't make the distinction will, entirely reasonably, tell them it's locked in the moment the app says so — because why would he assume otherwise.

When two people write the same fact twice

Here is the failure case offline-first design exists to solve, and at any real scale it is close to inevitable. Two field officers, working different corners of the same programme, both offline, both register the same person for the same appointment slot, because the person mentioned interest to both of them on the same afternoon and neither device could check what the other had already recorded. Both records look correct from where they were entered. Neither officer did anything wrong.

The naive fix is to let the system pick one automatically when it reconnects — most recent timestamp wins, say — and this is precisely the wrong instinct, because a silent overwrite means someone's legitimate entry just vanished without anyone being told, and the officer who entered it has no idea it happened until a customer complains that their booking disappeared. Sync has to behave like a conversation: a duplicate rule that catches the collision, and a human review queue that a real person clears, rather than a database quietly deciding for itself which version of the truth survives.

Paper is not the enemy here

There's a reflex in digital-first thinking to treat paper as the thing you're trying to escape, evidence that a process hasn't been modernised yet. That reflex is wrong often enough to be worth correcting directly. A printed, numbered referral form is a perfectly good fallback — arguably a better one than a half-built digital workaround — provided two things are true: there's a same-day capture rule, meaning the paper gets entered into the system before the day ends, not "sometime this week," and there's one named person responsible for making that happen, not a general expectation that someone will get to it. Paper isn't the risk. An unowned queue is the risk: a stack of forms nobody is accountable for entering, which is where good field data quietly goes to die, one un-transcribed form at a time.

Who owns the reconciliation

None of the states and rules above matter if nobody is actually assigned to reconcile them once a connection comes back. It's tempting to treat sync as something the software just handles, and mostly it does handle the mechanical part — pushing records, timestamping conflicts, flagging duplicates. What software can't do on its own is decide, with judgment, which of two conflicting bookings should actually stand when a customer's preference matters, or notice that a "needs review" queue has quietly grown to forty items because everyone assumed someone else was clearing it. That's a named role, not a feature. A small operation can get away with the founder personally checking the queue every evening. A fifty-person field operation cannot, and needs someone whose job explicitly includes closing out what accumulated offline each day, with a target for how quickly it gets cleared and a way of noticing when it isn't.

The same discipline applies to a second, quieter risk: the device itself. A phone that's the sole record of a day's bookings until it syncs is a phone that represents real, if temporary, business risk — lost, stolen, or simply left to die overnight with the charger back at the office. Treating that risk seriously doesn't require exotic technology. It requires a habit, enforced rather than merely suggested, of syncing at defined checkpoints rather than whenever it happens to be convenient, so that the window during which a day's work exists in exactly one place stays as short as it can reasonably be.

Training for the moment it breaks

Most training covers the happy path (how the app behaves when everything's working) because that's the easy part to teach and the part that photographs well in a training deck. The training that actually matters is the recovery drill: physically killing the connection mid-task, in front of the team, and watching what a team member does next. Do they know the offline fallback exists. Do they use it correctly, or do they freeze and wait for the bars to come back. Then a harder version — the battery dies mid-visit, the branch is genuinely full and can't take a walk-in, the price changed since the last sync — because these compound failures are where the wiki-page version of a procedure falls apart and only a rehearsed instinct holds up.

Go back to that field officer on the dead stretch of road, pharmacy owner ready to buy, signal gone. A business that's thought through its offline moments has already decided, before that Tuesday ever happened, what he's allowed to promise without a live connection, what state that promise carries until it's confirmed, and who's responsible for making sure it actually gets recorded once the signal comes back. A business that hasn't made those decisions is asking the Nigerian market to behave like the demo environment the app was built and tested in — reliably connected, evenly powered, one user at a time — and the market, every day, quietly declines.

Notes on sources

• Nigeria's internet subscriber base and the connectivity backdrop that makes intermittent signal an operating reality rather than an edge case: NCC Industry Statistics — Internet Subscriber Data, Nigerian Communications Commission, June 2026 (roughly 156.9 million active internet subscribers, teledensity at 88.67%).
• Nigerian transactions already routing across multiple channels — ATM, POS, USSD, mobile money — rather than a single rail, as a design cue for building recovery paths rather than a single point of failure: e-Payment Statistics, Central Bank of Nigeria.