Every abortive visit, every job that takes twice as long as it should, every engineer who calls the office from a cabinet — these are information failures. The work is fine. The preparation wasn’t.
Ask any field engineer what the worst part of the job is and they’ll rarely say the work itself. They’ll say arriving at a job that wasn’t properly set up. The wrong address. The missing access code. The service that’s supposed to be copper but turns out to be fibre. The cabinet that the job sheet describes as having a free port when it clearly hasn’t had one for two years.
Each of these failures has the same root cause: information that should have been resolved before the engineer left the depot was left for them to figure out on arrival. That costs time, money and — on a bad day — the job itself.
Here are five things a field engineer should never have to figure out on site and why each one is a system problem rather than a people problem.
1. Which port they’re supposed to connect to
The job sheet says Cabinet 7. It doesn’t say which port. Or it says port 14, but port 14 is occupied and has been for some time. The engineer spends twenty minutes working out the actual available port, or calls the office, or makes a pragmatic decision that may or may not be recorded anywhere.
Port assignment should happen at the point of provisioning, validated against live inventory and confirmed on the job sheet before dispatch. If the port isn’t validated before the engineer leaves, the validation is happening on site, at the worst possible time, at the highest possible cost.
2. Whether the customer is copper or fibre
This sounds basic. It isn’t, on networks that have been migrating for several years. A customer who was on ADSL two years ago and migrated to FTTH eighteen months ago may still have residual copper records in a system that was never fully cleaned up. An engineer dispatched expecting to work on a copper line arrives to find a fibre installation. The job cannot proceed. Everyone’s time is wasted.
The service type at every address should be unambiguous in the job specification. If there’s any uncertainty — if the inventory records are contradictory or incomplete — that uncertainty needs to be resolved before dispatch, not discovered on site.
3. Whether anyone will be home
This one is operational rather than technical, but it accounts for a significant proportion of abortive visits. The appointment was booked. The customer confirmed it. But nobody called to remind them the day before. The engineer rings the bell. No answer. Waits. Calls the number on the job. Voicemail. Leaves.
Automated appointment reminders — sent the day before, with a reply mechanism that flags cancellations back to the scheduling system in time to reallocate the slot — are not a luxury feature. They are basic operational hygiene that pays for itself in avoided abortive visits within weeks of being implemented.
4. What equipment is at the property
A service upgrade job. The engineer needs to know whether the existing ONT can support the new speed tier or whether it needs replacing. The job sheet doesn’t say. The engineer calls the office. The office looks it up. Or doesn’t know. The engineer makes a judgement call. Sometimes it’s right. Sometimes it means a second visit.
The equipment inventory at each customer premises — model, firmware version, serial number, capability — should be on the job sheet as a matter of course for any job where the existing equipment is relevant. This information exists somewhere in the network. Getting it onto the job sheet is an integration problem, not a knowledge problem.
5. Whether the job is part of a wider programme
The engineer is doing what looks like a standard fault resolution job. What the job sheet doesn’t mention is that the address is in a copper withdrawal zone, fibre is being installed on the same street this week and the correct resolution is to flag the address for expedited fibre migration rather than repair the copper fault. The engineer fixes the copper. The customer is happy for three months. Then the copper is withdrawn and they’re unhappy again.
Job context — whether an address is in a withdrawal zone, a capacity upgrade area, a known fault cluster — should be surfaced to the engineer at the point of dispatch. Not as additional paperwork, but as flags on the job that change what “done correctly” means.