> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/use-cases/hospitality-groups-multi-venue/venue-level-forecasting-pack.md).

# Venue-Level Forecasting Pack

This use case explains how to build a standardised venue level forecasting pack for hospitality groups that operate multiple restaurants, bars, cafes or venues.

You will:

* Represent each venue as its own branch with consistent variable structure.
* Build volume and pricing drivers for food, beverage and other revenue lines.
* Model venue level COGS, staff, rent and operating costs.
* Package the outputs into a repeatable pack you can use across all venues.
* Roll venue packs into group level views and scenarios.

Model Reef is not a POS or rostering system. It uses aggregated drivers, not individual transaction or shift level data.

## When to use this pattern

Use this pattern when:

* You run multiple venues and want a consistent forecasting framework.
* You need to compare venue performance using the same definitions.
* You want a pack you can hand to each venue manager to own and update.
* You want venue forecasts that roll into group reporting and valuation.

It is a foundation for:

* Group Level Consolidated Reporting
* Promotions and Margin Sensitivity
* Staff Rostering and Labour Planning
* Build a Multi Division Model

## Architecture overview

Venue level forecasting uses:

1. Structure
   * Branches for each venue with a shared template.
   * Parent branches for regions and the group.
2. Revenue drivers
   * Covers, guests or transactions.
   * Average spend per head by category.
   * Day of week and seasonality patterns.
3. Cost drivers
   * COGS percentages or recipe cost per item.
   * Staff rosters and wage rates.
   * Rent, utilities and other operating expenses.
4. Outputs
   * Venue P\&L, Cashflow and key KPIs.
   * Group level rollups across venues and regions.

***

{% stepper %}
{% step %}

### Create a standard venue template

Start by creating a single venue branch, for example `Venue - Template`, with variables for:

* Revenue - Food - Dine In.
* Revenue - Beverage - Dine In.
* Revenue - Takeaway or Delivery.
* COGS - Food.
* COGS - Beverage.
* Staff - Front of House.
* Staff - Back of House.
* Opex - Rent.
* Opex - Utilities.
* Opex - Local Marketing.
* Opex - Other Operating Costs.

Use this template to define the naming conventions and categories that every venue will use. Once you are happy with the template, duplicate the branch for each real venue and rename, for example `Venue - Site 001`, `Venue - Site 002`, and so on.
{% endstep %}

{% step %}

### Build demand and revenue drivers per venue

In the Data Library, set up drivers such as:

* Average Covers per Day by day of week.
* Average Spend per Cover for Food and Beverage.
* Split of sales between dine in, takeaway and delivery.
* Seasonality factors by month or week.
* Event or holiday uplift multipliers where relevant.

For each revenue variable, use formulas such as:

* Food Revenue = Covers × Food Spend per Cover × Seasonality.
* Beverage Revenue = Covers × Beverage Spend per Cover × Seasonality.

If you track separate day parts such as lunch and dinner, create separate driver sets for each and sum them for the day or week.
{% endstep %}

{% step %}

### Model COGS and gross margin

For each venue, define COGS drivers such as:

* Food COGS Percentage of Food Sales.
* Beverage COGS Percentage of Beverage Sales.
* Alternative recipe based costs where required.

Implement COGS variables like:

* COGS - Food = Food Revenue × Food COGS Percentage.
* COGS - Beverage = Beverage Revenue × Beverage COGS Percentage.

Where you want more precision, use recipe and menu costing in a separate driver table and map those costs into venue level COGS via average cost per menu mix.
{% endstep %}

{% step %}

### Add staff, rent and operating cost models

For each venue, create Staff variables for:

* Front of House staff.
* Back of House staff.
* Managers and supervisors.
* Other key roles.

Attach drivers for:

* Hours per week and hourly rates.
* Salary levels for salaried roles.
* On cost percentages for tax and benefits.
* Payment delays for cash timing.

For non staff costs, use Opex variables with drivers such as:

* Rent per period with scheduled increases.
* Utilities as a percentage of sales or based on historical patterns.
* Local marketing as a fixed amount or percentage of sales.
* Other operating costs with appropriate drivers.

This produces venue level EBITDA before any group wide overhead.
{% endstep %}

{% step %}

### Package the venue pack for repeated use

Create standard dashboards and reports for a single venue, for example:

* Venue level P\&L with key subtotals.
* Charts for revenue, gross margin and staff cost over time.
* KPIs such as sales per cover, gross margin percentage and staff cost percentage.
* Simple cashflow and headroom views if required.

Make sure that all charts and reports reference branches and categories that exist in every venue template. When you duplicate the template for each new venue, the same pack will work automatically, just focused on the selected venue branch.
{% endstep %}

{% step %}

### Use scenarios at venue level

You can treat each venue as a scenario by duplicating the whole model, or you can hold scenarios within a single group model by:

* Duplicating the group model for each funding or strategy case, or
* Using driver toggles for different scenarios and switching sets of assumptions.

For each venue, test scenarios such as:

* Price increases.
* Changes in opening hours.
* Staff and roster adjustments.
* Menu changes and mix shifts.
* New channels such as delivery or catering.

Compare venues and scenarios using the same standard pack so performance is interpreted consistently across the network.
{% endstep %}
{% endstepper %}

***

## Check your work

* Venue revenue and cost patterns reconcile with historical performance for a sample of sites.
* Staff, COGS and rent assumptions reflect actual contracts and practices.
* The template is general enough to apply across venues without customisation, or you have clearly documented where it differs.
* Group rollups from venue branches align with internal group management reports.

***

## Troubleshooting (expandable)

<details>

<summary>Venue results look inconsistent across similar sites</summary>

Check that driver assumptions are consistent for similar venues and that event or seasonality adjustments have been applied correctly.

</details>

<details>

<summary>The pack is too complex for venue managers to maintain</summary>

Simplify driver structures, hide non essential detail, and provide clear instructions for which inputs venue managers should update regularly.

</details>

<details>

<summary>Model performance slows with many venues</summary>

For long range planning, group smaller venues into representative cohorts and keep per venue detail for near term periods or key sites.

</details>

***

## Related guides

* [Valuation](/how-tos/valuation.md)
* [Build Cross Branch Drivers & Dependencies](/how-tos/data-workflows-and-automation/build-cross-branch-drivers-and-dependencies.md)
* [Non Current Liabilities](/help/financial-outputs-and-valuation/non-current-liabilities.md)
* [Entering Delays](/syntax/timing-syntax/entering-delays.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.modelreef.io/use-cases/hospitality-groups-multi-venue/venue-level-forecasting-pack.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.