How to Manage Multiple Shop Locations Without Calling Every Branch at Night

Every evening around eight, you call Kumasi. The manager picks up, sometimes on the third try, and reads you the day’s figures from an exercise book. Sales, expenses, what went out on credit. You copy them into your own book in Accra, next to your own shop’s numbers. On Friday you compare what he told you against what actually landed in the MoMo account, and it almost adds up. Almost.

If that ritual sounds familiar, you already know the real cost of a second shop. It is not the rent or the fridges. It is that you can only stand in one place at a time. Everything you used to check with your own eyes now arrives second-hand, over a patchy network, from someone who also wants to close up and go home. Prices drift apart between the two branches. A stock-out goes unmentioned for three days. A shortfall surfaces a week after it happened, when nobody remembers anything.

This guide is about retiring that phone call. One screen that shows every branch, live, wherever you happen to be standing.

Here is something nobody selling you software will say: a lot of second shops open too early, and the expansion quietly kills the first one. If your Accra shop cannot run for a full week without you behind the counter, you do not have a business yet. You have a job. Opening in Kumasi will split your attention until both shops limp along at half strength.

The test is boring but it works. The first shop has been profitable for at least a year. You have a manager you would trust with the keys and the float. Your prices and procedures are written down somewhere other than your head. Pass all three and expansion makes sense. Fail one and no dashboard will save you, because a system multiplies whatever you already have, including the confusion.

The first thing a multi-store system fixes is your product list. When each branch keeps its own list, prices drift apart without anyone deciding it. A promotion runs in one shop and not the other. An old price keeps ringing up in Kumasi three weeks after you raised it in Accra, and the margin difference comes straight out of your pocket.

With a central catalog, every branch sells from the same list. Your supplier raises the price of cooking oil, you change it once from your phone, and it changes everywhere at the same minute. A new product appears in every shop, ready to sell, the moment you create it. Just as useful: your reports finally compare like with like, because both branches are selling the same defined items at prices you set.

One list does not mean one pile of stock. The product definitions live centrally; the quantity on the shelf is tracked branch by branch. Kumasi might hold forty bags of rice while Accra is down to eight and needs a reorder. The system knows both, separately, and the low-stock alert fires for the shop that is actually running dry.

Skip this and you fall into the classic multi-shop trap: the combined total looks healthy, so you feel fine, while one specific branch has been out of your best seller for three days and sending customers next door. Totals hide problems. Per-branch counts expose them. You want to see each shop as the distinct business it really is, from one screen, without driving three hours to count shelves.

Once each branch has its own count, moving goods between them stops being guesswork. Kumasi is sitting on a slow line, Accra just sold out of it: you record a transfer, the quantity leaves one count and lands in the other, with a trace of what moved, when, and on whose say-so.

That trace matters more than it looks. Ask any owner who has run branches for a few years where stock disappears, and transfers come up fast. Goods that "moved" but never arrived. A carton that left Accra as twelve pieces and reached Takoradi as ten. When every transfer is logged on both sides, the gap has a name and a date, and someone has to explain it. There is a cash benefit too: instead of buying more of a product one shop is drowning in, you shift it to the shop that needs it. Money on the right shelf instead of dead on the wrong one.

The dashboard is the whole point. One screen adds up sales across every branch as they happen. At three in the afternoon you know, to the cedi, what Takoradi has taken. At eight you look at the group total, tap into any branch that looks off, and go eat with your family instead of playing accountant over the phone.

That consolidated number is the one that tells you whether the business as a whole is growing, and you cannot assemble it reliably from photos of exercise books. With digabloPos, one dashboard covers all your branches: the group total and each shop’s detail live in the same place, under one login, so the picture never depends on who answered the phone.

The group total is half the story. You also need each shop on its own terms: its daily takings, its best and worst sellers, its busy hours, its margin. A line that flies in Accra can sit untouched in Kumasi, and you only act on that if you can read the two locations separately.

Then comes the part paper can never give you: fair comparison. Because both branches sell the same catalog, you can put them side by side and ask real questions. Which one turns stock faster? Which holds the better margin? Which loses more to voids and refunds? Differences you had written off as "that area is just like that" often turn out to be fixable habits: a manager who discounts too freely, a branch that reorders badly, slow hours carrying too many staff. Comparison also shows you the branch that gets it right, so you copy what works instead of guessing. Without shared numbers, the loudest manager wins every argument. With them, the numbers do.

The more branches you run, the more places a loss can hide, and the combined figures blur everything into a fog. Recorded per branch, and per person, the fog lifts. Every sale, void, refund and discount carries a location and a PIN. You compare what each shop should have banked against what it did bank, and you investigate the gap where it appeared, not across the whole group.

One branch with an odd rate of voids after closing time. Refunds that cluster around one shift. A transfer that left but never arrived. None of this accuses anyone by itself. It just turns "something feels off in Kumasi" into a specific number, on a specific day, that a specific person can be asked about. You cannot police what you cannot see, and honest staff prefer it this way too: the record clears them as often as it catches anyone.

When you cannot be everywhere, control has to live in the system. Each employee gets a personal PIN, and what that PIN can see stops at the walls of their own branch. The Kumasi manager signs in and sees Kumasi: its sales, its stock, its team, nothing from Accra. A cashier rings up sales but cannot void a transaction or check the day’s takings without a supervisor. You see everything, everywhere.

This is what makes delegation safe rather than nerve-wracking. You hand a manager their shop without handing them the group, and you stop being the bottleneck for every small decision made three towns away.

Not always, and pretending otherwise costs you sales. Rent on an Accra high street is not rent near Takoradi Market Circle, and neither are the customers’ pockets. The right setup is one group price list by default, with a deliberate branch-level override where the local market demands it.

The key word is deliberate. A price war around one branch, a line that will not move at the group price: fine, override it, on purpose, visibly. What ruins multi-shop pricing is drift, prices wandering apart because each manager remembers a different number. Decide which items are group-priced, let the system hold the line, and treat every exception as a decision you made rather than one that happened to you.

Your customers pay in cash and, more and more, by Mobile Money: MTN MoMo, Telecel Cash, AirtelTigo Money. In a multi-shop business, each branch’s payments must reconcile on their own. Kumasi’s MoMo against Kumasi’s sales, Accra’s cash against Accra’s, every evening, separately.

Mix them and your end-of-day figures mean nothing. A shortfall dissolves into the group total and resurfaces weeks later as a vague hole nobody can place. Kept apart, each shop closes with its own cash-up: this much cash, this much MoMo, matched against what it sold, and a gap points at one till on one day. That nightly discipline, multiplied across branches, is most of what separates a chain you control from a set of shops you hope are honest.

Anyone trading in Ghana plans around dumsor and dead network zones. For a multi-shop business the danger doubles: if every till depends on one central connection, one outage can freeze the whole group at once, including the branches where the power is fine.

So each branch has to work offline on its own. Sales carry on at that shop with no internet, saved on the device, and sync to the dashboard when the connection returns, with nothing lost. Kumasi keeps selling through a network drop without knowing or caring what Accra’s connection is doing. digabloPos is built this way, each location independent, syncing when it can. Before you sign up for anything, ask the vendor one blunt question: if this branch loses internet for two days, what do I lose? The only acceptable answer is nothing.

Watch the pricing model more than the price. Some systems charge per location, so the bill doubles every time you grow, which punishes you for the exact thing the software is supposed to help with. Others lock you into proprietary hardware, a monthly fee for a terminal that does less than the Android phone already in your pocket.

For a two-or-three-branch business, a sensible ceiling is simple: the software should cost far less per month than one day of one branch’s takings, and starting should cost nothing at all. Begin with a free tier that covers selling, stock and per-branch records, prove the habit works across your shops, then pay for extra modules only when a real need shows up. Put the first cedis into a decent phone per branch and a thermal printer, not into a subscription you have not tested.

Run any candidate system past these eight points: (1) one central catalog, so a price changes once for every branch; (2) stock tracked separately per location, with per-shop low-stock alerts; (3) recorded transfers between branches, logged on both sides; (4) a consolidated dashboard plus reports for each shop; (5) staff PINs and permissions scoped to a single location; (6) MoMo and cash recorded per branch, so each shop reconciles alone; (7) every branch keeps selling offline and syncs when the network returns; (8) runs on ordinary Android phones, with no per-shop fees hiding in the contract. Eight yes answers and you are looking at a system built for branches. A no on points 1, 2 or 7 and you are looking at a single-shop till wearing a multi-store costume.

Start with the shop you cannot see, because that is where the surprises live. Set up the central catalog with your fifty fastest-moving products, correct prices attached. Give the branch manager and cashiers their PINs. Run the system alongside the exercise book for two weeks; the book is your safety net, and watching the two disagree will teach you more about that branch than a year of phone calls.

Then bring your own shop on, add the slower stock, and record your first real transfer instead of sending goods with a note on a trotro. Within a month you are reading both branches from one screen, and the eight o’clock call becomes a chat about the neighbourhood instead of an interrogation about the float. Trying this costs you nothing: digabloPos is free to start, and it was built for exactly this kind of business, power cuts included.