Maintenance Records: Knowing When a Machine Was Last Serviced
The generator that failed had been serviced twice in four years and nobody could say when. Maintenance is not really an engineering problem in most Kenyan organizations — it is a records problem that only becomes an engineering problem at the worst possible moment.
Every organization that owns equipment has had the same afternoon. Something important stops working, the technician asks when it was last serviced, and four people give three different answers — one from memory, one from a WhatsApp message, and one from an invoice that turns out to be for a different machine.
What that afternoon reveals is not neglect. Somebody almost certainly did service it. The problem is that the servicing produced an invoice and a conversation rather than a record attached to the asset, so the maintenance history exists only as scattered evidence that nobody can assemble under pressure.
Three questions a maintenance record has to answer
Before discussing schedules, intervals or software, it is worth being clear about what you actually need to be able to answer — because these three questions cover almost every situation where maintenance records matter.
| The question | Who asks it | What it needs |
|---|---|---|
| When was this last serviced, and by whom? | A technician, mid-breakdown | A history on the asset, not on an invoice |
| Is this out of service right now, and since when? | Whoever is trying to plan work around it | A status on the asset that changes when it leaves |
| What have we spent on this machine in three years? | Whoever decides to repair or replace | Costs traceable to the asset, not to a repairs account |
The third one is the expensive question. Organizations replace equipment on feel — "this one is always broken" — and keep other equipment far too long, because nobody has ever added up what a machine costs to keep alive. A generator absorbing more than its replacement value in repairs over four years is not unusual and is almost never noticed.
Maintenance as a movement, not a note
The conceptual shift that makes this work is to treat a trip to the workshop the same way you treat any other custody event. The asset left. Somebody has it. It is expected back. That is exactly the structure a register already uses for a laptop issued to an employee, and applying it to maintenance costs nothing.
In AWRA OpsHub, sending an asset for maintenance and receiving it back are recorded movements in their own right, sitting in the same history as assignments, transfers and verifications. The asset carries a maintenance status while it is out, so the register does not quietly claim it is available on site.
-
Record it leaving, at the moment it leaves
Not when the invoice arrives three weeks later. A movement recorded late is indistinguishable from one that never happened, and the gap in the history is exactly the period somebody will later ask about.
-
Name who has it
The workshop, the technician, the supplier. An asset in maintenance is an asset in somebody else's custody, and "at the garage" is not a custodian.
-
Note what it went for
One line. "Service — 250 hours" reads completely differently from "would not start" when you look back at the pattern six months later.
-
Record the return, and the condition
The return is the half everyone forgets, because by then the crisis is over. An asset that never comes back on the register stays in maintenance forever and pollutes every availability report you run.
The return is the half everyone forgets. By the time the machine is back, the crisis is over and nobody feels the need to write anything down — which is how a register ends up showing three items permanently at the workshop.
Preventive versus reactive, honestly
Preventive maintenance is obviously correct and almost universally under-practised, and the reason is not ignorance. It is that reactive maintenance schedules itself — the machine breaks and demands attention — while preventive maintenance competes with everything else for a slot that nobody is forcing.
Reactive only
- Work is scheduled by failure, always at a bad time
- Downtime is unplanned and usually longest when busiest
- Costs arrive as emergencies, at emergency rates
- The decision to replace is made in a panic
- Nobody knows a machine is failing until it has
A modest preventive rhythm
- Work happens in slow weeks, chosen by you
- Downtime is planned around production, not against it
- Costs are predictable enough to budget
- Replacement is decided from a cost history
- Deterioration shows up as rising frequency, in the record
Where our register stops — read this before designing a schedule
There is no preventive-maintenance scheduler. The register records maintenance events, statuses and history; it does not hold a service interval per asset and will not remind you that a machine is due at 500 hours. Warranty expiry is a date on the asset, and custody returns can be chased, but the servicing calendar itself is yours to run. We would rather say that plainly than let you buy expecting a scheduler.
The practical consequence: keep the schedule where you keep other recurring obligations — a shared calendar, a standing monthly agenda item, or a scheduled report you read on the first Monday. The register's job is to tell you truthfully what happened and when. Deciding what should happen next remains a human rhythm.
The pattern worth watching
Once movements are being recorded properly, one pattern pays for the whole discipline: rising frequency. A machine that went to the workshop twice in its first two years and four times in the last eight months is telling you something, and it is telling you before the failure that will actually hurt.
The repair-or-replace conversation, with numbers
Illustrative, in KES. Note which number decides it. The repair spend is arguable — 780,000 against a 2.4 million asset can be defended. Forty-one days without a delivery vehicle usually cannot, and it is invisible unless somebody records when the asset left and when it came back.
What we do and do not do
What AWRA OpsHub does today
- Maintenance as recorded movements — sent to maintenance and returned from maintenance sit in the asset's movement history alongside assignments, transfers and verifications.
- A maintenance status on the asset, so availability reporting reflects what is actually on site.
- Damaged and lost as their own recorded outcomes, distinct from a routine service trip.
- Custody with named holders, expected return dates and return reminders you can configure.
- Warranty expiry held as a date on the asset record.
- Barcode and QR labelling, with movements capturable by scan and optional GPS capture on checkout, check-in, transfer and verification.
What it does not do
- No preventive-maintenance scheduler. There is no service interval per asset and no "due for service" reminder based on time or usage.
- No meter or hours tracking. Engine hours, kilometres and print counts are not fields the register maintains.
- No work orders or parts consumption. A maintenance trip is a movement, not a job card with labour and spares against it.
- No automatic cost roll-up per asset. Repair invoices live in purchasing and expenses; tying spend to a specific asset is a coding discipline you enforce, not a total the register computes.
The last gap is worth solving with a convention rather than a feature: put the asset code in the reference on every repair invoice and expense. It takes seconds, and it is what makes the repair-or-replace conversation above possible at all.
Start smaller than you think
Organizations attempting maintenance discipline usually begin by trying to schedule everything, which collapses within two months. The version that survives is narrower: pick the assets whose failure actually stops work — the generator, the delivery vehicles, the cold room, the two machines the whole line depends on — and record movements religiously for those alone.
Ten assets recorded properly will tell you more than four hundred recorded intermittently, and the habit spreads outward from something that visibly worked. The broader discipline of custody and verification is covered in asset tracking in Kenya.
Our take
Record the leaving and the returning as movements, name who has the asset, and put the asset code on every repair invoice. Do it for the ten assets whose failure stops work. Keep the service calendar somewhere that reminds you, because the register will not — and within two quarters you will be able to answer the repair-or-replace question with numbers instead of feelings.
See asset tracking in AWRA OpsHub
A register with named custody, recorded movements including maintenance, scannable labels, verification history and configurable return reminders.
Explore asset trackingFrequently asked questions
Does the system remind us when an asset is due for service?
No. There is no preventive-maintenance scheduler, no service interval per asset and no usage-based reminder — that is the clearest limit in this area and worth knowing before you design a process around it. What the register does hold is warranty expiry dates and configurable custody-return reminders, and what it records faithfully is every maintenance event that happened. Keep the service calendar in whatever tool already reminds your team about recurring obligations.
How do we track what a machine has cost us in repairs?
By convention rather than by feature: put the asset code in the reference on every repair invoice, purchase order and expense claim relating to it. There is no automatic roll-up of spend per asset, so the discipline is what makes the number available later. It takes a few seconds per document and it is the only way the repair-or-replace decision ever gets made on evidence.
Should maintenance really be recorded as a movement?
Yes, and it solves two problems at once. Custody is genuinely transferring — the workshop has your asset — so recording it keeps the register honest about what is actually on site, and it puts the maintenance history in the same timeline as everything else that happened to that asset. The alternative, a separate maintenance log, ends up incomplete because it is a second place to remember to write things.
What about small tools and equipment that go missing rather than break?
Those are a custody problem rather than a maintenance one, and the register handles them differently: pooled quantities for consumable-like items, named custody for anything individually valuable, and periodic verification to establish that what the register claims is still true. Marking something lost or damaged is a recorded outcome in its own right, which matters — an asset quietly deleted from a register is the pattern auditors look for.
Is it worth doing this for every asset we own?
No, and attempting it is the most common reason these programmes fail. Start with the assets whose failure stops work — usually between five and twenty items in a mid-sized organization — and record those movements without exception. Ten assets tracked properly produce better decisions than four hundred tracked intermittently, and the habit is far more likely to survive its first busy month.
