Key takeaways
- A date is a proxy for wear, and a poor one. Usage is the thing that actually degrades equipment.
- Keep three intervals, not one: the manufacturer’s, yours, and the one you actually achieve.
- Since last service and lifetime are different counters answering different questions.
- Knowing a job is due is too late. You need lead time to find a part and a slot.
- Maintenance history belongs beside the machine’s output and downtime — not in a separate register.
Almost every maintenance plan starts as a calendar. Quarterly service, annual inspection, monthly check. It is easy to set up, easy to audit, and it is measuring the wrong thing.
Machines do not wear out because time passed. They wear out because they ran. A calendar treats the press that did three shifts a day all quarter and the one that sat idle waiting for a job as identical — and services them on the same day, which means one of them was serviced too late and the other was serviced for nothing.
The date is a proxy, and you can do better
Calendar intervals persist because they are the only thing a spreadsheet can compute. A spreadsheet does not know how many hours the machine ran, how many cycles it completed or how many metres went through it. So the plan gets written in the only unit the tool understands, and everybody quietly accepts that it is approximate.
The moment you have usage data, the calendar becomes a fallback rather than the rule. And the usage figure that matters is rarely “hours” in general — it is the unit that correlates with wear for that specific equipment. Cycles for a press. Kilometres for a vehicle. Litres for a pump. Impressions, metres, starts, cuts. Getting to choose the unit is most of the value.
The machine that needs servicing is rarely the one whose date came up. It is the one that has been running hardest.
Three intervals, not one
Mature maintenance planning keeps three numbers where most systems keep one, and the gaps between them are where the useful information lives.
The manufacturer’s interval is what the handbook says. It is a starting point and a warranty condition, and it was written for an average duty cycle that is probably not yours.
Your interval is what you have decided to do, based on your environment, your duty cycle and what you have learned. It might be tighter than the manufacturer’s for a machine in a dusty room, or looser for one that is lightly loaded.
The interval you actually achieve is the third, and the one nobody writes down. If your plan says 500 hours and the record says you have averaged 780, then you do not have a 500-hour plan. You have a 780-hour plan with a guilty conscience, and the honest response is either to fix the scheduling or to change the number to something you believe.
Keeping the manufacturer’s figure separately from your own is what makes that conversation possible at all. Overwrite it and you lose the ability to say how far you have drifted, and why.
Since last service, and since new
Two counters, easily conflated, answering genuinely different questions.
Since the last service is what drives the next one. It resets each time the job is done, and it is what tells you the machine is 80% of the way to its next intervention.
Lifetime never resets, and it is what tells you the machine is approaching the end of a component’s design life — or, more usefully at budget time, that this asset has now consumed more service hours than the replacement would have cost. Reset that counter as part of a service and you have destroyed your only evidence for a capital decision.
Watch out for
Counters that a person updates. A usage-based plan whose usage figure is typed in monthly by whoever remembers is a calendar plan with extra steps — and a less honest one, because the number now looks precise. If the equipment can report its own hours or cycles, that is the difference between a usage-based plan and a well-intentioned one.
Due is too late
The other thing a single interval cannot express is warning. Knowing a service is due today is not actionable: the part is not on the shelf, the machine is mid-run, and the technician is at another site. What you need is a second, earlier threshold — a preventive point, some distance ahead of the service point, that exists purely to give you time to arrange it.
How much lead depends on what the job needs, which is why it belongs to the plan rather than being a global setting. A filter change might need a week. Something needing a part with a six-week lead time needs six weeks, and a plan that cannot express that will generate an alert you cannot act on, every time, until people stop reading the alerts.
A service is not one job
Real maintenance is nested. The quarterly service on a machine is not a task, it is a container: check these six things, replace these two, calibrate this one, and record readings for those three. Modelling it as a single line loses the detail, and modelling it as six unrelated reminders loses the fact that they happen together, by one person, in one visit.
A plan that can hold sub-tasks in sequence is a plan somebody can actually follow, and — more importantly — one whose completion means something specific rather than a tick against a heading.
Where the history has to live
Here is the part that decides whether any of it compounds.
Maintenance systems are frequently bought separately, which means the machine exists twice: once in the maintenance register and once in whatever records production, downtime and faults. Both records are called by the same name and neither knows about the other.
The consequence is that the most valuable question you can ask about maintenance becomes unanswerable. Did the failures cluster before the last service or after it? Does the downtime on this machine correlate with how far past its interval it was running? Is the machine we service most also the machine that stops most? Every one of those needs maintenance history and operating history to be facts about the same record.
When they are, maintenance stops being a compliance activity and starts being a feedback loop — the reason to move an interval is evidence rather than instinct.
Where Capitán fits
In Capitán a maintenance plan belongs to a resource, and it is expressed the way this post argues it should be: against counters — a running counter, a counter in a unit you choose, and a lifetime counter — alongside three intervals, the preventive one, the service one and the manufacturer’s. Plans nest, so a quarterly service containing several sub-tasks is modelled as that rather than as unrelated reminders.
The point of putting it in Capitán rather than a standalone maintenance tool is the last section. The resource carrying the maintenance plan is the same resource the shop floor reports against, so a machine’s service history sits beside its output, its downtime and its faults instead of in a separate register that has to be cross-referenced by hand. Work done on it is recorded like any other work, by the same people, in the same place — whether that is a planned service, a callout, or a job on the production floor. The same pattern covers buildings and sites rather than machines through facility management.
If you want to sanity-check your own intervals, the quickest test is the third number: pick five plans and compare what the plan says with what the records show you actually did. We are happy to go through that with you.
The short version
Service on usage, not on dates. Keep the manufacturer’s interval, your interval and your achieved interval as three separate numbers, because the gaps are the information. Never reset the lifetime counter. Give yourself lead time rather than a notification on the day. And keep the maintenance history and the production history on the same record, or you will never be able to prove which interval was right.