How to choose a CMMS (without drowning in feature matrices)

What problem you are actually buying a CMMS to solve

You are not buying “software.” You are buying a durable loop: someone reports a stop on an asset, someone owns the repair, parts and history stay attached, and the next shift can see what happened.

Write down the failure modes that hurt today:

• Breakdowns live in chat or verbal handoffs
• PM exists as a binder or sheet nobody updates after a busy week
• Spare parts are guessed at the moment of failure
• Asset history cannot be reconstructed after a bad month
• Adding technicians creates more chaos than coverage

If a vendor demo does not clearly fix those loops, feature matrices will not help. Integrations, dashboards, and AI labels matter only after the floor can claim, start, and complete work on the machine that stopped.

Must-have criteria for manufacturing plants

Score every shortlist against manufacturing reality — not against a generic IT checklist.

Work orders on assets

Every meaningful stop and repair should become a work order tied to an asset. “Shared to-do list” tools without asset history fail at the first shift change.

Preventive maintenance inside production windows

PM that ignores changeovers, sanitation, or weekend windows will be skipped. Ask how due PM becomes owned work with a time box — not just a calendar reminder.

Spare parts linked to assets and jobs

Technicians should see parts context on the asset and on the work order. Catalog beauty without linkage does not shorten MTTR.

Mobile floor adoption

If the crew will not open the app on the floor, you bought a reporting tool for the office. Test claim / start / complete with photos on a phone during the pilot.

Multi-plant visibility without seat panic

When you grow from one facility to three, pricing and permissions should not punish inviting every technician who touches the line.

Reporting that serves weekly decisions

You need overdue PM, open work, and repeat failures — not a dashboard theater that only finance opens once a quarter.

Pricing models: per-user vs per-facility

Per-user pricing taxes growth. Plants with contractors, seasonal coverage, and cross-trained operators quietly under-license — then adoption dies because half the crew is locked out.

Per-facility pricing aligns with how plants actually staff: invite the people who work the line, then measure completion, not seat count.

When you compare quotes, ask:

1. What happens when technician headcount doubles?
2. Are contractors and read-only viewers billed the same as full seats?
3. Is multi-plant pricing additive in a way you can forecast?
4. What is included before professional services start?

A cheaper sticker price with a seat tax often costs more once the floor is fully invited.

Implementation timeline as a selection criterion

Treat go-live speed as a first-class requirement. Most CMMS implementations for mid-sized plants take roughly 2–6 weeks when scope includes asset cleanup, training, and services packages. That is not a moral failure — it is the cost of big-bang rollouts and integration-first projects.

Ask each vendor for a realistic first-facility timeline and what “live” means (real work orders, not just login). Corivo’s guided setup for a first facility typically targets under a day when you focus on critical assets and live work orders, then expand line by line. Use that contrast in your scorecard: weeks of services-heavy rollout vs a guided start you can time-box.

See the companion guide on [CMMS implementation timeline](/guides/cmms-implementation-timeline) for a checklist you can reuse across vendors.

How to run a fair vendor pilot on one line

Demos prove slides. Pilots prove adoption.

1. Pick one critical line with known repeat stops.
2. Import only the assets on that line — not the whole plant register.
3. Invite the actual crew who will use the tool on shift.
4. Run one to two weeks of real work: breakdowns as work orders, due PM converted to owned jobs.
5. Score completion rate, time-to-claim, and whether history is usable for the next shift — not feature checkmarks.

Use the same week and the same crew for every vendor you seriously shortlist. If a vendor refuses a plant-shaped pilot, treat that as a signal.

Red flags in demos and RFPs

• Vapor integrations — “we connect to everything” with no named connector or timeline
• Mandatory professional services just to open the first work order
• Seat surprises buried in the order form after a facility-friendly pitch
• Perfect-data prerequisites that delay go-live until the asset register is “clean”
• Mobile as an afterthought — desktop-first workflows sold as floor tools
• PM that never becomes a work order — reminders without ownership
• Export ambiguity — unclear CSV/API exit if you leave

Push for written answers. Vague “we’ll figure it out in onboarding” is a buying risk.

Decision checklist

Use this before you sign:

• [ ] We named the plant problem (handoffs, PM ownership, history, parts) in one paragraph
• [ ] Must-haves scored: assets, work orders, PM windows, parts, mobile, pricing model
• [ ] Pricing modeled at 2× technician headcount and at multi-facility growth
• [ ] First-facility go-live timeline is written and believable
• [ ] Pilot ran on one line with real technicians for at least one week
• [ ] Completion and adoption beat feature-matrix scores
• [ ] Data export and soft-delete / recovery rules are clear
• [ ] We know what is deferred (integrations, full PM library) until after day-one value

If two vendors both pass, pick the one your technicians will open without a manager standing over them. Floor adoption is the product.