Two identical machines, very different wear: service by the calendar or by usage?

Same date, different wear

Take two identical machines. One runs a single shift. The other runs three. Both are serviced on the 1st of every quarter.

On paper, that is fair: same model, same schedule, same date. On the floor, the second machine has run roughly three times as long since the last visit, and its bearings, belts and filters know it.

Why the calendar is everywhere

Calendar-based service is easy to plan, easy to budget and easy to audit. Everyone can see the date, and a missed date is obvious. For safety and statutory checks (pressure vessels, lifting gear, fire systems) it is the right tool, because the rule itself is written in time.

The trouble starts when the same logic is used for parts that wear with use, not with time.

What the drift costs

• The lightly used machine is serviced earlier than it needs. A visit, a technician and some parts, spent on a machine that has hardly worked.
• The heavily used machine is serviced later than it should be. It reaches the date already past the point where the part should have been looked at.
• Nobody notices, until the second one stops. On the calendar everything was on time, so the breakdown looks like bad luck.

A schedule that is always on time can still be wrong about the machine.

Set both: whichever comes first

Many maintenance teams now give a task two limits: a time limit and a usage limit, and the service is due when the first one is reached. The time limit catches the machine that sits idle (oil ages, rubber dries, filters clog even when nothing runs). The usage limit catches the machine that works hard.

Which one is right for a given part is a question for the machine's manual and your own history. The point here is only that one date for everything is a shortcut, not a rule.

Why machine builders feel it most

A machine builder sells one model to ten customers, and it runs in ten different ways: one plant on a single shift, another around the clock, a third seasonally. A service plan written in dates treats all ten alike. The builder either visits too often, which costs money, or too rarely, which costs the customer's trust when a machine stops.

A plan based on real usage lets the builder offer service that follows each customer's actual use. It is also an easier conversation: "this machine has run 400 hours since the last service" (an example) is a fact, not an opinion.

The hard part is the usage number

Usage limits sound simple, and they fail for one reason: where the number comes from. Running hours written in a register or a spreadsheet are only as current as the last time someone updated them. In a busy plant, that is often not recently.

The machine itself knows. Its controller sees every start and stop, so it knows how long it really ran and how many cycles it completed. Counting at the machine removes the typing, the rounding and the gaps.

A short checklist for your own plan

1. List the tasks on your calendar and mark the ones that really depend on wear, not on a rule.
2. For each of those, decide the usage measure: running hours, cycles or parts made.
3. Keep the time limit too, as the second condition, for parts that age while idle.
4. Take the usage number from the machine, not from a register someone updates by hand.
5. Send the reminder to the person who will act on it, in a channel they actually read.

How we handle it in Flowtics

Service reminders in Flowtics, the platform we build at AvestaHQ, work this way: by date or by usage, counted at the machine, and sent to the right person on WhatsApp or email. You choose the date or the usage limit that fits each task.

Whatever you use, the aim is the same: service the machine for the work it has done, not for the date on the calendar.