If the app needs 4G, the fragmented trade doesn't have it

The fix is offline-first order capture: the app must take a valid, priced order with no signal and reconcile it when the connection returns, not merely cache a few catalog screens. Most enterprise B2B storefronts fail here because they assume a live connection for pricing, promotions and stock, then degrade to a spinner the moment an outlet has none. Build a local-first data model, a durable order queue, and a priced snapshot with a validity window.

What does the fragmented trade actually look like on the network?

Picture the point of capture. A rep or the retailer is standing in a small independent outlet — concrete walls, a back room, a shared low-end Android on a prepaid plan with a few hundred megabytes left for the month. The signal is one bar of something between 2G and patchy 4G, and for whole minutes it is simply gone. The order has to be written now, in the aisle, before the rep moves to the next store. This is the fragmented, distributor-served trade that carries the bulk of volume in most emerging markets, and its defining network property is not slow connectivity. It is absent connectivity, intermittently, at exactly the moment you need to commit a transaction.

Connectivity here is not a degraded version of a good connection that you can paper over with a loading spinner and a retry. Treating it that way is the root error. An app that needs the network to price a line, validate a promotion or check stock does not run slowly in this environment; it does not run at all, and the order is lost or written on paper and keyed in later with the errors that follow.

Why do enterprise B2B storefronts fail offline?

Because offline is bolted on as an edge case rather than designed in as the base case. The tell is that the offline experience is a different, thinner product than the online one — and the features that thin out are precisely the ones that make an order correct.

Salesforce Consumer Goods Cloud is a useful, documented example, because its offline capability is a separate application with its own rules. A Salesforce implementation partner's write-up of the offline app puts the setup cost plainly:

The new offline application location for Consumer Goods Cloud is separate from the standard Salesforce mobile application and requires its own configuration, which requires expert support.

The pricing story is more revealing. Penny-perfect pricing has to be computed on the device, and the administrator chooses exactly how: Salesforce's own Trailhead guidance documents an Offline (Button) and an Offline (Edit Mode) setting — tap Calculate to price the order, or recalculate on every edit (as of May 2026). Meanwhile, implementation guides note that Advanced Promotions are not available on the offline mobile app (as of May 2026). So the promotion that makes the deal and the price that makes it penny-accurate are the two things most at risk of being wrong, or absent, exactly when the shop has no signal. None of this is a knock on the pricing engine; it is what happens when correct pricing depends on compute that a connection-dependent design never guaranteed would be there.

So what does offline-first order capture actually require?

Three things, and they are architectural, not cosmetic. Get them right and the network becomes an optimisation rather than a prerequisite.

• A local-first data model. The catalog, that customer's price list, the applicable promotion rules and their credit and returnable-empties balance live on the device. The app reads local first and treats the network as a background sync, so a full, correct order can be assembled with the radio off.
• A durable, idempotent order queue. Every order is persisted locally the instant it is written, with a client-generated id, and retried on reconnect. The server deduplicates on that id, so a flaky sync that fires twice does not create two orders.
• A priced snapshot with a validity window. Each order carries the price-list version and promotion set it was quoted against, plus an expiry. On sync the server re-validates against that snapshot and either accepts within tolerance or flags the difference — which is how you resolve conflicts deterministically instead of silently overwriting the rep's number.

This is a proven pattern at scale, not a research project. A top-three global brewer's APAC B2B platform shipped an offline-capable progressive web app alongside SMS ordering for markets with limited connectivity, and, per the same case study, reached 30% of operating-company revenue within two years across 25-plus countries and 370,000-plus users — with the first market live in about two months and new markets standing up at roughly 35% of the original implementation cost. The offline PWA and the SMS fallback were not garnish; they were how the platform reached outlets a live-connection app would have missed entirely.

How do you fix a connection-dependent ordering app?

Retrofitting offline-first is real work, but it is bounded work. Do it in this order.

1. Define offline per role and pick the worst realistic network. A rep in an aisle and a retailer self-serving have different needs. Choose a concrete target — throttled 2G, thirty seconds of no signal — and design to it, not to your office wifi.
2. Push the data model to the device. Sync catalog, customer-specific price lists, promotion rules, credit and empties balances down, and make the app read them locally. The network is for reconciliation, not for assembling the order.
3. Snapshot price and promotion at capture. Stamp every order with the price-list version, promotion set and an expiry window, so the server can re-validate deterministically rather than re-price from scratch.
4. Make the queue durable and idempotent. Client-generated ids, local persistence, retry on reconnect, server-side dedupe. Assume the sync will fire twice and design so that is harmless.
5. Decide conflict resolution before you ship. Auto-accept within a tolerance; flag expired snapshots, changed prices and out-of-stock lines for review. Silent overwrite is the failure mode that erodes trust in the numbers.
6. Keep a no-smartphone fallback. SMS or USSD ordering keeps the long tail without a data plan transacting, and it runs on the same order queue underneath. That long tail is also where the delivery truck's economics are hardest, so every order it captures counts twice.
7. Test on a genuinely bad network. Airplane mode, a throttled connection, a basement, a lift. Measure sync success rate and time-to-confirmed-order, not the happy path. When offline-first is a first-class part of your platform architecture rather than a feature flag, these tests are cheap to run continuously.

The direction of travel makes this easier, not harder. As mid-range devices carry more local compute — on-device pricing, on-device promotion evaluation, eventually small models for order suggestion — and as event buses make bidirectional sync cheap and observable, offline-first stops being a special mode you maintain in parallel and becomes the default that the online path is merely a fast case of. The question worth asking of any order-capture roadmap is no longer whether it works offline, but whether the network is a prerequisite or an optimisation. In the fragmented trade, only one of those answers ships orders.