CMMS Software Compared: How to Shortlist

Almost every CMMS selection I am asked to rescue failed at the longlist, not at the demo or the implementation. Someone searched for maintenance management software, collected fourteen names, booked eleven demos, and by demo six had lost the ability to tell the products apart. Every one showed a work order screen, a PM calendar, a mobile app and a dashboard. They all looked fine. So the decision got made on rapport with the salesperson, or on the lowest quoted number, and eighteen months later the organisation was back in the market. The fix is a disciplined funnel that gets you from forty-plus products to three before you sit through a single presentation.

The message up front: the shortlist is the decision. By the time three products sit in front of you, most of the outcome is determined, because you have already chosen a market tier, a deployment model and an integration posture. Spend your effort on the elimination, not the beauty contest. Write the must-have list before you look at any product, use market tiers to check you are shopping in the right league, use hard filters to cut the field to eight or ten, then use reference calls and one scripted demo on your own data to reach three.

1. Which article you are in, and which you probably also want

This cluster has several pieces that look similar from the outside, so let me be blunt about the division of labour. This article is the funnel only: how to get from a market of forty-plus CMMS programs down to three you will evaluate properly. It deliberately does not rank vendors and deliberately does not score them.

• You want named vendors ranked and characterised. That is the CMMS buyer shortlist. Read it after you have finished the filtering here, because reading it first tempts you to fit your requirements to a product you already like.
• You have your final three and need to choose between them. That is the weighted scoring framework. There is no scorecard here on purpose; building one before you have a shortlist is how organisations end up scoring products they should never have longlisted.
• You care about preventive maintenance capability depth. That is how to choose preventive maintenance software, function by function through PM scheduling, meters, routes and compliance.
• You are not yet sure a CMMS is the right category. Start with CAFM vs CMMS vs EAM vs IWMS and what a CMMS actually is. Choosing the wrong category is more expensive than choosing the wrong product inside the right one.

I am assuming you have settled on maintenance management software as the category and now face the market. That market is genuinely crowded, and the crowding is not an illusion created by review sites. Narrowing it is a skill.

2. Write the must-have list before you look at any product

This is the most important sequencing rule in the process and it is broken almost universally. Define requirements, then look at products. Not the reverse. Doing it in the wrong order is not a minor inefficiency, it is fatal, and here is the mechanism.

Once you have seen three good demos, your idea of what a CMMS should do has been quietly rewritten by what those three products happen to do well, because vendors demo their strengths. If two of them have excellent mobile inspection rounds and weak multi-currency handling, your requirement list drifts toward inspection rounds and stops mentioning currency, even if you operate across three countries. You then select correctly against a requirement set the vendors wrote for you, and it is invisible from the inside because the process feels rigorous throughout.

The must-have list is short. If it has forty items it is a wish list with the word must in front of it. What I look for is eight to fifteen genuine must-haves, each written so a yes or no answer is possible, and each carrying a consequence if unmet. The consequence test is the discipline: if you cannot finish the sentence "if the product cannot do this, then we will have to ...", it is not a must-have.

The shape of a usable must-have entry

• Bad: "Strong mobile app." Unfalsifiable, and every vendor says yes.
• Better: "Technicians must complete a work order, attach photos and record parts used with no network connection for up to four hours, and sync without data loss."
• Better: "Purchase requisitions raised in the CMMS must create purchase orders in Business Central, and goods receipt must return to the CMMS work order, via supported API with no file transfer."

Write this list with the people who will live in the system: a planner, a senior technician, a storeman, the finance person who signs off spares, and whoever owns statutory compliance. Not a committee of managers. Managers write requirements about reporting. Technicians write requirements about whether the thing is usable at 6am on a roof, which determines whether you get data worth reporting on. The RFP writing guide covers turning this list into a document vendors can respond to.

3. Segment the market into tiers before you segment products

The forty-plus products are not one market. They are six overlapping markets sharing a vocabulary, and most of your elimination work is done the moment you identify your tier. A mobile-first mid-market product and an enterprise EAM both say "work order" and "preventive maintenance" and mean roughly the same thing, but they are built for organisations differing by two orders of magnitude in asset count, governance complexity and implementation budget.

Those product names are tier illustrations, not recommendations. I am not saying Limble is better or worse than Fiix; I am saying that if your must-have list includes linear asset management and Weibull analysis, neither belongs in your longlist, and if it is "get eleven technicians off WhatsApp within a quarter", neither Maximo nor SAP PM belongs either. The deeper comparison of the mid-market names sits in the UpKeep, Fiix, Limble, eMaint and Fracttal comparison, and individual introductions to MaintainX, Limble and Fiix go a level deeper on each.

Maximo CMMS deserves a note because it is searched for constantly by people who should not be buying it. IBM Maximo is an enterprise asset management platform containing a very capable CMMS. It is the right answer for a water utility with sixty thousand networked assets, statutory reporting obligations and a reliability engineering team. It is the wrong answer for a plant with four hundred assets and no dedicated system owner, not because it cannot do the job but because the configuration effort, governance overhead and internal skill requirement are sized for a different organisation. Choosing a platform you cannot staff is a slow failure rather than a fast one, which makes it harder to see coming.

4. The filters that eliminate fastest

Once you know your tier, apply hard filters. A hard filter is a binary question where a no removes the product: no workaround conversation, no roadmap promise accepted. Softer trade-offs come later, at the scoring stage. The order below is arranged by how much of the field each filter removes.

Applied honestly, these eight filters usually take a forty-product market down to six to ten candidates, from vendor documentation and one written questionnaire, before you have watched anything. That is the whole trick: the remaining work is qualitative and expensive, so you want as little of it as possible.

One discipline point on the asset and user bands: state them as bands, not exact numbers, and state them for three years out. A product that fits today's eight hundred assets and thirty users but strains at four thousand assets and ninety users after two site acquisitions has not passed. Equally, do not inflate the band speculatively; buying for a hypothetical future estate is the other half of why organisations over-specify, covered in the implementation mistakes piece.

5. Using analyst grids and review sites without being led by them

Analyst quadrants and software review marketplaces are useful for exactly one thing: discovering that a product exists. They are close to useless for deciding whether it suits you.

Analyst grids rank against a market definition the analyst chose, weighted toward attributes that matter to the analyst's client base, which skews large. Completeness of vision and ability to execute measure vendor health, which matters, but neither tells you whether the product handles your statutory inspection regime. A product in the bottom-left can be correct for a two-hundred-asset estate. Read grids for the market map and the viability signal, then stop.

Review sites have a structural problem worth naming: review volume correlates with marketing spend, because most reviews arrive through vendor-run campaigns. A product with nine hundred reviews and one with forty may simply have different acquisition budgets, and star averages compress further because almost everything sits between four and four point six.

How to actually mine a review site

• Filter to your own profile by company size and industry, then ignore the headline average. A product praised by fifty-person teams tells you nothing about its behaviour at nine sites.
• Read only the three and four star reviews. Five-star reviews are campaign-sourced and content-free; one-star reviews are usually implementation failures, informative about the partner rather than the product. The middle band describes real trade-offs.
• Search for the words in your must-have list. If nobody in hundreds of reviews mentions multi-currency, that is a signal about who buys the product.
• Sort by date and discount anything older than eighteen months. This market ships quickly; a complaint about a mobile app from three years ago may describe software that no longer exists.
• Note the reviewer's role. A glowing review from a maintenance manager and a lukewarm one from a technician, on the same product, usually predicts an adoption problem.

Treat both sources as inputs to the longlist and never to the decision. Their job is to make sure a good product did not escape your attention. Ranking is not their job, however confidently they present it.

6. The mechanics: forty to ten to three

Here is the sequence I would run, with effort front-loaded onto cheap activities.

1. Build the longlist to around twenty-five names from analyst market maps, review-site category listings, your tier table and, importantly, asking peers in your sector what they run. Do not curate yet; breadth here costs almost nothing.
2. Tier-filter to about fifteen. Remove anything built for an organisation two orders of magnitude away from yours. This takes an afternoon and is the highest-yield hour in the process.
3. Apply the hard filters from vendor documentation to reach eight to ten. Do this yourself, from published material, before you talk to anybody. You will be wrong about two or three, and the next step corrects that.
4. Send a short written questionnaire to those eight or ten. Twenty questions maximum, every one answerable yes, no or with a named mechanism. Give a deadline and treat a missed deadline as data about future responsiveness.
5. Cut to five on the questionnaire responses. Products that answered evasively go. An honest no on one requirement is a better signal than a confident yes on everything.
6. Run one short discovery call each with the five. Forty-five minutes, no demo: you describe your estate and constraints, they tell you where the friction will be. The vendors who use the time to understand you rather than to present are the ones worth shortlisting.
7. Cut to three and only now invest in reference calls and scripted demos. Three is roughly the limit of what a selection team can hold in mind with enough detail to compare fairly, and small enough that you can do the expensive steps properly for each.

Note that this sequence never asks for pricing until late, and pricing is deliberately absent from this article. Price is a real constraint but a poor filter, because early quotes are anchoring devices rather than costs. The CMMS pricing guide deals with that properly. Bringing price into the elimination round tends to remove the wrong products, because the cheapest licence frequently carries the most expensive implementation.

7. Reference calls: the questions that actually reveal something

Vendor-supplied references are curated, and you should assume so without resenting it. Every vendor offers their happiest customers, so "are you satisfied" has a predetermined answer and asking it wastes the call. The value comes entirely from questions a coached reference cannot answer with a rehearsed positive.

Questions worth asking

• "What did you have to change about how you work, to fit the product?" A reference who says nothing changed either has not been through a real rollout or is not being candid.
• "What is still on a spreadsheet?" The most revealing question in the set. Everybody has something, and the answer tells you where the product's coverage stops in practice rather than on a feature list.
• "How long from contract to the first month technicians were reliably using it?" Not go-live, which is a date somebody declares. Reliable use, which is a state.
• "What did PM compliance do in the first six months, and did it dip first?" A reference who reports a dip is describing a real rollout, because accurate recording usually makes the numbers look worse before better.
• "Who configures it now, and how much of their week does it take?" This exposes the ongoing internal skill requirement, the cost nobody quotes you.
• "Tell me about a support ticket that went badly." A refusal to answer is itself informative.
• "What did the last major version upgrade cost you in effort or breakage?" For cloud products this catches forced-update disruption; for on-premise it catches the upgrade treadmill.
• "If you were choosing again today, what would you put in the requirements that you left out last time?" The best question to end on, because it invites reflection rather than judgement.

Two mechanics improve reference calls. First, ask for a reference matched to your profile on the dimensions from your filter table: similar site count, asset band, regulatory context, ideally your region. If the vendor cannot produce one, that is itself a finding. Second, get on a call with a technician or planner, not only the project sponsor. The sponsor bought it and is invested in it having been a good decision; the planner uses it daily and has no such stake. Beyond the supplied list, sector user groups and regional maintenance networks talk about products with a directness no vendor-arranged call ever will.

8. Scripted demo discipline, with your own data

An unscripted demo is a sales presentation and teaches you only what the vendor wanted. A scripted demo is a test. The rule: you write the script, you supply the data, and the vendor does not see the script far enough ahead to build a bespoke configuration for it.

The script structure that works

1. Supply real data in advance. A sanitised extract of your asset register, with your real hierarchy depth, your real naming, your genuinely messy records and your actual PM schedules. Two hundred to five hundred assets is enough. Generic demo data hides every problem you care about, and watching a vendor load your hierarchy tells you more about the data model than any architecture slide.
2. Give the scenarios two to three days ahead, not two weeks. Enough time to load the data, not enough to build a custom prototype. If a vendor needs three weeks to show your scenarios, that itself is the answer.
3. Script five to seven end-to-end scenarios from your must-have list, each expressed as a task rather than a feature. "Show me you can handle permits" is a feature. "A contractor arrives to work on a live electrical panel; take me from permit request through authorisation, isolation, the job and de-isolation, then show me the audit record a regulator would ask for" is a task.
4. Require the same person to drive every scenario. Rotating presenters lets a vendor field a specialist per module and conceals how much cross-module knowledge the product really demands.
5. Insist your own people drive at least one scenario. A technician who has never seen the product should attempt to complete and close a work order on a phone, unaided, while everyone watches in silence. This is the most uncomfortable and most valuable twenty minutes of the evaluation.
6. Include one deliberately awkward scenario. A work order raised against the wrong asset that needs correcting after parts were issued. A PM rescheduled across a shutdown window. Retrospective entry of work done during a system outage. Products differentiate on the awkward cases, never on the happy path.
7. Ask for one thing to be configured live. Add a field to a work order form and make it mandatory for one asset class. The answer separates products you can adjust yourself from products where every change is a vendor ticket, and that distinction shapes your next five years more than most feature differences.

Score each scenario on the spot, before the next one starts. Memory contaminates fast across demos, and a scorecard filled in at the end of a week of presentations records impressions rather than observations. The mechanics of that scoring belong to the scoring framework.

A note on the enterprise tier: with products like Maximo, Hexagon EAM or Planon , the demo often shows a partner's configured environment rather than the base product. Ask explicitly which parts are standard, which are configuration and which are custom development, and get it in writing. The gap between those three is where enterprise implementation budgets are consumed.

9. Where shortlisting funnels break

The same failures recur, and all of them are process failures rather than judgement failures, which is encouraging because process is fixable.

• A vendor enters late, outside the funnel. Usually via an executive relationship, arriving at shortlist stage without passing a single filter. Either it goes through the filters like everything else, or the funnel has no authority.
• The must-have list gets edited to fit a favourite. Detectable only if the list was dated and circulated. This is what the sealed-envelope discipline exists to catch.
• Roadmap promises are counted as capability. If it is not in the product today, it is not in your evaluation. Contractual delivery dates with remedies are a different matter, and vendors rarely offer them.
• Nobody who will use the system is in the room. A shortlist chosen entirely by management selects for reporting and against usability, and then the reporting is worthless because the data never arrives.
• The shortlist is five or six products. Each gets shallow treatment and the decision reverts to impression. Cut to three even when it feels premature.
• Integration is assessed on a logo wall. A vendor listing your ERP's logo means a connector exists in some form for some version. Name the records and the direction, always.
• The team runs out of energy at the demo stage. Common and rarely admitted. It is the reason to front-load elimination onto documents: by the time you reach the expensive activities you should have three products left and enough appetite to do them justice.

There is a structural point too. If your asset register is incomplete, your hierarchy inconsistent and nobody agrees what counts as an asset, no shortlisting process will save you, because you will be evaluating products against requirements you cannot yet state. ISO publishes the 55000 family on asset management, and working through its framing of asset data and lifecycle responsibility is a better use of a month than a tenth demo. The implementation plan covers what has to be true about your data before any product can help.

10. Where this process does not work

I have described a funnel that takes several weeks of real effort, and it is not always the right investment.

Small teams should not run this. For one site, under three hundred assets and a handful of technicians, the full funnel costs more in management attention than the decision is worth, and the products in that band are similar enough that a mediocre choice is modest and reversible. Run a compressed version: a one-page must-have list, three products, free trials with your own data, decide in a fortnight. The small teams guide is written for that case.

It does not help when the decision is already constrained. If corporate policy mandates modules of the incumbent ERP where they exist, you do not have a forty-product market. You have a build-versus-configure question inside one product, and pretending otherwise produces a theatrical process with a predetermined outcome.

It does not resolve category confusion. If half your stakeholders want space planning and lease administration and the other half want reliability engineering, the funnel will thrash, because you are not shortlisting within one market at all. Settle the category question first, with which of CAFM, CMMS or EAM is right for you.

And it cannot compensate for an unresolved owner question. If nobody will own the system after go-live, the shortlist is irrelevant. I would rather see an organisation spend its first month naming and resourcing a system owner than run a rigorous selection that produces an excellent product nobody administers.

The idea to walk away with

The crowded CMMS software market is not a comparison problem, it is an elimination problem, and elimination is cheap while comparison is expensive. Almost all the value sits in the part nobody enjoys: writing a short, falsifiable must-have list before you look at anything, identifying which tier you belong to, and applying hard filters from published documentation until a handful remain. Do that and the final three will be genuinely comparable, the demos will be tests rather than presentations, and the scoring stage will have something real to score. Skip it and you will watch eleven similar demos, lose the thread, decide on feel, and rediscover your actual requirements during implementation, when changing your mind costs far more than it did in week two.

Final thoughts

Forty products down to three is a mechanical exercise, and that is the good news, because mechanical exercises can be done well by disciplined people without deep product expertise. You do not need to know every CMMS maintenance management software product on the market. You need to know your own constraints precisely enough that most of the market disqualifies itself, which is a question about your organisation, not the vendors.

So write the list first, circulate it and date it. Work out your tier honestly, including the uncomfortable possibility that the enterprise platform your board has heard of is two tiers above what you can staff. Filter from documents before you filter from impressions. Ask references what is still on a spreadsheet. Make the vendors work with your data, and let one of your own technicians try to close a work order in front of everybody. Then take three products into a proper scoring exercise, and you will be choosing between good options rather than guessing between blurred ones.

Related reading: Best CMMS software: the buyer shortlist, A weighted scoring framework, How to choose preventive maintenance software, What maintenance software really costs, CMMS implementation: a step-by-step plan.