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 four operations. That is the complete list, and it is short enough that publishing it costs nothing and 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 | Yes — queued and replayed | Mobile app |
| A till sale | No — a sale needs a connection | — |
| A stock count | No — the count screen needs a connection | — |
| Anything in the browser | No — there is no offline mode in the web app | — |
The pattern in that table is not accidental. The four operations that queue are the ones performed away from a desk — a storekeeper at a depot gate, a driver dispatching a transfer, a supervisor moving equipment between sites. Those are the places where connectivity is genuinely unreliable as a matter of geography rather than as a matter of a bad afternoon, and they are where the offline work was done first. A till, by contrast, usually sits in a building with a router in it.
That is an explanation of the priority, not a defence of the gap. If your counter is the thing that has to keep trading, the four operations above do not help you, and you should read the rest of this page with that firmly in mind.
What AWRA OpsHub does today
- Four operations queue on the mobile app — stock transfers, check-ins, check-outs and asset movements — captured on the device and replayed 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.
What it does not do
- A till sale cannot be completed offline. No point-of-sale screen queues anything. When the connection is down, the counter stops.
- Stock counting needs a connection. Counting is not one of the four queued operations, which is worth knowing before a stock take at a site with no signal.
- The browser has no offline mode. The web app is online-only, and a laptop at the counter is not a fallback for a phone.
- No 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.
Not ours, by choice
- We will not describe a product as "offline-capable for stock and asset movement" on the strength of four operations. The phrase implies the whole system degrades gracefully, and ours does not — the mobile app queues four things and the rest 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.
Offline selling and offline counting are scope, not ceilings. The queue, the device register, the deduplication and the conflict detection all exist and work for four operations today, so extending the list 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".
This page previously said sales were held on the device and synced later. That was wrong, and it has been corrected rather than quietly deleted, because a buyer who read the old version deserves to be able to find out that it changed.
What is not built today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — 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 the gap you just read about. Two honest qualifications so this is worth what it claims: a handful of gaps on this blog are deliberate refusals rather than missing work — 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 rather than calling it a gap. 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 gaps, which are the ones this blog admits 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
Plainly: the till stops. A cashier standing in front of a queue with a device that will not complete a sale is going to do something, and what they do next is the part you can still control.
The failure that costs most here is not the twenty minutes of trading. It is that 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 the four operations that do queue, 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 even though it applies only to the four operations that do queue.
A device can only unlock offline for twenty-four hours from its last verified sign-in. Within that window 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 the four operations genuinely earn their keep
Read positively rather than as a shortfall, that 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 the four operations were built to close, and closing it is worth a great deal even in a business whose till still needs a connection. 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 is simpler than you would expect
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.
Because a sale in AWRA requires a connection, that collision does not arise. There is no window during which sales exist on a device but not at KRA, and no argument to have with an adviser about how long such a window may acceptably be. It is a genuine simplification, and it is worth naming because it is the one place where the constraint on this page works in your favour.
What you should still establish, and in writing, is what your counter is permitted to do during an outage. If the answer involves taking money on paper, then the fiscal question comes back immediately 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 with stock and asset movement 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 four operations on the mobile app, selling is not among them, 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
Four operations captured on the device, a register of what is pending per device, [deduplication](/glossary/deduplication) on replay, and conflict detection on custom fields — with the boundaries stated rather than implied.
Explore offline operationsFrequently asked questions
Can we keep selling when the internet goes down?
No. A till sale in AWRA requires a connection — no point-of-sale screen queues offline, and the browser has no offline mode at all. What does queue on the mobile app is four operations: stock transfers, check-ins, check-outs and asset movements. If uninterrupted counter trading through outages is a firm requirement for your business, that is a real constraint and you should weigh it properly rather than discover it later. 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?
Four operations on the mobile app: creating a stock transfer, checking stock in, checking stock out, and recording an asset movement. 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. Everything else — selling, counting, and the entire web application — needs a connection.
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 the four queued operations keep 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 the offline constraint create an eTIMS problem?
The opposite, in fact. Because a sale requires a connection, there is never a period during which sales exist on a device but have not been transmitted, so the timing question that usually accompanies offline trading does not arise. What you should still settle in writing is what your counter is permitted to do during an outage. If the answer involves taking money on paper, 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.
