Offline Is a List, Not a Switch: What a Kenyan Till Needs When the Line Drops
Every vendor sells offline capability as a switch. It is a list — and the only useful question is which operations are on it. Here is ours, including the ones that are not, and what a Kenyan counter should actually do when the line drops.
The connection will drop. Not as a rare disaster — as a normal Tuesday. A fibre cut on the road outside, a router that wants restarting, a power interruption the UPS covers for the till but not for the switch it depends on, a mobile network that degrades for twenty minutes at five in the afternoon for reasons nobody at the shop will ever learn. In a Kenyan retail environment this is an operating condition, not an incident, and the businesses that handle it well are the ones that planned for it as such.
So a shortlist forms and everybody asks the same question: does it work offline? Every vendor says yes. Every vendor is describing something different, and almost nobody is lying, which is what makes the question so unhelpful.
This post is about the better question, and about answering it honestly for our own product first, because a page that interrogates everyone else and exempts itself is not worth reading.
Offline is a list, not a switch
The word bundles together capabilities that have almost nothing to do with each other technically, and a system can hold any subset of them. When a vendor says "we work offline", they might mean any one of these, and they will rarely volunteer which.
- A sale can be completed with no connection, held on the device and posted later. This is the hardest one to build correctly and the one buyers assume they are being offered.
- A stock movement can be recorded offline — a receipt at a depot, a transfer dispatched, an issue to a department — and replayed on reconnection.
- A count can be captured offline, which is a different problem again, because a count is an assertion about a moment in time and the moment has passed by the time it syncs.
- A lookup works offline — the app can still show you a price, a stock figure or a customer from a cached copy — without any write being possible.
- The app opens at all offline. Sign-in is a network operation. Plenty of systems that technically hold data locally will not let you past the login screen without a connection.
- The browser works offline, which is a wholly separate build from the mobile client and is usually not what a vendor means, even when they are demonstrating on a laptop.
Those six are independent. A product can do the fifth and none of the others. A product can do the second and the fourth and honestly describe itself as offline-capable while your till still stops dead. The only way through is to stop asking whether and start asking which, operation by operation, and to get the answer before the contract rather than during an outage.
Every vendor on your shortlist will say yes to "does it work offline". Ask instead for the list of operations that work, and watch how quickly the conversation becomes specific.
Our list, in full
Offline capture in AWRA runs in the mobile app and covers the operations below. That is the complete list, and publishing it costs nothing while hiding it would be indefensible.
| Operation | Works offline? | Where |
|---|---|---|
| Stock transfer | Yes — queued and replayed | Mobile app |
| Stock check-in (receiving) | Yes — queued and replayed | Mobile app |
| Stock check-out (issuing) | Yes — queued and replayed | Mobile app |
| Asset movement, including verification | Yes — queued and replayed | Mobile app |
| A till sale | Yes — queued with a provisional receipt | Mobile app |
| A stock count | Yes — count lines and count approvals queued | Mobile app |
| Approvals — requests, invoices, leave, adjustments | Yes — queued and replayed | Mobile app |
| Receiving against a purchase order | Being brought offline next | Mobile app |
| Anything in the browser | Online, with a banner when the line drops — the queue lives in the mobile app | — |
The pattern in that table is not accidental. The operations that queue are the ones performed where the line actually drops — a cashier at an upcountry counter, a team halfway through a stock take, a storekeeper at a depot gate, a supervisor moving equipment between sites. Stock and asset movements were brought offline first, because they happen away from a desk; the till and the count followed.
That is an explanation of the order, not a promise that every case is covered. A sale captured offline still depends on a few things set up while the device was connected, and the rest of this page is about those edges.
What AWRA OpsHub does today
- Sales at the till queue on the mobile app, with a provisional receipt, alongside stock counts, check-ins and check-outs, stock transfers, asset movements including verification, and approvals — captured on the device and replayed exactly once when the connection returns.
- Devices are registered and send a heartbeat, reporting network status, app version, and how many operations are queued, failed and synced.
- Every queued operation is inspectable — module, action, status, when it was captured offline, how many sync attempts it has made, and the conflict code and message if it failed.
- Operations are deduplicated on a client-generated identifier, so a replayed report does not create a second copy of the same record.
- Conflicting custom-field edits are detected on sync against the field definition versions the device held when it captured, rather than being silently overwritten.
More we can add to your workspace
- Receiving against a purchase order offline, which is being brought offline next; a check-in without an order already queues.
- An offline mode in the browser. The web app is online-only today, and a laptop at the counter is not a fallback for a phone.
- A conflict resolution for the same stock moved twice offline. Two disconnected devices can both issue the last unit; both operations sync and the position goes negative for a person to resolve.
Where we point you to a specialist
- We will not describe a product as “works offline” without the list beside it. The phrase implies the whole system degrades gracefully, and ours does not — the mobile app queues the operations listed above, and the browser requires a connection.
- We do not supply tills, tablets, routers or power. The most effective fix for an unreliable counter is almost always connectivity and power engineering, and that is a conversation with an ISP and an electrician rather than a software vendor.
Receiving against a purchase order is the next operation on the list. The queue, the device register, the deduplication and the conflict detection all exist and already carry the till and the count, so extending the list further is a written specification, a price and a timeline rather than new ground. What it is not is something to assume from the phrase “works offline”.
The list above is the claim, and every item on it is something you can watch on a phone in flight mode: ring up a sale, count a shelf, move stock, then reconnect and see each one arrive with the time it was captured.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsWhat actually happens at your counter at five on a Tuesday
On the mobile app, the till keeps trading. The sale is captured on the device with a provisional receipt — provisional because the server reprices it from its own catalogue when it syncs — and joins the queue. Three things decide whether that works on the day: the device must have opened the till once while connected, so it holds the counter setup; a cash drawer must have been opened for the counter before the line dropped, or the queued sales are refused when they sync; and an M-Pesa prompt or a card authorisation still needs its own network, so cash is the tender that trades through an outage.
The failure that costs most is the counter that does stop — a laptop in the browser, or a device that never opened the till while connected. There, a paper fallback which worked once becomes the thing people reach for whenever the system is merely inconvenient, and then you are running two records permanently.
- Back-entry is lossy. Sales written on paper and typed in later lose the customer, the exact item, the discount, and occasionally the sale itself when the page is mislaid.
- Stock drifts from the moment goods leave. The inventory position is wrong from that point forward and nobody knows by how much until somebody counts.
- The shift cannot be reconciled. The drawer holds cash for sales the system never saw, so the variance means nothing and gets absorbed.
- The exception becomes the habit. People remember the day it stopped far more vividly than the months it worked, and they plan around the memory.
Make paper a documented exception, not a habit
If the counter genuinely cannot trade, paper is the right answer — but it should be a numbered duplicate book, opened with a manager's name and a time written in it, entered the same day, and reconciled against the drawer before anyone goes home. The difference between a controlled fallback and an uncontrolled one is entirely procedural, and it is decided in advance or not at all.
Fix the connection before you buy the feature
This is the unglamorous half, and it is usually the half that matters more. A counter that loses connectivity twice a week has a connectivity problem, and buying software that tolerates the outage treats the symptom at considerably greater expense than treating the cause.
-
Put the switch and the router on the UPS
The single most common cause of a "the system went down" report in a Kenyan shop is a power interruption that the till survived and the network equipment did not. The till has a battery; the router usually does not. This is a small, cheap and permanent fix that a surprising number of businesses have never made.
-
Add a second path, not a second provider on the same cable
A 4G router as automatic failover behind the fibre gives you a genuinely independent route. Two fibre providers whose cables run down the same road and get cut by the same excavator do not. Ask where the physical route goes, not just who bills you.
-
Measure the outages you actually have
Most teams estimate this from memory and are wrong in both directions. A simple uptime monitor for a month turns "it goes down all the time" into a number, and the number decides whether this is an engineering problem or a procedural one.
-
Decide the trading rule in writing
What does the counter do during an outage — hold the queue, take cash on a duplicate book, or close? Write the answer down, tell the staff, and put it somewhere they can see it. A cashier improvising in front of eleven customers will invent something, and it will not be your policy.
-
Name who checks the queue
For everything that queues, the till included, somebody has to confirm daily that the device count reached zero. A pending operation nobody watches is a gap discovered at month-end, by which time the person who captured it has forgotten the detail.
The twenty-four-hour clock on offline work
This one is specific to us and rarely asked about anywhere, so it is worth stating clearly: it applies to everything that queues, the till included.
A device can only unlock offline for twenty-four hours from its last verified sign-in. Within that window a cashier or a storekeeper can open the app with no connection and keep capturing. Past it, the app will not unlock offline and the device has to reach the server before any more work can be recorded.
That is a deliberate security position rather than an oversight — an indefinitely trusted device is a credential somebody can walk off with — but it has a practical consequence worth planning around. A team going to a site with no coverage for three days cannot capture for three days. They can capture for the remainder of the first twenty-four hours from their last sign-in, and then they are stopped. If that describes your operation, get the team to sign in within range at the start of each day, or raise it with us before rollout rather than after.
Test the window, not just the feature
In a pilot, put a device in aeroplane mode, capture a few check-ins, and then leave it overnight past the twenty-four-hour mark and try again in the morning. The behaviour you find is the behaviour your storekeeper will find on a site visit, and it is much cheaper to discover it during a pilot.
Where stock movement offline genuinely earns its keep
Beyond the counter, the list is well matched to a particular and very common Kenyan problem: work that happens away from the office and gets written on paper because the system was not there.
A storekeeper receiving a delivery at a depot gate. A driver dispatching a transfer between branches. A supervisor issuing materials at a site. Somebody moving a generator from one project to another. In each case the alternative is not a slower digital process — it is a delivery note in a shirt pocket, entered three days later by a person who was not present, with the detail already gone.
That is the failure offline stock and asset movement was built to close, and closing it is worth as much as keeping the till open. The distribution version of this argument is in inventory and distribution in Lagos, the field version in offline field workflows and van stock and site custody.
The eTIMS question, which the queue makes real
Offline trading and fiscalisation usually collide, because a sale completed on a disconnected device has to be transmitted to KRA at some later point and the timing becomes a compliance question rather than a technical one.
In AWRA the collision is real and it is narrow. A sale captured offline carries its fiscal reference only once the device syncs and the server records it, so for the length of an outage sales exist on a device but not at KRA. Decide the policy before go-live: keep selling, check at cash-up that every sale carries its fiscal reference, and follow up any that do not.
What you should still establish, and in writing, is how long that window may acceptably be, and what a counter that cannot queue is permitted to do during an outage. If the answer involves taking money on paper, then the fiscal question comes back in a different form — those sales still have to be fiscalised when they are entered, and the timing of that is a matter for KRA or your tax adviser rather than for a software vendor. Settle it once, properly, before it is a live problem.
Questions to put to every vendor, including us
If you take one thing from this page, take this list. It converts a claim that everybody makes into a set of answers that can be compared, and it works regardless of which product you end up choosing.
The offline interrogation
- Name every operation captured offline. Not “sales and stock” — the actual screens, one by one.
- Which client does each of those work on? Mobile, browser, or both? A demo on a laptop proves nothing about a phone, and the reverse is equally true.
- Can the app be opened and unlocked with no connection at all, and for how long after the last sign-in?
- What happens on reconnection if the same record was captured twice? Ask them to demonstrate it rather than describe it.
- What happens if two disconnected devices both move the last unit of stock? Every honest answer to this is some version of "a person resolves it" — be suspicious of any other answer.
- Where can a supervisor see what is still pending on a device, and what does a failed operation look like on that screen?
- Is there a limit on how many operations a device can hold, and what happens when it is reached?
- For a fiscalised market: at what moment is the sale transmitted, and what is the vendor's written position on the gap?
Then run the test rather than trusting the answers. Take a device offline, capture several operations, reconnect, and count exactly what arrives. Duplication on reconnection is a real failure mode in offline systems, it produces sales counted twice and stock moved twice, and it is entirely invisible until the evening somebody tries to reconcile.
Our take
Treat connectivity as an engineering problem first — a UPS on the router and an independent second path will do more for a Kenyan counter than any software feature, and cost less. Then be precise about what you are buying: ask every vendor for the operation-by-operation list rather than the yes. Ours is the till, the count, stock and asset movements and approvals on the mobile app, with receiving against a purchase order next, and we would rather you knew that from a page you found before the demo than from an afternoon you were not expecting.
See what does queue, and how it syncs
Sales, counts, stock and asset movements captured on the device, a register of what is pending per device, deduplication on replay, and conflict detection — with the boundaries stated rather than implied.
Explore offline operationsFrequently asked questions
Can we keep selling when the internet goes down?
Yes, on the mobile app. A till sale is captured on the device with a provisional receipt and synced exactly once when the connection returns, repriced by the server from its own catalogue as it posts. The device must have opened the till while connected, and a cash drawer must be open for the counter, or the queued sales are refused on sync. An M-Pesa prompt or a card authorisation still needs a network, so cash is the tender that trades through an outage, and the browser works online only. It is also worth costing the alternative fix first, because a UPS on the network equipment and a 4G failover path usually address the underlying problem more cheaply than any software feature does.
What exactly works offline, then?
On the mobile app: sales at the till, stock counts, checking stock in and out, stock transfers, asset movements including verification, and approvals. Each is captured on the device with the time it was taken, held in a queue, and replayed when the connection returns. The device registers itself and reports how many operations are queued, failed and synced, so a supervisor can see what has not yet reached the server rather than assuming. Receiving against a purchase order is being brought offline next, and the web application works online.
How long can a device stay offline before it stops working?
Twenty-four hours from the last verified sign-in. Within that window the app unlocks with no connection and everything on the list keeps working. Past it, the device has to reach the server before any more work can be captured. This is a deliberate security boundary rather than a technical limit — a device trusted indefinitely is a credential somebody can walk away with — but it matters operationally if you send teams to sites with no coverage for more than a day. Have them sign in within range at the start of each day, or raise it with us before rollout.
Will operations be duplicated when the connection returns?
They should not be. Each operation carries an identifier generated on the device, and the server matches on that identifier rather than creating a new record, so a replayed batch updates what is already there. That said, this is exactly the kind of claim you should test rather than accept from any vendor including us: take a device offline, capture several operations, reconnect, and count precisely what arrives. It takes ten minutes during a pilot and it is the single most useful test on this page.
What if two disconnected devices both move the same last unit?
Both operations sync and the stock position goes negative for a person to resolve — there is no automatic arbitration for that case. In practice it is uncommon within a single store where people can see each other, and much more likely across genuinely separate locations drawing on one scarce pool. If that describes your operation, treat it as a process question — who is allowed to issue from that pool, and how they know — rather than assuming the software will decide.
Does selling offline create an eTIMS problem?
It creates a window rather than a problem. A sale captured offline carries its fiscal reference only once the device syncs, so for the length of an outage sales exist on the device but not at KRA. Decide the policy before go-live: keep selling, check at cash-up that every sale carries its fiscal reference, and follow up any that do not. If your counter ever takes money on paper instead, those sales still have to be fiscalised when they are entered, and the acceptable timing for that is a question for KRA or your tax adviser rather than for us.
