Go into any sector that still runs on engineering — packaging, energy, chemicals, rail, food processing, semiconductors, water treatment — and you will find the same person. Somebody who walks past a machine, stops, and says that is not right.
Not because an alarm fired. Nothing fired. They heard it. Or they felt a change in the rhythm of the line, or noticed the system was cycling half a second slower than it should, or read something in the operating data that nobody had flagged because no threshold had been crossed.
Every experienced service organisation has two or three of them. They are usually the people you call at two in the morning. They are also, almost always, the people closest to retirement.
So the honest question, and the one I want to answer properly rather than rhetorically: can AI replace those individuals?
The answer is more interesting than either camp wants it to be. Yes on one half, decisively no on the other — and the half where AI falls short is precisely the half your customer experiences. That gap is where this becomes a customer experience problem rather than a maintenance one. And it is being made worse right now by a set of management decisions that have quietly made the job unattractive to the very people who might have replaced those engineers.
1. What AI Can Genuinely Hear
Let us give the technology full credit, because it deserves it.
Detecting faults from machine sound is a serious research field with real deployments behind it. The international benchmark that tracks it, the DCASE Challenge, ran its 2026 task on anomalous sound detection for machine condition monitoring. The premise is exactly the human skill described above: sound carries the health of a machine, and a model can learn to tell normal from abnormal.
In controlled conditions these systems perform well. A microphone a sensor, a robot never gets tired, never takes annual leave, and monitors continuously rather than when someone happens to walk past. On that dimension the machine beats the human comfortably, and any service organisation not using condition monitoring is leaving uptime on the table.
But read what the researchers themselves list as unsolved, because it is unusually candid.
Domain shift. Models trained in one acoustic setting degrade when the setting changes — and the setting changes constantly, through different operating conditions, different loads, different ambient noise. Your plant in Bavaria and your customer’s plant in Minneapolis, Tel Aviv, Dubai or Shenzhen are different domains.
Interference. In a real industrial hall, many machines run at once. The signal you want arrives buried in the noise of everything else. The 2026 task specifically added microphones at different distances to try to separate the target machine from its environment. That is a problem being worked on, not a problem solved.
The first-shot problem. Faults are rare, so anomalous recordings are scarce. Recent challenge editions deliberately test whether systems can handle entirely novel machine types with no comparable training data — the exact situation you face when a customer runs a twenty-year-old line that exists nowhere else.
None of this means the technology is weak. It means the technology answers one specific question: has something deviated from normal? That is a binary. It is genuinely valuable. It is also not what your best engineer does.
2. What the Engineer Hears That the Model Cannot
The model detects deviation with cameras and sensors. The engineer assigns meaning. Those are different cognitive acts and only one of them is currently automatable.
When your veteran hears the fault, four things happen almost simultaneously. They recognise the deviation. They classify it against a mental library of every similar noise they have heard across two decades and dozens of installations. They judge urgency — run it until Thursday, or stop the line now. And then they do the thing no model does at all: they decide what to tell the customer standing next to them, knowing that customer’s contract, history, pressure and tolerance for bad news.
Detection is step one of four. We have automated step one and declared the problem handled.
This is why I get uneasy when a board treats condition monitoring as a substitute for capability rather than an input to it. An alert without an interpreter is just a notification. Somebody still has to decide what it means, and that somebody is getting older.
3. Why This Is a CX Problem, Not a Maintenance One
Here is the part most industrial companies still classify wrongly. They file this under operations. It belongs under customer experience, and the evidence is direct.
Analysis presented at the Field Service Forum UK 2026, where service expert Paul Camidge set out the case, makes the point plainly: customer interactions at the point of service often determine renewal decisions, Net Promoter Score, or other metrics more relevant for our time and the perceived value of advanced service offerings.
Read that again as a commercial statement. Your renewal is not decided in the negotiation. It is decided by whoever stood in front of the customer the last three times something went wrong, and whether that person inspired confidence or improvised.
In industrial B2B, the field engineer is not a delivery mechanism for customer experience. The field engineer is the customer experience. Everything else — the portal, the brand, the account management — is packaging around that encounter.
Which means the capability question and the CX question are the same question. And the same research puts between 20% and 40% of engineers retiring within the next decade.
4. Then We Optimised the Job Until Nobody Wanted It
The retirements are demography. What follows is not.
In the UK, engineering apprenticeships have fallen by roughly 40% over the past decade. Unfilled engineering vacancies already run into the tens of thousands, with projections escalating toward hundreds of thousands and, on some estimates, approaching a million by 2030. The retirement wave we could not prevent. The collapse in apprenticeships was a budget decision, taken repeatedly, by people who are now surprised.
Meanwhile we tripled the job. In the mid-1980s a field engineer needed technical skill and the ability to organise their week; anything else the customer asked got redirected to head office. Today the same role is expected to handle contract entitlements, parts logistics, complex service issues resolved alone in front of the customer, and commercial opportunities — with the same analysis concluding that soft skills may now matter more than technical skills. Neither the education system nor corporate training moved to match.
So we now advertise for a unicorn: deep technical expert, plus emotional intelligence, plus commercial awareness, plus composure working alone under pressure. Those traits do not reliably coexist in one person. We merged two roles into one job description and concluded the market was empty.
And then, the part that implicates my own profession. Young workers rank autonomy and flexibility at or near the top of what they want from work. Field service structurally cannot offer remote work — unavoidable. But we then added real-time tracking, route optimisation and dense scheduling algorithms, all defensible on a productivity slide, all capable of making the role feel monitored rather than autonomous.
Think about what that trade actually was. The job’s one remaining compensating benefit was that you ran your own day and owned the outcome. We instrumented it away for a few points of utilisation. Then we were surprised the role stopped appealing to people who value autonomy above almost everything. I have written before, in Below the Waterline, about how the layer beneath the experience decides what surfaces above it. The same logic applies to people. Optimise the visible metric, degrade the invisible one, pay later.
5. What It Already Costs at the Customer
This is not a future risk sitting in an HR deck. The performance spread is measurable now.
Benchmark data compiled by SightCall from the Aquant 2024 Field Service Benchmark Report, the Service Council’s Voice of the Field Service Engineer and Salesforce service research puts organisations in the bottom 20% at nearly four times longer to resolve an issue than leaders, and low performers needing three times more visits per asset. The strongest sectors, including medical devices and food equipment, achieve first-time fix rates between 76% and 87%, which tells you how much room exists below.
Four times the resolution time. Three times the truck rolls. That is not a tooling gap. That is a capability gap, and capability is what training and retention produce.
The same body of work shows how little of the day reaches the customer at all: 81% of service representatives spend excessive time on administrative tasks, 42% of engineers say they receive too much information, 26% name time spent hunting for information as a major frustration, and a quarter say their employer does not make it easy to know which parts a job needs.
Set against that, 86% of decision makers say their field teams are critical to growing the business, and 82% of organisations depend on those mobile workers to upsell.
We call them critical to growth, bury them in admin, hide the parts data, monitor their movements, and then measure them on utilisation.
6. Breaking the Loop
The spiral is simple enough to name. Turnover is high, so training looks like money that walks out after two years, so it gets cut. The role becomes harder and offers less development. More people leave. Turnover rises, which appears to prove that training was wasted. Cut again.
Three interventions, each cheaper than the vacancy it prevents:
Split the unicorn. Stop demanding one person be a deep technical expert and a polished commercial manager. Team-based delivery and differentiated roles are more sustainable and far easier to hire for.
Give back the autonomy you took. If your scheduling system makes an engineer feel surveilled, that is a configuration choice, not a technical necessity. Let people shape their day within constraints rather than receive it fully assembled.
Deploy AI to interpret, not to instruct. A copilot that surfaces a diagnostic pathway and asks the engineer to judge it builds the next veteran. One that returns a finished answer builds dependency. Same tool, opposite outcome in five years.
So — Can AI Replace Them?
My answer, and I will defend it. AI will match and eventually exceed the human ear at detecting that something has changed. It is already close in controlled conditions and improving fast.
It will not, on any timeline I can see, replace the judgement that turns a deviation into a decision, or the credibility of a person who can stand in a plant at two in the morning and tell a customer the truth about their line. That is the part your renewal actually rests on.
Which leaves an uncomfortable conclusion. The technology is not the constraint. The constraint is whether we still produce people capable of using it well — and for fifteen years we have been quietly dismantling the conditions that produced them.
So two questions I would like answered by the people running these operations. How many engineers do you still employ who can diagnose by judgement rather than by lookup, and what is their average age? And would your field team describe your AI tools as something that expanded what they can do, or something that reduced what they are allowed to decide?
Your answer to the second one probably predicts your answer to the first, ten years from now.
👉 Stay ahead of CX, AI, and innovation — Subscribe to my weekly LinkedIn Newsletter “CX Insights by Ricardo S. Gulko.
Share it if it’s useful — and let’s connect for more. Ricardo Saltz Gulko
My columns in several respected CX publications.
- My recent articles on Eglobalis: https://www.eglobalis.com/blog/
- My recent articles on the European CX Organisations ECXO.org : https://ecxo.org/blog/
- My recent articles on CMSWire: https://www.cmswire.com/author/ricardo-saltz-gulko/
- My German articles on CMM360: https://www.cmm360.ch/author/ricardo/
- My old articles on CustomerThink: https://customerthink.com/author/rgulko/








