Why maintenance costs rise without anyone deciding to spend more

Take one air conditioning unit in one building. Call it 4B. Over five months it fails three times. Each time, a tenant reports it, a technician attends, a part gets fitted, an invoice arrives, and the job is closed. Nothing about any of those three events is handled badly. The response times were fine. The technician was competent. The invoices were correct and paid.

And yet the right decision was almost certainly to replace that unit after the second failure. Nobody made the wrong call. Nobody made the call at all, because nobody was in a position to.

Five people, five true things

Here's who knew what.

The tenant knew the unit had failed again, and told someone on WhatsApp, because that's how they've always reported things and it works.

The technician knew this was the third time, because he attended all three. That knowledge lives in his head. He didn't escalate it, because his job is to fix the unit and he fixed the unit.

Finance knew three invoices had been paid to that contractor. They did not know the three were the same unit, because the invoices reference a job number and the job numbers don't tell you anything.

Admin knew the tenancy on that flat expires soon, which matters because a vacancy is the cheap window to replace a unit and an occupied flat is not.

Management knew the building was getting more expensive, because they can see the total. They did not know why, and the total is the one number from which the cause cannot be recovered.

The sentence nobody holds is this: AC unit 4B in Building A has failed three times in five months, affecting the tenant in a flat whose contract expires in six weeks, at a cumulative cost approaching the price of replacement, from a contractor whose callback rate on this asset class is worse than average.

Every fact in that sentence already exists inside the business. Not one of them is missing. They're distributed across a WhatsApp thread, a technician's memory, an accounting system, a tenancy file and a management report, and the distribution is the entire problem.

Why this is not a discipline problem

The tempting diagnosis is that people should communicate better. Get the tenant to use the proper channel. Get the technician to flag repeat visits. Get finance to code invoices against assets. Have a monthly meeting where this surfaces.

Try it and you'll find it works for about a quarter. It fails for a structural reason rather than a motivational one: you're asking five people to each carry a piece of a correlation that none of them can complete. The technician who flags a repeat visit has done his part, and his flag lands in a system that doesn't know the cost or the tenancy. He gets no feedback, sees no consequence, and reasonably concludes the flagging was pointless. Within two months he stops.

This is the same shape as the twelve unassigned jobs. Noticing that unit 4B has become a replacement question rather than a repair question is job one, five and ten on that list: noticing, interpreting, and identifying risk from a pattern. It's unassigned. So it happens only when a conscientious person happens to hold enough of the picture at once, which is rare and getting rarer as the portfolio grows.

The three ways cost actually drifts

Once you look for it, the same mechanism produces cost increases in three distinct ways, and none of them are visible in a total.

Repair instead of replace. The unit 4B case. Individually cheap decisions that collectively cost more than the expensive decision would have. This is the most common and the easiest to catch, because it only needs a count.

Contractor drift. One contractor's work generates more callbacks than another's. Their invoice per job might even be lower, which is why they keep getting the work. The true cost is invoice plus callback plus tenant goodwill, and nobody computes it, so the cheaper contractor is quietly the more expensive one for years.

Silent capacity loss. The team is busier every year and nobody can say why, so eventually someone hires. But the increase in workload may be concentrated in two buildings with ageing plant, in which case another technician treats the symptom permanently. Hiring is the most expensive possible response to a diagnosable problem, and it's the default response when the diagnosis isn't available.

What has to be true to fix it

The fix isn't a better report. Reports are the wrong tool because they're periodic and aggregated, and this problem is continuous and specific.

What's needed is one connected model of the operation, where a job knows which asset it was for, an asset knows which unit it's in, a unit knows which tenancy occupies it, a tenancy knows when it ends, and every cost attaches to the thing that caused it. Once those relationships exist in one place, the third failure of unit 4B isn't something somebody has to notice. It's a count that already exists, and the system can raise it the moment it happens.

That's a boring requirement and it's the whole thing. Not artificial intelligence, not predictive maintenance, not a nicer dashboard. A model of the business that's connected rather than filed, and something watching it that doesn't get busy.

The intelligence comes later and it comes for free, in a sense, because once a year or two of properly connected operating history exists the interesting questions become answerable with arithmetic. Which properties are becoming inefficient. Which contractor creates rework. Which assets to replace on schedule instead of on failure. Where you're actually understaffed as opposed to where it feels busy.

Why this is specific to property

One last point, and it's an argument for narrow software rather than broad software.

Nothing above works if the system doesn't know what a tenancy is. A generic work order tool can hold "Task 214, open, medium priority" perfectly well and will never produce the sentence about unit 4B, because it has no concept of an asset that lives inside a unit that's occupied under a contract that expires. Those aren't custom fields. They're the actual objects of the business, and the relationships between them are where every useful conclusion lives.

Which means the software has to be built for property specifically, and can't be pointed at a logistics firm next quarter. That's a limitation, and it's the reason it can say anything at all.