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.
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 and system classes 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
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 scenarios lets you answer with a number instead of a shrug - and, conversely, to show which measures degrade under a constrained budget.
Starting small
- Pick one service area with public visibility (winter roads is the classic).
- Define 2-3 measures - one community, one or two technical. Give the technical ones a data source so their values maintain themselves.
- Record a year of measurements before adding more areas. A small LoS program with real data beats a comprehensive one with empty tables.