# Office/Team Profitability Modelling

This use case describes how to model profitability by office, practice or team in a professional services or consulting firm using Model Reef.

You will:

* Use branches to represent organisational units such as offices, practices or teams.
* Map revenue, staff and Opex into the right branches.
* Allocate shared or central costs.
* Produce P\&Ls and KPIs at both office or team level and firm level.

***

## When to use this pattern

Use this pattern when:

* You want to understand profitability at office, practice or team level.
* You need to allocate shared overheads such as head office costs to those units.
* You want decision makers to be accountable for local performance while seeing the impact of central costs.

This pattern assumes you have already set up rate card, utilisation and pipeline structures that determine revenue.

***

## Architecture overview

{% stepper %}
{% step %}

### Branch structure

* One branch per office, practice or team.
* One or more branches for central or overhead functions.
  {% endstep %}

{% step %}

### Direct revenue and costs

* Revenue, staff and direct Opex mapped to their owning branch.
* Expenses that clearly belong to a specific office or team kept local.
  {% endstep %}

{% step %}

### Shared cost allocation

* Central costs grouped in an overhead branch.
* Drivers used to allocate those costs back to offices or teams for a fully loaded view.
  {% endstep %}

{% step %}

### Reporting

* Office or team P\&L views.
* Consolidated firm view.
* Comparison dashboards across units.
  {% endstep %}
  {% endstepper %}

***

{% stepper %}
{% step %}

### Define the organisational units you want to track

Decide what you want to treat as a unit for profitability analysis, for example:

* Offices or geographies.
* Practices or service lines.
* Named teams or squads.

In many firms, a two dimensional view is helpful, such as offices by practice. For modelling purposes, choose one dimension as the primary branch structure and keep the other as a reporting attribute if needed.

In Model Reef, create a branch tree such as:

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

Or, for practice first:

* `Firm`.
  * `Practice - Strategy`.
  * `Practice - Technology`.
  * `Practice - Implementation`.
  * `Overheads`.
    {% endstep %}

{% step %}

### Map revenue to offices or teams

Ensure that Revenue variables are attached to the branch that actually delivers or owns the work, not just to a single firm level branch.

Depending on your modelling approach, you may:

* Create revenue variables per branch that link to billable hours and rates for that branch.
* Allocate a share of project or client level revenue to different branches based on delivery mix.

The objective is that each office or team branch has a realistic share of revenue that reflects their contribution.
{% endstep %}

{% step %}

### Map staff and direct costs to offices or teams

Next, ensure that:

* Staff variables (salaries, benefits, payroll tax) are assigned to the branch where people sit or where their costs are managed.
* Direct Opex such as local office rent, local travel, local marketing and team expenses are also placed in the relevant branch.

Patterns:

* `Staff - Consultant - London` in `Office - London`.
* `Opex - Office Rent - London` in `Office - London`.
* `Staff - Support Team - Firm` in `Overheads` if they serve the entire firm.

This separation of direct and central costs is critical for clear profitability analysis.
{% endstep %}

{% step %}

### Group central and shared costs

Create an `Overheads` or `Central` branch for costs that support the whole firm, such as:

* Executive leadership.
* Finance, HR and internal IT.
* Central marketing.
* Firm wide systems and licences.
* Office of the managing partner.

Model these as Staff and Opex variables in the `Overheads` branch.

Firm level P\&L at the root branch will include all branches, including Overheads, by default.
{% endstep %}

{% step %}

### Design allocation logic for shared costs

If you want to see fully loaded profitability per office or team, design allocation drivers for central costs, for example:

* Revenue share.
* Gross margin share.
* Headcount share.
* Some hybrid of the above.

In the Data Library, create drivers such as:

* `Allocation Key - Revenue Share - London`.
* `Allocation Key - Revenue Share - Manchester`.

These should sum to 100 percent across the target branches for each allocation scheme.

Then, in each office or team branch, create Opex variables such as:

* `Allocated Overheads - London`.
* `Allocated Overheads - Manchester`.

Define formulas that:

* Take total central costs from the `Overheads` branch.
* Multiply by the allocation key for each branch.

You can choose to leave central costs in the `Overheads` branch as well (for reconciliation) or show them only via allocations in profitability views, depending on communication needs.

For the mechanics of cross branch references, see **Build Cross Branch Drivers and Dependencies**.
{% endstep %}

{% step %}

### Build office or team P\&L views

Use reports and dashboards to provide:

* P\&L per office or team showing:
  * Revenue.
  * Direct staff and Opex.
  * Allocated overheads.
  * Operating contribution and fully loaded profit.
* Consolidated firm P\&L at the root branch.

You can add KPIs such as:

* Revenue per FTE.
* Contribution margin per office.
* Profit per partner or per manager.

Present pre allocation and post allocation views so that managers can see both raw and fully loaded performance.
{% endstep %}

{% step %}

### Use scenarios for structural changes

To test structural changes such as office openings, closures or team restructures:

* Clone the base model into scenario models representing different structures.
* Adjust branch structures, allocation drivers and staff assignments.
* Compare office and firm level profitability across scenarios.

This lets you evaluate the impact of:

* Consolidating small offices.
* Investing in new practices.
* Moving roles between locations.

Because scenarios are separate models, you can explore substantial changes without affecting the live plan.
{% endstep %}
{% endstepper %}

***

## Check your work

{% hint style="info" %}

* Revenue, staff and Opex are mapped to branches that match how the firm is actually run.
* Central costs in the `Overheads` branch are complete and not duplicated in local branches.
* Allocation drivers are clearly defined and documented so stakeholders understand how overheads are spread.
* Office or team P\&Ls reconcile to firm level P\&L.
  {% endhint %}

***

## Troubleshooting

<details>

<summary>Units complain about overhead allocations</summary>

Present both pre allocation and post allocation results and be transparent about the allocation rules and rationale.

</details>

<details>

<summary>Results jump when organisational changes occur</summary>

Carefully track branch structure changes and staff moves between branches, and annotate major changes in notes or tags.

</details>

<details>

<summary>Difficulty reconciling to ledger based reports</summary>

Ensure source data imports align with branch and category mapping, and that central versus local costs are categorised consistently in the ledger.

</details>

***

## Related guides

* [Build a Unit Economics Model](/how-tos/operations-and-unit-economics/build-a-unit-economics-model.md)
* [Build a Valuation Sensitivity Model](/how-tos/valuation/build-a-valuation-sensitivity-model.md)
* [CSV Import](/help/importing-and-data-inputs/csv-import.md)
* [Entering Seasonality](/syntax/how-input-fields-work/entering-seasonality.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/office-team-profitability-modelling.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.