A Large-Site Operations Dashboard: 20 KPIs Without Vanity Metrics

Start from decisions, not from available data

The most common failure is assembling whatever is easy to export: total work orders, headcount, square metres, camera counts. The result is a showcase rather than a control tool. Operations guidance repeatedly stresses the same discipline: name the decisions the dashboard must support, then separate must-have metrics from nice-to-have ones. A screen that tries to serve executives, analysts and frontline teams equally usually serves none of them well.

So before picking numbers, write down the questions people must answer daily: what to do when an asset becomes unavailable, when the work-order queue ages past a limit, when a public zone is overloaded or when energy use jumps without a change in occupancy. Each question needs an owner, a deadline and an action. Only then does a metric acquire meaning: it shows whether that decision is being executed, rather than reporting an interesting trend.

It also helps to separate activity metrics (how many orders were closed) from outcome metrics (whether repeat complaints, downtime and cost actually fell). A number that drives nothing today — total site visits with no link to cleaning or safety — is a vanity metric and stays off the main screen.

• List five to eight operational decisions before opening the dashboard editor.
• Attach an owner, deadline and trigger action to each decision.
• Ask whether the number would change at least one decision made today.

Twenty KPIs across five decision themes

The set below is balanced so that one dimension of performance does not crowd out the rest. Theme one is engineering and asset reliability: preventive maintenance (PM) completed on time; the reactive share of maintenance work; critical-asset downtime in hours per month; and the repeat-fault rate within thirty days.

Theme two is work orders and service delivery: SLA attainment, or the share of work inside agreed response and completion windows; open backlog volume and its aging by priority; first-time resolution rate; and emergency response time for the critical class of requests. Theme three is spatial utilisation on a map: zone utilisation or occupancy rate; peak-to-planned capacity per zone; cleaning and service adherence by zone; and complaint density per thousand square metres by zone.

Theme four covers energy and environment: energy-use intensity in kilowatt-hours per square metre normalised for climate and occupancy; water consumption trend; utility cost per square metre; and the share of waste diverted to recycling. Theme five brings together cost, compliance, people and experience: FM and maintenance cost per square metre; completion of statutory inspections; the closure rate for safety near-misses and hazards; and occupant or tenant satisfaction tied to repeat complaints.

The list is a starting point, not a straightjacket. A business park, a campus, a hospital and a logistics site will weight the themes differently, but the discipline — owner, source, target, cadence, action — stays the same.

• Engineering: on-time PM, reactive share, critical downtime, repeat faults.
• Service: SLA attainment, backlog aging, first-time resolution, emergency response.
• Space (GIS): zone utilisation, peak-to-capacity, cleaning adherence, complaint density.
• Energy: EUI, water, utility cost per m², recycling rate.
• Cost and experience: FM cost per m², statutory checks, safety closure, satisfaction.

The KPI card: what turns a number into an action

A metric becomes a vanity metric precisely when its card is incomplete. Every KPI needs a documented card: the business question it answers; a precise definition and formula; the source system that owns the data; the accountable owner; a target; a refresh cadence; the action taken on breach; and an escalation path. If any field is empty, either complete it or drop the metric from the main view.

Take preventive maintenance compliance. The percentage means little unless it is split by asset criticality and by reason for lateness — access, parts, staffing, vendor, emergency work. A high score can hide weak maintenance if technicians close orders without readings, findings, photos or corrective actions. Similarly, complaint density per zone is only useful when each spatial cluster has a named owner and a deadline for root-cause action.

The card also disciplines the data. If numbers come from manual spreadsheets with no quality control, reporting loses trust. Use the maintenance management system, building automation, finance records and the GIS layer as systems of record, and standardise definitions so that services cannot argue about what a metric means.

• Definition and formula with no vague terms such as “timely service”.
• Source system and the person accountable for data quality.
• Target with warning and critical thresholds.
• Breach action and escalation path.
• Refresh cadence matched to decision value.

The GIS layer and zone-level aggregation

On a large site the portfolio average is close to useless: it hides where complaints, downtime and overload actually accumulate. Metrics should therefore aggregate to zones, districts or buildings, and the dashboard should behave like an interactive map with drill-down. Urban planning platforms now let you define metrics at different resolutions — a space, a building, a parcel, or the whole study area — and choose how values roll up.

The key rule is that ratios must not be summed across the territory. Summing floor-area ratios, utilisation rates or complaint densities across zones produces incorrect results, so these are computed at the chosen level and displayed as a map rather than as one number. The spatial layer connects work orders, cleaning schedules and sensor data so that a problem cluster is visible at once.

Municipal digital practices follow the same logic: life-cycle indicators of a territory are shown on interactive maps and dashboards, letting operators compare districts and act on a specific zone instead of reacting to a city-wide average.

Cadence, thresholds and the exception view

Refresh frequency should follow decision value, not fashion. Safety events and emergency signals demand immediate reaction; queues, staffing coverage and dispatch benefit from fifteen-minute to hourly updates; cost and energy trends are better read daily or weekly. Defaulting everything to real time adds noise and hides what matters.

Balance leading and lagging indicators. A growing backlog, falling shift coverage and a rising share of reactive work are early warnings, while missed SLAs and downtime are outcomes. A dashboard that shows only lagging numbers becomes a scoreboard rather than a management tool.

Colour rules should be strict and consistent: green in range, amber warning, red immediate action. Red is not decoration. Add an exception view that lists breached thresholds and overdue tasks with owners, so the daily stand-up begins with what needs attention now.

Honest limits: gaming, data quality and benchmarks

Every metric can be gamed. Teams close and reopen orders, exclude paused time, or prioritise easy tickets to flatter averages. So beside response and completion time you track reopen rate, first-time resolution and backlog aging. A rise in near-miss reporting under a healthy safety culture indicates better visibility and stronger reporting, not worse performance.

Benchmarks need context. A premium airport, hospital, school and warehouse do not share operating models or risk profiles. Set targets from your own clean baseline, and treat published numbers as directional guidance. Energy-use intensity is only comparable when normalised for climate, operating hours and occupancy; comparing raw kilowatt-hours per square metre without adjustment misleads.

Finally, review the dashboard architecture itself. If a widget has not changed a single decision in two reporting cycles, remove it. A regular audit is the only way to keep the screen compact and honest.

A staged rollout that protects trust

Pilot the dashboard with one service or one zone and a deliberately small set of metrics before scaling to the whole site. Agree on update rules, and train dispatchers and supervisors on what to do when a threshold fires. Once the team is comfortable with the exception view, add more indicators.

Document every metric, then review monthly which widgets are actually used, which create confusion and which never influenced an action. That review is what separates a working dashboard from a display: it shortens the time between signal and response and makes accountability across services visible and auditable.