Diagnostics in the technician’s hand

The hardest problem in field service is not scheduling. It is that the knowledge required to fix a machine is unevenly distributed, and it is almost never standing next to the machine.

The senior technician who has seen this fault before is on another site. The manual is a PDF nobody can navigate one-handed. The manufacturer's bulletin exists and the person who needs it does not know it exists. So the technician calls a colleague, or guesses, or books a second visit — and second visits cost roughly what first visits do while earning nothing.

What the technician actually has

Start from the evidence available at the point of failure, because it is more than people assume:

A fault code — the machine's own account of what it thinks is wrong.
Symptoms — what it sounds like, when it happens, what changed.
A view of the equipment — which a camera can capture better than a person can describe.
Diagnostic data — readings, logs, or a dump from a connected unit.
History — what was done to this asset last time, which the platform already holds.

Each is a fragment. The reason diagnosis is hard in the field is that nobody assembles them.

Assembling them into an answer

A diagnostic agent on the technician's phone takes the fragments as they arrive and works the way a good senior colleague does — narrowing rather than announcing.

The technician describes the fault or enters the code. The agent asks the discriminating question: does it happen from cold, or only under load? A photograph resolves what a description cannot — which variant is installed, whether the connector is the older type, whether there is visible damage the technician has stopped noticing because they have seen it all week. Diagnostic readings are ingested rather than retyped.

What comes back is a sequence, not a verdict: check this, then that, and if the second reading is out of range the cause is here. Where a procedure is easier shown than written, reference video plays inline. Each step confirms before the next, so the agent knows where the technician is rather than assuming they followed all of it.

Three design principles hold this together.

Ask before answering. A diagnostic that produces its most confident guess from one symptom is a search engine. The value is in the second and third question.

Show the reasoning. "Replace the sensor" is unverifiable. "The code indicates a circuit fault; the reading you took rules out the harness; therefore the sensor" can be checked by the person holding the meter — who is the last line of defence against a confident wrong answer.

Write it back. The diagnosis, the steps followed and the outcome belong on the job card and the asset history. The second visit to the same machine should start from what happened on the first.

The site where none of this is allowed

Now the constraint that breaks most mobile-first thinking.

In a great many of the places field service actually happens — refineries, pharmaceutical clean rooms, defence facilities, mines, secure manufacturing floors — cameras and phones are prohibited. The technician walks through a gate and leaves the device in a locker. Every assumption behind a mobile diagnostic agent is void.

What survives that gate is remarkably old technology: a telephone. There is usually a landline, or a site handset, or a phone just outside the restricted area.

So the same diagnostic capability answers an ordinary phone call. The technician dials, describes the fault and the code, and gets the same narrowing questions and the same step-by-step guidance spoken back — paced for someone with their hands inside a machine, repeating on request, waiting for a reading rather than talking over it.

Two things make this a genuine capability rather than a demo. It runs on the same telephony rails as the rest of the platform, so the call is routed, recorded and linked to a record like any other call — the guidance ends up on the job card even though no phone was present at the work. And it operates under a bounded identity with the same permissions model as everything else, rather than being an unaccountable voice on a line.

The interface constraint is real and worth respecting: voice-only means no diagrams and no video, so the guidance has to be genuinely linear and the agent has to be comfortable with silence while someone takes a reading. That is a different conversational design from a chat window, not the same one read aloud.

What this changes operationally

The measurable target is first-time fix rate, and it moves for a specific reason: most second visits are caused by diagnosis, not by parts availability. A technician who identifies the right fault while still on site either fixes it or orders the right part — instead of ordering a plausible part and returning to discover it was not that.

The second effect is slower and larger. Every diagnosis written back to the asset builds a history of what actually fails on this equipment, in this environment, at this age. That is the raw material for maintenance intervals that reflect reality rather than the manual — and it accumulates only if the diagnosis is captured, which is the part that has historically been lost.

What we are careful about

Guidance is assistive. It does not replace a qualified technician's judgement or a manufacturer's authorised procedure, and it should never be presented as doing so. Where a manufacturer procedure exists, it governs.

Confident wrong answers are the failure mode. A diagnostic that hedges everything is useless; one that never hedges is dangerous. Showing the reasoning, and stating when evidence is insufficient, is the only honest middle.

Safety-critical work has a floor. Some procedures require certification, isolation and sign-off. An agent's job there is to help someone qualified work faster, never to help someone unqualified attempt it.

What I would tell another design team

Design for the constrained site first, not last. The mobile-first version is easier and it is the one that fails at the gate — and if the phone-only path is an afterthought, it will be a menu tree rather than a conversation.

Then make the agent ask questions. The instinct is to build something that answers, because answering demonstrates capability. What a technician standing in front of a stopped machine actually needs is someone who narrows it down with them.