In a branch network the problem is not the branch but what sits between them: different prices, invisible stock, and a daily report arriving in three formats.
Key takeaways
- The gap between branches is the problem, not operations inside a branch.
- Price and stock need one source of truth; without it every report lies.
- A daily report in a uniform format beats a detailed report arriving differently from each branch.
- Permissions by branch are an operational requirement, not only a security one.
- Transfers between branches are where stock disappears - and they are the least recorded.
In a network of three to five branches, the problem is almost never inside a branch but between branches: a price updated in one and not the other, stock sitting in one branch that a customer in another never hears about, and a daily report arriving in three shapes and getting merged by hand in the evening. Those are the three places automation returns the most.
The three gaps
| The gap | How it shows | The prevention |
|---|---|---|
| Price | Different prices between branches | One source of truth, automatic distribution |
| Stock | "Out of stock" in one branch, in stock in another | Stock visible across branches |
| Reporting | A different report from each branch | A uniform form or fixed fields |
The first row is the one customers feel, and it is also the cheapest to fix - it is mainly a process matter rather than a system one. The full logic is in price updates across all channels, and in a network it applies doubly because there are more points to update.
Stock across branches: what is actually required
Not necessarily a full inventory system, but visibility: somebody in branch A being able to see the item exists in branch B. That alone prevents lost sales, and in small networks it is usually the largest gap.
What is required technically is that stock is counted in one place rather than in three files. What is required operationally is harder: that transfers between branches get recorded. An item sent from branch to branch and never logged disappears from both sides - and a month later the count discrepancy gets attributed to "shrinkage" when it is actually missing paperwork.
Why uniformity matters more than precision
In a network, a precise number you cannot compare is worth less than a rough one you can. A branch reporting sales including returns and one reporting them excluded produce two correct numbers with no relationship between them, and any comparison built on them misleads.
So the first investment is not precision but definition: what counts as a sale, what counts as out of stock, and what counts as an exception. Three written definitions are worth more than any improvement to the reporting itself.
It is also what makes the report useful six months later. Data collected under shifting definitions cannot be compared over time, and then the question "did we improve" stays unanswered.
The daily report: uniform before detailed
Most small networks receive a daily report from each branch in a different shape - one as a message, one in a spreadsheet, one by phone. Merging the three by hand in the evening is exactly the work that can be removed.
The simple solution is one form with the same fields for every branch, feeding an automatically merged report. Three or four fields are enough to start: sales, exceptions, out-of-stock items, and incidents. A more detailed report arriving in different formats is worth less than a basic uniform one, because branches cannot be compared.
Permissions by branch
- A branch manager sees their own branch in full.
- A staff member sees only what the shift requires.
- Stock in other branches - usually yes, read-only.
- Other branches' sales figures - usually no.
- Changing prices - only at network level, not in a branch.
The last row is a control rather than distrust: when a branch can change a price locally, the gap between branches creates itself and becomes unavoidable. What should be possible is requesting a change - a clear case for an internal form, as covered in internal forms instead of WhatsApp chaos.
What gets measured at network level and what at branch level
Confusing the two produces most of the useless reports in small networks. A branch-level measure should lead to an action by the branch manager; a network-level measure should lead to a decision by the owner. When they are mixed, a branch manager receives numbers they cannot influence, and the owner receives detail that changes no decision.
At branch level: daily sales, out-of-stocks, busy hours, exceptions. At network level: comparison between branches, items out across the network, price discrepancies, and trends. One cut per level is enough to start.
Comparing branches needs the most care: branches differ in size, location and customer base, so comparing absolute values is nearly always misleading. What does compare is the trend - whether each branch improved against itself.
What to automate first
- Price distribution from the source to every point of sale.
- A uniform daily report from one form.
- Stock visibility across branches, read-only.
- Recording transfers between branches.
- Exception alerts - a branch that did not report, an item out across the network.
The order is based on what breaks fastest. Prices and reporting are process rather than system, so they fix themselves within weeks; stock and transfers need tooling, so they come after.
Where stock disappears in a network
Three places, all of them closable with record-keeping rather than a system. The first is transfers between branches, where the item left and was never recorded on either side. The second is a sale recorded in one branch with the item taken from another branch's stock. The third is returns - an item that came back and was never booked in again.
The third is the largest in small retail networks, because it happens at busy times and nobody stops to record it. The result is stock that exists physically and does not exist in the system - and then it does not sell, because nobody knows it is there.
Closing these is not technical: all three need a three-second entry at the moment they happen. What does help technically is having that entry within reach on the same screen where the action takes place, rather than in a separate form somebody has to open.
What if every branch works slightly differently?
That is the normal state, especially in networks that grew gradually or include an acquired branch. The first instinct is to unify everything, and that is usually a mistake - some differences come from different customers, location or size, and they make sense.
What does need to be uniform is only the three things that travel between branches: price, report structure, and the definition of an item. Everything else - work order, hours, picking method - can stay local with no harm done.
That distinction also matters because of resistance: a branch manager who feels their entire working method is being replaced will object, with justification, and the same manager will readily accept a uniform reporting form. Uniformity in what is measured, flexibility in what is not - that is the rule that holds.
Sources
Frequently asked questions
Do you need one system for all branches?
Preferably, but not as a prerequisite for starting. You can get a long way with one source of truth for prices and a uniform reporting form, even while each branch runs its own till.
How do you measure whether it worked?
Three numbers: how many price discrepancies a quarterly check found, how many sales were lost for lack of knowing another branch had stock, and how long producing the merged daily report takes.
What about a branch that does not report?
An alert on the absence of a report, not a manual chase. A branch that has not reported by a set hour is an event worth alerting on, and it is a clear example of alerting on what did not happen - as covered in [business event alerting thresholds](/blog/business-event-alerting-thresholds).
Should you open another branch before sorting this out?
Every additional branch multiplies the existing gaps, so it is worth at least sorting prices and reporting first. The broader operational logic of running a network is in [multi-branch operations in a system](/blog/multi-branch-operations-systems-israel).
Keep reading
Related service
Inventory & Purchasing
SKU-level stock, reorder rules and an approval flow that leaves a record.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build and I'll tell you the fastest reliable way to ship it.
