Ask your best technician how many breakdowns he fixed this month. Then open the CMMS. The two numbers have nothing to do with each other. All of that gap is ghost maintenance: real work, done, effective — and invisible.
In the first article of this series, we saw how maintenance KPIs lie when you compute them on dirty data. This one goes after the root cause: if the data is dirty, it is first because a large share of the work never enters it.
Maintenance always disappears in the same three places: the repair too short to bother logging, the know-howthat never leaves the veteran's head, and the close-out data — time, parts, readings — nobody enters. Three silent leaks that, added up, mean you run a plant on half of its reality.
This article diagnoses these 3 blind spots, with the numbers and references to back them, and gives each one a concrete fix you can implement without budget — the only thing that matters being to make capture easier than the workaround.
The repair that never becomes a work order
The gap nobody measures because it exists nowhere
Ghost maintenance = real, done, effective work that is never recorded. Not an isolated oversight: a default mode, because the friction of logging exceeds the length of the repair.
The trap
The best technician walks past a machine, hears a bearing singing, fixes it in five minutes and moves on. Open a work order for that? "I'd be done before I found the right menu." A sensor tweak, a belt retightened, a drive restarted: micro-jobs that never reach the system.
It is not negligence. It is arithmetic: as long as logging costs more than working around it, the workaround wins. And every untracked repair is a line of history the asset will never tell.
The asset "never fails" in the system — while it is nursed daily. Its MTBF is fiction (see article #1), no real failure pattern emerges, and the decision to replace or to improve reliability rests on a history that lies by omission.
How to close the gap (3 actions)
- Mobile logging in seconds. QR-scan the asset at the foot of the machine, photo, voice note — not a twelve-field desktop form. Capture must be faster than not logging at all.
- A request turned into a work order in one tap. An operator flags it, the repair becomes a WO with no re-entry. A quick log from the phone beats the Friday re-entry — which never happens.
- A team rule: "if you touched it, it exists". A twenty-second log beats a perfect report that is never written. You celebrate the trace, not the prose.
The knowledge that lives in one head
The day he leaves, the plant unlearns
Bus factor = the number of people who can disappear before a critical skill is lost. In maintenance it is often 1.
The trap
The veteran knows that pump #7 restarts after tapping the valve, that this fault calls for that remedy, that this press makes this noise before it lets go. None of it is written. Not out of hoarding — out of obviousness: to him it's obvious, so why write it down.
As long as he is here, it runs. The system has no way of knowing that everything rests on one person.
He leaves — and a thirty-minute repair becomes a three-hour one, or the machine stays down. The junior replacing him re-runs the trials the veteran had ruled out ten years ago. The know-how is not passed on: it evaporates.
How to close the gap (3 actions)
- Capture the problem AND the solution on the WO. Not a "fixed OK": symptom → cause → what worked. Two sentences are enough. That is the difference between a logbook and a living archive.
- A searchable fault → solution history per asset. The next person to open pump #7 reads what happened the last five times — instead of starting from scratch.
- A structured summary at close-out. Symptom, cause, remedy, parts: a few fields that feed the machine's history and, in time, let an assistant surface the past solution at the right moment.
Data built on holes
Your numbers are an average of whatever happened to get entered
The ghost close-out: the job is marked "Done", but the time spent, the parts consumed and the meter reading are never entered.
The trap
Time is reconstructed from memory on Friday — or never. The part is grabbed off the shelf with no stock issue. The meter reading is skipped. The "Done" button asks for nothing, so nothing is given: close-out becomes a status, not data.
Each hole is tiny. Added up, they make your numbers describe a different plant than yours.
- Time spent: from memory or never
- Parts: grabbed off the shelf, off-stock
- Meter reading: skipped
- Job cost: unknown
- Time logged at close-out
- Stock issue linked to the WO
- Meter reading entered at the end
- Real cost computed automatically
MTTR, stock level, cost per asset: all become fiction. You cannot budget, justify a headcount or prove a return on investment when half the work never entered. The planned/reactive ratio you present at the monthly review does not describe your plant — it describes your logging rate.
How to close the gap (3 actions)
- Capture at close-out, not after. Time, parts and meter reading in the same action that ends the WO. Entered while fresh, never reconstructed a week later.
- Link the stock issue to the work order. The part leaves stock because it was used on this job — not via a ghost Friday inventory that no longer knows what for.
- Push friction below the workaround threshold. If logging the part is faster than quietly grabbing it off the shelf, the data captures itself. It is the only lever that holds over time.
Recap table — the 3 places your maintenance disappears
Where the work evaporates, the field gap, the fix, the real risk.
| Where work disappears | Field gap | Fix | Real risk |
|---|---|---|---|
| Untracked repair | The "5-minute fix" never turned into a work order | Mobile logging in seconds (QR-scan) + rule "if you touched it, it exists" | Fictional MTBF |
| Tribal knowledge | Problem and solution in one head | Problem AND solution on the WO + searchable fault → solution history | Bus factor = 1 |
| Uncaptured data | Time, parts, meter never entered at close-out | Capture at close-out (time + parts + reading) linked to the WO | Costing impossible |
3 tests to run this week
None of these three blind spots is fixed by new software or a reminder. They are fixed by making capture easier than the workaround and by linking every job to the equipment. Here are three tests you can run this week.
Count the gap
For one day, ask a technician to note everything he touches, even five minutes. Compare it to the number of work orders created that day. The gap is your ghost maintenance.
Test the bus factor
Take your 3 most critical machines. For each, write down who else besides your best technician can fix it without him. An empty column = a risk you can name.
Pull a closed WO at random
Take a work order closed last month. Can you read what was broken and what was done? Or just "Done / fixed OK"? If the WO tells you nothing, neither does your history.
Going further
- ISO 14224:2016 — Collection and exchange of reliability and maintenance data for equipment (the standard exists precisely because uncaptured data makes any reliability analysis impossible)
- SMRP— maintenance productivity metrics ("wrench time", typically 25 to 35% of a technician's time)
- Article #1 of the series — The maintenance KPIs that lie (ghost maintenance is its root cause)
- ISO 55000 — Asset management (know-how as an intangible asset worth preserving)
What if half your maintenance became visible again?
FreeMaint is a freemium CMMS (Core free forever, no user or asset limits). Mobile logging in seconds (QR-scan → work order), capturing the solution on every job, and time + parts + reading at close-out are built for one thing: so the real work stops being a ghost.
Written by Melek Mehrez, founder of FreeMaint. See all articles.
Frequently asked questions
What is ghost maintenance?
Ghost maintenance is all the maintenance work actually performed but never recorded: a five-minute fix done in passing, an adjustment that never becomes a work order, time and parts consumed off-system. It is not an isolated oversight but a default mode: the friction of logging exceeds the length of the job, so nothing gets tracked. The result is a false asset history and downstream KPIs (MTBF, MTTR, cost) that lie.
Why don't my technicians log their work?
In almost every case it is not bad will: it is friction. Creating a work order in a twelve-field desktop form takes longer than the repair itself. As long as logging costs more than working around it, the workaround wins. The answer is not a reminder but mobile logging in seconds — QR-scan the asset, photo, voice note — faster than not logging at all.
What is the bus factor in maintenance?
The bus factor is the number of people who can disappear before a critical skill is lost. In maintenance it is often one: a single technician truly knows how to fix a given machine. When that know-how stays in their head — never written on a work order — their retirement, vacation or resignation turns a thirty-minute repair into a prolonged outage. Reducing it means systematically capturing the problem and the solution on every job.
How do you capture the knowledge of a technician who is retiring?
You don't need a knowledge-management project: it is enough that every job captures the problem AND the solution on the work order, in two sentences — symptom, cause, what worked. Over the months, the per-asset fault-to-solution history becomes searchable by the next technician: they read what happened the last five times on the same machine instead of starting from scratch. The veteran's tacit knowledge gradually becomes the equipment's memory.