> 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/staff-rostering-and-labour-planning.md).

# Staff Rostering & Labour Planning

{% hint style="info" %}
Model Reef is not a rostering or payroll processing platform. It models labour at planning level, not individual shifts or timesheets.
{% endhint %}

## Staff Rostering and Labour Planning

This use case explains how to model staff rostering, labour planning and cost across multiple hospitality venues in Model Reef.

You will:

* Represent roles and teams at venue and group level.
* Build drivers for staffing by day part, day of week and season.
* Convert rosters into FTE and labour cost with on costs and timing.
* Use scenarios to test labour models, opening hours and wage changes.

***

### When to use this pattern

Use this pattern when:

* Labour is one of your biggest controllable costs.
* You need to align staffing with sales and service expectations.
* You operate multiple venues with different demand profiles.
* You want to test labour strategies before implementing them operationally.

It integrates with:

* Venue Level Forecasting Pack
* Group Level Consolidated Reporting
* Build a Staffing Cost Model
* Build a Cashflow Early Warning System

***

### Architecture overview

Labour planning for hospitality uses:

* Role structure
  * Front of house, back of house, bar, management and other roles.
  * Separate roles where pay rates and responsibilities differ.
* Roster drivers
  * Hours per role by day part and day of week.
  * Seasonality and event adjustments.
  * Minimum staffing levels per venue.
* Cost and timing
  * Hourly rates, salaries and on costs.
  * Weekend, evening or public holiday loadings.
  * Payment frequency and delay.
* Scenario analysis
  * Different opening hours, service models and wage assumptions.
  * Volume driven labour models versus more fixed staffing models.

***

{% stepper %}
{% step %}

### Step 1: Define roles and staff variables per venue

For each venue, list key roles, such as:

* Venue Manager
* Assistant Manager
* Front of House team
* Bar staff
* Kitchen team
* Cleaning or support staff

Create Staff variables for each role and venue, for example:

* Staff - Venue 001 - Front of House
* Staff - Venue 001 - Kitchen
* Staff - Venue 001 - Manager

These variables will hold FTE or headcount assumptions and drive labour cost.
{% endstep %}

{% step %}

### Step 2: Build roster and workload drivers

In the Data Library, create drivers for each role that express:

* Hours per day part (breakfast, lunch, dinner, late) by day of week.
* Number of staff per role in each slot.
* Event or holiday adjustments per role and venue.
* Seasonality factors where demand differs by month or season.

From these, derive total weekly or period labour hours, for example:

* Weekly Hours per Role = sum of hours across all day parts and days.
* Period Hours = Weekly Hours × weeks in period adjusted for seasonality and events.

You can differentiate between base staffing and incremental staffing driven by forecast volume where desired.
{% endstep %}

{% step %}

### Step 3: Convert roster hours into labour cost

For each Staff variable, attach cost drivers:

* Base hourly rate or salary.
* Weekend, evening and public holiday loadings where applicable.
* On cost percentage for tax, pension and other contributions.
* Overtime rules if you want an approximate uplift for extended hours.

Compute labour cost as:

* Wage Cost = Hours × Effective Hourly Rate.
* Total Staff Cost = Wage Cost × (1 plus On Cost Percentage).

Enter timing settings to reflect pay cycles, typically weekly or fortnightly, with short payment delays.
{% endstep %}

{% step %}

### Step 4: Link labour plans to sales and service expectations

Where appropriate, link roster drivers to revenue and capacity assumptions. For example:

* Express required FTE per cover or per sales amount.
* Define minimum staffing levels for opening hours.
* Add additional staffing for events or high demand periods.

This helps ensure that labour planning is aligned with forecast sales and service requirements and avoids static, unresponsive staffing patterns.
{% endstep %}

{% step %}

### Step 5: Use scenarios for labour strategy and wage changes

Clone the base model into scenario models to test variations such as:

* Shorter or longer opening hours.
* Different service models (for example table service versus counter service).
* Increased or decreased staffing levels per cover.
* Wage rate changes due to awards, inflation or negotiation.
* Shifts between permanent and casual staff mix.

In each scenario, adjust:

* Roster and staffing drivers.
* Hourly rates, salaries and loadings.
* On cost percentages.
* Links to sales and capacity assumptions.

Compare scenarios using:

* Labour cost as a percentage of sales by venue and group.
* Total labour cost and changes over time.
* Venue level EBITDA and margin after labour.
* Cashflow patterns including payroll timing.
  {% endstep %}

{% step %}

### Step 6: Build group level labour views

Use group level reporting and dashboards to:

* Compare labour cost percentages across venues and regions.
* Track labour cost versus sales for different segments and day parts.
* Identify venues that are over or under staffed relative to peers.
* Monitor the impact of wage changes and labour strategies at group level.

Drill from group or region level charts down to venue and role level views to support targeted interventions.
{% endstep %}
{% endstepper %}

***

### Check your work

* Roster based hours align with actual staffing patterns for sample venues.
* Labour cost outputs reconcile with historical payroll totals when using past data.
* Scenario changes produce realistic outcomes in both cost and staffing levels.
* The model reflects strategic choices rather than operational scheduling detail that is better handled in rostering systems.

***

### Troubleshooting

<details>

<summary><strong>Labour cost appears too low or too high compared to history</strong></summary>

Recheck hours per role, pay rates, on costs and loadings, and ensure that you are not double counting or missing roles.

</details>

<details>

<summary><strong>Rosters do not scale with sales changes</strong></summary>

Introduce volume based drivers that increase hours or staff numbers when sales rise and decrease them when sales fall within reasonable limits.

</details>

<details>

<summary><strong>Model becomes too complex with many individual roles</strong></summary>

Group similar roles into role families and use average rates and hours, keeping more detailed roles only where they matter to decisions.

</details>

***

### Related guides

* [Build an Annual Planning Pack](/how-tos/scenarios-and-planning/build-an-annual-planning-pack.md)
* [Build an Opex Planning Model](/how-tos/operations-and-unit-economics/build-an-opex-planning-model.md)
* [Operational Drivers](/help/drivers-variables-and-timing/operational-drivers.md)
* [Export Options](/syntax/chart-and-table-syntax/export-options.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/staff-rostering-and-labour-planning.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.