# Level of service

> Turn service commitments into measurable targets - service areas, community and technical measures, auto-derived values, and the measurement history that shows whether you deliver.

Source: https://app.assetlab.ca/docs/infrastructure/level-of-service

Level of service (LoS) is the language of modern asset management plans: instead of "we maintain the roads", a commitment like "90% of priority routes cleared within 8 hours of snowfall end" - stated, targeted, and measured. AssetLab's LoS module keeps those commitments live rather than buried in a plan PDF.

## The model

### Service areas

A **service area** is a domain of service delivery: Winter Roads, Drinking Water, Parks Turf, Facility Comfort. Each can be linked to the [sites](/docs/asset-management/locations) and [system classes](/docs/asset-management/classifications) that deliver it, tying service performance back to the assets responsible. Those are the only two asset links - service areas don't attach to infrastructure networks or feature classes directly, so an infrastructure-flavored measure scopes through the system classes involved.

### Measures

Within a service area, **measures** are the specific metrics. Each measure carries:

- A **type**: **community** (what the public experiences - "% of watermain breaks restored within 24h") or **technical** (what the engineers watch - "% of network below PCI 40")
- A **category**: quality, reliability, responsiveness, safety, sustainability, cost efficiency, or capacity
- A **community statement** - the plain-language commitment as it reads in the plan
- A unit and a **direction**: higher is better, lower is better, or target-is-optimal (for measures where both too little and too much are misses)
- A **target**, plus a **minimum acceptable** floor and a **stretch goal**
- A **weight**, which sets how much the measure counts in its service area's roll-up

### Measurements

**Measurements** are the recorded values over time, on a monthly, quarterly, semi-annual, or annual period. Values arrive three ways:

- **Manual entry** - type the period's value in
- **Auto-derived** - a technical measure can declare a **data source** computed from your AssetLab data: average asset condition, FCI, % of assets at critical risk, work order response and completion times, backlog and overdue counts, PM compliance rate, deferred maintenance ratio, % past useful life, and more (community measures are always manual). Values recorded from a data source are flagged as auto-recorded and keep a snapshot of the numbers behind them, so an auto value is auditable later.
- **API** - push values from source systems via the [API](/docs/reference/rest-api)

Target changes are kept as history too, so "we raised the bar in 2025" stays visible in the trend.

## Reading LoS

The LoS page has three tabs:

- **Status** - system-level performance against **system LoS targets**, a separate targets layer set per system and derived from criticality, computed live from current asset data
- **Community** - the service areas and their measures against target, with a **heatmap** across areas and periods and a **gap analysis** showing where actuals sit relative to targets
- **Targets** (administrators only) - where the system-level targets are managed

A measure can also carry **consequences**: statements of what it means when the target is missed, each with a severity and the roles to notify - so a missed target is an event someone owns, not a quiet red cell.

This is board-report material by design: the annual asset management plan's LoS section becomes an export of what the system already tracks.

## LoS and money

The point of LoS in an asset management framework is the cost-of-service conversation. When council asks "what would it take to clear residential streets in 12 hours instead of 24?", the linkage from service area → system classes → [replacement planner](/docs/projects/replacement-planner) scenarios lets you answer with a number instead of a shrug - and, conversely, to show which measures degrade under a constrained budget.

## Starting small

1. Pick **one service area** with public visibility (winter roads is the classic).
2. Define 2-3 measures - one community, one or two technical. Give the technical ones a data source so their values maintain themselves.
3. Record a year of measurements before adding more areas. A small LoS program with real data beats a comprehensive one with empty tables.