Performance and Risk Indicators Dashboard | FireFlight
Last updated: April 2026

Performance and Risk Indicators Dashboard

Service Type Request distribution and Technician Workload two metrics that together signal whether demand patterns are shifting toward risk and whether individual capacity is balanced before either condition produces a service delivery failure.

FireFlight's Performance and Risk Indicators Dashboard shows two live metrics: Service Type Request volume broken down by request category, and Technician Workload showing how current assignments are distributed across the team. Both update in real time from time entry and work order records. Most operations are running live performance and risk indicators in weeks, not months.
FireFlight Performance and Risk Indicators Dashboard showing service type request distribution and technician workload balance

Two metrics sounds minimal. For the specific risks these two metrics address, two is exactly right. Service delivery risk in field operations concentrates in two places: the nature of demand shifting faster than the team can absorb it, and individual capacity reaching the point where quality and completion timelines become unsustainable. Both show up before they produce visible failures. Both require different management responses. A single combined dashboard that answers both questions in one view is not a compromise it is a tool calibrated to how operations managers actually make daily capacity and risk decisions.

Schedule your free consultation

How does a shift in service request type signal operational risk?

The distribution of service request types is one of the earliest leading indicators of a maintenance program deteriorating or an asset fleet aging past its reliable service life. When the proportion of planned maintenance requests is stable or growing, the operation is executing its preventive program and demand is predictable. When the proportion of emergency and unplanned repair requests begins increasing even while total request volume stays constant the operation is absorbing more reactive work, which is inherently less efficient, less predictable, and more disruptive to planned workloads than the preventive work it is displacing.

The risk in a shifting request type distribution is that it is gradual and invisible unless tracked. A team that handled 15% emergency requests in January and is handling 24% in April has experienced a significant shift in the character of its demand. That shift may indicate deferred PM work returning as failures, a specific asset class aging out of reliable service, or a change in how requests are being classified. Each explanation has a different response, but all of them require knowing that the shift has occurred and that knowledge comes from tracking the distribution over time rather than from looking at total request volume alone.

Capacity gap analysis view in FireFlight showing technician workload distribution and service request patterns

Technician Workload as a risk indicator addresses a different problem. The risk is not the total volume of work it is the distribution. An operations team where three technicians each carry 8-10 active assignments while two colleagues carry 18-22 is not running at excess capacity overall. It is running with a concentrated capacity problem that affects specific people, specific work types, and specific clients rather than the operation as a whole.

The management response to visible workload imbalance is simple: redistribute. The management response to invisible workload imbalance is nothing because nothing signals that a problem exists until a technician misses a deadline, submits work that does not meet quality standards under time pressure, or leaves for a less demanding role. All three outcomes are preventable if the imbalance is visible. The Technician Workload metric is what makes it visible in real time from time tracking data logged as work happens, rather than from a utilization report assembled after the week is over.

How do these two metrics function together as a risk management view?

The two metrics identify risk from complementary directions. Service Type Request looks at demand what the operation is being asked to do and whether that composition is shifting toward types of work that are more expensive, less predictable, and harder to staff for than the planned work they are displacing. Technician Workload looks at capacity whether the people responsible for meeting that demand are carrying loads that are sustainable and distributed equitably across the team.

The risk scenario that both metrics together can surface is one that neither alone would catch: an operation where total work volume appears normal but where emergency request proportion is rising and two specific technicians are absorbing most of that reactive work because they are the ones with the relevant skills. Total request volume looks fine. Technician average workload looks acceptable. But the request type shift is heading toward a structural imbalance and the two technicians carrying the reactive load are approaching the point where their individual sustainability becomes the constraint on the operation's ability to respond. Both signals are visible in this dashboard. Neither is visible in a total volume count.

Both metrics read from point-of-work time entries and live work order records. Service request categories are assigned when requests are created not estimated after the fact. Technician workload reflects actual open assignments as recorded in the work order system, not scheduled capacity that may or may not match real allocation. The dashboard shows the current state of both demand and capacity from the same data source that drives all other operational reporting in FireFlight.

PCG has been building performance and capacity management systems for field operations since 1995. The pattern of service type mix shifting toward reactive work before operations teams recognize the shift is one of the most consistent early warning signals in industrial, environmental, and service environments and it is consistently a signal that is only visible when the distribution is tracked rather than when total volumes are reported.

What actions does each metric support in day-to-day management?

Service Type Request supports demand-side decisions. When emergency request proportion is rising, the immediate response is to investigate which assets or service areas are generating the increase. The longer-term response may be adjusting the PM schedule, adding resources for reactive response capacity, or beginning an asset replacement analysis for the equipment class driving the failures. None of those responses can be initiated without the data showing that the shift has occurred and which service types are driving it.

Technician Workload supports capacity-side decisions. When the workload distribution is uneven, the immediate response is reassignment redistributing open work orders from over-assigned technicians to those with available capacity. The longer-term response may involve cross-training, hiring, or schedule restructuring if the imbalance is structural rather than situational. Both the immediate and the longer-term response require knowing which technicians are over-assigned and by how much information the metric provides from real work order data rather than from a calendar review that reflects scheduled rather than actual load.

Ikhana on-screen guide
Meet Ikhana

Your Personal Guide on Every Page

From the first click to the final step, Ikhana, your on-screen tutor, shows you how it all works. Every field, every button, every page explained with clarity, right where you need it.

On the Performance and Risk Indicators Dashboard, Ikhana explains what a healthy service type distribution looks like versus a distribution shifting toward risk, how to interpret technician workload relative to team average rather than in isolation, and when the two metrics together indicate a situation that warrants immediate management attention versus one that reflects normal variation.

Learn more about Ikhana

What the two metrics give your operation

  • FireFlight Service Type Request. The distribution of incoming service requests broken down by type category planned maintenance, corrective repair, emergency, inspection, installation, or any classification structure defined for the operation. The distribution view shows not just total volume but the composition of demand, making shifts toward higher-risk request types visible as they develop rather than after the ratio has changed enough to affect service delivery outcomes. Trends in this metric are the earliest available signal that the character of operational demand is changing.
  • FireFlight Technician Workload. Current active assignment volume per team member, showing how the total workload is distributed across the technical staff in real time. Over-assigned technicians and under-utilized colleagues are both visible simultaneously, making workload rebalancing decisions immediate rather than dependent on a scheduled capacity review. The metric reads from actual open work orders rather than from planned schedule capacity, so it reflects the real current state of individual load rather than what was allocated in theory at the start of the week.

What PCG learned across 31 years of operations management system builds: the performance risks that cost the most were rarely the ones that appeared suddenly. They were the ones that had been developing gradually a request type mix drifting toward reactive work, an individual technician accumulating an unsustainable load while the available metrics showed totals that looked normal because they were averages.

Distribution matters more than total volume for both of these metrics. A service team where 80% of emergency work goes to one technician is carrying more risk than its average workload suggests. A request portfolio where emergency volume has doubled as a proportion while total volume is flat is heading toward a different operational reality than its aggregate numbers indicate. These two metrics are designed to show the distribution, not just the total, because the distribution is where the risk actually lives.

What operations see after deployment

  • FireFlight Shifts in service demand type are caught while they are still early-stage trends rather than established patterns. A rising emergency request proportion identified in week three of a four-week period is a management conversation about what is changing. The same shift identified at the end of the quarter is a post-mortem about what already changed.
  • FireFlight Technician overload is visible before it produces missed commitments or turnover. Workload redistribution happens while the over-assignment is still a scheduling problem rather than after it has become a service quality or retention problem. The cost of a redistribution decision made on Tuesday is a few minutes of management time. The cost of the same decision made after a missed deadline or a resignation is considerably higher.
  • FireFlight Daily operational decisions about assignment and prioritization are based on current data. Managers who check the dashboard before the morning team deployment know which technicians have capacity, which are at their limit, and whether yesterday's request intake included an unusual proportion of emergency requests that will affect today's planned work schedule before anyone has been sent anywhere.
  • FireFlight Preventive maintenance investment decisions have supporting data. When the Service Type Request metric shows a sustained increase in reactive work, the case for increasing PM investment is grounded in the actual request distribution rather than in anecdotal observations about how the team feels busier with emergency work than it used to be. The data makes the conversation about PM program adequacy objective rather than subjective.

Questions operations managers ask before deploying FireFlight

FireFlight What does the Performance and Risk Indicators Dashboard show in FireFlight?
+
The dashboard shows two live metrics: Service Type Request volume broken down by request category, and Technician Workload showing how active work is distributed across the technical team. Together they identify where service demand is concentrated by type and whether the workload that demand generates is balanced or overloaded at the individual level. Both metrics update in real time from time entry and work order records.
FireFlight What does Service Type Request show and why is it a risk indicator?
+
Service Type Request shows the distribution of incoming requests by type. It becomes a risk indicator when the distribution shifts: a rising proportion of emergency and repair requests relative to planned maintenance requests signals that reactive work is increasing, which typically reflects deferred preventive maintenance catching up as failures or an asset class approaching end of reliable service life. Catching that shift in the distribution is earlier warning than waiting for equipment failure rates to confirm it.
FireFlight How does Technician Workload function as a risk indicator?
+
Technician Workload shows how current active assignments are distributed across the team. The risk appears when distribution is significantly uneven: a technician carrying two to three times the workload of colleagues is at risk of missed completions and quality issues under time pressure. The dashboard surfaces the imbalance before any of those outcomes has occurred while there is still time to redistribute assignments and protect both the work and the person doing it.
FireFlight How does this dashboard connect to time tracking in FireFlight?
+
Both metrics read from the same records that FireFlight's Time Tracking on Job app writes to. When a technician logs hours against a work order or task in the field, that entry contributes to the Technician Workload metric immediately. When a new service request is created and categorized, it contributes to the Service Type Request distribution. The dashboard reflects the current state of both demand and capacity from point-of-work data rather than from end-of-day estimates.
FireFlight What actions does the Performance and Risk Indicators Dashboard support?
+
Service Type Request supports demand analysis: understanding which request types are increasing and whether the mix is shifting toward more reactive work. This informs decisions about preventive maintenance investment, staffing specialization, and resource planning. Technician Workload supports capacity management: identifying which technicians are over-assigned and which have capacity, enabling real-time workload balancing before over-assignment produces missed commitments.
FireFlight How does this dashboard relate to the Work Order Efficiency and Operations Dashboard?
+
The Work Order Efficiency and Operations Dashboard provides ten metrics covering aging, closure rates, backlog trends, shop distribution, and asset-level service patterns. The Performance and Risk Indicators Dashboard provides two specifically calibrated to demand type and individual capacity. For operations managers who need a fast read on whether request patterns are shifting toward risk and whether any technician is at capacity, the two-metric view is the starting point. The Efficiency Dashboard provides the detail needed once either indicator raises a flag.
FireFlight How long does it take to deploy FireFlight performance and risk reporting?
+
Most operations are running live performance and risk dashboards in weeks, not months. Both metrics read from work order and time tracking records that the broader FireFlight deployment captures. Service request type categories are configured during deployment to match the operation's actual request classification structure. The dashboard populates from the first requests and time entries logged in the system.

If your current view of operational performance shows total request volume and average technician utilization, the two distributions that carry the most operational risk how demand is shifting by type and how load is concentrated at the individual level are not in the picture. FireFlight's Performance and Risk Indicators Dashboard puts both in view from live records. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert
Allison Woolbert
Principal, Phoenix Consultants Group  |  Developer, FireFlight Data Systems

PCG founded 1995. 500+ applications built across 31 years, roughly one-third in regulated environments where software failure carries direct operational and compliance consequences. FireFlight is the platform built from that body of work. When you contact PCG, Allison is the person who answers.

phxconsultants.com LinkedIn

FireFlight Data Systems is a product of Phoenix Consultants Group. PCG founded 1995. All system configurations are custom-built for each deployment. Implementation timelines, module availability, and integration scope vary by organization. Contact PCG directly to discuss requirements specific to your operation.

Performance and Risk Indicators Dashboard

 From hours to invoices, capture everything.
Track and allocate time and money with full auditability.