The single structural question about any maintenance schedule program is what drives the next due date. Dates are the obvious answer and they are wrong for a large share of equipment, because anything that wears by use reaches its service point at a rate the calendar cannot see. A programme that supports only one driver forces every asset of the other kind into an approximation, and those approximations are where over-servicing and missed services both come from.
Calendar assets and runtime assets, side by side
A building's air handler is due in the spring regardless of how hard it worked. A compressor is due at a number of running hours regardless of the month. Both live on the same site, often in the same room, and a schedule that can express only one of them turns the other into a periodic guess that somebody has to correct by hand every time it drifts.
Getting the readings in without instrumentation
Runtime scheduling does not need connected sensors. Reading the hour meter at each visit and entering it is enough to drive an interval, and it is what most sites actually do. What the schedule needs is a place for the reading and the arithmetic to project the next due point from the trend rather than assuming a constant rate.
The both case, and which one wins
Plenty of assets carry both: service every six months or every five hundred hours, whichever comes first. That is one rule, not two schedules, and a programme that cannot express whichever comes first will have somebody managing the second condition on paper. Ask about it specifically, because it is common and it is often missing. There is a third driver worth knowing about, less common and genuinely useful: condition, where the next service is triggered by a reading rather than by a date or a count. Most schedule programmes cannot express it and most sites do not need it, but if a handful of your assets are monitored it is worth asking whether a reading can move a due date.
Questions people ask about maintenance schedule program
Can a spreadsheet handle runtime scheduling?
It can hold the readings. What it cannot do is move the next due point when a reading is entered, so somebody recalculates, and that is the step that gets skipped when things are busy.
How often should hour meters be read?
At every visit, at minimum, which gives you a rate between visits and lets you project the next due point. More often is better on assets whose duty varies a lot.
What about assets with no meter?
Estimate the duty and use the calendar, then revisit if failures suggest the estimate is wrong. An honest calendar interval beats an invented runtime figure.