Taking orders where there is no signal
Half of a distribution route can be out of range. Here is how the Sajilo Stores app keeps taking orders anyway.
Distribution / / 4 min read
The route does not follow the towers
A salesman's day runs through bazaars, highways and hill roads. Coverage comes and goes, and an app that needs a connection for every tap stops being used by the second week.
The usual fallback is paper: orders are written down and phoned in at night, and some of them never arrive.
Software built at a desk in Kathmandu tends to assume the network is there. On the route it often is not, and the shops with the weakest signal are still customers who expect their delivery.
What paper costs
Going back to the order book feels safe, but it moves the work somewhere worse.
- Orders are typed twice. Once by the salesman on paper, once by whoever takes the evening phone call.
- Mistakes arrive late. A wrong quantity is found when the truck is being loaded, or when the shop refuses the delivery.
- The warehouse plans blind. Nobody knows what tomorrow's dispatch looks like until the calls come in.
- The khata is out of date. The salesman cannot see what a shop owes while standing in it.
An offline app has to remove these costs. If it only works in town, the paper book stays in the bag.
Keep what the salesman needs on the phone
Sajilo Stores stores products, stock hints and parties on the device. The salesman opens a shop, sees its khata and builds the order from that cached data, with or without signal.
Nothing in the order screen waits for a server. Searching a product, adding a line and saving the order all happen on the phone, so the app is as fast on a hill road as it is in the office.
Queue first, send later
Every order follows the same path, whether or not there is a connection at the time:
- The order is written to the phone's own storage.
- It is placed in a queue of orders waiting to send.
- When a connection returns, the queue sends itself in the order the orders were taken.
- If the network drops again, the app retries with a growing delay.
The salesman does not press a sync button, and does not need to know which orders have gone. A beverage distributor's sales manager described it as orders that sync as soon as the bike reaches the highway.
Writing to the phone first matters most. An order that only lives in memory while it waits for the network is lost if the app is closed or the battery dies.
Nothing is promised from the phone
Stock on the phone is a hint, because the warehouse may have moved since the last sync. Two salesmen on different routes can both sell the last ten cartons.
So an order from the field is a request. It lands in a pending list, where an admin checks it against real warehouse stock and does one of three things:
| Decision | What happens |
|---|---|
| Confirm | The full order goes ahead as taken |
| Part-confirm | Available quantities go ahead, the rest is dropped |
| Reject | Nothing is committed and the order is closed |
Overselling is caught at this step, before a truck is loaded, and the shop hears about a shortage before the delivery arrives short.
How to test an offline app
Before trusting any field app with a real route, try to break it in the office:
- Put the phone in flight mode and take five orders.
- Close the app completely, then open it again. The orders should still be there.
- Turn the network on for a few seconds and off again in the middle of sending.
- Check the admin screen. Every order should appear once, in the order it was taken.
If any order is missing or duplicated, the app will fail the same way on the road, where nobody is watching.