A supermarket lives or dies at the checkout. Everything else — buying well, merchandising, promotions — is undone if the queue at 6pm on a Friday is fifteen people deep and two of them put their baskets down and walk out.
This is about running that checkout: how many lanes you actually need, where the seconds go, and how stock disappears at the till without anyone stealing anything. If you are still choosing a system, our supermarket POS page covers the buying decision.
The queue is an arithmetic problem
Queue length is not bad luck. It is throughput against arrival rate, and both are measurable.
Say your average basket is 14 items, and your operator takes 2.5 seconds per scanned item plus 25 seconds for payment and bagging. That is:
14 x 2.5 + 25 = 60 seconds per customer per lane
One lane clears 60 customers an hour. If 180 customers arrive in your 6pm hour, you need three lanes running just to break even — and any lane that dips below that rate starts building a queue that does not clear until closing.
Two numbers move the result:
Seconds per item. A scanned barcode takes about 2 seconds. The same item typed in by code takes 6 to 10. On a 14-item basket, that difference alone is over a minute.
Payment seconds. Cash with change is slow. An M-Pesa STK push that the customer confirms on their phone while the operator is still bagging is close to free, because it overlaps with work already happening.
Where the seconds actually go
In most Kenyan supermarkets the biggest losses at the till are not the scanning at all:
Items with no barcode, or a barcode that will not read. Loose produce, bulk goods, repacked items. Every one becomes a manual lookup, and the operator has to remember or search a code. Fix: barcode everything you repack yourself, and put a printed quick-code sheet at each lane for the twenty items that genuinely cannot carry one.
Price checks. An item rings up at a price the customer disputes, and someone walks to the aisle. Fix: shelf labels printed from the same catalogue the till reads, so they cannot disagree.
Voids and corrections. An operator rings the wrong item and needs a supervisor. Fix: let operators void their own line before payment while logging every void, rather than requiring a supervisor walk.
Weighing. Produce weighed at the lane rather than in the aisle turns a 2-second scan into a 20-second interaction. Fix: weigh and label in the department where possible.
Barcode discipline on a large catalogue
A supermarket carrying several thousand SKUs has a catalogue problem more than a software problem. Three rules keep it usable:
- Every sellable thing has exactly one code. Duplicates are how the same product ends up with two prices and two stock counts.
- Repacked goods get your own barcode, printed in-store. Sugar decanted into 1kg bags is a product you created; it needs a code you control.
- A new product is not on the shelf until it is in the system. The temptation to put stock out and "add it later" is where the catalogue starts rotting, because later never comes and the item gets sold under a near-enough code.
Shrinkage at the till, without anyone stealing
Supermarket shrinkage is usually blamed on theft. In practice a large share of it happens at the checkout through ordinary process gaps:
| What happens | How it looks in your data | Control |
|---|---|---|
| Item scanned once, two in the bag | Stock lower than sales | Weight-check high-value lines |
| Wrong item rung under a similar code | One line over-sells, another never moves | Review zero-movement report weekly |
| Void after payment | Cash matches, stock does not | Require reason codes; review voids per operator |
| Discount applied without authority | Margin drops on specific operators | Cap discount rights by role |
| Returns handled informally | Stock never comes back | Every return through the till, no exceptions |
The pattern to notice: none of these need a dishonest employee, and all of them are visible in reports you already have. A weekly look at voids per operator and discounts per operator finds most of it.
What to review every week
Not monthly. Weekly, because a pattern caught in seven days is still traceable:
- Voids and discounts by operator. Outliers are worth a conversation, not an accusation — often it is a training gap.
- Zero-movement lines. Products that sold nothing all week. Either dead stock, or being sold under the wrong code.
- Margin by category. A category whose margin slipped without a price change means shrinkage or mispricing.
- Peak-hour throughput. Customers per lane per hour during your busiest hour, tracked over time.
- Stockouts on your top 50. Your best sellers hitting zero is the most expensive failure in the shop, and the least visible.
Peak hours and staffing
Most Kenyan supermarkets have two peaks: lunchtime and the evening commute, with month-end payday amplifying both dramatically. Staffing evenly across the day guarantees queues at the peaks and idle operators in between.
Pull last month's transactions by hour and by day of week. The shape is usually stable enough to roster against, and month-end will stand out clearly enough that you can plan extra lanes for it rather than being surprised every time.
Offline is not optional
A supermarket that cannot sell when the internet drops is a supermarket losing its busiest hour to a router. Any POS running a Kenyan supermarket needs to keep scanning, keep printing, and keep deducting stock while offline, then sync when the connection returns. Test this deliberately before you need it — unplug the router during a quiet hour and put a basket through.
Compliance at volume
Every sale needs a KRA eTIMS-compliant receipt, and at supermarket volumes that cannot be a separate step someone does afterwards. It has to be automatic at the till, or it will not happen consistently. See how eTIMS works on a POS.
Running a supermarket in Kenya? Start a free sell.ke trial — barcode scanning, offline mode, per-operator permissions and automatic eTIMS receipts, from one dashboard.