Running Multi-Branch Retail in Kenya Without Losing Control
The second branch is where Kenyan retailers discover that trust is not a control system — how to run branches on visibility instead: live dashboards, governed transfers, and branch P&Ls.
One shop runs on the owner's eyes. The second branch runs on phone calls and a trusted supervisor. The third runs on hope. This is the standard trajectory of Kenyan retail growth, and it explains a pattern every distributor knows: turnover doubles, profit doesn't. The gap between them is what branches do when nobody with ownership eyes is watching — and the fix is not more trust or more visits. It is a system where the branches are visible without visiting.
What head office must see live
- Sales per branch, per hour — not yesterday's summary photo'd from a notebook. Slumps and spikes mean something the same day.
- Stock per branch, per item — so branch A's stockout can be served from branch B's overstock instead of a new purchase.
- Shift reconciliations — every drawer close, with variances named, from every counter.
- Margins per branch — same products, same prices, different profitability usually means discounting, shrinkage, or unrecorded expenses.
- Expenses at branch level — the petty cash that eats branch profits never appears in a sales report.
Transfers: where branch stock goes to disappear
Inter-branch transfers are the multi-branch blind spot. Goods leave branch A, arrive at branch B — or mostly arrive, eventually, minus a carton. Untracked transfers make both branches' stock cards fiction. The discipline:
- Every transfer is a document, not a phone call: requested, approved, dispatched, received — with quantities at each step.
- In-transit is a real location: goods that left A and haven't reached B are visible, not vanished.
- Receiving counts against the dispatch note; variances are flagged at receipt, attributed, and investigated that day.
- This is exactly what stock transfers with approvals systematize.
Pricing and purchasing: centralize the decisions, not the work
| Decision | Where it belongs | Why |
|---|---|---|
| Prices & discounts | Head office, in the system | Branch-level "manager discounts" are margin leaks with good intentions |
| Supplier selection & terms | Head office | Consolidated volume gets better prices than three branches buying separately |
| Reorder quantities | System-suggested, branch-confirmed | The branch knows local demand; the system knows the numbers |
| Local expenses | Branch, within budget | Autonomy inside a visible envelope |
The branch P&L conversation
The most powerful multi-branch ritual costs nothing: a monthly 30-minute review per branch manager over their own P&L — sales, margin, variance, expenses. Managers who see their numbers manage them. Managers who only hear "do better" manage appearances.
Rolling it out without chaos
- One branch first — the most cooperative manager, not the biggest branch. Prove the routine, then replicate.
- Standardize the item list before connecting branches; three shops with three names for the same product cannot share data.
- Go live per branch at a stock count, so opening numbers are trusted from day one.
- Watch the first month's variance reports together — the system will surface what was invisible, and how leadership responds sets the culture.
The counter-level disciplines that feed all of this — per-shift closes and shrinkage control — are covered in their own guides, and the system checklist is in choosing a POS & inventory system.
What AWRA OpsHub does today
- Stock per warehouse and per bin location, so each branch has its own real position rather than a share of a total.
- Stock transfers between branches as recorded, governed movements.
- Per-location reporting — inventory levels, low stock by location, location usage and throughput.
- Counters bound to a warehouse, so a branch sells from its own stock and cannot oversell it.
- Cycle counts scoped to a branch or location with blind entry and variance rules.
- Role-based permissions, so branch staff see their branch.
More we can add to your workspace
- A branch entity as such. A branch is a warehouse, a location or a department depending on what you are tracking — workable, but you must apply the convention consistently or reporting fragments.
- Inter-branch pricing or transfer pricing.
- A consolidated multi-branch dashboard tile set — you get per-location reports rather than one branch-comparison view.
- Row-level security by branch beyond the standard permissions.
This is one of the clearest fits in the corpus. The single design decision to get right on day one is what a "branch" means in your setup — pick warehouse or department, write it down, and apply it to every module, because retrofitting that convention across a year of data is genuinely painful.
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 needsSee every branch from one screen
Live sales, stock, transfers and counts across every location — with each branch selling from its own enforced stock position.
See multi-branch retail in AWRAFrequently asked questions
At what point does a retailer need branch software — two shops? Three?
The honest answer is at two: the moment stock moves between locations and someone else closes a drawer, the owner's eyes stop being the control system. At two branches the setup is also easiest — retrofitting five undisciplined branches is a much harder project.
Should each branch have its own stock, or is it one pool?
Each branch is its own stock location with its own counts and variances — otherwise responsibility dissolves. The pool exists at the reporting level: head office sees everything and moves stock deliberately via transfers, not by assumption.
Our branch managers resist "being watched". How do we handle that?
Frame it as their instrument, not your camera: they get their own live dashboard, their own P&L, and protection from blame for variances that originate elsewhere (short deliveries, transfer losses). Good managers embrace visibility quickly — it proves their performance. Sustained resistance is itself information.
Can branches keep selling if the connection to head office drops?
Yes — with an offline-capable for stock and asset movement system each branch keeps selling locally and syncs when connectivity returns. Head office sees a gap during the outage, then the full picture. What you avoid is branches that stop trading — or start trading on paper.
