Back to InsightsOperator Playbook

Running two locations without living in spreadsheets

Sep 25, 2026 8 min read

The jump from one restaurant to two is deceptively brutal. When you had one location, you were the system — you knew the numbers, the staff, and the problems by walking the floor. With two, you can only be in one place at a time, and the informal ways you ran things quietly stop scaling. The trap most owners fall into is patching the gap with spreadsheets emailed back and forth. Here’s how to grow without building a spreadsheet empire.

Decide what’s central and what’s local

The core question of multi-unit operations: what should be identical everywhere, and what should each location control? A useful split:

Write this down. Ambiguity here is what creates the “every location does it differently” chaos that makes numbers impossible to compare.

Standardize recipes and specs first

If a dish is plated one way in location A and another in B, your food cost, quality, and guest experience all drift apart — and you can’t tell whether B is less profitable or just doing it differently. One master recipe book, one spec per dish, rolled out to both kitchens. This single move makes everything downstream comparable.

Report on the same definitions

“Sales are up” means nothing if the two locations count comps, voids, and hours differently. Agree on the exact definitions — net sales, labor %, food cost %, covers — and make sure both locations produce them the same way. Comparability is the entire point of having more than one location; without it, you’re running two unrelated businesses that happen to share a logo.

Compare locations, don’t just total them

The value of two locations is the ability to learn from the difference. Put them side by side on the same metrics every week. When A’s labor runs 4 points lower than B’s on similar sales, that’s a lesson to carry over — not just a number to average away. A rollup that only sums both hides exactly the signal you opened a second location to get.

Kill the spreadsheet relay

The failure mode is predictable: each location keeps its own spreadsheet, emails it Sunday night, and you spend Monday reconciling versions that never quite agree. It’s slow, error-prone, and always a few days stale. Whatever you use, the goal is one source of truth both locations write into — so “the numbers” are a single, current thing, not a pile of attachments.

Where a connected system helps

You can hold this together with strong templates and discipline for a while. Where a connected system helps is exactly the seam that breaks: recipes and prices set once and inherited by every location, one org-wide data layer so each location’s numbers are defined identically, and a control center that compares them side by side in real time. That’s the problem VexaOS is built for — but the central-vs-local discipline above is what makes any tool work.

More operator playbooks are in Insights. If you’d like to see multi-location running on one system, we’re happy to show you — no pressure.

See how VexaOS runs a restaurant