Routing tools optimize the sequence before the truck rolls. They rarely measure idle time per technician after the day closes or feed that figure back into the next morning's dispatch logic.
Windshield Time Is the Metric Your Routing Software Collects but Never Acts On
Every routing platform in field service records windshield time. ServiceTitan logs it. Jobber tracks it. Housecall Pro surfaces it in reports. As of 2026, the global field service management software market is valued at more than five billion dollars and growing, and nearly every dollar of that market is built around the same premise: sequence the jobs before the truck rolls, then hand the data back to a human to interpret. What none of those platforms do is feed yesterday's idle time per technician back into this morning's dispatch logic. The number sits in a report. The route goes out unchanged. The same technician crosses the same dead zone on the same day of the week, and the system calls it optimized.
Windshield time is not a reporting problem. It is a dispatch problem wearing a reporting costume. The distinction matters because the fix is not a better dashboard. It is a system that closes the loop between what happened yesterday and what gets assigned tomorrow.
What Routing Software Actually Optimizes
Routing software optimizes sequence, not outcome. It solves for the shortest path between known job locations at the moment the route is built, before the day begins. That is a real and useful calculation. It is also an incomplete one.
The sequence problem is solved at 7 a.m. The idle time problem accumulates from 7 a.m. to 5 p.m. and is never fed back into the next morning's calculation. A technician who spent ninety minutes in transit between jobs three and four yesterday will receive a route tomorrow that was built without that information. The routing engine does not know that job four ran long, that the customer at stop two was not ready, or that the technician sat idle for forty minutes waiting for access at a commercial property. It knows addresses and appointment windows. It optimizes around the map, not around the output.
Why does idle time accumulate even on optimized routes?
Idle time accumulates for reasons that no pre-day routing algorithm can anticipate: jobs that run short, jobs that run long, customers who are not on-site, access delays at commercial properties, and technicians who finish a job in a geography with no nearby follow-on work. Each of these events creates a gap. The gap is logged. The log is never read by the dispatch system. The next day's route is built from the same static inputs as the day before.
According to Geotab's field service research, the average field service technician loses more than 40 percent of the workday to travel, idle time, and scheduling inefficiency. That figure is not a routing failure alone. It is the compounded result of a system that optimizes the sequence and then stops paying attention.
The average field service technician loses more than 40% of the workday to travel, idle time, and scheduling inefficiency. (Geotab, 2025)
Production Value Per Technician Is the Number That Matters
Production value per technician is the metric that windshield time directly erodes. Every hour a technician spends in transit or idle is an hour that cannot be billed. Routing software optimizes around the map. The number that actually matters to an operator or a PE buyer is how much billable output each technician produces per shift, and that number is determined not by the sequence of stops but by the ratio of time-on-site to time-in-transit.
The math is not complicated. A technician running eight hours with 40 percent of that time lost to travel and idle gaps produces roughly 4.8 hours of billable work. Reduce that loss to 25 percent and the same technician produces 6 hours. On a twenty-truck fleet, that difference is the equivalent of adding three to four full-time technicians without hiring anyone. Organizations that systematically close the loop between post-day idle data and next-day dispatch report 30 to 50 percent increases in work completed per technician without meaningful increases in overtime or headcount.
That is not a routing optimization. That is a dispatch intelligence problem. And it requires a system that reads what happened yesterday before it builds what happens tomorrow. See how dispatch without a dispatcher works in practice when the orchestration brain closes that loop automatically.
The variable job cutoff problem routing tools ignore
Variable job cutoff times compound the idle time problem in ways that static routing cannot address. A commercial cleaning job that was scheduled for two hours but completed in ninety minutes creates a forty-five-minute gap before the next appointment window opens. A routing tool that built the day's sequence at 7 a.m. has no mechanism to fill that gap in real time. A dispatcher watching a board might catch it. More often, the technician drives to a staging area, waits, and the gap becomes permanent lost production.
The fix is not a faster dispatcher. It is a system that monitors job completion in real time, identifies the gap as it opens, checks the technician's skill set and current location against the open job queue, and inserts a fill job before the technician has left the previous site. That is a closed-loop dispatch function. It is not a feature that ServiceTitan, Jobber, or Housecall Pro ships as a default behavior. Each of those platforms surfaces the data. None of them act on it autonomously.
The Feedback Loop That Routing Software Breaks
The core failure is architectural. Routing software is built as a planning tool, not a learning system. It takes inputs, produces a sequence, and delivers that sequence to a dispatcher or directly to a technician's mobile app. What happens after the truck rolls is recorded in a separate data layer, often a different module or a different system entirely, and that layer does not talk back to the planning engine.
The result is a one-way information flow. The route goes out. The day's actual performance comes back as a report. The report is reviewed, sometimes, by a manager who may or may not adjust tomorrow's assignments based on what they read. In most operations, the adjustment never happens because the manager is already managing the next day's exceptions. The idle time data ages out without ever influencing a dispatch decision.
This is the second brain problem in its most operational form. The routing tool holds one version of the day. The actual performance data holds another. They never reconcile. Read how the second brain problem shows up across field service operations and why clean data alone never fixes it.
Affinity and region filters: the dispatch logic that compounds density
When idle time data does feed back into dispatch, the first thing a well-designed system does is build affinity filters. A technician who has serviced three properties on the same commercial corridor in the past thirty days has implicit knowledge of access procedures, contact names, and site-specific quirks that a first-visit technician does not. Routing that technician back to that corridor is not just efficient on a map. It is efficient in execution time, in first-time fix rate, and in customer satisfaction.
Region filters work the same way. A technician whose historical idle time is lowest in a specific geographic zone should be preferentially assigned to jobs in that zone. The routing engine does not know this because it does not read historical idle time. It knows the address. The system that closes the loop knows the technician's production value by zone, by job type, and by time of day, and it builds the next day's dispatch from that data rather than from a map.
This is how density compounds. Every serviced job produces data that makes the next assignment in the same area cheaper to execute. The route gets tighter. The idle time shrinks. The production value per technician rises without adding headcount or changing the service area.
What a Closed-Loop Dispatch System Actually Does
The Facility19 control tower is the live proof of what closed-loop dispatch looks like in production. Eight agents run on a single orchestration brain to manage a twenty-truck facility management fleet. Dex, the dispatch agent, does not build a route and hand it off. Dex reads the prior day's completion data, idle time by technician and zone, variable job durations, and open capacity before the first assignment goes out. When a job closes early, Dex identifies the gap, checks the open queue, and fills it before the technician has left the site. Iris, the overtime agent, has already flagged the shift boundary before the technician crosses it. Molly, the checkout agent, knows the job is closing and prepares the invoice before the technician reaches the truck.
The agents share state. The brain routes decisions between a fast-response layer for time-sensitive dispatch and a deliberative layer for compliance and scheduling logic. When Dex is routing a dispatch and Iris is simultaneously evaluating an overtime call on the same truck, the brain knows both are in motion and suppresses the conflict before either agent acts on incomplete information. No double contact. No colliding assignments. Every decision logged and auditable.
This is not a feature set. It is an architecture. The difference between a routing tool that records windshield time and a system that acts on it is the difference between a report and a loop. See the full loop: dispatch, invoice, and collection running as a single system.
The EBITDA Case for Closing the Loop
Operators and PE buyers reading idle time as a routing metric are underpricing the problem. Idle time is a payroll problem. A technician on the clock and not on-site is a fully loaded labor cost producing zero billable output. On a twenty-truck fleet running eight-hour shifts, a 15 percent reduction in idle time per technician recovers roughly 24 technician-hours per day. At a fully loaded labor rate of sixty dollars per hour, that is 1,440 dollars per day in recovered capacity, before a single additional job is booked. Annualized across a 250-day operating year, the number exceeds 360,000 dollars in recovered labor capacity from one fleet.
That recovered capacity does not require new customers. It requires the same customers, the same routes, and a dispatch system that reads yesterday's data before building today's assignments. The EBITDA impact compounds further when the recovered capacity is filled with incremental jobs rather than left as slack. Organizations that implement closed-loop dispatch alongside route optimization report a 5 to 7 percent EBITDA uplift, driven by higher production value per technician, lower overtime, and reduced fuel spend, three metrics moving together rather than one flattering number in isolation.
At a twelve times exit multiple, a 360,000 dollar annual improvement in recovered labor capacity is worth more than four million dollars in enterprise value. That is the number sitting inside the idle time report that no routing tool is acting on.
Frequently Asked Questions
What is windshield time and why does it matter for field service profitability?
Windshield time is the portion of a technician's shift spent driving between jobs rather than performing billable work. It matters because it is a direct drag on production value per technician: every hour in transit is an hour that cannot be invoiced. Operations where windshield time exceeds 35 percent of the workday are leaving significant billable capacity on the table without adding a single new customer.
Why doesn't my routing software fix the idle time problem automatically?
Most routing software is a planning tool, not a learning system. It optimizes the sequence of stops before the day begins and does not read post-day performance data back into the next morning's dispatch logic. The idle time is recorded, but the recording never influences the next route. Closing that loop requires an orchestration layer that sits above the routing engine and feeds actual performance data back into dispatch decisions.
What is production value per technician and how is it different from utilization rate?
Production value per technician measures the total billable output a technician generates per shift, accounting for both the number of jobs completed and the revenue per job. Utilization rate measures the percentage of scheduled hours spent on active tasks. Production value is the more useful number for operators because it captures the revenue consequence of idle time, not just the time consequence.
How does closed-loop dispatch differ from standard route optimization?
Standard route optimization solves for the shortest path between known job locations at the start of the day. Closed-loop dispatch reads what actually happened the previous day, including idle time by technician and zone, variable job durations, and early completions, and uses that data to build the next day's assignments. It also monitors job completion in real time and fills gaps as they open, rather than waiting for a dispatcher to notice them.
Can a twenty-truck fleet realistically run dispatch without a human coordinator?
Yes, and it is running today. The Facility19 control tower operates a twenty-truck facility management fleet with eight agents coordinated by a single orchestration brain. Dex handles dispatch, Iris manages overtime routing, and Molly prepares invoices at job close. The brain enforces shared state so agents never issue conflicting assignments, and every decision is logged for audit. Human oversight handles the hard 20 percent of exceptions; the system runs the rest.
What is the EBITDA impact of reducing idle time on a mid-size fleet?
A 15 percent reduction in idle time on a twenty-truck fleet running eight-hour shifts recovers roughly 24 technician-hours per day. At a fully loaded labor rate of sixty dollars per hour, that is more than 360,000 dollars in recovered annual capacity before any incremental jobs are booked. When that capacity is filled with additional work, organizations report a 5 to 7 percent EBITDA uplift, with lower overtime and reduced fuel spend moving alongside the productivity gain.
The route goes out. The data comes back. The loop closes. That is the difference between a routing tool and a dispatch system.
See the Orchestration Brain Running in Your Operation
See the orchestration brain running in your industry and understand what closed-loop dispatch looks like when it is live in production, not modeled in a pitch deck.
If you operate a fleet and want to walk through exactly how idle time data feeds back into dispatch logic, book a systems walkthrough and see the Facility19 control tower running against a real twenty-truck operation.
