Multi-Venue Wine Pricing: Consistency Without Losing Local Control

Three venues, three prices, one shrug

A hospitality group opens its second site and, for a while, everything is fine. Then someone notices that the same Provence rosé is 14 a glass at the flagship, 12 at the new place, and 15 at the third venue that opened last spring. Nobody decided this. There's no strategy behind it. The prices drifted apart because three people, at three sites, set them at three different moments using three different mental shortcuts.

This is pricing drift, and it's one of the most reliable symptoms of a wine program that has outgrown its tools. It's rarely the result of bad judgment. It's the result of pricing decisions being made independently, repeatedly, with nothing to anchor them to a shared standard.

Drift is expensive in two directions at once. Where prices drifted low, you're leaving margin on the table. Where they drifted high, you're confusing guests and undercutting the others. And because there's no record of why any price is what it is, you can't even tell which is which.

The instinct is to clamp down: mandate one price list, push it out, enforce it. But that breaks the moment a venue has a legitimate reason to differ, a different clientele, a different rent, a different position in the market. The real answer isn't standardisation versus flexibility. It's a system that gives you org-wide defaults with deliberate, deterministic local overrides, and makes the active venue explicit so nobody prices the wrong context by accident.

Why drift happens (and why discipline doesn't fix it)

The usual response to drift is to ask people to try harder. Send a memo. Standardise the spreadsheet. Have the group beverage director review every list.

It doesn't work, because the problem isn't effort, it's architecture. When pricing logic lives in someone's head, or in a per-venue spreadsheet, every site is an island. There's no shared rule to inherit from, no single place where "this is how the group prices Burgundy" actually lives. So each island reinvents it, slightly differently, every season.

Three structural failures drive the drift:

No shared default. Each venue starts from a blank page instead of from a group standard.
No deliberate override. When a venue does differ, it's an undocumented one-off, not a recorded decision, so it can't be reviewed or rolled back.
No explicit context. Staff editing prices don't always know which venue's data they're touching, so changes land in the wrong place.

Fix the architecture and the discipline takes care of itself. People will happily follow a standard that's built into the tool; they won't reliably reconstruct one by hand.

Org defaults: a single source of truth for pricing logic

The foundation is an organisation-wide default: the group's pricing rules, defined once, applying everywhere unless something deliberately overrides them.

Think of it as the house position. "We mark up bottles by this much. We round to these increments. We compute VAT on this basis." Define it at the org level and every venue inherits it automatically. A new site that opens tomorrow is correctly priced on day one, because it inherits the same rules the flagship uses, not a hastily copied spreadsheet that's already drifting.

This is the moat, really. When the pricing engine is the system of record for how you price, not just the prices themselves, consistency is the default state, not an achievement you have to keep re-earning. (For the underlying rules logic, see how to price a wine list.)

Site overrides: deliberate, deterministic, recorded

Defaults alone would be a straitjacket. Real groups need real local variation. The flagship in a high-rent district legitimately prices differently from the neighbourhood spot. A venue with a different guest mix may run a different by-the-glass strategy.

The key word is deterministic. A site override isn't a free-for-all where anything goes, it's a recorded, scoped decision that the system resolves predictably:

If this site has its own pricing rule for this wine, use it. Otherwise, fall back to the org-wide default.

That fallback is the whole game. Site-scoped rules and site-scoped pricing records sit on top of org defaults, and the engine resolves them in a known order. There's never ambiguity about which price applies, because the resolution is deterministic: most-specific wins, and everything else inherits.

The practical effect:

Most wines inherit the group standard. No per-site effort, no drift.
The wines that genuinely should differ carry an explicit, recorded override at the site level.
Every override is a decision you can see, review, and reverse, not an anonymous edit lost in a spreadsheet.

Standardisation and flexibility, then, not as a compromise, but as two layers of one system. You're not choosing between control and local autonomy; you're getting controlled local autonomy.

	Copy-paste per venue	Org defaults + site overrides
New site setup	Re-key everything	Inherits standard instantly
Most wines	Drift over time	Stay consistent automatically
Legitimate local variation	Indistinguishable from drift	Explicit, recorded override
"Why is this price different?"	Nobody knows	The override tells you
Rolling back a change	Manual archaeology	Remove the override, fall back

Active-site context: pricing the right venue, on purpose

There's a subtler failure mode that org defaults and overrides don't, by themselves, solve: editing the wrong venue's data without realising it.

In a multi-site operation, the question "which venue am I working on right now?" has to have a clear, system-level answer. Otherwise someone updates a price, generates a wine card, or adjusts a reorder rule, and it silently lands on the wrong site. The change isn't wrong; the context was.

Vinius makes this explicit with active-site context: the selected venue drives core operations. Inventory, pricing rules, and wine cards all follow the active site. You're never guessing which location a change applies to, because the context is declared, not assumed. Complexity that already exists in your group, multiple sites, multiple price lists, multiple stock pools, becomes explicit and governable rather than implicit and error-prone.

This matters beyond pricing. The same active-site context means stock decisions are made against the right location's inventory (no pulling from the wrong cellar), and venue-specific wine cards stay correct. It's the connective tissue that makes "multi-venue" a real capability rather than several single-venue setups sharing a login.

Governance: who can change what, where

Multi-venue pricing is also a permissions question. As a group grows, the wrong people changing the wrong prices at the wrong sites becomes a genuine operational risk.

A few governance foundations make this manageable:

Multi-organisation support, so an operator running several entities can switch between them without logging out, the right context, cleanly separated.
Scoped access for integrations, so headless clients and automation operate with explicit, required scopes rather than blanket access. If you connect a POS or an external tool, it acts within defined limits.

The principle is the same as the pricing model itself: make the structure explicit so it can be governed, rather than relying on everyone remembering the unwritten rules.

A sane rollout for a group

You don't standardise three venues overnight. A workable sequence:

Model your sites in the system so each venue is a distinct, explicit context.
Set org-wide defaults, the group's house pricing rules, so every site inherits a shared standard.
Generate site-specific wine cards from each venue's live inventory, confirming the right prices land in the right place.
Add overrides deliberately, only where a venue genuinely should differ, as recorded decisions.
Layer in governance, scoped access and integration controls, as you connect more tools.

The destination: most of your list priced consistently and automatically across every venue, a small set of intentional local differences you can see and defend, and zero accidental drift.

The takeaway

Pricing drift across venues isn't a discipline failure, it's what happens when every site sets prices independently with nothing to anchor them. The fix is architectural: org-wide defaults that every venue inherits, deterministic site overrides for the wines that genuinely should differ (recorded, reviewable, reversible), and active-site context so nobody prices the wrong venue by accident. That's consistency without losing local control, not a compromise between the two, but both at once. Start by modeling your sites and setting the house standard; let the engine handle the rest.