CMMS Demo Evaluation: What to Make Vendors Prove

By the time you evaluate shortlisted CMMS systems, you should know which requirements matter, what each vendor claims and where uncertainty remains. A vendor-led tour can show polished screens under favorable conditions. Use the demo to reduce uncertainty about the work your operation needs to perform.

Don't ask whether the CMMS can do it. Define what you need to know, choose the right way to prove it, observe what actually happens, and preserve what remains uncertain.

Build your demo tests ↓

The problem with the normal CMMS demo

A vendor-led presentation naturally concentrates on prepared workflows. Even a buyer-controlled demonstration establishes only what happened with the data, configuration, permissions and conditions shown. Ask whether another module, license, integration or customization made the result possible; whether the same process works at the scale and connectivity your team faces; and what happens outside the prepared path.

CMMS Buyers Guide method — demonstration boundary: a demonstration is evidence of what happened under the conditions demonstrated. It does not establish performance under every operating condition. NIST distinguishes examining materials, interviewing people and testing mechanisms under specified conditions in its security and privacy control assessments. We adapt that general assessment distinction to CMMS purchasing; NIST does not prescribe this CMMS buying method. [1]

Read the demonstration-boundary evidence note for its source, limits and buyer action.

Start with the uncertainty

The CMMS software comparison should leave a record of unresolved claims, dependencies and operating conditions. Take a material unknown from that record into the demo plan. For example: Requirement — technicians must complete assigned work without connectivity. Vendor claim — offline mobile is supported. Known dependency — a mobile application is required. Remaining uncertainty — which records remain available offline, which actions can be performed, and what happens on reconnecting.

Requirement ↓ Vendor Claim ↓ Uncertainty ↓ Evidence Needed ↓ Proof Method ↓ Scenario / Assessment ↓ Observation ↓ Evidence Obtained ↓ Remaining Uncertainty ↓ Commercial Boundary

Not every claim belongs in a demo: the CMMS Claim-to-Evidence Map

The aim is to obtain the appropriate evidence for each material claim. A screen demonstration is useful for observable workflows; other questions need documents, configured tests, independent assurance where applicable, references or written scope. The map below is CMMS Buyers Guide methodology, not a list of tests every buyer must run.

CMMS Buyers Guide method — proof-method fit: match the evidence method to the claim. NIST uses examine, interview and test as different methods for obtaining evidence in the context of security and privacy control assessments. Its distinction between methods and specified test conditions informs this adaptation; it is not a NIST CMMS procurement recommendation. [1]

Read the proof-method-fit evidence note for the applicable source and limitations. See also CMMS integrations for behavior across system boundaries and CMMS data migration for sample migration scope.

Turn requirements into tests

A useful scenario specifies the actor, trigger, operating condition, required actions, exception and expected evidence. Begin with the condition that could change the decision.

The second request identifies records, actions, connectivity conditions and a conflict to observe. Document the expected outcome before the session, including what would count as unresolved. The scenario is an illustrative buyer test, not a claim that any product performs it.

Use your CMMS requirements to choose material tests. The mobile CMMS guide helps identify field conditions; the maintenance work-order guide helps define the work and record flow.

Give every vendor the same test

Same requirement. Same scenario. Same questions. Same evidence standard.

If Vendor A demonstrates an action while Vendor B answers a question about it, the evidence is different. Provide finalists the same operating context and the same success and exception conditions when comparability matters. Note any different conditions each vendor requires rather than quietly treating unlike demonstrations as equivalent.

Return outcomes to the comparison record so the same requirement and evidence question stay together.

Separate what was said from what happened

Use evidence-state labels to describe what the buyer currently has: STATED — the vendor says the capability exists; SHOWN — something relevant was demonstrated; TESTED — the buyer’s defined scenario was exercised; SUPPORTED — appropriate additional evidence supports the claim; UNRESOLVED — a material question remains.

These labels are not scores or sequential stages. A claim can be TESTED + UNRESOLVED when the scenario ran but conflict handling was not shown. A security claim may be SUPPORTED by documentation or independent assurance without a meaningful sales-demo demonstration.

CMMS Buyers Guide method — evidence state is not a vendor score. The labels record the scope of evidence, not product quality. NIST assesses stated objectives using methods and reports findings for specific controls; our five labels are our own editorial vocabulary, not NIST labels. [1]

Read the evidence-state-is-not-a-vendor-score evidence note for the source boundary. Do not convert these labels into points, percentages or a vendor ranking.

Record observation before interpretation

Record what happened before deciding what it means.

The observation belongs in the evidence record. An interpretation comes after checking the applicable conditions, dependencies and unanswered questions. If the demonstration used prepared data or a simulated connection loss, record that condition too.

Ask the dependency question

What would we need in order to reproduce exactly what we just saw?

Record the edition or plan, module, configuration, integration, add-on, custom development, implementation service, data preparation, buyer responsibility, third-party product and additional cost where relevant. A successful demonstration does not establish that the tested setup is included in the offer.

Connect each dependency to the commercial boundary in the comparison guide. Confirm what is included in the written CMMS quote and who is responsible in the implementation plan.

Test the exception

A normal workflow may hide a consequential failure path. For work orders, try missing required information. For inventory, request a part that is unavailable. For mobile work, change the same record on two devices while one is offline. For approvals, make the approver unavailable. For preventive maintenance, overlap scheduled work with an open corrective work order. For permissions, compare what a technician and supervisor can see and change. For an integration, make the connected system unavailable.

Test only exceptions that materially affect your requirements. Agree on the expected behavior and how to record the outcome before you run a scenario.

Use the inventory guide for parts flows, the preventive maintenance guide for scheduled work and the asset maintenance guide for asset context.

Stop trying to prove everything on screen

Some uncertainties are better handled through documentation, technical review, a sandbox or trial, a proof of concept, sample migration, security review, customer reference, written implementation scope, commercial proposal or contract. If the uncertainty can reasonably be resolved in the demo, test it. Otherwise assign the appropriate follow-up evidence and an owner.

Can this uncertainty reasonably be resolved in the demo? YES → Test it. NO → Assign the appropriate follow-up evidence.

An answer promised for later remains unresolved until the evidence is actually obtained. For example, a connected system may need a configured integration test rather than a mock screen.

The cloud CMMS guide can frame hosting and access questions, while CMMS vs ERP can clarify which system owns the information crossing a boundary.

CMMS Demo Evidence Sheet

Use one field/value record per material requirement. Copy these field names into your own document or spreadsheet. The example below is a hypothetical scenario, not evidence about any product.

Replace the illustrative observation with what your team actually saw. Leave untested fields open rather than copying the example outcome into a live vendor record.

After the demo

Preserve observations. Identify unresolved requirements and assign follow-up evidence. Confirm the configuration and buyer/provider responsibilities behind what was shown. Reconcile demonstrated capability with the commercial proposal. Then return each result to the comparison record so the decision reflects evidence across candidates.

An unresolved item is not automatically a failure. It is an identified uncertainty that still needs evidence or an explicit decision about whether to accept it.

The demo isn't the decision

A disciplined demo should leave fewer assumptions, even if it does not identify a winner. Record what each system demonstrated, the conditions that made it possible, which claims have other supporting evidence, which commercial dependencies matter and what remains unanswered. Bring those findings back to the comparison before making the final decision.

Previous guide: CMMS Software Comparison: How to Compare Systems That Made Your Shortlist →

Next: How to Evaluate a CMMS Proposal →