The anatomy of estate-wide promotions

There's a specific operational moment that every multi-site hospitality marketing director knows intimately.

The commercial team has agreed a promotion. "2-for-1 Sunday lunch across the casual dining brand, all venues, four-week window starting in two weeks." The strategy is signed off. The economics work. The marketing team has the campaign brief.

Then the implementation phase begins, and three weeks evaporate.

Week one: the menu update. Pricing changes need to land in every EPOS terminal at every venue. Each terminal needs to be updated individually because the EPOS vendor's deployment model is per-till. The website CMS needs separate updates because it's a different platform. The third-party booking platform needs its own update to reflect the promotional pricing. The online ordering channel needs another. Each update is a ticket, an approval, a rollout, a verification.

Week two: the marketing assets. The email needs building in the marketing platform. The social posts need scheduling separately. The paid media creative needs production. The local-market collateral needs printing for in-venue display. Each asset team works to their own timeline, against their own approval process.

Week three: the segmentation and targeting. The marketing platform needs the right segments built: customers who've ordered Sunday lunch before, customers who haven't visited in 60 days, customers within driving distance of participating venues. The CRM extract that feeds the segmentation is itself a separate workflow, often requiring an analyst to pull data manually because the integration drift means the marketing platform's view of the customer base doesn't match the CRM's.

Three weeks elapsed. The promotion launches. A general manager at one venue calls head office to flag that her venue's pricing in the EPOS doesn't match the website. A customer service ticket comes in from someone who got the email but the local online ordering channel doesn't honour the offer. By Sunday afternoon of week one of the campaign, twelve customer complaints have accumulated about pricing inconsistencies.

This is the operational reality at every multi-site hospitality group running a fragmented stack. The promotion eventually runs. The metrics eventually look fine. But the cost (in elapsed time, in coordination overhead, in customer-experience friction) is significant. And it's the same cost every single time.

The architectural reason promotions are slow

The slowness has the same underlying cause as the menu management slowness: the promotion lives in too many places, owned by too many vendors, synced by too many integrations.

The pricing change lives in the EPOS. The menu display lives in the CMS. The booking discount lives in the reservation platform. The email creative lives in the marketing platform. The segmentation lives in the CRM. The audience exclusions live in the loyalty system. The reporting lives in the BI tool that aggregates all of them after the fact.

Every promotion is, structurally, a coordination project across seven or eight separate systems. The marketing team's job is half campaign design and half human integration layer, making sure the right people in the right vendor systems take the right actions in the right order so the promotion lands consistently across surfaces.

This work is invisible. It doesn't show up in any quarterly board pack. It doesn't have its own line item in the budget. But it absorbs an enormous proportion of the marketing function's actual time. The marketing director who should be thinking about brand strategy and acquisition economics is spending Tuesday afternoon coordinating with the EPOS vendor's support team about why one venue's till still shows the old pricing.

What changes when promotions live in the same database

The mDOS architecture takes a different position. A promotion is a single definition in the database. It's held as one promotion record at company scope, with venue-level overrides using the same override pattern used for menus. The marketing team defines the promotion once in the UI. Because every surface (EPOS terminals, website CMS, online ordering, in-room tablets, QR ordering screens) resolves pricing from that one definition at read time, there's no per-surface re-entry and no vendor-to-vendor sync to keep in step.

The pricing change is the promotion. There's no separate EPOS update. The promo terms are visible to the till because the till reads from the same database that the promotion was defined in. The CMS shows the promotional pricing because the CMS reads from the same database. The booking widget honours the discount because the booking widget reads from the same database. No integration. No sync delay. No version skew.

Venue-level overrides handle the specific operational reality that promotions rarely apply identically across an estate. The country house hotel might want to exclude its Sunday roast from the "2-for-1 Sunday lunch" promo because that specific dish is already premium-priced. The city centre venue might want to extend the promo window to Saturday because its trading pattern is different. The northern venues might want different complementary side pricing. Each of these is a venue-level override on the promotion's venue settings: no separate definition, no parallel campaign, no duplicated logic.

The settings-driven-by-default architecture

The pattern behind promotions is worth understanding at the architectural level, because it's the same pattern that makes the entire platform adaptable to operators of dramatically different sizes and business models.

Every business rule in mDOS (tax rates, tipping conventions, terminology, compliance rules, pricing tiers, promotional eligibility, loyalty earn rates, booking cutoff windows, modification policies, voucher expiry rules, allergen labelling requirements) lives in the settings hierarchy and resolves via a single resolver. The hierarchy cascades from company down to brand down to venue, with optional venue group overlays cutting across the brand boundary.

This means a promotion isn't a fixed configuration baked into the platform. It's a settings-driven artifact. The promotion type, the discount mechanism, the eligibility criteria, the redemption rules, the reporting categorisation: all of these are operator-configurable. A pub group can build promo types that match their commercial model. A hotel group can build different promo types for room-rate promotions versus F&B promotions versus spa packages. A multi-brand operator can build brand-specific promo types that differ in fundamental ways.

The same architecture is why mDOS works for operators in different jurisdictions without bespoke development. Tax rules differ between the UK and Ireland and the US. They're settings. Allergen labelling conventions differ between Natasha's Law and the FDA's requirements. They're settings. Tipping conventions differ between the UK's discretionary model and the US's expected tip. They're settings. The platform adapts to the operator rather than the operator adapting to the platform.

What estate-wide promotions actually look like

The marketing team for a 50-venue multi-brand group opens the promotions interface. They define a new promo: "2-for-1 Sunday lunch, casual dining brand only, all venues, four-week window from 15th June, eligible items: any main course from the Classics section of the menu, customer eligibility: marketing-consented contacts within 25 miles of a participating venue."

They click activate.

Because each surface resolves pricing from the single promotion definition, the promotional pricing applies the next time a terminal or page resolves the menu, with no per-venue reconfiguration and no overnight sync. An EPOS terminal picks it up on its next menu/promotion fetch. The website displays the promotional pricing on the menu page within the next page reload. The booking widget shows the promo terms during the booking flow. The online ordering channel honours the offer.

The marketing team then defines the email campaign in the same UI. The email targets the segment of marketing-consented contacts within 25 miles of participating venues. The segment is built against the live guest records, current as of right now, not as of last night's CRM sync. The email schedules for the Wednesday before each Sunday of the promo window. The send happens via the same engine that handles every other automated communication.

Total elapsed time from "promo concept agreed" to "promo live across the estate with email campaign scheduled": twelve to fifteen minutes, depending on how much segmentation work the marketing team chooses to layer in. No coordination with the EPOS vendor. No separate CMS update. No CRM extract for the segmentation. No tickets opened with the integration team.

The marketing director's time is now available for the work that actually matters: thinking about why the 2-for-1 Sunday lunch is the right promotion for this quarter, whether the four-week window is the right duration, whether the 25-mile catchment is the right geofence, whether there should be a complementary mid-week offer to fill the dining trade between Sundays. Strategic work, not coordination work.

The reporting loop closes automatically

For most legacy promotions, post-campaign reporting is its own project. Sales data from the POS, redemption data from the loyalty system, email engagement data from the marketing platform, attribution data from the analytics tool: all of these need to be reconciled to answer the question the CFO actually asks: "did the promo make us money?"

In a unified architecture, closing the reporting loop doesn't require stitching vendors together. The promo definition lives in the same database as the orders that redeemed it; redemptions and discount totals are captured at the order level through promo-code redemption; email engagement is tracked against the same guest records. That shared foundation is what turns a full promo-performance view (gross and net revenue, redemption rate, email contribution, cohort and venue-level variance) into a straightforward reporting build rather than an integration project. Today the platform surfaces redemption count, discount total and gross at the promo-code level; the consolidated executive view across those dimensions is on the reporting roadmap.

The CFO doesn't wait three days for an analyst to reconcile vendor exports. The marketing director doesn't have to build a custom report. The board doesn't have to make next-quarter decisions on incomplete data.

What this means for the multi-site marketing director

For the marketing director of a multi-site group, the promo execution problem has been a structural constraint on the function's strategic value for years. The marketing function should be doing strategy, brand, and audience work. Instead, a meaningful proportion of marketing time is spent as a human integration layer between vendor systems.

Unified promotion architecture removes that constraint. The marketing director can ship campaigns at the speed the commercial reality requires. Mid-season tactical promotions become viable because they don't require three weeks of coordination. Reactive promotions to local market conditions become possible because individual venues can layer overrides without affecting the rest of the estate. A/B testing of promo mechanics becomes practical because two parallel promos can run with different definitions and clean reporting on each.

For acquirers evaluating mDOS as IP, the promotion architecture is downstream of the broader Settings-Driven by Default pattern. The platform's adaptability across operator types and jurisdictions is what makes it commercially scalable. A consolidator deploying mDOS to a pub group, a hotel group, and a restaurant chain can configure the platform to each operator's specific business model without bespoke development. The settings architecture is the moat that makes that possible.

---

The promotions architecture inherits the platform's Settings-Driven by Default pattern with venue-level overrides. Technical documentation available under mutual NDA.