Headcount Capacity Planning for
Security & Alarm Systems

How to Calculate Headcount Capacity for Security Engineers

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. 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 work 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 isn't linear.

So averaging a dense metro region together with a sparse rural one doesn't give you the average. Instead, it distorts both, understating travel in sparse regions and overstating it in the dense ones.

For an operation with genuinely different regional densities, a single blended area produces roughly 30 to 60% error in modeled travel distance. That sounds bad, but drive time is only 10-25% of total minutes attached to a job.

So the error is reduced by the time it reaches headcount capacity: expect 5 to 12% error in the modeled technician requirement.

It's larger for short-job operations such as inspections, running about 20-40 minute visits, where drive time dominates the job. And it's smaller where jobs take longer.

So the accuracy gain from modeling regions separately is real but modest, and we aren't going to overstate it. The reason this tool insists on multiple regions is different:

Measuring per region is the answer.

If you run 200 technicians you already know your headcount. What you probably don't know is that one region completes 18% fewer jobs per technician per day than another. Or that travel time between jobs eats nearly a third of the working minutes in your worst region and a tenth in your best. That gap is actionable.

Worked Security & Alarm Example

A security and alarms operation running 990 alarm system jobs a day across three regions with 320 engineers. Time on site averages 95 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 70% planned and 30% reactive. 75% of engineers have a general skillset covering 75% of job types, while the remaining specialists cover 25% of the workload.

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

The model requires 292.2 engineers in total, a band of 248 to 336 once the ±15% uncertainty is applied. The operation has 320. 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 6.4% fewer alarm system jobs per engineer per day than Metro, 3.93 against 4.19.
• Travel per job in Regional is 2.31× Metro's, 11.99 minutes against 5.19.
• Travel consumes 11.2% of job time in Regional, against 5.2% in Metro.
• Across the operation, 547.9 engineer-hours a week are spent driving between alarm system jobs.

There are two results worth noting from the example:

• Cutting reactive work from 30% to 15% drops the requirement to about 291.4 engineers.
• Raising jobs share for general engineers from 75% to 95% drops it to about 290.9.

Neither is dramatic on its own. And this is worth knowing before you reorganize a workforce on the promise of large cost-savings.

Finally, the reason for insisting on three regions rather than one:

Modeled as a single blended area of 990 alarm system jobs across 3,804 km², the mean leg distance comes out at 3.29 km, against 2.46 km when the regions are calculated separately. That's 33.4% overstated, and it would have been invisible.

Why a Mixed Engineer Mix 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 isn't D but s×D. Because 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 headcount. It's tempting to average the coverage across all of your technicians and then apply the square root.

That order of operation understates drive time, because 1/√s is a convex function, so the average of the penalties is always larger than the penalty of the average.

Take 75% engineers with a general skillset covering 75% of job types and 25% specialists covering 25%:

Correct:  0.75/√0.75 + 0.25/√0.25  =  0.86603 + 0.50000  =  1.36603
Naive:    s̄ = 0.75(0.75) + 0.25(0.25) = 0.625 ;  1/√0.625  =  1.26491

Doing it correctly gives a travel factor 8.0% higher than the naive blend (1.36603 against 1.26491). Put the other way round:

The naive method understates the travel time penalty by 7.4%.

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 doesn't average out.

It's also why a field operation can add technicians without adding much in terms of job execution:

If the technicians you added are specialists, most of their extra capacity goes into windshield time.

Planned vs Reactive: What the Mix Does to Capacity

Planned work can be batched and clustered geographically, and scheduled into sensible AM/PM windows.

Reactive jobs arrive during the day against a response SLA, and you have to insert them into routes that you've already built.

That costs more. And it costs more than its own share of volume, because inserting an urgent job downgrades the planned route you insert the job 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 adding urgent jobs against a response target.

The second bracket is the disruption to planned routes that's injected when you add reactive work. It's the cost of re-planning the day as it changes. Without it, the model would treat the job share as independent, which isn't 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.

Security & Alarm Headcount 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.

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-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 routing problem. (ServiceTitan, 2026)
• Technician utilization: 70-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 isn't productive. (FieldEdge)
• Windshield time: 20-30% for technicians in cities, 40 to 50% in rural areas. Drive time is a 15-30% productivity tax on most field service businesses. 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. This is 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 don't batch like planned work, and they degrade the planned routes around them. This is why the planned vs reactive mix changes your headcount. (Utility Magazine)
• Fire alarm systems need a minimum of two maintenance visits a year. Every serviced system under BS 5839-1 consumes at least two booked slots annually before any callout, the single biggest recurring-capacity driver in this trade. (BS 5839-1; Fire Alarm Answers)

BS 5839-1 requires a minimum of two maintenance visits a year for most non-domestic fire alarm systems, spaced about six months apart, the single biggest recurring-capacity driver, since every serviced system consumes at least two booked slots a year before any callout. (BS 5839-1; Fire Alarm Answers)

Where your own operation sits against these is what the headcount capacity calculator works out, region by region.

Security and Alarm 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.

Security work splits between quick service visits and installs that consume most of a day, which is why these rows run from 45 minutes to eight hours. Read the row matching your own average job rather than the middle of the table: a routine intruder service sits near the top of it, a fault or false-alarm callout somewhere in the middle, and a CCTV or access-control install near the bottom.

Read across a row and the effect of density is clear: at 30 minutes on site, a rural technician completes about a third fewer alarm system jobs than an urban one purely because of driving. At 120 minutes the same density difference costs only about 12%.

The shorter your alarm system jobs, the more your capacity is really a travel problem.

What Should You Do When One of Your Regions Is Underperforming

There are five levers that you need to consider, in the order that we see most field service operations face them. (Only one of them is software.)

1. Redraw the boundaries of your regions

   The boundaries of your service zone is the largest single input to route density. And this 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 headcount before anyone does anything differently.

2. Train specialist technicians to those with a general skillset

   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. Fire-alarm commissioning and networked-CCTV specialists are usually the narrowest pool on a security and alarms team, so target them first.

3. Move your technician's starting point

   Driving overhead comes off the top of every technician's available minutes before any work happens. In a normal working day it's 35 minutes of a 510-minute shift, about 7%.

   A depot in the right place, or a shift to a route with a home-start where geography permits it, recovers some of that time across the whole region at once.

4. Convert reactive callouts to planned visits

   This is the biggest lever in the model and usually the hardest one to achieve.

   Anything that moves work from a false-alarm or fault callout to a scheduled visit reduces both the direct cost of the reactive job and the disruption it causes to the routes around it.

   Condition-based triggers, better job priority at the point of booking, and a tighter planned-visit cadence all make that shift easier.

   Customer-facing slot booking and selection is another.

5. Start scheduling jobs better

   This model assumes competent but unaided scheduling. This is a reasonable baseline for most field operations, but it isn't the ceiling.

   The gap between that and constraint-aware optimization is real. This is what route optimization software actually addresses.

   Three things in particular:

   1. Road networks
   2. Skills and time windows attached to each job
   3. How current routes and schedules stay accurate as the day unfolds

   Sequencing jobs against the actual road network is the first.

   The second is doing that without a dispatcher holding it all in their head. That means respecting technician skills and time windows automatically, instead of relying on the dispatcher.

   The third is staying accurate as your operations change during the day.

   Re-planning when the day changes, rather than keeping to a plan that was created in the morning. This is what keeps routes and schedules accurate even after lunchtime.

   It's 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.

Recurring BS 5839-1 servicing is exactly the kind of planned load that breaks down as an install base grows; see why PPM scheduling stops scaling past 50 field technicians for where that usually shows up first.

Frequently Asked Questions