What is going on

An AI application works with what it is given

A language model that proposes a schedule, predicts a fault or summarises a job sheet knows the business only through the systems it is allowed to look into. Where something is missing, it fills the gap with the most likely guess, and that guess looks every bit as confident as an answer that happens to be right. That is what makes messy data so treacherous. No error message appears and no warning light comes on; the advice simply lands slightly wide of reality, and nobody notices until an engineer is standing in front of an installation that looks nothing like what the system described.

What the figures say

The research of the past eighteen months all points the same way. In early 2025 Gartner predicted that, through 2026, organisations will abandon sixty percent of their AI projects where the underlying data is not in order. A year later Harvard Business Review Analytic Services, in a study with Cloudera among more than 230 people involved in AI decisions, reported that only 7 percent consider their data fully ready for AI; more than a quarter say it is barely ready or not ready at all.

For field service the picture is starker still. In a survey by TrueContext and Field Service Next of a hundred service organisations, 6 percent describe their field data as high quality and actually used for analytics and AI. More than half call it adequate but inconsistently recorded, 29 percent find it scattered across several systems and nearly one in ten say it is largely incomplete or unreliable.

One caveat belongs here. Cloudera and TrueContext both sell software for precisely this problem, and a hundred companies is a modest sample. The most telling result therefore comes from a comparison within the same survey. Predictive maintenance alerts are rated very effective by 55 percent of companies; AI that assesses a fault on its own and chooses the next step earns that rating from 8 percent. The difference comes down to fuel. Predictive maintenance runs on readings the installation supplies itself, clean and structured, while the autonomous kind has to make do with whatever people have typed in over the years.

What it means for technical service

One customer, three records

Almost every customer database that has been around for twenty years contains a customer who exists three times: Jansen BV, Jansen B.V. and the Jansen family, all at the same address. One record dates from the previous owner's time, the second appeared when the office did not search hard enough during an emergency callout, and the third belongs to the maintenance contract. For the planner this is a nuisance. For an AI application it is a trap, because it sees three fragments of a single history and concludes that the boiler has never had a fault, while those faults sit quietly on another record. Meanwhile the contract hangs on the wrong name and the invoice goes to an address that has been out of date for years.

A customer database is, in that sense, the most honest archive a service business keeps: it shows in fine detail how the company has worked for the past twenty years.

Installations without a memory

The installation history suffers from something similar, only more quietly. An entry such as "boiler, attic", with no make, model, serial number or year of installation, is enough for an engineer who knows the building. For predictive maintenance it is useless, because a model cannot spot a wear pattern in an appliance when it does not know what the appliance is or how old it is. In practice the largest gaps often turn up in maintenance contracts taken over from others and in installations fitted by another company; that observation rests on experience and has not been measured. The success of predictive maintenance in the survey above has the same flip side. It works where the installation supplies its own data, and falters where its memory lives in a binder or in the head of a single engineer.

The job sheet as a story

The job sheet is where most of it gets lost. TrueContext offers an example any service manager will recognise: "replaced valve assembly, 90 minutes, closed". Behind those words is an engineer who heard something wrong in the first few minutes, ruled out a couple of obvious causes and only then turned to the valve. Ninety minutes of craftsmanship came down to eleven words, typed in the van at the end of the day. An AI application trained on ten years of such job sheets can say what was replaced. Why, and what was ruled out first, remains unknown, because it was never written down.

A stubborn misconception deserves correcting here. Free text is perfectly legible to a language model: from "F28, boiler reset, working again" it extracts a fault code and an action without effort. That undermines the idea that everything must sit in fixed fields before AI can do anything with it. What a language model can never do is reconstruct a serial number nobody noted. The weak spot of the job sheet, then, is what is missing from it. The Bolier case shows how engineers' free text can still end up in a complete service report.

Five steps to get the basics in order

Cleaning up sounds like an endless project, and it becomes one if it starts without direction. Five steps keep it manageable.

1. Start with one application. Decide what AI should deliver first, such as smarter scheduling or less retyping of job sheets, and establish which data that application genuinely needs. The rest can wait (see table 01).
2. Measure before cleaning anything. A sample of fifty job sheets from the past month, checking for each whether the customer, installation, fault code and cause can be traced, gives a more honest picture in an afternoon than any meeting about data quality.
3. Fix it at the source. A few mandatory fields on the job sheet stop the problem from growing. The number is best kept small, because every extra field costs the engineer time, and an engineer who feels audited fills in the bare minimum. TrueContext arrives at the same advice: whoever adds fields has to take typing away elsewhere.
4. Clean up the backlog only where the chosen application needs it. AI can lend a hand here. A language model suggests which customer records belong together and pulls serial numbers and fault codes out of old free text, while the decision stays with a colleague who knows the customers.
5. Appoint an owner. Data without an owner gets messy again sooner or later. Someone in the office or the accounts team who is responsible for customer and installation data, and is given the time for it, is the cheapest investment on this entire list.

Hype, useful, and when

Two persistent stories circulate around data quality, and both are too easy. The first holds that AI will clean up the mess by itself. That is half true. A language model is an excellent aid in tracking down duplicates and sorting old job sheets, but it cannot invent data that was never recorded, and it should not try.

The second story is its mirror image: first a large data programme lasting a couple of years, and only then AI. It sounds responsible, fits neatly into the business model of whoever sells such programmes and keeps a company away for years from the application it set out to build.

What works is the middle road: choose one application, put the data for that application in order and fix the source so the mess does not creep back. We recommend starting there before a single euro goes to an AI vendor. The work pays for itself even if the AI project never materialises, because the planner sees the full history of an address, the invoice reaches the right customer and a new engineer has less to guess.

Cleaning up is the least exciting part of any AI project. It is also the only part that is certain to pay off.