Everything you Need All in one Platform
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.
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 consultationHow 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.
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.
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 IkhanaWhat the two metrics give your operation
-
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.
-
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
-
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.
-
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.
-
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.
-
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
What does the Performance and Risk Indicators Dashboard show in FireFlight?
+
What does Service Type Request show and why is it a risk indicator?
+
How does Technician Workload function as a risk indicator?
+
How does this dashboard connect to time tracking in FireFlight?
+
What actions does the Performance and Risk Indicators Dashboard support?
+
How does this dashboard relate to the Work Order Efficiency and Operations Dashboard?
+
How long does it take to deploy FireFlight performance and risk reporting?
+
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
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 LinkedInFireFlight 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.