How to Build Preventive Maintenance Schedules That Actually Get Done

Most PM programs slip within 90 days. The fix usually isn't more discipline — it's picking the right trigger model up front and removing friction at the point of work.

The pattern almost every maintenance manager has lived

You inherit (or build) a preventive maintenance program. The spreadsheet is detailed. Every asset has a PM cadence. Every technician has assignments. The first month goes well. PM compliance sits around 90%.

By month three, compliance has drifted to 70%. Some PMs are getting done — the easy ones, the ones near other work, the ones the technicians remember. Others are quietly slipping. Nobody's catching it because the dashboard hasn't been updated in three weeks.

By month six, the program is more theatre than execution. The PMs that didn't get done aren't getting caught up — they're just absorbed into the new month's load, where they'll slip again. The audit shows up and you scramble.

This pattern repeats so consistently across operations that it's worth treating as a design problem, not a discipline problem. PM programs don't fail because technicians are lazy. They fail because of decisions made — or skipped — at the design stage.

Decision 1: pick the right trigger type for each asset

The most common reason PMs slip is that the trigger doesn't match the asset's actual failure pattern. There are three trigger types, and each fits a specific class of equipment.

Calendar-based triggers

The PM is due every N days regardless of actual usage. Daily, weekly, monthly, quarterly, annual.

Works well for:

• Equipment with relatively consistent duty cycles
• Regulatory inspections with mandated frequencies (fire safety, pest control)
• Time-degrading components (lubricants, gaskets, seals)
• Building infrastructure that operates continuously

Fails for:

• Equipment with highly variable usage (forklifts during peak vs off-season)
• Spare or standby equipment that sits idle most of the time
• Anything where wear is dominated by cycle count, not elapsed time

Runtime-based triggers

The PM is due after N hours of operation, N cycles, N miles, or some other usage metric. This requires runtime tracking — either via the equipment itself, an integrated system, or manual operator entry.

Works well for:

• Forklifts and other mobile equipment (hour meters track operating time)
• Conveyor and sortation systems with cycle counters
• Pumps, motors, and compressors with runtime instrumentation
• Vehicles (mileage-based)

Fails for:

• Equipment without reliable runtime measurement
• Assets where elapsed time matters more than usage (rubber seals dry-rotting in storage)
• Operations where you can't trust manual hour-meter logging

Condition-based triggers

The PM is triggered when a measured condition crosses a threshold. Temperature drift, vibration increase, current draw rising, differential pressure climbing. Requires sensors and integration.

Works well for:

• Critical equipment where failure has high consequences (refrigeration, fire suppression)
• Equipment with characteristic degradation signatures (bearings, motors, compressors)
• Operations with environmental monitoring already in place

Fails for:

• Equipment without sensor instrumentation (and the sensors aren't cheap)
• Failure modes that don't have early warning signals (sudden bearing failures)
• Programs without the analytical capability to act on sensor data

How to pick

For most distribution operations, the right pattern is a mix:

• Calendar-based for regulatory inspections and building infrastructure
• Runtime-based for lift trucks and mobile equipment
• Condition-based for refrigeration (paired with your environmental monitoring)

Most CMMS tools support all three. What separates them is how easy it is to actually configure runtime tracking and condition triggers — many systems claim support but require extensive manual setup that nobody ever finishes.

Decision 2: cadence has to match maintenance reality, not warranty docs

A common mistake: pulling PM frequencies straight from manufacturer documentation. The manufacturer's recommended cadence is usually conservative — it covers the worst-case operating environment to protect their warranty exposure. In a normal operation, that cadence is often overkill.

Two failure modes:

• Too frequent: Technicians lose faith in the program. "We did this last week" becomes a refrain. PMs get pencil-whipped.
• Too infrequent: Equipment fails between PMs. The program isn't catching real issues. Trust evaporates from the other direction.

The right cadence usually emerges from history. Start with manufacturer recommendations, then adjust based on what you actually find when you do the inspections. If you've done six quarterly inspections and never found anything actionable, the cadence is too tight. If you keep finding issues that have clearly been developing for weeks, it's too loose.

This argues for a CMMS that lets you adjust cadences easily, and that captures findings during PM completion (not just "yes I did it") so you can see whether the program is producing real value.

Decision 3: every PM needs a checklist, not just a name

A PM that says "Quarterly inspection — Cooler 3" leaves everything to the technician's memory. Different technicians do different inspections. Some skip steps. Some add steps. Documentation is inconsistent.

A PM with a structured checklist eliminates that variability:

• Each step is named explicitly
• Each step has a pass/fail or measurement field
• Failed steps trigger follow-up actions automatically
• Photo capture for specific items (gaskets, condenser coils, gauge readings)
• Notes field for anything outside the checklist

Checklists also make new-technician onboarding dramatically easier. A new tech can do a PM they've never done before if the checklist is good. Without one, every new asset is a teaching session.

Decision 4: completion has to be mobile, fast, and at the equipment

This is the biggest single execution lever. The same PM is dramatically more likely to get done if the technician can complete it from their phone at the equipment, versus having to log it at a desk later.

The friction at "log it later" is real:

• Technician finishes the work, walks back to the office, finds something else demanding attention
• By end of shift, the PM hasn't been logged
• The next day, details are fuzzy ("did I check the gasket or not?")
• The log entry gets vaguer over time, or skipped entirely

Mobile completion at the asset means:

• QR code on the asset opens the right PM directly
• Checklist completion happens as the work is done
• Photos captured at the point of inspection, not from memory
• Signature captured before walking away
• The record is complete before the technician moves to the next task

Decision 5: visibility, not discipline, is what saves slipping programs

Most slipping PM programs don't lack discipline. They lack visibility. By the time anyone notices PMs are slipping, weeks have passed. The recovery cost is high — a backlog accumulates faster than it gets worked down.

Visibility means three things, in order of importance:

1. A real-time dashboard that shows current compliance percentage. Not a report you have to run; a number you see daily.
2. Alerts that fire when something is overdue. Routed to the right person, not buried in a notifications inbox.
3. A 7-day forward view that shows what's coming. So PMs don't surprise anyone.

These three elements together make slipping visible at the moment it starts, not weeks after. That's the difference between a program that recovers easily and a program that quietly fails.

The harder question: what about PMs that never should have existed?

Most operations carry PMs that aren't actually useful — inherited from previous managers, copied from manufacturer docs that don't fit the operation, added in response to a single failure event from years ago.

Annually, it's worth reviewing the PM program against actual failure data:

• Which failures did the PM program prevent or catch early? (Look at PM completion records with findings.)
• Which failures happened anyway, between scheduled PMs?
• Which PMs have produced zero findings in 12+ months?

PMs that consistently find nothing are candidates for either reduced cadence or elimination. PMs that didn't prevent the failures they should have are candidates for redesign — different cadence, different checklist, different trigger type.

This is the work that separates a maintenance program from a maintenance ritual.

What QMS Pro CMMS does about all this

QMS Pro CMMS is structured around these decisions:

• Calendar, runtime, and condition-based PM triggers (the last one tied directly to environmental sensors)
• Checklist support on every PM with photo and signature capture
• QR code on every asset for direct mobile PM completion
• Real-time compliance dashboard with overdue alerts
• 7-day forward view on the operations dashboard
• Findings recorded against PMs, so you can see whether the program is producing real value
• Failed checklist items auto-route to Smart Alerts and can generate non-conformances when appropriate

Explore QMS Pro CMMS Why a standalone CMMS isn't enough