Types and Mix Dashboard | FireFlight

Last updated: April 2026

Types and Mix Dashboard

Tasks by step type, hours by step type, and meeting hours three metrics that show how the team's time is actually distributed across categories of work, logged in real time as the work happens.

FireFlight's Types and Mix Dashboard shows three time-tracking metrics segmented by step type: how many tasks fall into each category, how many hours each category is consuming, and how much of the team's logged time is going into meetings. All three update in real time from time entries logged directly to jobs, work orders, and tasks using start/stop timers or quick entry. Most operations are running live time mix reporting in weeks, not months.

FireFlight Types and Mix Dashboard showing time distribution by step type across tasks, hours, and meeting activity

Most operations that track time know how many hours were logged in total. Far fewer know how those hours were distributed across types of work what proportion went to direct field activity, what proportion to administrative tasks, and what proportion to meetings. Without that breakdown, a labor cost that is running over budget has no obvious explanation. With it, the explanation is visible in the step type distribution before the overrun reaches accounting. The Types and Mix Dashboard provides that breakdown continuously, from the hours your team is logging right now, without requiring a separate analysis to see it.

Schedule your free consultation

What does the work type mix actually tell operations and finance teams?

The work type mix reveals the structure of how time is being spent, not just the volume. A team that logs 400 hours in a week and spends 60% of those hours in direct field work, 25% in planning and administrative tasks, and 15% in meetings has a specific cost profile. A team logging the same 400 hours but spending 35% in direct field work, 30% in administrative tasks, and 35% in meetings has a different cost profile and probably a different delivery capacity even though the total hours are identical.

The mix matters for billing accuracy, for project cost allocation, and for understanding whether the operation is delivering work at the rate the project budget assumed. A project estimated based on 70% direct field hours and running at 50% direct field hours will finish over budget even if nobody worked an unauthorized overtime hour. The Types and Mix Dashboard shows that discrepancy as it develops in real time, when there are still decisions to be made about how the remaining work is allocated.

Why does tracking Meeting Hours as a separate metric change how teams manage their time?

Meeting time is consistently one of the largest categories of non-direct-work hours in service operations, and it is consistently the category that gets the least scrutiny because it is distributed across many individual calendar entries rather than appearing as a single visible cost center. A team member who spent 12 hours in meetings last week did not log those hours as "12 hours not doing fieldwork." They logged them as individual meetings, each of which seemed reasonable in isolation.

The Meeting Hours metric on this dashboard aggregates those individual entries into the total that actually reflects the cost. For operations managers reviewing the week's time distribution, seeing that 18% of all logged hours went to meetings provides a very different kind of information than reviewing each team member's calendar. It also provides a trend if Meeting Hours as a proportion of total logged hours has been increasing over the past six weeks, that trend is visible in the dashboard rather than invisible in individual schedules. The change that trend warrants is a management conversation that the data makes possible and that the absence of aggregation makes nearly impossible to initiate.

Time entries in FireFlight are logged at the point of work, not reconstructed at the end of the day. Start/stop timers capture exact durations as team members move between tasks. Quick-entry logs let team members record time against a specific job, work order, or task in seconds. The step type classification is applied at entry, so every hour logged carries both its attribution and its type classification from the moment it is recorded.

The consequence for the Types and Mix Dashboard is that the distribution it shows reflects what actually happened, not what someone remembered happening when they filled out a timesheet at 5pm. PCG has built time tracking and labor management systems for field operations since 1995, and the gap between end-of-day recalled time and actual time-at-task is consistently the largest source of labor data inaccuracy in operations that do not use point-of-work logging.

How does the task count by step type add to what hours alone show?

Hours by step type tells you where time is going. Tasks by step type tells you how that time is structured. A step type that represents 20% of total hours but 40% of total tasks contains many short tasks high-frequency, low-duration work. A step type that represents 30% of total hours but only 8% of total tasks contains fewer but substantially longer tasks low-frequency, high-duration work.

That structural difference matters for scheduling, for staffing, and for estimating future projects of similar type. An operation planning a new engagement that will require significant high-frequency short-task work needs to staff and schedule differently than one planning a project dominated by a smaller number of long-duration tasks even if the total hours look similar in the estimate. The Tasks by Step Type metric provides the structural context that hours alone cannot, and it is available from the same dashboard view as the hours data rather than requiring a separate task-level query to find it.

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 Types and Mix Dashboard, Ikhana explains what step types are and how they are assigned, why Tasks and Hours show different distributions for the same work, and how to interpret a meeting hours proportion relative to total logged time. Team members learn to log time with correct step type classification on day one rather than creating uncategorized entries that the dashboard cannot segment.

Learn more about Ikhana

What the three metrics give your team

Tasks by Step Type. The count of tasks in each defined step type category for the selected period. Shows the structural composition of the work mix how many tasks of each type the team is carrying separate from how long those tasks take. High task counts in specific categories identify where task volume is concentrated, which informs scheduling decisions about how many task transitions the team is managing in a given period.
Hours by Step Type. The total hours logged against each step type category for the selected period. Shows where the team's actual time is going across work categories. When the hours distribution shifts away from the types that generate direct value field work, direct service delivery, productive output toward administrative and overhead types, the shift is visible in this metric before it shows up in project cost overruns or delivery delays.
Meeting Hours. The total hours logged against meeting-type entries for the selected period, tracked separately from other step types. Provides the aggregate view of coordination and overhead time that individual calendar entries do not produce. When meeting hours as a proportion of total logged hours is increasing over time, the trend is visible in this metric as a management signal rather than remaining invisible in distributed calendar data.

What PCG learned across 31 years of labor tracking system builds: the operations that managed labor costs accurately were not the ones with the strictest time logging policies. They were the ones where logging time was faster and easier than not logging it, and where the classification system matched the way the team actually thought about their work rather than requiring translation at the point of entry.

Step types that reflect real work categories produce real data. Step types designed by someone who does not do the work tend to produce "other" entries that the dashboard cannot segment. The configuration conversation at deployment is the most important technical decision in a time tracking implementation and it is the one PCG spends the most time on, because the quality of the dashboard depends entirely on the quality of the classification that feeds it.

What operations see after deployment

Labor cost distribution is visible before it becomes a budget problem. When hours are shifting toward lower-value step types, the distribution in the dashboard shows it during the period rather than at month-end when the project cost report arrives and the cause is no longer recent enough to investigate accurately.
Meeting time becomes a managed variable rather than an invisible overhead. When meeting hours are visible as a proportion of total logged time, the decision to add another standing meeting has a quantified cost that was previously missing from the conversation. The metric does not eliminate meetings it makes their time cost visible alongside the direct work time it displaces.
Project estimates for similar future work become more accurate. When historical step type distributions are available from completed projects, the estimate for a new project of the same type is grounded in actual data about how time was spent not just total hours, but which categories of work consumed which proportions of those hours.
Time logging accuracy improves when team members see the data their entries produce. When the dashboard reflects their actual work in recognizable categories, team members understand what they are logging to and why. The motivation to log accurately increases when the data visibly represents real work rather than appearing as an administrative requirement with no visible output.

Questions operations and finance teams ask before deploying FireFlight time tracking

What does the Types and Mix Dashboard show in FireFlight?

The dashboard shows three time-tracking metrics segmented by step type: Tasks by Step Type, Hours by Step Type, and Meeting Hours. Together they show how the team's time is distributed across different categories of work how many tasks fall into each type, how many hours each type is consuming, and how much of the total logged time is going into meetings rather than direct work activity.

What is a step type in FireFlight time tracking?

A step type is a category assigned to a task or time log entry that describes the nature of the work being performed inspection, installation, diagnostic, administrative, travel, training, or any category structure defined for the operation. Step types are the classification system that lets the Hours by Step Type metric show not just total hours logged but which kinds of work those hours represent.

Why does tracking Meeting Hours separately matter for operations?

Meeting time is a significant and often underappreciated portion of a team's logged hours. When meeting hours are embedded in a general administrative or overhead category, the actual proportion of the team's available time consumed by meetings is invisible. Tracking Meeting Hours separately makes that proportion visible which is the first step toward deciding whether it is appropriate relative to the direct work the operation is supposed to be delivering.

How does Tasks by Step Type differ from Hours by Step Type?

Tasks by Step Type shows the count of tasks in each category how many inspection tasks, how many installation tasks, how many administrative tasks exist in the current period. Hours by Step Type shows the time actually consumed by each category. A step type with a high task count but low hours contains many short tasks. A step type with a low task count but high hours contains fewer but longer tasks. The two metrics together reveal the time cost structure of the work mix in a way that either metric alone cannot.

How does this dashboard connect to job-based time tracking in FireFlight?

FireFlight's time tracking logs hours directly against the job, work order, asset, or task that generated them using start/stop timers or manual quick-entry. The step type classification is applied at the point of entry, so every hour logged carries both its job attribution and its step type from the moment it is recorded. The Types and Mix Dashboard aggregates those classifications in real time, so the distribution of hours by type reflects exactly what has been logged, not what was planned.

What does a changing work type mix signal about an operation?

A work mix that shifts toward a higher proportion of administrative or meeting hours over direct work hours signals that operational capacity is being consumed by coordination and overhead at the expense of delivery. A mix that shifts toward a higher proportion of reactive or emergency step types over planned work types signals that the operation is increasingly running on response rather than on schedule. Both shifts are visible in the Hours by Step Type metric before they show up in delivery performance or cost overruns.

How long does it take to deploy FireFlight time tracking with step type classification?

Most operations are running live time tracking with step type reporting in weeks, not months. The step type structure is configured during deployment to match the operation's actual work categories. PCG handles configuration. Teams begin logging time immediately after training, and the Types and Mix Dashboard reflects actual data from the first hours logged.

If your operation tracks total hours but not what kind of work those hours represent, labor cost overruns have no explanation until after they have already happened. FireFlight's Types and Mix Dashboard shows the distribution of time across step types in real time, from hours logged as the work occurs. Configuration takes weeks, not months, and PCG handles the step type structure that makes the data meaningful.

Schedule your free consultation

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.

Types & Mix Dashboard

Start/stop timers or quick-entry time logs.
Track time by job, user, task, or work order

By Person Dashboard | FireFlight

Last updated: April 2026

By Person Dashboard

Hours logged per person, tasks completed per person, and the top five heaviest workloads on the team three individual-level metrics that make capacity distribution visible in real time rather than estimable at end of week.

FireFlight's By Person Dashboard shows three individual-level productivity metrics: Hours by Person from point-of-work time entries, Tasks Completed by Person from live task records, and Top 5 Workloads identifying the team members carrying the most at this moment. All three update continuously. Most operations are running live individual productivity dashboards in weeks, not months.

FireFlight By Person Dashboard showing hours logged, tasks completed, and workload distribution by individual team member

Managing a team without individual-level visibility is managing by aggregate. The aggregate tells you the team logged 340 hours and completed 87 tasks this week. It does not tell you that two people accounted for 180 of those hours and 61 of those completions while three colleagues are significantly under their capacity. That distribution is the information that drives the management decision and the By Person Dashboard makes it visible continuously from the same time tracking and task records that drive every other operational dashboard in FireFlight.

Schedule your free consultation

What does individual-level visibility actually change about team management?

Team-level metrics answer whether the operation is on track. Individual-level metrics answer who is carrying it there and whether that distribution is sustainable. A maintenance team that is hitting its weekly completion targets because two of its six technicians are consistently running at 140% of their normal load is not managing well. It is storing up a retention problem, a quality risk, and a single-point-of-failure dependency that will surface when either of those two technicians is unavailable or decides to leave.

The By Person Dashboard makes that pattern visible before it produces those consequences. An operations manager who checks Hours by Person midweek and sees that two specific team members are already at 85% of their weekly hour target while others are at 40-50% has the information and the time to rebalance assignments for the second half of the week. That rebalancing takes minutes when it is done proactively. It takes considerably more when it is done reactively after a deadline is missed or a team member reaches a breaking point.

Individual productivity view in FireFlight showing per-person task completion and hours data for team capacity management

Tasks Completed by Person adds the output dimension to the input picture that hours alone provide. Two team members logging the same number of hours with significantly different task completion counts are either working on tasks of different complexity and duration which is expected and appropriate or experiencing different workflow conditions that affect their ability to close work. The comparison prompts the question rather than answering it, which is the right function for a dashboard metric. The manager who sees the difference investigates. The manager who never sees the difference does not know to ask.

Top 5 Workloads is the metric designed for the 60 seconds before the day's work assignments are confirmed. The five team members currently carrying the most combined load are the ones most likely to be at or near capacity for taking on additional work. When an urgent request comes in and someone needs to be assigned, the Top 5 list is the first check: not who is available on paper, but who is actually carrying the most right now. That distinction is where the difference between good and poor daily capacity decisions is made.

How does this dashboard use Custom Reporting to go beyond standard views?

The three metrics on the By Person Dashboard provide live individual-level views from time tracking and task records. For operations that need formatted periodic reports at the individual level monthly productivity summaries for project billing, performance documentation for client deliverables, or compliance records showing hours worked by team member against specific work orders FireFlight's Custom Reporting capability converts that live data into professionally structured documents built to each operation's specific format requirements.

Custom Reporting in FireFlight is managed rather than self-service. Operations that need a polished PDF showing each technician's hours against work orders by project for the month, or a formatted summary of task completions by person for a specific client engagement, describe the output they need and PCG produces the report template. The dashboard provides the live operational view. Custom Reporting provides the formatted deliverable. Both read from the same underlying records without requiring parallel data management or manual aggregation.

Individual metrics are sourced from point-of-work time entries, not from scheduled capacity or end-of-day estimates. Hours by Person reflects hours that have been logged against actual work as it happened. Tasks Completed by Person reflects tasks that have been closed in the system, not tasks that someone expects to close by end of day. The dashboard shows the individual-level picture as it currently exists in the records rather than as it is projected to exist when the week closes.

PCG has been building individual productivity and capacity management systems for service operations since 1995. The pattern of team-level metrics masking individual-level imbalances and those imbalances only becoming visible after they have produced a retention or delivery problem is consistent across industrial, field service, and professional services environments. The By Person Dashboard is built specifically to surface the individual picture that team aggregates obscure.

How does this dashboard relate to the other time tracking dashboards in FireFlight?

The By Person Dashboard is the individual-level view in a suite of time tracking and operations dashboards that each answer a different question at a different level of granularity. The Volume and Status Dashboard shows current work order counts the operational total. The Trends Dashboard shows daily task completion rates over time the operational trajectory. The Types and Mix Dashboard shows how time is distributed across step type categories the operational composition. By Person shows how all of that distributes at the individual level who is carrying what.

For an operations manager who finds that a team-level metric is not where it should be, the By Person Dashboard is frequently the next view. The Trends Dashboard showing declining daily task completion rates prompts the question of whether the decline is distributed across the team or concentrated in specific individuals. By Person answers that question. The Types and Mix Dashboard showing a rising proportion of meeting hours prompts the question of whether that rise is uniform or whether specific team members are disproportionately in meetings. By Person answers that too. It is the individual-level diagnostic that gives team-level pattern observations an actionable direction.

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 By Person Dashboard, Ikhana explains how hours and task completions are attributed to individuals, what the Top 5 Workloads metric is measuring and how it should inform assignment decisions, and how to use filters to isolate a specific team member or project period for a focused view. Operations managers and team leads interpret the individual metrics correctly from day one.

Learn more about Ikhana

What the three metrics give your team

Hours by Person. Total hours logged per team member for the selected period, sourced from point-of-work time entries rather than from scheduled capacity or end-of-day summaries. Shows the actual time investment each team member has made against real recorded work. Used for capacity management, project billing accuracy, and identifying individual workload distribution before imbalances accumulate to the point where they affect delivery or retention.
Tasks Completed by Person. Individual task completion count for the selected period. Shows the output each team member is producing alongside the hours they are investing. The relationship between hours and completions per person reveals whether time is being converted to finished work at an expected rate and where the relationship looks unusual, it prompts the management investigation that uncovers whether the cause is task complexity, scope variation, workflow friction, or something else entirely.
Top 5 Workloads. The five team members currently carrying the heaviest combined load. Updated in real time as hours are logged and tasks accumulate. Used at the start of each day to check whether any of the team's most-loaded members is approaching a capacity threshold before new assignments are made. Also the first check when an urgent request requires same-day assignment and the decision of who can absorb it without disrupting existing commitments needs to be made in seconds rather than after a schedule review.

What PCG learned across 31 years of team capacity management system builds: the operations that maintained team health alongside delivery performance were not the ones with the most detailed individual tracking. They were the ones where workload imbalance was visible before it had been sustained long enough to produce burnout, attrition, or quality decline.

Individual visibility done well is a care tool, not a surveillance tool. When a manager sees that a specific team member is consistently in the Top 5 Workloads week after week, the appropriate response is a conversation about capacity and support not a performance expectation that the pattern continues. The data surfaces the situation. What happens next is a management judgment that the data makes possible.

What operations see after deployment

Workload imbalances are caught mid-week rather than at end-of-week when nothing can be changed. A Wednesday check of Hours by Person and Top 5 Workloads gives operations managers the information and the time to rebalance assignments before the overloaded team members have finished the week at a pace that is not sustainable and the under-utilized team members have finished the week without contributing to their capacity.
Urgent assignment decisions are made with current data. When a high-priority request arrives and someone needs to be assigned, Top 5 Workloads shows who is already most loaded and who has capacity to absorb the additional work without disrupting their existing commitments. The assignment decision is based on actual current load rather than on a guess about who seems less busy.
Individual contribution to team totals is visible and attributable. Project billing, performance documentation, and client reporting that requires hours or task completions by team member are available directly from the dashboard data rather than from timesheet reconstructions or manually assembled summaries. Custom Reporting converts the live data into the formatted deliverable each use case requires.
Team-level metrics have individual-level explanations when they need them. When a daily trend, a volume count, or a type mix metric looks unusual at the team level, By Person is the next view that tells the operations manager whether the pattern is distributed or concentrated. That direction makes the management response specific and proportionate rather than broad and imprecise.

Questions operations managers ask before deploying FireFlight

What does the By Person Dashboard show in FireFlight?

The dashboard shows three individual-level metrics: Hours by Person showing total logged hours per team member for the selected period, Tasks Completed by Person showing individual task completion counts, and Top 5 Workloads identifying the five team members carrying the heaviest combined load. All three update in real time from time tracking and task records.

How does Hours by Person differ from a standard timesheet report?

A timesheet report shows hours logged what each person recorded. Hours by Person in FireFlight shows hours logged from point-of-work time entries captured as work happens rather than at end of day. For operations managers who need to know whether a specific team member is approaching their weekly capacity threshold before the week ends, the real-time view is what makes that question answerable on Wednesday rather than on Friday.

What does the Top 5 Workloads metric show and how is it used?

Top 5 Workloads identifies the five team members currently carrying the heaviest combined load. This metric is designed for daily capacity management: an operations manager who checks Top 5 Workloads at the start of the day can see immediately whether any of the heaviest-loaded team members is approaching a limit that warrants reassignment before the day's dispatch decisions are made. It also identifies which team members have the most capacity to absorb new work without disrupting existing commitments.

How does Tasks Completed by Person relate to Hours by Person?

Hours by Person shows the time investment each team member has made. Tasks Completed by Person shows the output each team member has produced. The relationship between the two is a per-person throughput signal: a team member logging many hours with few task completions may be handling complex long-duration tasks which is appropriate or experiencing workflow friction. The comparison prompts the management question that leads to the right interpretation for the specific person and situation.

How does this dashboard support performance conversations without being punitive?

The By Person Dashboard is a capacity and workload management tool, not a performance evaluation system. Hours logged and tasks completed reflect the work that was recorded, which is affected by how work is defined, how tasks are scoped, and how well the time logging process captures actual activity. The dashboard surfaces patterns that warrant conversation not conclusions that can be drawn from the numbers alone.

Can the By Person Dashboard be filtered by date range, project, or work type?

Yes. Hours by Person, Tasks Completed by Person, and Top 5 Workloads can each be filtered by date range, project, work order type, or site. Filtering to a specific project shows each team member's contribution to that project specifically. Filtering to a specific date range shows weekly or monthly individual productivity without the cumulative period data obscuring short-term patterns.

How long does it take to deploy FireFlight individual productivity reporting?

Most operations are running live By Person dashboards in weeks, not months. The metrics read from the same time tracking and task records that the broader FireFlight deployment captures. No additional configuration is required beyond the base time tracking and work order setup. The dashboard populates from the first hours and task completions logged in the system.

If your current view of individual productivity comes from end-of-week timesheet summaries or from asking team members how they are doing, the workload distribution that drives your team's capacity decisions is always a week old and partially estimated. FireFlight's By Person Dashboard shows individual hours, task completions, and the current top five workloads from live records, continuously. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

By Person Dashboard

Unlike the Ad-Hoc Reporting tool: which is built for technical users familiar with SQL, joins, filters, and relational data. Custom Reporting is fully managed.

Trends Dashboard | FireFlight

Last updated: April 2026

Trends Dashboard

Tasks completed per day, tasks assigned per day, and cumulative tasks completed three daily trend lines that show whether task throughput is keeping pace with demand and whether the operation is on track against its planned completion baseline.

FireFlight's Trends Dashboard shows three task metrics plotted over time: Tasks Completed per Day, Tasks Assigned per Day, and Cumulative Tasks Completed. The daily view shows the rate of assignment versus completion. The cumulative view shows whether total completed work is tracking ahead of, behind, or on pace with where it should be at this point in the project or period. All three update in real time as tasks are assigned and completed. Most operations are running live task trend data in weeks, not months.

FireFlight Trends Dashboard showing daily task completion, assignment rates, and cumulative progress over time

A daily task count tells you how much work was finished today. It does not tell you whether that amount is enough to stay on schedule, whether assignment volume is creating a backlog that will become a problem next week, or whether the team is ahead of or behind where cumulative completion should be at this point in the month. Those questions require a trend view rather than a point-in-time count. The Trends Dashboard provides exactly that three daily metrics plotted over time, updated from real task data logged as work happens rather than from end-of-day estimates.

Schedule your free consultation

What does a gap between assigned and completed tasks actually signal?

The relationship between Tasks Assigned per Day and Tasks Completed per Day is the most direct measure of whether the operation is keeping pace with its workload. On any given day, if 14 tasks are assigned and 11 are completed, the open task queue grows by 3. That single-day gap is manageable. If the same pattern repeats for five consecutive days, the queue has grown by 15 tasks. By day ten, it has grown by 30 and the cumulative completion line is visibly tracking below where it should be against any planned baseline.

The trend view makes that accumulation visible as it is happening rather than after it has produced a schedule problem. An operations manager who can see that the gap between assigned and completed has been widening for three days in a row has time to respond by adjusting assignments, adding a resource for a specific category of tasks, or having a conversation about scope before the accumulation has reached the point where it requires a schedule restructure to address.

Operational tracking view in FireFlight showing task completion rates and daily trend data

The Cumulative Tasks Completed metric adds the baseline comparison that daily rates alone cannot provide. A project scoped for 150 tasks over 15 working days has an implied daily pace of 10 tasks per day. By day 7, cumulative completion should be approximately 70 tasks. If the cumulative line shows 54 tasks completed by day 7, the project is 23% behind its implied pace a fact that is visible from the cumulative chart without any calculation. The chart shows where the actual line is versus where the expected pace would place it.

For operations managers tracking multiple concurrent projects or managing a team against a monthly task target, the cumulative view answers the question they most need to answer early in the period: are we on track? Not whether today was a good day, but whether the cumulative body of work is where it needs to be for the overall target to be met. A strong daily count on a day when the cumulative line is already significantly behind the baseline does not represent recovery it represents the start of possible recovery, and the trend view makes that distinction clear.

Why does point-of-work task logging produce better trend data than end-of-day reporting?

The quality of the trend lines on this dashboard depends entirely on when task completions are recorded. If team members log task completions at the end of the day based on memory, three things happen consistently: some completions from late in the day get recorded the following morning, some completions from early in the day get forgotten by logging time, and the time distribution within the day is lost entirely. The daily count may be roughly accurate, but its timing is not and timing matters for trend analysis.

FireFlight's Time Tracking on Job app records task completions at the point of execution. A technician who marks a task complete in the field at 10:47am generates a completion record timestamped 10:47am. That record flows into the Trends Dashboard in real time. By midday, an operations manager can see actual morning completion rates rather than a blank screen that will be populated when someone remembers to log at 5pm. For operations managing daily task targets or time-sensitive project milestones, that intraday visibility is the difference between responding to a slow morning before it becomes a slow afternoon and discovering the slow day after the fact.

The trend lines on this dashboard are only as reliable as the task records that feed them. Operations that log task completions at the point of work produce trend data that reflects actual daily throughput patterns. Operations that batch-enter completions at end of day produce trend lines that are accurate in total but misleading in pattern. PCG's deployment process includes configuring the Time Tracking on Job app specifically to make point-of-work logging faster than the alternative because the dashboard is only valuable if the data it reads is current and granular.

PCG has been building task tracking and labor management systems for field operations since 1995. The pattern of end-of-day batch logging producing unreliable trend data is one of the most consistent findings across 31 years of implementations in industrial, environmental, and service environments. The fix is not better reporting it is removing the friction from point-of-work logging so that the behavior change is easier than the old behavior, not harder.

How does this dashboard work alongside other time tracking and operations views?

The Trends Dashboard occupies a specific position in FireFlight's time tracking and operations dashboard suite. Volume and Status shows current-state work order counts. Types and Mix shows how logged time is distributed across step type categories. Trends shows the daily and cumulative trajectory of task completion against assignment volume over time.

The three dashboards address different questions that share the same data source. Volume and Status answers where things stand right now. Types and Mix answers how time is being allocated across work categories. Trends answers whether the operation is moving in the right direction over the past days and weeks. An operations manager who starts with Volume and Status to check current state, then checks Trends to see whether the current state reflects an improving or worsening trajectory, then checks Types and Mix to see whether the time allocation supports the throughput rate the Trends dashboard shows that sequence gives a complete operational picture without requiring a custom report for each layer of the question.

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 Trends Dashboard, Ikhana explains how to read the gap between assigned and completed trend lines, what the cumulative completion line means relative to a planned pace, and how to use date range filters to isolate a specific project period versus the full operational history. New team members understand what the charts are telling them before they make a management decision based on a misread of the data.

Learn more about Ikhana

What the three metrics give your operation

Tasks Completed per Day. The daily count of tasks moved to completed status, plotted over the selected period. Shows the throughput rate of the team on a day-by-day basis whether completion volume is stable, accelerating, or declining. High-completion days and low-completion days are both visible in context, which distinguishes a normal day-to-day variation from a pattern of consistently declining daily throughput that warrants investigation.
Tasks Assigned per Day. The daily count of new task assignments over the selected period. Plotted alongside Tasks Completed per Day, this metric shows whether the team is receiving more work than it is completing each day. A persistent gap between assigned and completed where assigned consistently exceeds completed is the trend signal that a backlog is actively accumulating before it appears in overdue counts or missed deadlines.
Cumulative Tasks Completed. The running total of all tasks completed since the start of the selected period. Compared against a planned baseline pace, this metric shows whether total completed work is ahead of, behind, or on track at any point in the project or period. The cumulative view is what converts daily rate data into a project health indicator showing not just what happened today but whether the full body of completed work reflects the pace required to meet the end-of-period target.

What PCG learned across 31 years of operations tracking system builds: the teams that hit their task targets consistently were not the ones that worked harder on the last day of the month. They were the ones where the gap between planned and actual pace was visible early enough to act on it.

The Trends Dashboard provides that early visibility. A cumulative line that is 15% behind its planned pace by day 8 of a 20-day period is a recoverable situation 12 remaining days to close a gap that amounts to roughly 1.5 extra tasks per day. The same gap discovered on day 18 is not recoverable without extraordinary effort. The difference between those two outcomes is not the size of the gap. It is when the gap was visible and therefore when the decision to close it could be made.

What operations see after deployment

Backlog accumulation is visible as it begins rather than after it has compounded. The gap between assigned and completed trend lines widens visibly before the accumulated backlog shows up in overdue counts. The management response happens at day three of a widening gap rather than at day ten when the backlog has reached the point where closing it requires pulling resources from other work.
Project and period targets are tracked against actual pace throughout the period rather than discovered at the end. The cumulative completion line shows project health in real time. A project that is on track by mid-period stays on track because the trend has been visible and managed. A project that fell behind mid-period had the opportunity to be corrected before the deadline made correction impossible.
Daily throughput patterns become legible rather than invisible. A team that consistently completes fewer tasks on Mondays and Thursdays than on other days has a pattern visible in the trend chart that is invisible in weekly totals. That pattern may reflect scheduling decisions, task type distribution on those days, or team composition and it is a management conversation that the daily trend data makes possible.
End-of-period surprises decrease. When cumulative completion is tracked in real time throughout the period, the final day is a continuation of a known trajectory rather than a revelation. Operations managers who check the Trends Dashboard regularly arrive at month-end or project close with an accurate expectation of where things will land rather than discovering the final number for the first time when the period closes.

Questions operations and project teams ask before deploying FireFlight

What does the Trends Dashboard show in FireFlight?

The Trends Dashboard shows three daily task metrics over time: Tasks Completed per Day, Tasks Assigned per Day, and Cumulative Tasks Completed. Together they show whether task throughput is keeping pace with assignment volume, whether daily completion rates are trending up or down, and what the running total of completed work looks like against the project or period baseline.

What does it mean when Tasks Assigned per Day consistently exceeds Tasks Completed per Day?

When assignments consistently outpace completions on a daily basis, the team's open task queue is growing every day. The gap between the two lines on the trend view is the net daily accumulation. A small and stable gap may be acceptable. A widening gap over multiple days signals a capacity problem. Catching that widening gap on day three is considerably less disruptive than catching it on day fifteen when the accumulated backlog requires a schedule restructure to clear.

What does Cumulative Tasks Completed show that daily counts cannot?

Daily completion counts show how much work was finished on a specific day. Cumulative Tasks Completed shows the running total of all completed work against the period or project baseline, making it possible to see whether the team is ahead of, behind, or on track relative to where completion should be at this point in the timeline. A project planned for 200 tasks over 20 days should show a cumulative line of approximately 10 tasks per day. If the cumulative line is running below that pace by day 8, the project is already behind a fact that daily counts alone would not make immediately obvious.

How does this dashboard connect to point-of-work time tracking in FireFlight?

The Trends Dashboard reads from the same task records that the Time Tracking on Job app writes to. When a technician marks a task complete in the field, the completion registers in the Trends Dashboard immediately. Because time is logged at the point of execution rather than at end of day, the daily completion count reflects what actually happened during the day rather than what someone reported having done when filling out a timesheet after the fact.

How does the Trends Dashboard differ from the Volume and Status Dashboard?

The Volume and Status Dashboard shows four current-state work order counts at a point in time. The Trends Dashboard shows task-level daily rates over a period, which reveals the direction of change rather than the current state. Volume and Status answers the question of where things stand right now. Trends answers the question of whether the operation is improving, holding steady, or declining over the past days or weeks. Both views are needed for different management decisions.

Can the Trends Dashboard be filtered by team, project, or date range?

Yes. The three trend metrics can be filtered by team member, project, work order type, site, or date range depending on the configuration deployed for the operation. Filtering to a specific project shows whether that project's daily task throughput is tracking to its planned completion rate. Filtering to a specific team member shows individual daily productivity trends. The unfiltered view shows the aggregate trend across all tasks in the system.

How long does it take to deploy FireFlight task trend reporting?

Most operations are running live task trend dashboards in weeks, not months. The Trends Dashboard reads from the task and time tracking records that the broader FireFlight deployment captures. No separate data pipeline or reporting configuration is required beyond the base system setup. The trend lines begin populating from the first day tasks are logged and completed in the system.

If your current view of task completion shows you today's count but not whether that count is moving in the right direction or whether cumulative progress is on pace with your target, you are managing by point-in-time data when trend data is available. FireFlight's Trends Dashboard shows assigned versus completed rates and cumulative progress in real time from task records logged as work happens. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Trends Dashboard

Forget the end-of-day scramble. With Time Tracking on Job, your team logs hours as they work — not after.

Backlog and Flow Dashboard | FireFlight

Last updated: April 2026

Backlog and Flow Dashboard

Upcoming demand, active work in progress, overdue tasks, and the aging distribution of everything in the queue four metrics that show whether work is moving through the system or accumulating in it.

FireFlight's Backlog and Flow Dashboard shows four live task metrics: Tasks Due in Next 7 Days as a forward-looking demand signal, Overdue Tasks as the count of work past its deadline, Work in-Process Tasks as the current active queue, and Task Aging Buckets showing the age distribution of all open work. All four update in real time from task records. Most operations are running live backlog and flow dashboards in weeks, not months.

FireFlight Backlog and Flow Dashboard showing upcoming tasks, overdue count, WIP, and aging buckets in real time

The four metrics on this dashboard answer the question that most task management views cannot: not just how much work is open, but where in the flow cycle each piece of work sits. Knowing the total open task count is less useful than knowing how much of it is actively in progress, how much is already past its deadline, how much is about to be due, and how long each bucket of open work has been waiting. That picture the structure of the backlog rather than its volume is what determines whether the operation is managing its work or being managed by it.

Schedule your free consultation

Why does the aging distribution of open tasks matter more than the total count?

Two operations each with 40 open tasks are not in the same situation if the age distribution of those tasks is different. The first operation has 34 tasks open for less than a week and 6 tasks open for 8-14 days work is flowing through the queue at a rate that keeps it current. The second operation has 10 tasks under a week old, 12 at 8-14 days, 11 at 15-30 days, and 7 over 30 days old the same total count, but a very different operational picture. The second operation is not closing tasks nearly as fast as it is opening them, and the aging distribution shows that pattern developing across weeks rather than as a sudden accumulation.

Task Aging Buckets is the metric that makes that distribution visible at a glance rather than requiring an age analysis of each open task to see it. When the older buckets are growing in proportion to the newer ones, backlog is accumulating in the queue rather than flowing through it. Catching that shift in the distribution on day ten is what allows a management response schedule adjustment, resource rebalancing, scope review before the day-30 bucket has become the majority of the open task inventory.

Task flow and capacity view in FireFlight showing WIP distribution and upcoming work demand for the next 7 days

Tasks Due in Next 7 Days is the forward-looking counterpart to the other three metrics. WIP shows what is currently active. Overdue shows what has already missed its window. Aging Buckets shows the age structure of everything open. Tasks Due in Next 7 Days shows what is about to demand resolution the incoming wave of work that needs to be completed within the current operational week. For operations managers making capacity decisions, this metric is what turns the current-state picture into a forward-looking question: does the team have the capacity to close both the current WIP and the next-7-days tasks before any of them become overdue?

When the answer to that question is no when the combined volume of WIP and next-7-days tasks exceeds what the team can realistically close in a week the options are clear: reassign work, add capacity, defer less critical tasks, or adjust due dates where that is appropriate. All of those decisions are better made on Monday from a 7-day forward view than on Friday from the overdue count that results from not having made them.

How does WIP relate to the other three metrics as a flow management signal?

Work in-Process Tasks is the current active queue tasks that are open, assigned, and within their due date window. It is the operational load the team is actively carrying at this moment, distinct from the overdue tasks that have passed their window and the upcoming tasks that have not yet entered their active window. WIP is healthy when it is at a level the team can manage: not so low that capacity is being wasted, not so high that quality and completion timelines are at risk.

The relationship between WIP and the aging buckets tells the flow management story. If WIP is high and the youngest aging bucket is also the largest, work is entering the active queue and moving through it at a reasonable rate. If WIP is high and the aging buckets show increasing work in the 15-30 day and over-30-day ranges, work is entering the active queue and not moving through it it is accumulating in the system rather than flowing out. That accumulation is what eventually shows up as overdue tasks, but the aging distribution makes it visible before the due dates are crossed, when intervention is still possible.

All four metrics read from live task records in FireFlight. A task that becomes overdue at midnight appears in the Overdue count at midnight. A task due in six days appears in Tasks Due in Next 7 Days from the moment it is created with that due date. A task that moves from assigned to in-progress updates the WIP count immediately. The Aging Buckets recalculate continuously as time passes and tasks age through the thresholds. The dashboard shows the actual current state of the task queue rather than a snapshot from the last time someone ran a report.

PCG has been building task management and workflow tracking systems since 1995. The pattern of backlog accumulation becoming visible only after it has already produced schedule failures and overdue counts is one of the most consistent operational problems across service, maintenance, and project-driven environments. The Task Aging Buckets metric is specifically designed to make that accumulation visible earlier in the age distribution of open tasks rather than in the overdue count that confirms the accumulation has already happened.

How does this dashboard connect to document and knowledge management in FireFlight?

The Backlog and Flow Dashboard reads from the task records that drive all operational activity in FireFlight including tasks generated from compliance obligations, document review cycles, and knowledge management workflows. For operations where task management includes compliance documentation tasks, inspection records, and regulatory submissions alongside operational work orders, the backlog and flow view applies to the full scope of what needs to be completed rather than only to field or maintenance tasks.

A compliance documentation task that appears in the Tasks Due in Next 7 Days metric carries the same flow management implications as a field service task: it needs to be completed within its window, it occupies WIP capacity while it is in progress, and it ages into the overdue bucket if it is not closed in time. The dashboard treats all task types consistently, which gives operations managers who manage both operational and compliance workloads a single view of the full task queue rather than separate tracking systems for different types of work.

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 Backlog and Flow Dashboard, Ikhana explains how aging bucket thresholds are defined, what a healthy versus unhealthy aging distribution looks like for a team of a given size and throughput rate, and how to read the four metrics together as a flow picture rather than as four independent counts. Operations managers and team leads interpret backlog signals correctly from their first week with the system.

Learn more about Ikhana

What the four metrics give your operation

Tasks Due in Next 7 Days. The forward-looking demand count: how many open tasks have due dates falling within the next seven days. Compared against the current WIP count and team capacity, this metric answers whether the team has enough throughput to clear both its active queue and the incoming near-term obligations before any of them cross into overdue. The planning conversation that should happen on Monday is visible from Monday's forward count rather than from Friday's overdue count.
Overdue Tasks. The count of open tasks that have passed their due date without reaching a completed status. Updated continuously as due dates are crossed. A stable, low overdue count reflects a team whose throughput is keeping pace with its commitments. A growing overdue count reflects either an incoming demand that has exceeded throughput capacity or a systematic pattern of deprioritizing specific task categories until their due dates have passed. The metric is the consequence. The other three metrics are what show the cause while it is still developing.
Work in-Process (WIP) Tasks. The current count of open tasks that are actively in progress assigned, within their due date window, and being worked. The live measure of operational load: how much work the team is actively carrying at this moment. When WIP grows faster than task completions, the excess begins aging into older buckets. WIP at a level that matches team capacity is the condition that produces consistent completion rates. WIP that consistently exceeds that level produces the aging distribution that predicts overdue accumulation.
Task Aging Buckets. Open tasks grouped by elapsed time since creation: 0-7 days, 8-14 days, 15-30 days, and over 30 days. The distribution across buckets shows the age composition of the open task queue whether work is moving through the queue at a rate that keeps it current, or whether it is accumulating in older buckets in a pattern that predicts a future overdue count. Growing older buckets are the leading indicator of backlog accumulation that the overdue count confirms only after the fact.

What PCG learned across 31 years of task management system builds: the operations that managed their backlogs well were not the ones that cleared the overdue count the fastest after it grew. They were the ones where the aging distribution never developed the pattern that produces a large overdue count in the first place.

Backlog is not a state it is a process. Work ages through buckets continuously. The moment it enters the oldest bucket is not the moment the backlog problem started; it is the moment the backlog problem became undeniable. Managing by aging distribution means catching the problem in the 15-30 day bucket and responding before the work crosses into the over-30-day bucket and the overdue count simultaneously. That is a different management timeline, and the Aging Buckets metric is what makes it achievable.

What operations see after deployment

Backlog accumulation is visible while it is still in the aging buckets rather than only after it has crossed into the overdue count. The 7-to-14-day bucket growing faster than the 0-7-day bucket is visible before any of those tasks are overdue. The management response happens at the bucket level rather than at the overdue level which is earlier, lower-cost, and does not require expediting work that is already past its deadline.
Near-term capacity decisions are made from forward demand data. The Tasks Due in Next 7 Days count on Monday morning is the input that should determine how the week's assignments are structured. Operations managers who check this metric before the week begins have the information to avoid the overdue accumulation that results from not checking it until the week is over.
WIP levels are managed proactively rather than reactively. When WIP is trending higher than team throughput can sustain, the Aging Buckets metric shows the consequence developing before due dates are crossed. The decision to slow new task assignment, redistribute active work, or add capacity happens while there is still room to make it cleanly rather than under the pressure of an already-overdue queue.
The four metrics together replace multiple separate checks. The morning operational review that previously required checking a due-this-week list, a WIP queue, an overdue report, and an age analysis now starts from the four numbers on this dashboard. The picture of where the task queue stands is assembled automatically from live records before the review begins.

Questions operations and project teams ask before deploying FireFlight

What does the Backlog and Flow Dashboard show in FireFlight?

The dashboard shows four live task metrics: Tasks Due in Next 7 Days showing upcoming demand in the near-term window, Overdue Tasks counting tasks that have passed their due date without completion, Work in-Process (WIP) Tasks showing what is currently active and in progress, and Task Aging Buckets grouping open tasks by how long they have been open. All four update in real time from task records.

What does Tasks Due in Next 7 Days tell operations managers?

Tasks Due in Next 7 Days is a forward-looking demand signal: how much work is committed to completion within the next week. Combined with the current WIP count, it tells a manager whether the team's active capacity is sufficient to clear both the in-progress work and the incoming due work within the same window. If the sum significantly exceeds what the team can realistically complete in a week, the planning conversation happens today rather than when the week ends with tasks still open.

How are Task Aging Buckets defined in FireFlight?

Task Aging Buckets group all open tasks by elapsed time since creation typically 0-7 days, 8-14 days, 15-30 days, and over 30 days. A healthy operation has most of its open tasks in the 0-7 day bucket with declining counts in older buckets. When the 15-30 day and over-30-day buckets are growing, tasks are aging in the queue without being completed a backlog accumulation signal that is visible before it shows up fully in the overdue count.

What is the difference between WIP Tasks and Overdue Tasks?

WIP Tasks are open tasks that are currently in progress actively being worked and within their due date window. Overdue Tasks are open tasks that have passed their due date without completion. WIP is the healthy active workload. Overdue is the portion that has exceeded its committed timeline. When WIP grows faster than completions, overdue tasks begin to accumulate the Aging Buckets show the transition in progress before it fully appears in the overdue count.

How do these four metrics work together as a flow management view?

The four metrics tell the story of work moving through the task system in sequence. Tasks Due in Next 7 Days is incoming demand. WIP is the current active queue. Overdue is the portion that has not moved through the queue fast enough. Aging Buckets shows where in the queue each piece of work sits and how long it has been there. Together they answer: how much is coming, how much is in motion, how much is stuck, and how long has the stuck work been stuck.

How does the Aging Buckets metric identify a backlog problem before it becomes critical?

Task Aging Buckets makes backlog accumulation visible as a distribution rather than as a count. An operation with 40 open tasks where 35 are in the 0-7 day bucket is managing its queue well. An operation with the same 40 open tasks where 7 are in the over-30-day bucket alongside growing 15-30-day accumulation is carrying a backlog that has been developing for weeks. The total count is identical. The aging distribution tells entirely different stories about the health of the two operations.

How long does it take to deploy FireFlight backlog and flow reporting?

Most operations are running live backlog and flow dashboards in weeks, not months. All four metrics read from task records that the broader FireFlight deployment captures. Aging bucket thresholds and due date logic are configured during deployment. The dashboard populates from the first tasks created and assigned in the system.

If your current task management view shows a total open count and an overdue count without the aging distribution or the 7-day forward demand, you are seeing the result of backlog accumulation rather than the process. FireFlight's Backlog and Flow Dashboard shows all four metrics from live task records, continuously, so the management response happens at the aging bucket stage rather than at the overdue stage. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Backlog & Flow Dashboard

Monitor TCO over time, o forms, records, and compliance tasks to provide full visibility across time.

Volume and Status Dashboard | FireFlight

Last updated: April 2026

Volume and Status Dashboard

Four live work order counts created, completed, active, and overdue that together answer the only question that matters at the start of every shift: is the operation in balance, falling behind, or catching up?

FireFlight's Volume and Status Dashboard shows four real-time work order counts: Work Orders Created, Work Orders Completed, Active Work Orders, and Overdue Work Orders. All four update the moment a work order is opened, closed, or passes its due date. No report request required. Most operations are running live work order dashboards in weeks, not months.

FireFlight Volume and Status Dashboard showing four live work order counts: created, completed, active, and overdue

Four numbers. That is the entire dashboard. The simplicity is deliberate. An operations manager who opens this dashboard at 7am needs to know in seconds whether their operation has more open work than yesterday, whether overdue work is accumulating, and whether yesterday's completions kept pace with new work coming in. Those four numbers answer all three questions without requiring any interpretation. If any of them looks wrong, the next step is the more detailed Efficiency and Operations Dashboard. Volume and Status is the check that determines whether that next step is necessary.

Schedule your free consultation

What do four work order counts actually tell you?

The four metrics on this dashboard create a picture of work order flow through a simple relationship. Work Orders Created is the input how many new work orders were opened in the selected period. Work Orders Completed is the output how many were closed. Active Work Orders is the current balance between the two the live queue right now. Overdue Work Orders is the signal that some of that active queue has passed its due date without being closed.

When Created exceeds Completed over multiple periods, Active grows. When Active grows long enough without Completed catching up, Overdue begins to increase. The sequence is predictable, and the Volume and Status Dashboard is designed to make each stage of it visible before it reaches the next. An Overdue count that is growing is a lagging indicator it reflects work that was already Active too long. An Active count that is growing faster than Completed is the leading indicator that Overdue is likely to follow. Watching all four simultaneously is what makes the dashboard a management tool rather than a status display.

Operational visibility view in FireFlight showing work order counts in real-time across active operations

The Overdue Work Orders count is the metric that generates the most immediate operational response, but it is also the most useful when its trend is visible rather than just its current value. A count of 7 overdue work orders means different things depending on whether it was 12 last week, 4 last week, or 7 every week for the past month. The dashboard's real-time update means the trend is always readable from the current number in context the manager who checks the dashboard every morning knows what the number was yesterday and can interpret today's number accordingly.

For operations that manage work orders across multiple sites, crews, or work types, the four counts can be filtered to a specific scope. A facilities manager responsible for one building sees that building's numbers. A shop supervisor sees their team's queue. The aggregate view shows the full operation. Both are available from the same dashboard with the same four metrics, filtered to the scope that makes the numbers actionable for the person reading them.

When does this dashboard signal a problem before it becomes visible in the field?

The signal appears in the relationship between Created and Completed before it shows up in Overdue. An operation where 45 work orders were created this week and 38 were completed is adding 7 to its Active queue per week. At that rate, an operation starting the month with 20 Active work orders will have 48 by the end of the month. Whether any of those 48 are Overdue depends on due date assignments, but the direction is clear three weeks before the Overdue count reflects it.

An operation where Created and Completed are roughly equal week over week is in balance. The Active count stays roughly flat. The Overdue count reflects individual work orders that took longer than expected, not a systemic capacity gap. That is a different management situation addressable at the individual work order level rather than at the resource planning level. The Volume and Status Dashboard makes the distinction visible by showing both the flow metrics and the current balance simultaneously, in the same four-number view, without requiring a separate analysis to identify which type of problem is present.

All four counts update from live work order transaction records. A work order created at 8am appears in the Created count at 8am. A work order closed at 2pm reduces the Active count and increases the Completed count at 2pm. A work order whose due date passes at midnight enters the Overdue count at midnight. There is no scheduled refresh, no overnight batch, and no lag between operational activity and what the dashboard shows.

PCG has built work order and maintenance tracking systems for operations since 1995 industrial facilities, fleet operations, environmental service contractors, and healthcare staffing organizations where the basic question of how much work is open, how much is getting done, and how much is overdue has direct consequences for service delivery, compliance, and cost. The Volume and Status Dashboard is the simplest possible version of the answer to that question, available in real time, without requiring anyone to build it.

How does this dashboard work alongside the Work Order Efficiency Dashboard?

The Volume and Status Dashboard is the first check. The Work Order Efficiency and Operations Dashboard is the investigation. Volume and Status tells an operations manager whether something needs attention. Efficiency and Operations tells them what specifically needs it and why.

A morning check that shows Active work orders up 15% from yesterday and Overdue up 3 prompts a question: which categories are driving it, which technicians are carrying the most, and whether the backlog is concentrated in a specific shop or spread across the operation. Those answers are in the Efficiency and Operations Dashboard aging buckets, per-technician load, shop distribution, top categories, emergency trends. The two dashboards are designed to be used in sequence rather than as alternatives. Volume and Status provides the trigger. Efficiency and Operations provides the diagnosis. Together they give an operations manager a complete picture from the morning check to the management decision in a single workflow.

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 Volume and Status Dashboard, Ikhana explains what each of the four counts measures, how the period filter affects the Created and Completed counts versus the Active and Overdue counts, and when to use this dashboard versus the more detailed Efficiency and Operations view. New team members learn to interpret the numbers correctly on day one.

Learn more about Ikhana

What the four metrics give your operation

Work Orders Created. The total number of work orders opened in the selected period. This is the demand input how much new work entered the system. Compared to Work Orders Completed over the same period, it immediately shows whether the operation is running at a surplus (closing more than opening), at a deficit (opening more than closing), or in balance. The trend of this number over time also reflects whether overall maintenance demand is increasing, decreasing, or stable.
Work Orders Completed. The total number of work orders closed in the selected period. This is the throughput output how much work the operation actually finished. When this number consistently matches or exceeds Created, the operation is clearing its queue. When it consistently falls short, Active will grow and Overdue will eventually follow. Completed is the metric that managers often know least precisely in real time because it requires aggregating closure records that may be logged at different times FireFlight makes it current automatically.
Active Work Orders. The live count of work orders currently open and in progress at this moment. This is the operational load the team is carrying right now. A stable Active count while Created and Completed are roughly equal is a healthy sign. A growing Active count with Created outpacing Completed is an early warning sign. An Active count that is large relative to team capacity is a capacity constraint visible in this single number before it becomes a service delivery problem.
Overdue Work Orders. The count of open work orders that have passed their defined due date. This number should ideally be small and should be decreasing over time as overdue work is prioritized and closed. A growing Overdue count indicates that the Active queue is not being processed in time either due dates are being set too aggressively, work is being deprioritized inappropriately, or capacity is genuinely insufficient to meet committed timelines. The Overdue count is the most direct signal of a service commitment that is not being met.

What PCG learned across 31 years of operations management system builds: the dashboards that operations managers actually used every morning were not the ones with the most metrics. They were the ones where the most important question had an answer in under five seconds.

For work order management, that question is always the same: are we keeping up? Four numbers answer it completely. The Volume and Status Dashboard is built on that premise. The detail is available one click away for the mornings when the four numbers say something needs investigation. Most mornings, the four numbers say everything is fine and the manager moves on. That outcome the fast confirmation that nothing needs attention is equally valuable and equally the point.

What operations see after deployment

The morning operational check takes seconds rather than minutes. The four counts are current, accurate, and immediately interpretable without pulling a report, checking a queue, or asking the team for a status update. The manager knows whether anything needs attention before the first team conversation of the day.
Capacity imbalances are visible before they produce overdue work. The relationship between Created and Completed shows the direction of Active before the direction of Active shows up in Overdue. That one-step lead time is often enough to adjust assignments, add a resource, or defer lower-priority work before the Overdue count reflects what would have happened without the adjustment.
Overdue work orders are tracked automatically without a manual flag process. Work orders that pass their due date appear in the Overdue count at the moment they become overdue. The manager does not need to run a query, check a schedule, or rely on a technician to self-report a missed deadline. The count is current because the due date logic is applied in real time.
Status reporting in team meetings is replaced by a shared view. When the four numbers are on a screen that everyone can see, the status update conversation becomes a response conversation. The question shifts from "where do we stand" to "what are we doing about it" which is a more productive use of the time that status reporting typically consumes.

Questions operations managers ask before deploying FireFlight

What does the Volume and Status Dashboard show in FireFlight?

The dashboard shows four live work order counts: Work Orders Created, Work Orders Completed, Active Work Orders, and Overdue Work Orders. All four update in real time as work orders are opened, progressed, closed, or pass their due dates. The four numbers together give operations managers an immediate picture of whether work is flowing through the system, accumulating, or falling behind schedule.

How does FireFlight determine that a work order is overdue?

A work order becomes overdue when its defined due date passes without the work order reaching a completed or closed status. The Overdue Work Orders count on the dashboard updates automatically at the point the due date is crossed no manual flag is required. For operations that set due dates based on maintenance schedules, SLA commitments, or compliance inspection deadlines, the overdue count reflects the actual number of missed targets in real time rather than requiring a daily report pull to find them.

What is the difference between Active Work Orders and Work Orders Created?

Work Orders Created is a cumulative count for the selected period every work order that was opened, regardless of current status. Active Work Orders is the current live count of work orders that are open and in progress right now. The difference between the two reflects how many work orders opened during the period have already been completed. If 80 work orders were created this month and 55 are still active, 25 have been closed a simple closure rate visible without any calculation.

How does the dashboard help identify when work order volume exceeds team capacity?

When Work Orders Created is consistently higher than Work Orders Completed over the same period, Active Work Orders will grow over time and Overdue Work Orders will begin to increase. Watching those four numbers together in real time shows the capacity imbalance as it develops before it has accumulated into a backlog that requires extraordinary effort to clear.

Does the Volume and Status Dashboard replace the Work Order Efficiency and Operations Dashboard?

The two dashboards serve different purposes. Volume and Status gives the fastest possible high-level read on work order health four numbers, immediate context, no interpretation required. The Work Order Efficiency and Operations Dashboard provides the 10-metric detail view: aging buckets, closure rate trends, per-technician load, shop distribution, most serviced assets, and emergency patterns. Volume and Status is the morning check. The Efficiency Dashboard is the investigation that follows when one of the four Volume and Status numbers requires explanation.

Can the Volume and Status Dashboard be filtered by site, crew, or work order type?

Yes. The four counts can be filtered by site, zone, shop, work order type, assigned technician, or date range depending on the configuration deployed for the operation. For multi-site operations, filtering to a specific facility shows that facility's current work order health without the numbers being diluted by activity at other sites. For operations managers responsible for a specific crew or category, the filtered view shows what is relevant to their scope rather than the full organizational total.

How long does it take to deploy FireFlight work order dashboards?

Most operations are running live work order dashboards in weeks, not months. The Volume and Status Dashboard reads from the same work order records that drive the full FireFlight operations environment. Configuration involves defining due date logic, status categories, and any filter structures needed for multi-site or multi-crew views. PCG handles configuration as part of the broader FireFlight deployment.

If knowing whether your work order operation is keeping up, falling behind, or accumulating overdue work currently requires pulling a report or asking the team, that information is arriving later than it should. FireFlight's Volume and Status Dashboard shows the answer in real time from four live numbers. No reports, no lag, no manual process. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Volume & Status Dashboard

Build configurable project templates that reflect your workflows, structures, and resource plans. Save time and maintain consistency across teams.

Work Order Efficiency and Operations Dashboard | FireFlight

Last updated: April 2026

Work Order Efficiency and Operations Dashboard

Ten live metrics covering work order volume, aging, closure rates, technician load, backlog trends, emergency patterns, and shop distribution all from one real-time view that updates as work orders are opened, assigned, and closed.

FireFlight's Work Order Efficiency and Operations Dashboard gives operations managers a continuous view of their work order portfolio: what is open and by what type, how long open orders have been aging, whether the backlog is growing or shrinking, which assets are generating the most service volume, and how the workload is distributed across technicians and shops. Every metric is live. Most operations are running this dashboard in weeks, not months. Nothing on it requires a report request to stay current.

FireFlight Work Order Efficiency and Operations Dashboard showing live metrics for open work orders, aging summary, and technician workload distribution

Operations managers who wait for a weekly work order summary to know whether their maintenance backlog is growing are always finding out at least five days late. By the time a trend shows up in a scheduled report, it has already been developing for a week. FireFlight's Work Order Efficiency and Operations Dashboard shows that trend as it develops from live work order data, continuously so the decision about whether to act happens while the backlog is still recoverable rather than after it has reached the point where catch-up requires overtime and expedited parts.

Schedule your free consultation

What does work order aging actually tell you about your maintenance operation?

The WO Aging Summary is the metric that separates a maintenance operation that is managing its backlog from one that is being managed by it. An operation where most open work orders are within the first seven days of opening is clearing work at roughly the rate it is coming in. An operation where the 15-30 day and beyond-30-day buckets are consistently growing is accumulating a backlog that will eventually require extraordinary resource allocation to clear and the extraordinary resource allocation will itself generate a new round of deferred work in the categories that got deprioritized to clear the backlog.

The value of seeing aging in real time rather than in a weekly summary is that the trend is visible while it is still being driven by decisions that can be changed. A bucket that was holding five work orders last Monday and holds nine this Monday has grown 80% in a week. That growth rate, spotted on Tuesday, produces a management conversation that can still affect the schedule for the rest of the week. Spotted in next Monday's report, it produces a conversation that is already describing last week's problem rather than this week's opportunity.

Work order data feeding into operational intelligence view in FireFlight showing asset service history and shop performance metrics

The Most Serviced Assets metric and Emergency WO Trends address different questions but point toward the same underlying issue when they move together. An asset appearing consistently at the top of the Most Serviced Assets ranking while the Emergency WO Trends metric is increasing is an asset that is failing frequently and being responded to reactively. The combination of those two signals before they show up in a maintenance cost analysis at the end of the quarter is what drives a reliability review or a replacement conversation at the point when the replacement decision is still economically rational.

WO Distribution by Shop adds the capacity dimension to that picture. An operation where one shop is carrying 60% of the work order volume while others are carrying 15% each is either working with a staff allocation that does not match the actual work distribution, or categorizing work in a way that concentrates certain types in one shop when that concentration is not operationally necessary. Both situations are addressable, but only if someone can see the distribution clearly rather than inferring it from dispatch schedules and technician utilization rates.

How does the WO Closure Rate change what gets discussed in operations reviews?

Monthly closure rate is the ratio of work orders closed in a period against work orders opened in the same period. A ratio above 1.0 means the operation is closing more than it is opening backlog is being reduced. A ratio below 1.0 means the operation is adding to its backlog every month. A ratio consistently below 1.0 across multiple months is a structural capacity problem, not a scheduling problem, and the evidence for that distinction is precisely the kind of trend data the closure rate provides.

When operations reviews are driven by a closure rate metric rather than by a list of overdue work orders, the conversation shifts from which specific work orders are late to whether the system that produces work orders is in balance with the capacity that closes them. That is a different management problem with different solutions staffing, preventive maintenance program design, contractor capacity, or scope reduction and identifying it requires a rate metric rather than a status list.

Every metric on the dashboard reads from live work order transaction records. When a work order is opened, the Open WOs by Type count updates. When it is closed, the Closure Rate and Aging Summary both reflect the change. When a new emergency work order is created, it contributes to the Emergency WO Trends count immediately. There is no overnight batch process and no reporting cycle that determines when the dashboard becomes current. The dashboard is current because the work order system is current.

PCG has been building work order and maintenance management systems since 1995, including systems for industrial facilities, fleet operations, healthcare staffing, municipal services, and environmental contractors where work order volume, aging, and backlog are operational metrics with direct financial and compliance consequences. The 10-metric structure of this dashboard reflects what maintenance and operations managers across those industries have consistently needed to see in real time to manage effectively.

How does Open WOs by Technician support day-to-day workforce management?

Open WOs by Technician is the metric that makes workload visibility actionable at the individual level rather than the team level. The team-level backlog trend tells a manager that the operation is accumulating work. The technician-level view tells them where. A technician carrying 22 open work orders while two colleagues each carry 7 is a distribution problem that has a straightforward remedy reassignment if the manager can see it. Without the per-technician view, the reassignment conversation requires checking individual schedules and asking each technician how their queue looks, which is a manual process that typically produces incomplete information and delayed action.

The metric also separates workload imbalance from performance issues. A technician closing 12 work orders per week with 18 in queue is performing at a normal rate against an above-average assignment. A technician closing 4 work orders per week with 9 in queue is either handling complex work that takes longer, or working through a workflow problem that a conversation can surface. The per-technician view makes both patterns visible from the dashboard rather than requiring a separate performance analysis to find them.

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 Work Order Efficiency and Operations Dashboard, Ikhana explains what each of the 10 metrics measures, how the aging buckets are defined, and how to read the backlog trend relative to the closure rate. New operations managers learn to interpret the dashboard correctly on day one rather than spending a week cross-referencing it against other reports to understand what the numbers mean.

Learn more about Ikhana

The full metric library

Open Work Orders by Type. Shows current open work order count segmented by work order type preventive maintenance, corrective repair, inspection, emergency, project-based, or any custom types defined for the operation. The type breakdown identifies which categories are carrying the most open volume and whether the distribution reflects the intended balance between planned and reactive work.
Work Orders Aging Summary. Groups open work orders by elapsed time since creation under 7 days, 7-14 days, 15-30 days, and over 30 days. Growing volume in the older buckets is the earliest visible signal that work is accumulating faster than it is being completed. Catching that signal in the 15-30 day bucket is considerably less expensive than catching it in the over-30-day bucket.
WO Closure Rate (Monthly). The ratio of work orders closed to work orders opened in each calendar month. A rate consistently below 1.0 identifies a structural capacity problem rather than a scheduling problem and that distinction determines whether the correct response is schedule adjustment or capacity addition.
Most Serviced Assets (WO Volume). Ranks assets by work order count over a defined period. High-ranking assets are consuming disproportionate maintenance resources relative to comparable assets in the same class. Combined with Emergency WO Trends, this ranking identifies assets where a reliability review or replacement analysis is warranted before the maintenance cost appears in a quarterly budget review.
Emergency WO Trends. Tracks the volume of emergency work orders over a rolling period and shows whether that volume is trending up, flat, or down. A sustained upward trend in emergency work is a leading indicator that preventive maintenance is being deferred, that specific assets are approaching end of reliable service life, or that a failure mode is recurring without a root cause resolution.
WO Average Completion Time (Days). Measures the average number of days between work order creation and closure across all types, and by type when filtered. Rising average completion time is an efficiency signal either individual work orders are taking longer, or the queue behind each work order is growing and extending the time to first action. Both interpretations point toward different interventions, and the metric surfaces the trend that prompts the investigation.
Open WOs by Technician. Shows current open work order count per team member. Workload imbalances between technicians are visible in real time rather than requiring a manual schedule review. The metric also distinguishes between high-assignment technicians closing at a normal rate and technicians whose queue is growing relative to their closure pace two different situations that look identical in a team-level backlog view.
Top WO Categories. Ranks work order categories by volume over a defined period. Categories that consistently rank in the top positions reflect the actual maintenance demand profile of the operation whether that aligns with the planned maintenance program or reveals that reactive work in specific categories is consuming more capacity than the planned program accounts for.
WO Backlog Trend. Shows total open work order volume over time as a trend line rather than a point-in-time count. A growing backlog trend combined with a closure rate below 1.0 and an aging summary showing work accumulating in the older buckets is the three-metric combination that identifies an operation that has passed the threshold from manageable backlog to structural capacity gap.
WO Distribution by Shop. Shows how work order volume is distributed across shops, service teams, or operational divisions. Uneven distribution is a capacity planning signal it identifies where work is concentrated relative to staffing and whether the concentration reflects operational necessity or an assignment practice that can be adjusted to improve overall throughput.

What PCG learned across 31 years of maintenance and operations system builds: the operations teams that managed work order backlogs well were not the ones with the best technicians or the most detailed work order records. They were the ones where the manager could see the backlog trend, the aging distribution, and the closure rate simultaneously, in real time, without building a report to do it.

Those three numbers together tell a complete story about whether the operation is in balance. The other seven metrics on this dashboard add the detail that turns that story into an actionable investigation: which assets, which technicians, which categories, which shops. The dashboard is designed to get from pattern to cause in the same view rather than requiring a separate query for each layer of the question.

What operations see after deployment

Backlog growth is caught while it is still recoverable. The combination of the Backlog Trend and Aging Summary metrics surfaces an accumulating backlog early enough to adjust assignments, schedule overtime, or defer lower-priority work before the backlog requires emergency resourcing to clear.
Reactive maintenance patterns are visible before they dominate the schedule. Rising Emergency WO Trends combined with high Most Serviced Assets volume on the same equipment signals that specific assets need reliability attention before reactive work has displaced the planned maintenance program entirely and the operation is running entirely on response.
Workforce management is based on current data rather than last week's schedule. Open WOs by Technician shows the real-time workload of every team member. Imbalances are addressable on the day they appear rather than at the next weekly planning meeting, which is the difference between a five-minute reassignment and a three-day delay.
Operations reviews start from a shared current picture rather than from individually prepared status updates. The dashboard is the status update. The review conversation starts with what to do about what it shows rather than with establishing whether the numbers each person brought are accurate.

Questions maintenance and operations managers ask before deploying FireFlight

What does the Work Order Efficiency and Operations Dashboard show in FireFlight?

The dashboard shows 10 live operational metrics covering work order volume, aging, closure rates, technician load, backlog trends, and emergency work patterns: Open Work Orders by Type, Work Orders Aging Summary, WO Closure Rate by month, Most Serviced Assets by volume, Emergency WO Trends, WO Average Completion Time in days, Open WOs by Technician, Top WO Categories, WO Backlog Trend, and WO Distribution by Shop. All metrics update in real time from live work order records.

What does the Work Orders Aging Summary show and why does it matter?

The Aging Summary groups open work orders into time buckets work orders open less than 7 days, 7-14 days, 15-30 days, and beyond 30 days. When the older buckets are growing, it signals that work is entering the queue faster than it is being closed, or that specific categories are consistently getting pushed back in prioritization. The Aging Summary identifies that pattern while the backlog is still manageable rather than after it has accumulated to the point where catch-up requires extraordinary effort.

How does FireFlight track Emergency WO Trends over time?

The Emergency WO Trends metric tracks the volume of work orders classified as emergency or urgent over a rolling period, showing whether that volume is increasing, stable, or decreasing month over month. A sustained increase in emergency work orders is typically a leading indicator of either deferred preventive maintenance catching up as failures, or a specific asset class approaching end of reliable service life.

What does WO Distribution by Shop show in FireFlight?

WO Distribution by Shop shows how work order volume is distributed across shops, crews, or operational divisions. For operations with multiple service teams, this metric identifies whether work is concentrated in one shop while others are underutilized, or whether the distribution reflects the actual workload profile of each area. Imbalanced distribution is a capacity planning signal it shows where work needs to be redistributed or where staffing adjustments are warranted before the overloaded shop begins missing completion targets.

How does the WO Backlog Trend differ from the Aging Summary?

The Aging Summary shows the current state of open work orders grouped by how long they have been open. The WO Backlog Trend shows how the total volume of open work orders has changed over time. A growing backlog trend combined with an aging summary that shows most work within normal timeframes means the operation is taking on more work than it is completing, even if individual work orders are not dramatically overdue yet. Catching that trend early is the difference between a capacity planning conversation and an emergency resourcing decision.

What does Most Serviced Assets by WO Volume identify?

The Most Serviced Assets metric ranks assets by the number of work orders generated against them over a defined period. An asset that consistently generates high work order volume relative to comparable assets in the same category is either due for a reliability review, approaching end of service life, or subject to conditions that increase failure frequency. This ranking surfaces the specific assets consuming disproportionate maintenance resources before those assets show up as a budget problem.

How does Open WOs by Technician help with workforce management?

Open WOs by Technician shows how many open work orders are currently assigned to each team member. This metric makes workload imbalances visible in real time a technician carrying significantly more open work orders than colleagues is a signal that either assignment practices need adjustment or the high-load technician is handling a category of work that requires rebalancing. The metric also identifies whether individual technicians are closing work orders at a rate consistent with assignment volume.

If your current view of work order status depends on a weekly summary or a manual schedule review, the trends that determine whether your maintenance operation stays in balance are already a week old by the time you see them. FireFlight's Work Order Efficiency and Operations Dashboard shows those trends from live data, continuously, so the management conversation happens while there is still time to change the outcome. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Work Order Efficiency & Operations Dashboard

From routine repairs to complex tasks — manage work at scale.
Schedule, assign, and complete with confidence.

Preventative Maintenance Management Dashboard | FireFlight

Last updated: April 2026

Preventative Maintenance Management Dashboard

PM compliance rates, upcoming workload, deferred tasks, equipment gaps, technician distribution, and schedule adherence 11 live metrics that tell maintenance managers whether the preventive program is being executed as planned before failures reveal that it was not.

FireFlight's Preventative Maintenance Management Dashboard shows 11 live metrics covering every dimension of PM program health: compliance rates by month, upcoming load over 30 days, average completion time, deferred tasks, equipment record gaps, technician distribution, location-based load, and schedule adherence. All 11 update in real time from maintenance scheduling and work order records. Most operations are running live PM dashboards in weeks, not months.

FireFlight Preventative Maintenance Management Dashboard showing PM compliance rates, upcoming load, technician distribution, and schedule adherence metrics

A preventive maintenance program that exists on paper but is not being executed as scheduled is not actually preventing anything. Equipment failures in operations with nominal PM programs are frequently traced not to the absence of maintenance schedules but to the absence of visibility into whether those schedules are being followed deferred tasks that accumulate quietly, PMs completed days outside their required window, equipment records that were never tied to the schedules that should be driving them. FireFlight's PM Management Dashboard makes all of that visible in real time, before the failure that reveals the gap.

Schedule your free consultation

What does PM Compliance Rate actually measure and why does monthly tracking matter?

PM Compliance Rate is the percentage of scheduled preventive maintenance tasks that were completed within their required window. A rate of 94% means 6% of scheduled PMs in that period were either missed, deferred past the window, or completed outside the acceptable completion range. For most operations, 6% sounds acceptable until it is multiplied by the number of scheduled PMs in a month and compared against the specific assets where the compliance gap is concentrated.

Monthly tracking reveals whether compliance is stable, improving, or declining over time. A compliance rate that was 96% in January, 91% in February, and 86% in March is telling a story about the PM program's deterioration that no single monthly snapshot could convey. The trajectory is as important as the current value, and the monthly trend is the measurement that makes the trajectory visible. For operations subject to regulatory maintenance requirements where an inspector can ask for PM compliance records going back 12 or 24 months the monthly compliance rate is the documentation that the program exists not just in scheduling but in execution.

Maintenance documentation and scanning history view in FireFlight showing equipment records linked to PM schedules and completion records

The Upcoming PM Load and Upcoming Workload (30 days) metrics address a problem that reactive maintenance management consistently creates: technician capacity is allocated based on current open work orders rather than on the known future demand that PM schedules represent. A maintenance team that is staffed to handle today's reactive work plus a normal PM cadence will be understaffed in the week when 23 quarterly PMs come due simultaneously a situation that is entirely predictable from the PM schedule but invisible without the forward-looking workload view.

PM Load by Location and Department adds the geographic dimension that aggregate load metrics cannot provide. Two facilities in the same organization may have very different PM densities in the same period. A regional maintenance manager viewing aggregate load without the location breakdown will plan staffing for the average rather than for the peak, leaving one location understaffed while another has excess capacity. The location breakdown is what makes resource allocation decisions site-specific rather than portfolio-average.

What does the PMs Lacking Equipment metric catch before it causes a compliance gap?

A PM that has been scheduled but not tied to a specific equipment record is a compliance documentation gap waiting to happen. The PM may be executed the technician may show up and do the work but if the completion does not post to an asset-level maintenance history, the asset has no documented service record for that interval. When an equipment warranty claim is denied because the manufacturer's required service interval cannot be documented, or when an audit flags an asset as lacking maintenance records, the root cause is frequently a PM that was scheduled at the program level but never associated with the specific asset it was supposed to maintain.

The PMs Lacking Equipment metric surfaces those scheduling gaps before the PM window closes. The Lacking Equipment PMs Report provides the detail which specific PMs are affected, scheduled for when, and which equipment categories they should be assigned to. Correcting the record assignment before the PM comes due means the completion posts to the right asset history. Discovering the gap after the PM has been completed against an unlinked record means the maintenance was done but the documentation value is lost.

Every metric on the dashboard reads from live PM scheduling and work order records. When a PM is completed, the compliance rate updates. When a PM is deferred, the deferred count updates. When a new PM schedule entry is created without an equipment record linked, the PMs Lacking Equipment count updates. The dashboard reflects the actual state of the PM program at the moment it is viewed, not the state from the last time someone ran a report.

PCG has been building preventive maintenance and asset management systems since 1995, including maintenance programs for industrial facilities, fleet operations, environmental equipment, and healthcare technology assets where PM compliance is not a best practice preference but a regulatory and warranty requirement. The 11-metric structure of this dashboard reflects what maintenance managers in those environments have consistently needed to see in order to manage a PM program rather than just schedule one.

How do Technician PM Distribution and Top Tasks Assigned by Name support workforce management?

Technician PM Distribution shows how preventive maintenance assignments are spread across the maintenance team. Uneven distribution where one technician carries 40% of PM assignments while others carry 10-15% each may reflect appropriate specialization, but it may also reflect an assignment practice that creates a single point of failure: if the heavily assigned technician is unavailable, the PM schedule falls behind in ways that are not distributed across the team and therefore not recoverable through normal coverage.

Top Tasks Assigned by Name shows which specific PM task types are being assigned most frequently and to whom. For maintenance managers evaluating training needs, succession planning, or workload equity, this metric shows where task type concentration exists at the individual level. A single technician who is the only person assigned to a specific high-frequency PM type is a knowledge and capacity dependency that the metric makes visible before the absence of that technician becomes a PM compliance gap.

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 Preventative Maintenance Management Dashboard, Ikhana explains how compliance rate is calculated, what the difference between deferred and overdue PMs means for the program record, and how to use the PM Load metrics to inform staffing decisions before a workload peak arrives rather than after it has produced a compliance gap.

Learn more about Ikhana

The full metric library

PM Compliance Rate by Month. The percentage of scheduled PMs completed within their required window in each calendar month. The monthly view shows compliance trajectory over time whether the program is stable, improving, or declining rather than just the current month's performance. For regulated environments, the monthly compliance record is the documentation that demonstrates the maintenance program is being executed, not just scheduled.
Upcoming PM Load. The volume of preventive maintenance tasks scheduled to become due in the near-term window, broken down to show when workload peaks are approaching. For maintenance managers allocating technician capacity, this metric makes forward demand visible before the week it arrives rather than at the start of that week when staffing adjustments are no longer practical.
Upcoming Workload (30 days). A 30-day forward view of all scheduled PM and maintenance tasks coming due. Used alongside current open work order volume, this metric gives maintenance planners the combined picture of both reactive and planned demand over the next month the baseline for staffing decisions, parts procurement, and contract resource planning that needs to happen now to be effective 30 days from now.
Average Completion Days. The mean elapsed time between PM task creation or due date and actual completion across the PM program. A rising average completion time signals that PMs are consistently being executed later in their windows or beyond their windows which reduces the program's effectiveness as a failure prevention measure and creates documentation gaps for tasks with specific required intervals.
PMs Lacking Equipment. The count of scheduled PMs that have no specific equipment record assigned. PMs without equipment links cannot post to asset-level maintenance history, cannot document service against warranty or regulatory intervals, and produce no auditable record of work performed against a specific asset. This metric surfaces the gap before the PM window closes and the documentation opportunity is lost.
Lacking Equipment PMs Report. The detailed breakdown behind the PMs Lacking Equipment count which specific tasks are affected, their scheduled dates, and which asset categories they should be linked to. Provides the actionable list for the records team to correct assignment gaps before they become completion-without-documentation events.
Deferred PM Tasks. PMs that were explicitly pushed to a later date before their original window closed. Distinct from overdue PMs, which were missed. Deferred PMs represent deliberate scheduling decisions. A small number of deferrals for legitimate reasons is normal. A growing deferred count indicates a pattern of systematic avoidance that will eventually surface as a compliance gap or equipment failure when deferred maintenance accumulates beyond what can be absorbed by the assets being maintained.
PM Load by Location and Department. PM workload distribution across sites, facilities, and operational departments. Identifies which locations have peak PM demand in a given period and which have below-average load information that drives staffing and resource allocation decisions at the location level rather than at the aggregate level, where location-specific peaks are invisible in the average.
Top Tasks Assigned by Name. The PM task types assigned most frequently, with assignment volume by task type. Identifies where task concentration exists in the program the high-frequency tasks that drive the most technician activity and where knowledge or capacity dependencies are most likely to affect compliance if a specific technician is unavailable.
Technician PM Distribution. How PM assignments are divided across the maintenance team. Uneven distribution flags single-point-of-failure risks where one technician carries a disproportionate share of PM responsibility. For maintenance managers evaluating cross-training needs or team capacity planning, this metric shows where the distribution warrants adjustment before an absence creates a compliance gap.
PM Scheduled Adherence. The rate at which PMs are completed on the day and within the window they were originally scheduled as distinct from the compliance rate, which only measures whether completion occurred at all. High compliance with low adherence indicates that PMs are being completed but consistently rescheduled, which disrupts dependent operational activities and suggests the PM schedule was built without reference to realistic available capacity.

What PCG learned across 31 years of preventive maintenance system builds: the operations with the lowest equipment failure rates were not the ones with the most detailed PM procedures. They were the ones where the PM program was managed against data compliance rates tracked monthly, deferred tasks visible before they accumulated, and technician load balanced against actual schedule requirements rather than estimated availability.

A PM program scheduled in a spreadsheet and executed without visibility into compliance rates, deferred tasks, and equipment record gaps is indistinguishable from no PM program at all when an auditor asks for documentation or when a failure investigation traces back to missed maintenance. The dashboard is what converts a scheduled program into a managed one.

What operations see after deployment

PM compliance is tracked and documented month by month rather than estimated annually. The monthly rate is available for regulatory review, warranty claims, and internal audits without requiring a reconstruction of historical maintenance records. Compliance gaps are visible as they develop rather than discovered during an audit when correction is no longer possible.
Deferred PMs are managed rather than lost. When deferrals are visible in a dedicated metric, the decision to defer a PM is a deliberate act with a visible record rather than a quiet omission that accumulates until an equipment failure makes the pattern apparent. Maintenance managers can see the deferred count growing and act on it before it produces compliance gaps.
Equipment documentation gaps are caught before PMs are completed against unlinked records. The PMs Lacking Equipment metric and its associated report identify records that need asset assignment while there is still time to make the correction before the task is completed and the documentation window closes.
Staffing decisions for peak PM periods are made in advance rather than in response. The 30-day forward workload view shows where PM demand peaks are approaching so technician allocation, parts procurement, and contractor scheduling can be positioned before the peak rather than improvised during it.

Questions maintenance managers ask before deploying FireFlight

What does the Preventative Maintenance Management Dashboard show in FireFlight?

The dashboard shows 11 live metrics covering PM compliance rates, upcoming workload, deferred tasks, equipment gaps, technician distribution, and schedule adherence: PM Compliance Rate by Month, Upcoming PM Load, Upcoming Workload (30 days), Average Completion Days, PMs Lacking Equipment, Lacking Equipment PMs Report, Deferred PM Tasks, PM Load by Location and Department, Top Tasks Assigned by Name, Technician PM Distribution, and PM Scheduled Adherence.

What does PM Compliance Rate by Month measure in FireFlight?

PM Compliance Rate by Month measures the percentage of scheduled preventive maintenance tasks that were completed within their required window in each calendar month. For operations subject to regulatory maintenance requirements or equipment warranty conditions, this monthly rate is the documentation that demonstrates whether the maintenance program is being executed as scheduled.

What are PMs Lacking Equipment and why does this metric matter?

PMs Lacking Equipment flags scheduled preventive maintenance tasks that have no equipment record assigned. A PM without an equipment record cannot drive asset-level maintenance history, cannot be tracked against an asset's service interval, and cannot contribute to equipment-specific compliance documentation. This metric surfaces the gap so it can be corrected before the PM window closes and the task is completed against a record that does not exist.

How does Deferred PM Tasks differ from overdue PMs?

Overdue PMs are scheduled tasks that have passed their completion window without being closed. Deferred PM Tasks are scheduled tasks that have been explicitly pushed to a later date before the original window closed. Both represent PM program gaps, but deferred PMs represent deliberate scheduling decisions while overdue PMs indicate execution failure or capacity problems. A growing deferred count indicates a pattern of systematic avoidance that will eventually surface as equipment failures.

What does PM Scheduled Adherence show beyond the compliance rate?

PM Compliance Rate measures whether PMs were completed. PM Scheduled Adherence measures whether they were completed on the schedule they were assigned. A compliance rate of 95% with low schedule adherence means most PMs are getting done but rarely on the day they were planned, which creates ripple effects in technician capacity planning and suggests the PM schedule was built without reference to realistic available capacity.

How does the Upcoming PM Load metric help with capacity planning?

Upcoming PM Load shows the volume of preventive maintenance tasks scheduled to become due in the near term. For maintenance managers planning technician assignments, this metric identifies when PM workload peaks are approaching before the week arrives rather than when the overloaded schedule becomes apparent on Monday morning. Combined with the Upcoming Workload 30-day view, it gives planners a rolling forward picture so technician allocation and parts procurement can be positioned in advance.

How long does it take to deploy FireFlight preventive maintenance scheduling and reporting?

Most operations are running live PM dashboards with compliance tracking and technician distribution reporting in weeks, not months. PCG handles setup of maintenance schedules, equipment records, and technician assignment structures. Existing PM programs from spreadsheets or other systems are migrated into FireFlight as part of deployment.

If your current PM program is managed from a schedule without visibility into compliance rates, deferred tasks, equipment record gaps, or technician load distribution, the program exists on paper but is not being managed against data. FireFlight's Preventative Maintenance Management Dashboard provides all 11 metrics from live records, continuously. Configuration takes weeks, not months, and PCG handles the migration of your existing maintenance schedules and equipment records.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Preventative Maintenance Management Dashboard

This workspace empowers your teams to prevent failures before they happen—and recover faster when they do.

Maintenance Usage Dashboard | FireFlight

Last updated: April 2026

Maintenance Usage Dashboard

Parts consumed by asset class and missing parts against active order requirements two live metrics that connect what maintenance is using to what procurement needs to have available before work orders stall.

FireFlight's Maintenance Usage Dashboard shows two live metrics: Parts Used by Asset Class or Type, giving a consumption breakdown by the category of equipment the parts were used on, and Missing Parts for Order Requirements, surfacing active work orders that need parts not currently in stock. Both update in real time from parts consumption and inventory records. Most operations are running live parts tracking in weeks, not months.

FireFlight Maintenance Usage Dashboard showing parts consumption by asset class and missing parts requirements for active work orders

A work order that stalls because a required part is not in stock did not fail because of a purchasing problem. It failed because parts consumption data was not connected to parts availability in a way that let procurement act before the technician arrived. Parts Used by Asset Class shows which equipment categories are consuming inventory at what rate the data that drives accurate reorder planning. Missing Parts for Order Requirements shows which active work already has a gap the data that drives immediate procurement action. Together they close the loop between what maintenance consumes and what procurement needs to provide.

Schedule your free consultation

What does parts consumption by asset class reveal that total consumption cannot?

Total parts consumption tells a maintenance manager how much the parts budget is being spent. Parts Used by Asset Class tells them where it is going and whether the distribution reflects the maintenance program's intent. A single asset class consuming 40% of total parts spend when it represents 15% of the fleet by count is either experiencing a disproportionate failure rate, requiring a specific type of repair that is parts-intensive, or approaching the point where replacement analysis is warranted. None of those conclusions are reachable from total consumption data they require the class-level breakdown.

The class-level view also drives more accurate reorder decisions than aggregate consumption averages. Different asset classes consume different parts at different rates. A generic reorder point calculated from total parts consumption across all asset types will consistently leave some classes under-stocked while others carry excess inventory. When consumption history is available by asset class, reorder points and safety stock levels can be calibrated to the actual consumption pattern of each class which reduces both stockouts and carrying costs simultaneously rather than forcing a choice between them.

Parts availability view in FireFlight showing missing parts flagged against active maintenance work orders before dispatch

Missing Parts for Order Requirements is where the dashboard prevents delays rather than documenting them. The metric surfaces active work orders that have parts requirements the current inventory cannot fulfill. When a gap appears, the procurement action generating a purchase order, contacting a vendor, pulling from a different location can happen before the work order has been dispatched and the technician is standing at the job site waiting for a part that should have been ordered two days ago.

The timing of that information is what determines its value. A missing parts alert that appears when a work order is created gives procurement the full lead time to resolve it days or weeks depending on the part. The same alert discovered when the technician opens the job is worth nothing because the resolution time required exceeds the available response time. FireFlight surfaces the gap as soon as the work order's parts requirements are compared against current inventory, which is at creation rather than at dispatch.

How do these two metrics connect to the Materials and Parts List catalog?

FireFlight's Materials and Parts List app is the master catalog for every part the operation uses sourcing data, preferred vendors, unit standards, and compliance references. The Maintenance Usage Dashboard reads from the transaction records that post against those catalog entries when parts are consumed in maintenance work. A part that appears in the Parts Used by Asset Class metric was consumed from a work order that referenced a catalog entry, which means the consumption record carries the part's full sourcing information.

When Missing Parts for Order Requirements flags a gap, the missing part is identifiable in the catalog along with which vendor supplies it, at what lead time, and at what unit cost. The procurement action is initiated from a complete information set rather than from a part number that someone has to look up separately. For maintenance operations that manage a large parts catalog across multiple vendors and asset classes, that direct connection between the gap identification and the sourcing information is what allows procurement to act on a missing parts flag in minutes rather than in hours.

Parts consumption records in FireFlight are generated at the point of use. When a technician issues a part to a work order, the consumption posts to the dashboard immediately. Missing parts gaps are identified when work order requirements are compared against live inventory levels not when the work order is scheduled, not when it is dispatched, but when it is created and the requirements are first recorded. The earlier the gap is visible, the longer the window for procurement to close it.

PCG has been building parts management and maintenance tracking systems since 1995 industrial maintenance operations, fleet service organizations, and field service companies where a stalled work order has a direct cost measured in downtime, delayed delivery, or failed compliance. The two-metric structure of this dashboard reflects the two questions that drive parts-related maintenance delays: which asset classes are consuming what, and which active work orders will be delayed if nothing is purchased today.

How does this dashboard connect to inventory and procurement workflows?

The Maintenance Usage Dashboard sits at the intersection of maintenance and procurement. Parts Used by Asset Class feeds into the analysis that sets reorder points and safety stock levels for each part category it is the historical consumption data that makes those decisions defensible rather than estimated. Missing Parts for Order Requirements feeds into the day-to-day procurement queue it is the current gap list that tells buyers which purchase orders need to be placed before specific work orders are delayed.

For operations that have historically managed parts availability by walking the stockroom before each week's maintenance schedule, this dashboard replaces that manual check with a live system view. The stockroom walk identifies what is present. The Missing Parts metric identifies what is absent relative to what is specifically needed for work orders that are already queued. The distinction matters because a stockroom with adequate general inventory may still have specific gaps against specific work orders gaps that a general inventory check would not surface but that the work-order-level requirements comparison in FireFlight surfaces automatically.

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 Maintenance Usage Dashboard, Ikhana explains how parts consumption is attributed to asset classes, what triggers a part to appear in the Missing Parts metric, and how to use the dashboard to initiate a procurement action directly from a flagged gap. Maintenance and procurement team members both understand what the dashboard is telling them and what response each metric supports.

Learn more about Ikhana

What the two metrics give your operation

Parts Used by Asset Class or Type. Parts consumption broken down by the category of asset the parts were consumed against. Shows which equipment classes are driving the most parts spend, enabling reorder points and safety stock levels to be calibrated to actual consumption patterns by asset type rather than to a generic average. Identifies asset classes with disproportionate parts consumption relative to their fleet share a signal that warrants further investigation into failure rates, repair patterns, or replacement timing.
Missing Parts for Order Requirements. Active work orders or maintenance tasks that require parts not currently available in inventory. Updated in real time as work orders are created and their parts requirements are compared against live stock levels. The metric surfaces gaps while the work order is still in the planning or queue stage rather than at dispatch, giving procurement the lead time to place the order before the technician's arrival on-site makes the delay inevitable.

What PCG learned across 31 years of maintenance parts management system builds: the operations that had the fewest parts-related work order delays were not the ones with the largest inventory. They were the ones where parts consumption history was connected to parts availability requirements at the work order level, and where the gap between what was needed and what was available was visible before dispatch rather than at the job site.

Inventory investment decisions are most accurate when they are based on actual consumption by asset class rather than on total consumption averaged across all equipment types. Procurement timing decisions are most effective when the gap is identified at work order creation rather than at the moment the technician cannot proceed. Both conditions require the data connection that this dashboard provides between what maintenance is consuming and what procurement needs to have ready before the next work order is dispatched.

What operations see after deployment

Work orders stop stalling because required parts were not ordered in time. Missing Parts for Order Requirements surfaces the gap when the work order is created. Procurement acts within hours. The technician arrives at the job with the required parts rather than arriving and waiting for an expedited order that should have been placed two days earlier.
Parts inventory is right-sized by asset class rather than by total consumption average. Reorder points for parts used heavily by one asset class are calibrated to that class's actual consumption rate. Asset classes with lower or more predictable consumption carry appropriate safety stock without holding excess inventory to cover the consumption profile of other asset types.
Asset classes with disproportionate parts spend are identified before the spend accumulates to the point where it appears in a budget review. The consumption breakdown by asset type makes the comparison between equipment classes visible in real time, surfacing the candidates for reliability review or replacement analysis while the maintenance investment decision is still timely.
Maintenance and procurement work from the same data rather than from separate systems that only occasionally align. Parts consumption records from maintenance flow directly to the dashboard that procurement reviews. The missing parts list that procurement acts on is the same list that maintenance sees. No reconciliation step and no information lag between when the gap exists and when procurement knows about it.

Questions maintenance and procurement teams ask before deploying FireFlight

What does the Maintenance Usage Dashboard show in FireFlight?

The dashboard shows two live metrics: Parts Used by Asset Class or Type, which shows parts consumption broken down by the category of asset the parts were consumed against, and Missing Parts for Order Requirements, which surfaces active work orders or maintenance tasks that require parts not currently in stock. Both metrics update in real time from parts consumption records and inventory data.

What does Parts Used by Asset Class or Type reveal about maintenance operations?

Parts consumption by asset class shows which categories of equipment are driving the most parts spend. An asset class consuming a disproportionate share of parts relative to its size in the fleet may be failing more frequently than comparable classes, may require a specific category of repair that is parts-intensive, or may be approaching the point where replacement is more cost-effective than continued maintenance. The breakdown by asset class makes that comparison possible without manually aggregating parts records by equipment type.

How does Missing Parts for Order Requirements prevent maintenance delays?

Missing Parts for Order Requirements shows which active work orders or maintenance tasks have parts requirements that cannot be fulfilled from current inventory. When this metric surfaces a gap, the maintenance team can initiate a purchase order before the technician arrives at the job and discovers the part is not available. The gap between discovering a missing part during job preparation and discovering it on-site is the difference between a procurement action and a stalled work order.

How does Parts Used by Asset Class connect to purchasing decisions?

Parts consumption by asset class is the data that makes reorder logic and safety stock decisions specific to equipment type rather than generic across all inventory. An asset class with high and consistent parts consumption needs a higher safety stock for the parts it commonly uses than an asset class with low and sporadic consumption. Without the class-level breakdown, safety stock decisions are based on average consumption that obscures the difference between asset types.

How do these two metrics work together to manage parts availability for maintenance?

Parts Used by Asset Class shows historical consumption patterns by equipment type. Missing Parts for Order Requirements shows current gaps against active work requirements. Together they give maintenance and procurement teams both the backward-looking view (which asset classes are consuming the most parts) and the forward-looking view (which current work orders will be delayed if no procurement action is taken now). Historical patterns inform reorder planning. Current gaps drive immediate action.

How does the Maintenance Usage Dashboard connect to the Materials and Parts List app?

The Materials and Parts List app is the master catalog of every part the organization uses sourcing data, preferred vendors, unit standards, and compliance references. The Maintenance Usage Dashboard reads from the transaction records that post against those catalog entries when parts are consumed in maintenance. Parts that appear in Missing Parts for Order Requirements are identifiable against the catalog, including which vendor supplies them and at what lead time, so the procurement action can be initiated from the same system that identified the gap.

How long does it take to deploy FireFlight maintenance parts tracking and usage reporting?

Most operations are running live parts consumption reporting in weeks, not months. The Maintenance Usage Dashboard reads from parts consumption records and inventory data that the broader FireFlight deployment captures. Asset class categorization and parts catalog setup are configured during deployment. PCG handles migration of existing parts catalogs and inventory records as part of the deployment process.

If your current view of parts usage is a total consumption number and your current awareness of missing parts comes from a technician calling from the job site, the data you need to prevent that call exists in your work order and inventory records it just is not being connected in real time. FireFlight's Maintenance Usage Dashboard makes that connection live. Configuration takes weeks, not months, and PCG handles the parts catalog and asset class setup during deployment.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Maintenance Usage Dashboard

Never miss a service milestone again. Automate asset maintenance with confidence.

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.

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

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?

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.

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.

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.

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.

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.

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.

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

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Performance and Risk Indicators Dashboard

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

Maintenance and Reliability Metrics Dashboard | FireFlight

Last updated: April 2026

Maintenance and Reliability Metrics Dashboard

Overdue work orders and PM inspection outcomes two metrics that together show whether the maintenance program is addressing known problems in time and whether preventive inspections are finding conditions that need correction.

FireFlight's Maintenance and Reliability Metrics Dashboard shows two live metrics: Overdue Work Orders counting maintenance and repair tasks that have passed their due date without completion, and PM Inspection Failed and Completed showing how many preventive maintenance inspections resulted in a pass versus a fail finding. Both update in real time from work order and inspection records. Most operations are running live reliability metrics in weeks, not months.

FireFlight Maintenance and Reliability Metrics Dashboard showing overdue work orders and PM inspection pass and fail outcomes

Reliability is not a property of equipment it is a property of the maintenance program managing that equipment. An asset fleet that is well-maintained produces predictable performance. One that accumulates overdue corrective work and where PM inspections pass without finding problems that actually exist is heading toward a different outcome. These two metrics are the simplest measurable expression of whether a maintenance program is doing what it is supposed to do: addressing known problems before they compound and catching developing problems before they become failures.

Schedule your free consultation

Why is an overdue work order a reliability metric rather than just a scheduling metric?

A work order becomes overdue when a known problem a corrective repair, a maintenance task, an inspection finding passes its resolution deadline without being addressed. The equipment involved is operating with a known condition that has not been fixed. For corrective repairs, that condition is already a failure that is generating wear, risk of secondary failures, and potential safety exposure with every hour it remains unresolved. For maintenance tasks with defined regulatory or warranty windows, an overdue work order may also be a compliance gap that has real consequences beyond the operational risk.

The count of overdue work orders at any moment is therefore a count of known reliability risks that are accumulating unresolved. A count of zero means every known problem has been addressed within its required window. A count that is growing means problems are entering the queue faster than they are being resolved, or that specific categories of work are consistently deprioritized until they age past their due dates. Both patterns have different management responses, but both require the same first step: knowing the count and knowing whether it is stable, growing, or shrinking.

Maintenance condition assessment view in FireFlight showing PM inspection findings and reliability indicators for asset fleet management

PM inspection outcomes tell a different but equally important story about asset reliability. A preventive maintenance program that completes all its scheduled inspections and records no failures is one of two things: either the equipment is genuinely in excellent condition, or the inspections are not rigorous enough to find the conditions that will eventually cause failures. The PM Inspection Failed and Completed metric distinguishes between these two interpretations by making the fail count visible alongside the completion count.

A PM program that never records inspection failures is not necessarily performing well. Zero failures may mean zero problems, or it may mean the inspection criteria are too lenient, the technicians are recording completions without performing full assessments, or the PM intervals are too short for conditions to develop to the point where they would be caught. When inspection failure rate is tracked and visible, a sustained period of zero failures against a fleet with normal age and operating hours warrants investigation rather than reassurance. The metric is what makes that investigation possible rather than invisible.

How do these two metrics together define the reliability health of a maintenance program?

The combination of Overdue Work Orders and PM Inspection Failed and Completed covers reliability from both the reactive and the preventive dimension simultaneously. Overdue Work Orders measures how well the operation is resolving known problems. PM Inspection Failed and Completed measures how effectively the preventive program is finding developing problems before they become failures. A maintenance program that performs well on both metrics low and stable overdue counts, PM inspections that find and record failures at a rate consistent with the age and operating conditions of the fleet is doing what a reliability-focused maintenance program should do.

The scenario that damages reliability most is the combination of a rising overdue work order count and a falling inspection failure rate. Rising overdue counts mean known problems are not being addressed. Falling inspection failure rates in that context are more likely to reflect inspection quality decline than improving equipment health. Both conditions are visible in this dashboard simultaneously, which is what makes the two-metric view a genuine reliability indicator rather than two unrelated counts displayed on the same screen.

Both metrics read from live operational records in FireFlight. An overdue work order count is calculated continuously against due date logic applied in real time a work order that becomes overdue at 11pm appears in the count at 11pm without anyone having to flag it. An inspection outcome is recorded at the point of inspection by the technician performing the PM. The dashboard reflects the current reliability state of the maintenance program from actual records, not from a weekly report that summarizes what happened before the week it was prepared.

PCG has been building maintenance and reliability tracking systems since 1995 industrial facilities, fleet operations, environmental service equipment, and healthcare technology assets where equipment reliability has direct operational, safety, and compliance consequences. The two-metric structure of this dashboard reflects the two questions that maintenance programs are actually designed to answer: are known problems being addressed in time, and is the preventive program finding problems before they become failures.

How does this dashboard connect to Project Work Orders in FireFlight?

Project Work Orders in FireFlight connect individual maintenance and inspection tasks to overarching project structures providing sequence, accountability, and traceability across multi-step maintenance engagements. When a PM inspection records a failure finding, the corrective action it triggers is a work order that can be linked to the originating PM record and, where appropriate, to the project structure that governs the maintenance engagement.

The Overdue Work Orders metric on this dashboard counts all work orders past their due date standalone, PM-generated, and project-linked giving the reliability view a picture of the full open maintenance obligation regardless of how the work was created. For operations managing complex multi-step maintenance projects where individual work orders within a project sequence may have their own due dates and dependencies, the overdue count surfaces schedule slippage at the work order level before it has propagated through the project timeline to affect downstream work.

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 Maintenance and Reliability Metrics Dashboard, Ikhana explains the distinction between overdue work orders as a scheduling metric versus a reliability metric, why a zero PM inspection failure count warrants investigation rather than celebration in certain fleet conditions, and how to interpret the two metrics together rather than in isolation. Maintenance managers and reliability engineers both use the dashboard correctly from day one.

Learn more about Ikhana

What the two metrics give your operation

Overdue Work Orders. The live count of work orders that have passed their due date without reaching a completed status. Calculated continuously from due date logic applied to live work order records. A count of zero reflects a maintenance program that is resolving known problems within required windows. A growing count reflects either a capacity gap or a systematic deprioritization of specific work categories. The underlying work order records show which assets, which locations, and which work types are driving the overdue count making the management response specific rather than generic.
PM Inspection Failed and Completed. The outcomes of preventive maintenance inspections, shown as a breakdown between completed with a pass result and completed with a fail finding. The fail count is the leading indicator that the PM program is doing its job: finding conditions that require corrective action before those conditions produce failures. A sustained period of zero or near-zero inspection failures against a fleet with normal age and operating history is a signal to review inspection criteria and recording practices rather than to confirm that the fleet is uniformly in excellent health.

What PCG learned across 31 years of maintenance and reliability system builds: the operations with the highest equipment reliability were not the ones with the most maintenance staff or the largest PM budgets. They were the ones where overdue work was visible and acted on before it accumulated, and where PM inspection outcomes were honest enough to generate corrective work orders at a rate consistent with the age and operating conditions of the fleet.

A maintenance program that records no failures is not necessarily running well. Reliability requires finding problems, not just executing a schedule. These two metrics are the simplest possible measurement of whether the maintenance program is accomplishing both: resolving known problems in time, and finding developing problems before they require resolution under emergency conditions.

What operations see after deployment

Known maintenance problems do not age undetected. The overdue work order count is visible and current at all times. Maintenance managers who see the count growing have the information they need to identify which specific work orders are involved and what is driving the accumulation before it reaches the point where the overdue work orders become a safety or compliance exposure rather than a scheduling lag.
PM inspection quality is measurable rather than assumed. When inspection failure outcomes are tracked and visible alongside completions, the quality of the inspection program can be evaluated over time. An inspection failure rate that is appropriate for the fleet's age and operating conditions confirms the program is finding what it should find. A failure rate that seems implausibly low prompts the investigation that either confirms good fleet health or identifies a problem with inspection rigor.
Reliability conversations with leadership are grounded in current data. When the overdue work order count is visible in real time and inspection outcomes are tracked, the discussion of whether the maintenance program is adequate is based on what the records show rather than on the maintenance team's general sense of how things are going. That is a different kind of conversation, and it produces different decisions about maintenance investment and staffing.
Reactive and preventive maintenance performance are visible together. A single dashboard view that shows overdue work order count alongside PM inspection outcomes gives maintenance managers a simultaneous picture of how the program is performing on both dimensions without switching between separate reports. The relationship between the two metrics often tells the most important part of the reliability story.

Questions maintenance and reliability managers ask before deploying FireFlight

What does the Maintenance and Reliability Metrics Dashboard show in FireFlight?

The dashboard shows two live metrics: Overdue Work Orders, counting all work orders that have passed their due date without reaching a completed status, and PM Inspection Failed and Completed, showing the results of preventive maintenance inspections broken out by pass and fail outcomes. Both update in real time from work order and inspection records.

How does tracking Overdue Work Orders specifically support reliability management?

Overdue work orders are not just a scheduling problem they are a reliability risk. A corrective repair that is 14 days overdue is a known failure that has been operating without resolution for 14 days. For equipment with defined maintenance windows under warranty, safety regulations, or service agreements, an overdue work order may also represent a contractual or regulatory gap. The dashboard surfaces the count and, through the underlying work order records, the specific assets and locations involved so the exposure is addressable rather than estimated.

What does PM Inspection Failed and Completed show in FireFlight?

PM Inspection Failed and Completed shows the outcomes of preventive maintenance inspections: how many were completed successfully and how many recorded a failure finding. The fail count is the leading indicator that separates a PM program that is finding problems from one that is simply executing a schedule. Tracking fail outcomes alongside completions shows whether the PM program is catching problems before they become failures.

How does PM Inspection failure rate signal asset health trends?

A rising PM inspection failure rate across a specific asset class or location signals that the equipment is increasingly not meeting inspection standards at the time of the PM. This may indicate that the PM interval is too long, that a specific component type is reaching end of reliable service life, or that an operational condition is creating accelerated wear. The failure rate trend is an earlier signal than waiting for corrective work orders to accumulate.

How do these two metrics work together as a reliability view?

Overdue Work Orders and PM Inspection Failed and Completed address reliability from two different directions. Overdue Work Orders shows where known problems are not being addressed in time. PM Inspection Failed shows where the preventive program is finding problems before they escalate. An operation with a low overdue count and a stable PM failure rate is managing reliability well in both dimensions. An operation with rising overdue work orders and a rising PM failure rate is accumulating deferred maintenance and finding more problems simultaneously a combination that produces equipment failures.

How does this dashboard connect to Project Work Orders in FireFlight?

Project Work Orders connect individual maintenance and inspection tasks to overarching project structures. When a PM inspection produces a fail finding, the corrective action can be linked to the originating project structure. The Overdue Work Orders metric counts all work orders past their due date regardless of whether they are standalone or project-linked giving the reliability view a complete picture of all open maintenance obligations.

How long does it take to deploy FireFlight maintenance and reliability reporting?

Most operations are running live maintenance and reliability dashboards in weeks, not months. Both metrics read from work order and inspection records that the broader FireFlight deployment captures. PM inspection pass/fail outcomes are recorded at the point of inspection using the maintenance scheduling app, and the results post to the dashboard immediately. PCG handles configuration of inspection outcome categories and due date logic during deployment.

If your current maintenance metrics show total work order volume and PM completion counts without tracking overdue accumulation or inspection failure outcomes, the two signals that most directly measure whether the program is producing reliability rather than just activity are not in your view. FireFlight's Maintenance and Reliability Metrics Dashboard provides both from live records. Configuration takes weeks, not months.

Schedule your free consultation

Allison Woolbert

Principal, Phoenix Consultants Group | Developer, FireFlight Data Systems

phxconsultants.com LinkedIn

Maintenance and Reliability Metrics Dashboard

Projects don’t have to be chaotic.
Stay on top of scope, sequence, and accountability.

Everything you Need All in one Platform

Types and Mix Dashboard

What does the work type mix actually tell operations and finance teams?

Why does tracking Meeting Hours as a separate metric change how teams manage their time?

How does the task count by step type add to what hours alone show?

Your Personal Guide on Every Page

What the three metrics give your team

What operations see after deployment

Questions operations and finance teams ask before deploying FireFlight time tracking

Types & Mix Dashboard

Everything you Need All in one Platform

By Person Dashboard

What does individual-level visibility actually change about team management?

How does this dashboard use Custom Reporting to go beyond standard views?

How does this dashboard relate to the other time tracking dashboards in FireFlight?

Your Personal Guide on Every Page

What the three metrics give your team

What operations see after deployment

Questions operations managers ask before deploying FireFlight

By Person Dashboard

Everything you Need All in one Platform

Trends Dashboard

What does a gap between assigned and completed tasks actually signal?

Why does point-of-work task logging produce better trend data than end-of-day reporting?

How does this dashboard work alongside other time tracking and operations views?

Your Personal Guide on Every Page

What the three metrics give your operation

What operations see after deployment

Questions operations and project teams ask before deploying FireFlight

Trends Dashboard

Everything you Need All in one Platform

Backlog and Flow Dashboard

Why does the aging distribution of open tasks matter more than the total count?

How does WIP relate to the other three metrics as a flow management signal?

How does this dashboard connect to document and knowledge management in FireFlight?

Your Personal Guide on Every Page

What the four metrics give your operation

What operations see after deployment

Questions operations and project teams ask before deploying FireFlight

Backlog & Flow Dashboard

Everything you Need All in one Platform

Volume and Status Dashboard

What do four work order counts actually tell you?

When does this dashboard signal a problem before it becomes visible in the field?

How does this dashboard work alongside the Work Order Efficiency Dashboard?

Your Personal Guide on Every Page

What the four metrics give your operation

What operations see after deployment

Questions operations managers ask before deploying FireFlight

Volume & Status Dashboard

Everything you Need All in one Platform

Work Order Efficiency and Operations Dashboard

What does work order aging actually tell you about your maintenance operation?

How does the WO Closure Rate change what gets discussed in operations reviews?

How does Open WOs by Technician support day-to-day workforce management?

Your Personal Guide on Every Page

The full metric library

What operations see after deployment

Questions maintenance and operations managers ask before deploying FireFlight

Work Order Efficiency & Operations Dashboard

Everything you Need All in one Platform

Preventative Maintenance Management Dashboard

What does PM Compliance Rate actually measure and why does monthly tracking matter?

What does the PMs Lacking Equipment metric catch before it causes a compliance gap?

How do Technician PM Distribution and Top Tasks Assigned by Name support workforce management?

Your Personal Guide on Every Page

The full metric library

What operations see after deployment

Questions maintenance managers ask before deploying FireFlight

Preventative Maintenance Management Dashboard

Everything you Need All in one Platform

Maintenance Usage Dashboard

What does parts consumption by asset class reveal that total consumption cannot?

How do these two metrics connect to the Materials and Parts List catalog?

How does this dashboard connect to inventory and procurement workflows?

Your Personal Guide on Every Page

What the two metrics give your operation

What operations see after deployment

Questions maintenance and procurement teams ask before deploying FireFlight

Maintenance Usage Dashboard