Covering twelve sites with four engineers

Support across many sites tends to settle into one of two arrangements, both unsatisfactory. Either every site has someone, which is expensive and leaves most of them underused, or everything runs from a central team, and the branches wait days. There is a workable middle, and it is built from routing rather than headcount.

Classify the sites first

Twelve sites are not twelve equivalent problems. Sort them by what a day of degraded IT actually costs:

• Sites where an outage stops revenueA warehouse, a production line, a trading floor, a clinic. These need fast physical response and real local capability.
• Sites where an outage is expensive but tolerable for hoursMost offices.
• Sites where an outage is an inconvenienceSmall offices, mostly mobile staff.

Different arrangements for each is not inequity; it is proportion. The mistake is uniform coverage, which over-serves the third group and under-serves the first.

Build in layers

Remote first, and properly resourced

This closes most tickets at every site. Its quality determines how much travel the rest of the model needs, so under-investing here makes every other layer more expensive.

A local pair of hands

Not an engineer — someone already on site with a key, a cupboard and enough confidence to reseat a cable, read a status light, swap a spare device or let an engineer in. Named, trained for an hour, and given a defined list of things they can do.

This is the highest-value and most underused layer in multi-site support. It resolves a meaningful share of physical tickets in minutes at almost no cost.

A traveling engineer on a circuit

A regular schedule — the northern sites on Tuesday, the southern on Thursday — carrying batched, non-urgent work. Predictability is what makes it efficient: users know a visit is coming and queue their non-urgent requests to it.

Dispatch for the urgent

For the first category of sites and for anything that stops work. This is where a third-party field capability earns its cost, because maintaining your own engineer within reach of every site is exactly the expense you are avoiding.

Route by cost of waiting, not by ticket age

A queue ordered by age sends an engineer to the nearest problem rather than the most expensive one. Routing should weigh what the outage costs, how long a visit takes including travel, and what else is waiting at that site.

One useful discipline: never dispatch for a single ticket at a site where other work is waiting. Check the site’s queue before traveling and clear it in one visit. Travel is the dominant cost and batching is the main lever against it.

Give each site a floor, and publish it

Every site should know what it is entitled to: how it raises a request, how quickly someone will respond remotely, when the scheduled visit is, and what qualifies for dispatch. Published, in plain terms.

Most branch dissatisfaction with central IT is not about the service level but about not knowing what it is — and an unpublished standard is one that can be quietly missed.

Make the remote layer work everywhere

Remote support fails disproportionately at branches, and always for the same reasons: no out-of-band access to the network gear, no remote console on the local server, a VPN that has to be up for the support tool to work, and no record of what is actually installed at that site.

Fixing those four is cheaper than a visit and pays back on the first avoided trip.

Look at the travel, quarterly

Hours traveled per site, per quarter, against tickets resolved. A site consuming disproportionate travel is telling you something — aging hardware, a network problem nobody has diagnosed, a local practice generating faults, or a circuit schedule that does not match its demand. That report usually pays for itself in one change.

We run this model from delivery centers in India with offices abroad, combining remote coverage with scheduled and dispatched attendance. Our infrastructure managed services cover the remote layer and the estate behind it; tell us the shape of your site list and we will map the layers against it.