# Utilisation & Capacity Planning

This use case explains how to use Model Reef to plan utilisation and capacity for professional services and consulting businesses.

You will:

* Model headcount and roles across offices or teams.
* Convert FTE capacity into available and billable hours.
* Apply utilisation and realisation assumptions.
* Connect supply of billable hours to revenue, margins and hiring plans.

The aim is to move away from static spreadsheets and build a capacity engine that is directly tied into your three statement model.

***

## When to use this pattern

Use this pattern when:

* You run or advise a consulting, agency or professional services firm.
* Utilisation is a key driver of revenue and margin.
* You want to understand when to hire, and how many people you need, to support planned work.
* You need to see the impact of utilisation changes on P and L and cash.

It is often combined with:

* **Rate Card and Billable Hours Forecasting**
* **Project Pipeline and Revenue Scheduling**
* **Office or Team Profitability Modelling**

***

## Architecture overview

You will build four layers:

{% stepper %}
{% step %}

### Branch structure

* Branches for offices, teams or service lines.
* Optional group or holding branch.
  {% endstep %}

{% step %}

### Capacity drivers

* FTE by role.
* Available hours per FTE.
* Utilisation and realisation assumptions.
  {% endstep %}

{% step %}

### Revenue variables

* Billable hours by role.
* Revenue as billable hours times rate card.
  {% endstep %}

{% step %}

### Outputs

* Utilisation and capacity KPIs.
* Office or team P and L.
* Impact on margin and hiring needs.
  {% endstep %}
  {% endstepper %}

***

## Step 1: Design the branch structure for your firm

Start by deciding how you want to see performance:

* By office or city.
* By practice or service line.
* By team or squad.

In Model Reef, create a branch tree such as:

* `Firm` (root).
  * `Practice - Strategy`.
  * `Practice - Technology`.
  * `Practice - Implementation`.
  * `Overheads` (for central costs).

Or, for geographic focus:

* `Firm`.
  * `Office - London`.
  * `Office - Manchester`.
  * `Office - Remote`.
  * `Overheads`.

This branch structure will drive how you see utilisation and profitability.

***

## Capacity & utilisation build steps

{% stepper %}
{% step %}

### Define headcount and capacity drivers

In the Data Library, create drivers for headcount and capacity, for example:

* `FTE - Consultant - London`.
* `FTE - Senior Consultant - London`.
* `FTE - Partner - Firm`.
* `Available Hours per FTE per Year` or per period.

You can choose to work in:

* Hours per week and number of weeks per year, or
* Hours per month or quarter directly.

For example:

* `Available Hours per FTE per Week = 40`.
* `Working Weeks per Year = 46`.
* `Available Annual Hours = 40 × 46`.

You may prefer to work with capacity modules per branch, storing all the assumptions for that branch in a small group of drivers.
{% endstep %}

{% step %}

### Add utilisation and realisation assumptions

Define the following drivers per role or per branch:

* Target utilisation percentage (share of available hours that are billable).
* Realisation percentage (share of billable hours that can actually be billed at full rate, after write offs and discounts).

Examples:

* `Utilisation - Consultant - London = 75 percent`.
* `Utilisation - Senior Consultant - London = 80 percent`.
* `Realisation - Firm = 95 percent`.

Store these as Modifier type drivers in the Data Library so they can be reused in formulas and easily updated.
{% endstep %}

{% step %}

### Convert capacity into billable hours and revenue

In each office or practice branch, create variables to compute:

* Available hours per role.
* Billable hours per role.
* Billable hours after realisation.

For example:

* `Available Hours - Consultant - London = FTE - Consultant - London × Available Hours per FTE`.
* `Billable Hours - Consultant - London = Available Hours - Consultant - London × Utilisation - Consultant - London`.
* `Billable Hours Realised - Consultant - London = Billable Hours × Realisation`.

Then link to rate card drivers (described in more detail in **Rate Card and Billable Hours Forecasting**), for example:

* `Revenue - Consultant - London = Billable Hours Realised × Rate - Consultant - London`.

Set these revenue variables as type **Revenue** so they flow into P and L and cash correctly.
{% endstep %}

{% step %}

### Compare capacity to demand

If you implement **Project Pipeline and Revenue Scheduling**, you will have a view of demand for billable hours over time.

You can then compare:

* Supply of billable hours (from this utilisation and capacity structure).
* Demand for billable hours (from pipeline and project schedules).

Use charts or custom reports to show:

* Excess capacity or shortfalls per office or role over time.
* Expected utilisation compared to target.

This helps answer questions such as:

* When do we need to hire more people in a team or location.
* Where are we likely to be overstaffed if pipeline slows.
  {% endstep %}

{% step %}

### Connect to staff cost and P and L

Make sure Staff variables exist for all roles in each branch, representing:

* Salaries or day rates for employees and contractors.
* Oncosts such as pensions and payroll tax.

Then check that:

* Revenue variables from billable hours and rate card are in the same branch as staff costs.
* Office or practice P and L shows revenue minus staff and Opex clearly.

This gives you a utilisation driven margin view at office or practice level.
{% endstep %}

{% step %}

### Build utilisation and capacity dashboards

Create a dashboard focused on utilisation and capacity that shows:

* FTE counts per role and branch.
* Available hours, billable hours and realised billable hours over time.
* Utilisation percentages per role and per office.
* Revenue per FTE and gross margin per FTE.

These views give partners and managers a clear line of sight from staffing to revenue and margin.
{% endstep %}
{% endstepper %}

***

## Check your work

{% hint style="info" %}

* FTE and hours assumptions are realistic and grounded in actual contracts and work patterns.
* Utilisation and realisation percentages are plausible given historical performance.
* Revenue per role and branch aligns with what you would expect from the rate card.
* Office or practice P and Ls reconcile to the consolidated firm view.
  {% endhint %}

***

## Troubleshooting

{% hint style="warning" %}
Utilisation looks too high across the board — Check that you have not confused billable hours with available hours, and that holidays and non-billable time are correctly reflected in the capacity assumptions.
{% endhint %}

{% hint style="warning" %}
Revenue jumps or dips unexpectedly — Look for step changes in FTE drivers or utilisation assumptions, and align them with known hiring or restructuring events.
{% endhint %}

{% hint style="info" %}
Too many roles make the model hard to manage — Group similar roles into bands for planning (for example junior, mid, senior) and track very granular titles only in HR systems.
{% endhint %}

***

## Related guides

* [Build an Opex Planning Model](/how-tos/operations-and-unit-economics/build-an-opex-planning-model.md)
* [Scenarios & Planning](/how-tos/scenarios-and-planning.md)
* [COGS Variables: what is, rules, what it affects](/help/drivers-variables-and-timing/cogs-variables.md)
* [Entering Accruals & Delays](/syntax/how-input-fields-work/entering-accruals-and-delays.md)


---

# Agent Instructions: 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:

```
GET https://help.modelreef.io/use-cases/professional-services-and-consulting/utilisation-and-capacity-planning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.