> 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/telecommunications-and-it-services/support-service-team-capacity.md).

# Support/Service Team Capacity

This use case explains how to model support and service team capacity, workload and cost for telecommunications and IT services businesses in Model Reef.

You will:

* Represent support and service functions by team, role and location.
* Build drivers for contact volumes, tickets and handling effort.
* Link workload to headcount, utilisation and service levels.
* Connect support economics to P\&L, Cashflow and customer strategies.

Model Reef is not a ticketing or contact centre platform. It uses aggregated workload and staffing assumptions, not per contact data.

## When to use this pattern

Use this pattern when:

* Support and service are major cost and experience drivers.
* You need to align headcount with subscriber and contract growth.
* You want to test service level and outsourcing strategies.
* You need to show how customer propositions affect support workload.

It ties directly into:

* Recurring Services Revenue Model
* Contract Renewal Forecasting
* Build a Staffing Cost Model

## Architecture overview

Support and service capacity modelling uses:

1. Structure
   * Branches for regions, channels or support functions.
   * Staff variables for roles and teams.
2. Workload drivers
   * Contacts or tickets per customer per period.
   * Average handling time per contact.
   * Mix of channels (phone, chat, email, self service).
3. Capacity and staffing
   * FTEs per role and location.
   * Working hours and schedule patterns.
   * Target utilisation and occupancy.
4. Financial outputs
   * Staff cost and overhead.
   * Cost per contact or per customer.
   * Impact on EBITDA and cash.

{% stepper %}
{% step %}

### Set up support and service branches

In the branch tree, create branches for your support structure, for example:

* Support and Service
  * Contact Centre - Country A
  * Contact Centre - Country B
  * Technical Support - Region Wide
  * Field Service Teams

Alternatively, if support is embedded within regions or product units, place support branches under each region or unit.
{% endstep %}

{% step %}

### Build workload drivers from subscribers and contracts

From your Recurring Services Revenue and Contract Renewal models, derive drivers such as:

* Subscribers or active contracts per segment.
* Contact Rate per customer per period (for example contacts per customer per month).
* Ticket Rate per active device or service for technical support.

Calculate total workload per period, for example:

* Contacts = Active Customers × Contact Rate.
* Tickets = Active Services × Ticket Rate.

If you use multiple channels, split contacts across channels using mix drivers such as:

* Share of contacts via phone, chat, email, self service.
  {% endstep %}

{% step %}

### Convert workload into effort and FTE requirements

Create drivers for handling effort, such as:

* Average Handling Time per contact in minutes by channel.
* After call work or wrap time allowances.
* Shrinkage factors for training, breaks and other non contact time.

Compute total effort, for example:

* Total Handling Minutes = Contacts × Average Handling Time.
* Required FTEs = Total Handling Minutes divided by (Working Minutes per FTE × Target Utilisation).

Use these calculations as driver variables to inform staffing decisions.
{% endstep %}

{% step %}

### Model staff headcount, cost and timing

Create Staff variables for each support role, for example:

* Staff - Contact Centre Advisors - Country A.
* Staff - Team Leaders - Country A.
* Staff - Technical Support Engineers.
* Staff - Field Technicians.

For each, specify:

* Headcount per period based on FTE requirements.
* Salary and on cost assumptions.
* Start dates for hires and any planned changes.
* Payment frequency and delay settings for cash timing.

Where you use outsourcers, represent them either as:

* Staff with different cost structures and flexibility, or
* Opex variables linked to volume and contracted unit rates.
  {% endstep %}

{% step %}

### Link service levels and self service to workload

Define drivers for:

* Target or actual service levels and first contact resolution.
* Proportion of queries handled by self service without agent involvement.
* Impact of product design or customer communication on contact rates.

Represent improvements in self service, product and process design as changes to:

* Contact Rate per customer.
* Channel mix toward lower cost channels.
* Average Handling Time.

Use scenarios to test investment in digital service and its payback in reduced contact volumes and staff cost.
{% endstep %}

{% step %}

### Use scenarios for sourcing, quality and service strategy

Clone the base model into scenario models to explore:

* Increasing or decreasing service levels.
* Shifting work between internal teams and outsourcers.
* Moving work to lower cost locations.
* Changing product or policy to reduce contacts.
* Upskilling teams to improve first contact resolution.

In each scenario, adjust:

* Workload, handling time and self service drivers.
* FTE requirements and sourcing assumptions.
* Pay rates and on costs.
* Target utilisation and service levels.

Compare scenarios using:

* Total support cost and cost per contact.
* Support cost per customer or per unit of revenue.
* Service level and workload metrics.
* Customer retention and NPS metrics where you choose to add them as external inputs or qualitative indicators.
  {% endstep %}
  {% endstepper %}

## Check your work

* Workload and contact rates reconcile with historical support reports.
* Staffing and cost assumptions align with HR and finance data.
* Scenario outputs are understandable for operations, finance and product teams.
* The model supports decision making on service strategy rather than trying to replicate operational systems.

## Troubleshooting

<details>

<summary>Required FTE numbers look too high or too low</summary>

Recheck handling time, shrinkage and utilisation assumptions and confirm that contact rates are on the correct basis (per active customer, per device, etc).

</details>

<details>

<summary>Support cost does not reconcile to P&#x26;L</summary>

Ensure that all support related costs (internal staff, outsourcers, tools) are mapped into the relevant Staff and Opex variables and categories.

</details>

<details>

<summary>Model is too granular for quick analysis</summary>

Aggregate roles, channels or regions where appropriate and use representative averages instead of detailed breakdowns when decisions do not require that level of detail.

</details>

## Related guides

* [Build a Rolling Forecast](/how-tos/scenarios-and-planning/build-a-rolling-forecast.md)
* [Build a Seasonality Adjusted Forecast](/how-tos/scenarios-and-planning/build-a-seasonality-adjusted-forecast.md)
* [Model Structure Principles](/help/building-your-model/model-structure-principles.md)
* [Creating Scenarios](/syntax/scenario-syntax/creating-scenarios.md)