--- title: "Setting different prices, staff and stock per location" url: "https://www.octalhq.com.au/insights/articles/different-prices-staff-stock-per-location" kind: article description: "How a multi-site system handles different prices, staff and stock per location — local control where it's needed, shared source of truth where it counts." published: "2026-02-07T00:00:00.000Z" updated: "2026-09-26T08:22:41Z" topics: ["Operations"] --- # Setting different prices, staff and stock per location A multi-site system shouldn't force every location to be identical. The good ones let each site vary its pricing, staff and stock while sharing one source of truth. Here's how. The short answer: bringing your locations onto one system doesn't mean flattening them into clones — the good ones let each site set its own pricing, staff, stock and schedule where those genuinely differ, while still sharing one source of truth and group oversight. Central where it should be, local where it needs to be. This is the fear that stops a lot of operators consolidating. They've heard "one system" and pictured every site forced into the same mould — same prices, same setup, same hours — which doesn't match reality on the ground. The good news is that's a limitation of bad systems, not a law of multi-site software. ## The short version - "One system" shouldn't mean every site works identically. - Locations often need different pricing, staff, stock and schedules. - A good multi-site system allows controlled local variation. - You get shared truth and oversight, plus local flexibility. ## Why does forcing uniformity fail? Locations aren't identical, and pretending otherwise breaks things. A site in a different area may need to price differently to match its market. Each location has its own staff, with their own roles and access needs. Stock varies from site to site. Hours and availability differ. If a "shared system" forces everything to be the same, it fights reality — and people quietly go back to spreadsheets to handle the differences it won't. That's the irony: rigid systems don't actually create consistency, they create shadow systems. The moment your software can't represent a real difference between sites, someone works around it, and now you've got the fragmentation you were trying to escape, hidden inside a tool that looks unified. Uniformity isn't the goal; consistency where it matters is. ## What does good multi-site variation look like? - **Pricing per location** — different price points per site, handled cleanly, not through naming hacks or duplicate entries. - **Staff and access per site** — each location's team, with the right permissions, so people see and do what their role needs and no more. - **Stock per location** — real per-site inventory, not one shared pool pretending to be several. - **Schedules per site** — local hours and availability, within a shared framework. The common thread is that these are first-class features, not workarounds. In a well-built system, "this site prices differently" is a setting, not a special case you maintain by hand. That's what keeps the local flexibility from turning back into local chaos. ## What's the balance that makes it work? The art is separating what should be shared from what should be local. Shared: the source of truth, the core process, the group oversight — the things you want consistent and current everywhere. Local: the specifics that genuinely differ site to site — the pricing, people, stock and schedules that reflect real conditions on the ground. Get that split right and you have consistency without rigidity — the group runs as one, but each site runs as itself. Get it wrong in either direction and you pay for it. Too much shared and you're fighting reality; too much local and you're back to a pile of disconnected sites. The skill is knowing which is which for your particular business, which is exactly why the mapping step matters so much. ## Why does this beat separate systems? Some groups handle location differences by running entirely separate systems per site — reasoning that if the sites are different, they may as well be separate. But that brings back all the fragmentation, re-keying and blindness: no single source of truth, no group view, and admin repeated everywhere. You've solved the variation problem by recreating every other problem. A single system with proper local variation gives you the differences you need and the shared truth you want, without the tangle. You keep the per-site flexibility that made separate systems tempting, but lose the reconciliation, the multiplied cost and the missing group view. That's the whole case for consolidation — see [When to move off separate accounts per site](/insights/articles/move-off-separate-accounts-per-site) and [A multi-site operator's guide to getting your locations onto one system](/insights/articles/multi-site-guide-one-system) for the fuller picture. ## What about differences that shouldn't exist? One useful side effect of mapping how your sites vary: you often discover differences that aren't real. Two locations price the same thing differently for no reason anyone can remember. One site follows a process the others don't, because of a staff member who left years ago. Consolidating is a chance to keep the differences that matter and quietly retire the accidental ones — which itself tightens up the operation. The point isn't to erase variation; it's to make every difference a deliberate choice rather than a leftover. ## Related reading - Up to the pillar: [Scaling operations: systems that grow with your business](/insights/articles/scaling-operations-systems-that-grow) - [Running multiple locations without multiplying the admin](/insights/articles/multiple-locations-without-multiplying-admin) - [Group oversight: seeing every location at a glance](/insights/articles/group-oversight-every-location-at-a-glance) ## The honest first step Getting this right starts with knowing which differences between your sites are real and which are accidental. Mapping how your locations actually vary shows what a system needs to allow locally while sharing everything else. That's the diagnosis that makes a single system fit your group instead of fighting it. *Tell us what you run, and we'll show you what's possible.*