Running two shops on one system: what to look for

The second shop is where a lot of small retailers discover their software was only ever designed for one.

It goes like this. The first shop runs fine. You open the second, set it up the same way, and for about a month everything seems normal because you are in one or the other every day. Then you take a Tuesday off, and somebody rings from shop two asking whether shop one has any of the blue ones, and there is no way to find out except to ring shop one. And you realise you now run two businesses that happen to share a bank account.

“Multi store” on a pricing page is meant to fix this. The trouble is that it means at least four separate things, they cost very different amounts to build, and a vendor who has one of them will say the words as confidently as a vendor who has all four.

The four things

One, separate shops under one login. You own two shops. You log in once and switch between them, and you get one bill instead of two. Each shop has its own catalogue, its own staff, its own stock and its own reports. This is the easy one and most systems that mention multi store have at least this.

Two, consolidated reporting. One screen that adds both shops up. Total takings, best sellers across the group, this shop against that shop. This is where “multi store” starts costing real engineering, and it is the thing most small business systems do not have, because adding numbers across two isolated sets of data is harder than it sounds once currencies, tax and permissions are involved.

Three, a shared catalogue. Create a product once and it exists in both shops, at the same price, with the same code. Without this, adding a new line to a chain of three means doing it three times, and by month four the three catalogues have drifted: different prices, different spellings, different codes, and no report can compare them because the products are not the same products.

Four, stock visibility and transfers. Each shop’s stock counted separately, but each shop able to see the other’s, and a real transfer document to move a crate from one to the other with both stock figures updating. This is the hardest of the four and the rarest.

Now the useful part. Which of those you need depends entirely on what kind of two shops you have, and there are really only two kinds.

Two shops, or one shop in two buildings?

Worth being honest with yourself about this, because it decides everything.

Two shops are genuinely separate businesses. Different areas, different customers, overlapping but not identical ranges, and stock that never physically moves between them. A second shop like this needs number one and it would quite like number two. It does not need three or four, and a system that only does one is not really holding it back.

One shop in two buildings is a chain, even if it is a chain of two. The same range, the same prices, a van that moves stock between them, and staff who work in both. This needs all four, and especially the fourth. If you run this and your software only does number one, you will spend your evenings reconciling by phone, and no amount of discipline fixes it.

Most people opening a second shop assume they are the first kind and turn out to be the second, because the second is more efficient and you drift towards it. So if you can afford to plan for a chain, plan for a chain.

Questions that get real answers

Vendors answer “do you support multiple stores” with yes. These are harder to answer vaguely.

1. Can I see today’s takings for both shops on one screen, without exporting anything? This is number two, and it is a yes or no.
2. If I create a product in shop one, does it appear in shop two? This is number three.
3. Can shop one see shop two’s stock level for a product? Then: is there a transfer document, or do I adjust both by hand? That is number four, and “you can adjust both manually” means no.
4. Is a member of staff one login for both shops, or two logins? Matters more than it sounds when someone covers a shift.
5. What does the second shop cost? Per shop, per till, or included? This is where the bill can double unexpectedly.
6. Can a manager be restricted to their own shop’s data? You will want this the moment you employ a manager, and retrofitting it is not something you can do yourself.

The part nobody warns you about

Two operational things that catch people out, and neither is really a software question, though software makes them better or worse.

Product codes must be identical across shops from day one. If shop one calls it TOM-400 and shop two calls it TOMATO400, then no report will ever compare them and no shared catalogue can be retrofitted without a painful cleanup. If you are opening a second shop and your system does not share the catalogue for you, write the codes down and enforce them like a rule, because this is the one that is genuinely expensive to fix later. The code discipline that helps a single shop is close to mandatory across two.

Cash handling needs to be per shop and per person. Two shops means two drawers and roughly twice the opportunity for a discrepancy nobody can explain. One login per person, per shop, is the only thing that keeps a short drawer a solvable problem rather than a monthly mystery.

And a third, which is about you rather than the software: decide what you will actually look at weekly. Two shops generates twice the numbers and no more of your attention. Pick the handful of figures you check per shop and ignore the rest, or you will look at all of it for a fortnight and then none of it for a year.

Where StoreWave sits

StoreWave does number one, properly, and does not do two, three or four. Worth being blunt about that if you are planning a chain.

What works: one account can own several shops, and you switch between them from the account portal with a single login and a single bill. Each shop gets its own address, its own staff and permissions, its own catalogue, its own stock and its own reports, and the isolation between them is enforced at the database level rather than by a filter in a screen, so one shop genuinely cannot see another’s data. Staff permissions are per shop, so a manager in one shop has no access to the other. The first shop is free; additional ones are on the paid plan at five US dollars a month each.

What does not work: there is no combined dashboard, so seeing group takings means opening each shop in turn or exporting both and adding them up in a spreadsheet. Products are per shop, so a new line has to be created in each. There is no stock visibility across shops and no transfer document, so moving a crate from one to the other is two manual adjustments.

Which lands it clearly: fine for two genuinely separate shops, wrong for a chain. If you have one range, one price list and a van that moves stock between branches, you want a system with all four and you should buy one. If you have two independent shops and mostly want one login, one bill and no data leaking between them, this is a reasonable fit today.