> 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/help/drivers-variables-and-timing/operational-drivers.md).

# Operational Drivers

This article focuses on operational drivers in Model Reef.

You will learn:

* What counts as an operational driver.
* How to express operations as time series.
* How to connect operational drivers to revenue, cost and staffing variables.
* Patterns for modelling funnels, capacity and utilisation.

Operational drivers describe the internal activity and capacity of the business rather than external economic conditions.

{% stepper %}
{% step %}

### What is an operational driver

Operational drivers typically include:

* **Volumes and units**
  * Units sold, orders, shipments, transactions, bookings.
* **Customer or user counts**
  * Active users, subscribers, logos, patients, visitors.
* **Headcount and hours**
  * Full time equivalents, shift hours, contractor hours, billable hours.
* **Pipeline and conversion metrics**
  * Leads, opportunities, quotes, win rates at each stage.
* **Capacity and utilisation**
  * Maximum throughput per plant, per store or per team.
  * Utilisation percentage or load factor.

These drivers translate operational assumptions into financial outputs through variables.
{% endstep %}

{% step %}

### Storing operational drivers in the Data Library

Examples of operational driver names:

* `Driver - Volume - Orders - Online`.
* `Driver - Active Users - Enterprise`.
* `Driver - Headcount - Engineers - Global`.
* `Driver - Pipeline - Qualified Leads`.
* `Driver - Utilisation - Support Team`.

When creating an operational driver, define:

* Name and description.
* Frequency (weekly, monthly, etc.).
* Units (for example units, customers, FTEs, hours, leads).
* Tags such as `Volume`, `Headcount`, `Pipeline`, `Capacity`.

These series become reusable building blocks for many variables.
{% endstep %}

{% step %}

### Linking operational drivers to revenue

Operational drivers often drive revenue through simple or layered formulas, for example:

* **Unit based**
  * `Revenue = Units * Price`.
  * Units are an operational driver, price may be an economic driver.
* **Customer based**
  * `Revenue = ActiveCustomers * ARPU`.
  * Both ActiveCustomers and ARPU are drivers.
* **Pipeline based**
  * `New Contracts = Leads * ConversionRate * AverageDealSize`.
  * Leads and conversion rates are operational drivers.

The variables that represent revenue reference these drivers in their formulas and take care of timing and accounting logic.
{% endstep %}

{% step %}

### Linking operational drivers to costs and staffing

Operational drivers also underpin:

* **COGS and variable costs**
  * `COGS = Units * UnitCost`.
  * `Delivery Cost = Orders * CostPerOrder`.
* **Staffing models**
  * `Required Headcount = Workload / HoursPerFTE`.
  * `Staff Cost = Headcount * Salary * OncostFactor`.
* **Capacity driven costs**
  * `Maintenance Cost = CapacityUnits * CostPerCapacityUnit`.
  * `Rent = Locations * RentPerLocation`.

This creates clear relationships between operations and financial outcomes.
{% endstep %}

{% step %}

### Modelling funnels and utilisation

You can use operational drivers to model funnels and utilisation:

* **Funnel stages**
  * Drivers: `Leads`, `Qualified Opportunities`, `Proposals`, `Closed Won`.
  * Drivers: `Conversion Rate - Stage A to B`, etc.
  * Variables: new revenue from each cohort.
* **Utilisation**
  * Drivers: `CapacityHours`, `BookedHours`.
  * Driver: `Utilisation = BookedHours / CapacityHours`.
  * Variables: revenue and staffing costs that depend on utilisation level.

Capturing these relationships makes the model more explainable for non finance stakeholders.
{% endstep %}

{% step %}

### Scenario work with operational drivers

Scenario examples:

* Base Case: planned headcount growth and stable conversion rates.
* Downside: slower pipeline growth and lower conversion, same staffing.
* Upside: higher conversion and better utilisation with moderate extra headcount.

Because operational drivers are scenario specific at model level, each scenario can express a different operating plan while reusing the same structure.
{% endstep %}
{% endstepper %}

### Good practice for operational drivers

Guidelines:

* Avoid mixing financial units and operational units in the same driver. Keep them separate.
* Use simple, descriptive units such as `customers`, `units`, `orders`, `hours`.
* Check that driver scales linearly make sense relative to capacity and constraints.
* Document key operational drivers so non finance users can understand and challenge them.

## Related articles

* [Multi-Client Profitability](/use-cases/media-agencies-and-creative-studios/multi-client-profitability.md)
* [Convert a PDF to a Structured Forecast](/how-tos/data-workflows-and-automation/convert-a-pdf-to-a-structured-forecast.md)
* [Naming (Drivers)](/help/building-your-model/naming-drivers.md)
* [Operational Driver Fields](/syntax/drivers-syntax/operational-driver-fields.md)