Facilities Maintenance Capacity Analysis Tool

How to work out how many field service technicians you need

The common approach is to divide total job hours by total shift hours. That answers a different question, because it assumes a technician spends the whole shift on site. In practice a meaningful share of the day goes on driving between jobs, and how much depends on how densely your work falls, how many of your technicians are qualified to take the job in front of them, and how much of the day is planned rather than reactive.

The calculation runs in seven steps, per region:

1. D = jobs per day ÷ service area, stop density, in jobs per km² per day.
2. d = (k × c) ÷ √D × skill factor × scheduling factor, mean distance between consecutive jobs, in km.
3. travel minutes = (d ÷ v) × 60 + p, driving time plus parking and access.
4. minutes per job = time on site + travel minutes
5. available minutes = shift − breaks − admin − commute overhead
6. jobs per technician per day = available minutes ÷ minutes per job
7. technicians required = (jobs per day ÷ jobs per technician per day) ÷ availability factor

D

Stop density, jobs per square kilometer per day. The single most important input, and the reason a blended service area gives a poor answer.

k

The Beardwood–Halton–Hammersley constant, 0.70. It comes from the approximation that a tour through n points scattered in an area A has length roughly k√(nA). Dividing by n gives mean leg distance as a function of density alone, the area cancels, which is what makes this computable in a browser.

c

Circuity, road distance divided by straight-line distance. 1.25 urban, 1.30 suburban, 1.35 rural.

v

Effective door-to-door speed, in km/h. 28 urban, 40 suburban, 52 rural. These are averages that already absorb stop-start driving, not free-flow speed limits.

p

Park, access and sign-in time, in minutes per job. Default 3.

Skill factor

The penalty for a mixed-skill workforce, because a technician can only be sent to jobs they are qualified for. Explained below.

Scheduling factor

The penalty for reactive work being injected into an otherwise planned day. Explained below.

Availability factor

The share of paid technician time actually available after holiday, sickness, training and on-call recovery. Default 0.82.

Why you can't do this with one blended service area

Mean distance between jobs scales as one over the square root of density. That relationship is non-linear, so averaging a dense metro region together with a sparse rural one does not give you the average of the two, it distorts both, understating travel in the sparse region and overstating it in the dense one.

For an operation with genuinely different regional densities, a single blended area produces roughly 30 to 60% error in modeled travel distance. That sounds fatal, but travel is only 10 to 25% of the minutes attached to a job, so the error is damped by the time it reaches headcount: expect 5 to 12% error in the modeled technician requirement. It is larger for short-job operations such as inspections, metering and 20 to 40 minute visits, where travel dominates the job, and smaller where jobs are long.

So the accuracy gain from modeling regions separately is real but modest, and we are not going to overstate it. The reason this tool insists on multiple regions is different: the per-region breakdown is the answer. If you run 200 technicians you already know your headcount. What you probably do not know is that one region completes 18% fewer jobs per technician per day than another, or that travel eats nearly a third of the working minutes in your worst region and a tenth in your best. That gap is actionable. A total is not.

Worked example

A field service operation running 800 jobs a day across three regions with 225 technicians. Time on site averages 75 minutes everywhere. The working day is a 510-minute shift less 30 minutes of breaks, 25 minutes of admin and 35 minutes of commute overhead, leaving 420 available minutes. Work is 60% planned and 40% reactive. 70% of technicians are generalists covering 75% of job types; the remaining specialists cover 25%.

Those settings give a skill factor of 1.40829 and a scheduling factor of 1.41900, which multiply to a combined travel multiplier of 1.99836 applied to every region's mean leg distance.

The model requires 207.7 technicians in total, a band of 177 to 239 once the ±15% uncertainty is applied. The operation has 225. That sits inside the band, so the honest conclusion is that the headcount is consistent with the model. There is no surplus or shortfall worth asserting.

The useful findings are elsewhere:

• Regional completes 18.5% fewer jobs per technician per day than Metro , 4.01 against 4.92.
• Travel per job in Regional is 2.88× Metro's , 29.69 minutes against 10.31.
• Travel consumes 28.4% of job time in Regional, against 12.1% in Metro.
• Across the operation, 960 technician-hours a week are spent driving between jobs.

Two sensitivities worth noting from the same example. Cutting reactive work from 40% to 20% drops the requirement to about 205.1 technicians. Raising the generalist share from 70% to 90% drops it to about 204.5. Neither is dramatic on its own, which is itself worth knowing before you reorganize a workforce on the promise of a large saving.

Finally, the reason for insisting on three regions rather than one: modeled as a single blended area of 800 jobs across 23,800 km², the mean leg distance comes out at 9.92 km, against a volume-weighted 7.64 km when the regions are calculated separately. That is 29.9% overstated , and it would have been invisible.

Why a mixed skill base costs more travel than you'd expect

If a technician can only perform a fraction s of your job types, then from that technician's point of view the density of eligible work is not D but s×D. Since mean leg distance scales as one over the square root of density, their travel scales as 1/√s.

The trap is what happens when you have a mixed population. It is tempting to average the coverage across your technicians and then apply the square root. That is the wrong order of operations, and it understates travel, because 1/√s is a convex function, so the average of the penalties is always larger than the penalty of the average.

Take 70% generalists covering 75% of job types and 30% specialists covering 25%:

Correct:  0.70/√0.75 + 0.30/√0.25  =  0.80829 + 0.60000  =  1.40829
Naive:    s̄ = 0.70(0.75) + 0.30(0.25) = 0.600 ;  1/√0.600  =  1.29099

Doing it correctly gives a travel factor 9.1% higher than the naive blend (1.40829 against 1.29099). Put the other way round, the naive method understates the travel penalty by 8.3%.

The intuition is worth holding on to: specialists are rare, so the nearest job a specialist is qualified for is disproportionately far away, and that penalty does not average out. It is why an operation can add technicians without adding much throughput: if the technicians added are specialists, most of their extra capacity goes into the windshield.

Planned vs reactive: what the mix does to capacity

Planned work can be batched, clustered geographically and scheduled into sensible AM/PM windows. Reactive jobs arrive during the day against a response SLA and have to be inserted into routes that were already built. The second kind costs more, and it costs more than its own share of the volume, because inserting an emergency job degrades the planned route it was inserted into.

The model handles this in two parts:

scheduling factor = (planned share × 1.15 + reactive share × 1.50)
                    × (1 + 0.25 × reactive share)

The first bracket is the weighted cost of the two kinds of work: 1.15 for planned work with batching and time windows, 1.50 for emergency insertion against a response target. The second bracket is the disruption term, the degradation that injected reactive work causes to the planned routes around it. It is the cost re-planning the day as it changes is meant to recover. Without it, the model would treat the two populations as independent, which is not how a dispatcher's day works.

At the extremes: an entirely planned operation carries a factor of 1.15. An entirely reactive one carries 1.50 × 1.25 = 1.875. The gap between those two is the largest single lever in the model, bigger than skill mix, and bigger than most realistic changes to headcount.

Field service capacity benchmarks: what "normal" looks like

Before you model your own operation, it helps to know the industry baselines. These are the numbers a well-run field service team tends to hit, and the gap between them and where most operations actually sit is what this tool is built to find. Unlike the modeled table below, these are observed figures from published sources.

• Jobs per technician per day: 3 to 5 is standard, up to 7 for short-visit work. The figure is driven almost entirely by time on site and travel, so the shorter the visit, the more the day becomes a travel problem. (ServiceTitan, 2026)
• Technician utilization: 70 to 85% is healthy, below 60% signals real inefficiency. Utilization is billable hours over paid hours, so a technician who spends the afternoon driving is busy but not productive. (FieldEdge)
• Windshield time: 20 to 30% of an urban technician's day, 40 to 50% in rural areas. Driving is a 15 to 30% productivity tax on most field service businesses, and above 35% in a city is a red flag. (Field Service Software, 2026)
• More than half the working day, before optimization. In complex, multi-region field service operations, eLogii commonly observes technicians spending over 50% of the day driving before routes are optimized, consistent with the upper end of published windshield-time ranges, and the single biggest recoverable capacity in most operations. (eLogii field data)
• First-time fix rate: around 80% average, 90% is the target. Every failed first visit is a second trip, pure travel with no new job completed. (CompareSoft, via ServiceTitan)
• Around a third of maintenance work is unplanned. Reactive callouts do not batch like planned work, and they degrade the planned routes around them, which is why the planned-versus-reactive mix changes your headcount, not just your stress levels. (Utility Magazine)

On a facilities contract, the cost of a sparse patch depends almost entirely on visit length: at a 45-minute statutory inspection round a rural engineer completes 25% fewer jobs per day than an urban one, but on a 180-minute plant job the same density difference costs only 9%. It is the compliance-visit end of the portfolio where redrawing a boundary pays. (eLogii analysis)

Where your own operation sits against these is what the analyzer above works out, region by region.

Facilities maintenance benchmarks: jobs per engineer per day

The table below is what this model implies for representative operations at three densities: 0.25 jobs/km²/day (urban), 0.06 (suburban) and 0.007 (rural), with the default working day of 420 available minutes, 60% planned work and a 70/30 generalist split.

These are modeled figures, not observed ones. They are reproducible from the formula above rather than drawn from a survey, and they are here so you can sanity-check your own inputs against the model's own logic. Published industry benchmarks with attributable sources, and eLogii's own figures once the benchmark dataset has volume, will replace this table, we are not going to print numbers we cannot attribute.

Facilities visits skew longer than the cross-industry default, which is why these rows start at 45 minutes and run to half a day. Read the row matching your own average attendance rather than the middle of the table: a statutory inspection sits near the top of it, a reactive callout somewhere in the middle, and plant work near the bottom.

Read across a row and the effect of density is clear: at 30-minute jobs, a rural technician completes about a third fewer jobs than an urban one purely because of driving. At 120-minute jobs the same density difference costs only about 12%. The shorter your jobs, the more your capacity is really a travel problem.

What to do when a region is underperforming

Five levers, in the order most operations should consider them. Only one of them is software.

1. Redraw the boundary

   The largest single input to travel is density, and density is partly a drawing decision. A region that covers a large sparse area plus a dense town is two different operations sharing a manager. Splitting them, or moving the boundary so each region has a coherent density, changes the arithmetic before anyone does anything differently.

2. Cross-train toward generalists

   Because the skill penalty scales as 1/√s, the returns are largest when coverage is worst. Moving a technician from covering 25% of job types to 50% cuts their travel penalty by nearly 30%. The same training applied to someone already at 75% barely moves anything. Target the narrowest specialists first.

3. Move the start point

   Commute overhead comes off the top of every technician's available minutes before any work happens. In the default working day it is 35 minutes of a 510-minute shift, about 7%. A depot in the right place, or a shift to home-start where it suits the geography, recovers some of that across the whole region at once.

4. Convert reactive work to planned

   This is the biggest lever in the model and usually the hardest one commercially. Anything that moves work from an unplanned callout to a scheduled visit, condition-based triggers, better triage at the point of booking, customer-facing slot selection, a tighter planned-visit cadence, reduces both the direct cost of the reactive job and the disruption it causes to the routes around it.

5. Schedule the work better

   This model assumes competent but unaided scheduling. The gap between that and constraint-aware optimization is real, and it is what routing software addresses: sequencing against the actual road network, respecting skills and time windows without a dispatcher holding it in their head, and re-planning when the day changes rather than at 6am. It is the last lever on this list because the four above are usually cheaper, and because software applied to a badly drawn region mostly just optimizes the driving between the wrong jobs.

Frequently asked questions