The CMMS Demo Checklist

A CMMS demo is more useful when the vendor shows your maintenance work moving through the system.

Give the vendor a few realistic situations before the meeting.

A request comes in.

A supervisor decides what to do with it.

A technician receives the work.

The technician needs asset history, instructions and parts information.

The work gets completed.

Someone later needs to know what happened.

Then ask the vendor to show you that process.

This gives you something much more useful to evaluate than a tour through menus and dashboards.

Start with your requirements

Bring the requirements you developed before contacting vendors.

You do not need to demonstrate every requirement in one meeting.

Choose the ones that are:

• important to daily work
• difficult or risky
• likely to differ between products
• important to technician adoption
• dependent on mobile or offline use
• dependent on integrations
• difficult to understand from a feature list

A requirement marked "supported" on a spreadsheet tells you very little about how the work will actually happen.

The demo is where important requirements begin to become observable.

Give every vendor the same core scenarios

If you are seriously comparing several systems, ask each vendor to demonstrate the same core workflows.

That creates a common basis for comparison.

The scenarios should come from your operation.

A water utility may care deeply about GIS, field connectivity and asset hierarchies.

A manufacturer may focus on production equipment, preventive maintenance, parts and technician response.

A facilities organization may emphasize service requests, buildings, inspections, vendors and mobile work.

The details change.

The evaluation method does not.

Public CMMS procurements provide good examples of this approach.

In 2025, Jordan Valley Water Conservancy District invited CMMS vendors to demonstrate their products using five scenarios supplied by the District.[1]

Indian River County, Florida went further in its 2026 CMMS procurement. Finalists were required to perform live, scenario-based demonstrations using the actual software interface. Slide-only demonstrations were not acceptable.[2]

You do not need a formal government procurement process to use the same idea.

Give vendors the work you need to see.

Scenario 1: From request to completed work

Ask the vendor to demonstrate a normal corrective-maintenance workflow from beginning to end.

For example:

1. An operator, employee or requester reports a problem.
2. The request reaches the appropriate person.
3. A supervisor reviews and prioritizes it.
4. A work order is created or approved.
5. The work is assigned to a technician.
6. The technician receives it on a mobile device.
7. The technician opens the asset record.
8. The technician reviews relevant history or instructions.
9. Labor and parts are recorded.
10. A photo or note is added.
11. The work is completed.
12. A supervisor or manager can see the result.

Watch the transitions.

How much information must be entered?

How many screens are involved?

Does someone have to re-enter information?

Can the technician see what matters without hunting for it?

What happens if the original request is incomplete?

If this is a workflow your team performs repeatedly, small amounts of friction will also be repeated.

Scenario 2: Preventive maintenance becomes due

Ask the vendor to show how a PM moves from setup to completed work.

Have them demonstrate:

• how the PM is created
• what triggers it
• how it is connected to an asset
• how procedures or checklists are attached
• how the work is generated
• how it is assigned
• what the technician sees
• how completion is recorded
• how follow-up corrective work is created
• what happens when the asset is retired or taken out of service

If your operation uses meter-, runtime- or condition-based maintenance, include that in the scenario.

Indian River County's demonstration script included preventive-maintenance scenarios and specifically asked vendors to show how PMs apply across similar assets and what happens to PMs when an asset is retired or taken out of service.[2]

That is a good example of testing the workflow beyond simply asking whether the software "has preventive maintenance."

Scenario 3: The technician is in the field

If technicians will use the CMMS on phones or tablets, spend meaningful demo time on the mobile product.

Ask the vendor to use an actual mobile interface.

Have the technician workflow demonstrated from the technician's point of view.

Can the user:

• see assigned work?
• understand priority?
• find the asset?
• see work history?
• read procedures?
• complete a checklist?
• enter labor?
• record parts?
• add notes?
• take or attach photos?
• capture meter readings?
• create follow-up work?
• complete the work order?

If connectivity is unreliable in your environment, ask for offline operation to be demonstrated.

Then ask:

What remains available offline?

What cannot be done offline?

What happens to changes when connectivity returns?

How are conflicts handled if records changed while the device was offline?

Indian River County required demonstrations to include desktop and mobile use cases. Its RFP also required offline mobile operation with automatic synchronization after connectivity returned.[2]

The county's demo rules allowed evaluators to ask the vendor to repeat an action in the mobile interface or explain how many steps were required to complete a task.[2]

That is a useful habit for any buyer.

If something looked easy on a presenter's desktop, ask to see the same work where your technician will actually perform it.

Scenario 4: Find the history of an asset

Pick an asset and ask the vendor to show you its story.

For example:

• open work
• completed work
• preventive maintenance
• failures
• meter readings
• labor
• parts
• costs
• documents
• photos
• parent/child relationships
• location
• warranty or vendor information, if relevant

Then move up or down the hierarchy.

If the asset is a component of a larger system, can you see the relationship?

Can a manager understand maintenance history without assembling it manually from several screens?

Indian River County specifically asked vendors to demonstrate hierarchy navigation from facility level down to an asset or component and to roll work history or cost information up to a higher level.[2]

If asset history is one reason you are buying a CMMS, make the vendor show you how that history becomes useful.

Scenario 5: A part is needed

If parts and inventory matter to your operation, put them into a maintenance scenario.

For example:

A technician opens a work order and needs a replacement part.

Ask the vendor to show:

• how the technician finds the part
• available quantity
• storage location
• whether the part is associated with the asset
• how it is issued to the work order
• whether inventory changes automatically
• what happens when stock reaches a reorder level
• how purchasing or replenishment works
• how the part cost becomes part of maintenance history

If purchasing happens in another system, ask the vendor to show or explain the boundary between the systems.

You are trying to understand where the workflow lives and where information has to cross between systems.

Scenario 6: A manager needs an answer

Do not begin with the polished executive dashboard.

Give the vendor a question.

For example:

• What work is overdue?
• Which PMs were missed this month?
• What is the current backlog?
• Which critical assets are creating the most work?
• How much maintenance has been performed on this asset?
• Which work orders are waiting for parts?
• How much labor was spent on a facility?
• What happened during a specific period?
• Can I see this across several sites?

Then ask the vendor to get you the answer.

Pay attention to where the information comes from.

Can a normal manager retrieve it?

Does the report depend on data technicians are realistically going to enter?

Can you move from the summary back to the underlying work?

A dashboard is useful when the operation can reliably produce the information behind it.

Scenario 7: Something changes

Clean demo data makes software look orderly.

Maintenance operations are not always orderly.

Introduce a change.

For example:

• a work order was assigned to the wrong technician
• the priority changes
• an asset goes out of service
• a technician entered the wrong part
• a PM needs to be postponed
• a work order needs approval
• the job requires another craft
• a second problem is discovered during the repair
• the technician loses connectivity
• a supervisor needs to reopen completed work

Ask the vendor to handle the change.

You are looking for what happens when the workflow leaves the happy path.

Can normal users correct mistakes?

Is there an audit trail?

Do corrections require an administrator?

Does the original information disappear, or is the change recorded?

This often tells you more about daily usability than watching another ideal transaction.

Test integrations with a workflow

If an integration is important, avoid stopping at:

"Yes, we integrate with that."

Pick information that needs to cross the boundary.

For example:

ERP / purchasing

A part is requested in the CMMS. What goes to the purchasing or ERP system? What comes back? Which system owns the record?

GIS

A field asset is selected on a map. What maintenance information can the user see? Can work be created or updated from that context?

Identity / SSO

How are users created, authenticated and removed? How are roles assigned?

Sensors or condition monitoring

A reading crosses a threshold. What happens next? Does it create work automatically? What information accompanies the event?

Business intelligence

Which CMMS data is available externally, how is it accessed, and how often is it updated?

For every important integration, establish:

• what data moves
• which direction it moves
• how often
• which system owns the data
• whether the integration exists today
• whether it requires configuration or custom work
• whether it creates an additional cost

An integration diagram can look impressive.

The workflow tells you whether it solves your problem.

Ask to see released software

When a demonstrated capability matters to your decision, establish what you are looking at.

Is it:

• part of the current production product?
• a configuration available today?
• an add-on?
• a third-party product?
• custom development?
• beta functionality?
• planned roadmap functionality?

Indian River County required finalists to demonstrate released production software available by the demonstration date. Future or roadmap functionality had to be clearly identified and was not scored as delivered functionality.[2]

That is a useful standard.

A future capability may eventually be valuable.

Record it as future capability.

Evaluate the purchase based on what you can reasonably expect to receive.

Ask the presenter to slow down

The person demonstrating the CMMS may know the software extremely well.

Your technicians do not.

If an important task goes by quickly, ask for it again.

Ask:

"Can you repeat that from the beginning?"

"Can you show that on the phone?"

"How many steps did that take?"

"Can a technician do that without administrator permissions?"

"What happens if they skip that field?"

"Can we see what the supervisor sees next?"

Indian River County explicitly reserved the right to interrupt demonstrations, request repeated steps, ask to see the same action on mobile and ask how many steps a task required.[2]

A demo is an evaluation session.

Use the time to understand the software.

Put the right people in the room

The people evaluating the CMMS should represent the people who will live with it.

Depending on the project, that may include:

• maintenance manager
• planner or scheduler
• supervisor
• technician
• reliability or asset-management staff
• storeroom or purchasing
• IT
• security
• finance
• operations
• implementation/project lead

Not everyone needs to attend every minute.

But a system that looks simple to a manager may feel very different to the technician entering information repeatedly throughout a shift.

Bring the people who can recognize whether the demonstrated workflow resembles the real operation.

Let a technician ask questions

A technician will often notice things other evaluators do not.

Where do I see my work?

How do I know what is urgent?

Can I use this with gloves?

What if there is no signal?

Where are the previous repair notes?

How do I record a part?

Can I take a picture?

What happens if I start the job and another technician finishes it?

How much typing is required?

You do not need the technician to evaluate architecture or commercial terms.

You need the technician to help evaluate technician work.

Vendor-authored CMMS demo guidance also commonly recommends including technicians in the evaluation because they can test the workflows they will actually use.[3]

Score evidence, not presentation quality

Create your scorecard before the demo.

Keep it tied to your requirements.

A simple scoring system can work:

Add an evidence column.

Define what matters most before seeing the products.

A beautifully demonstrated low-priority capability should not outweigh a serious problem with a must-have workflow.

Use the same core scorecard for every vendor.

Record what was actually demonstrated

For each important requirement, distinguish between:

Demonstrated

You saw the workflow in working software.

Explained

The vendor described how it works but did not show it.

Documented

The vendor provided documentation supporting the capability.

Future

The capability was described as planned or roadmap functionality.

Unresolved

You still need an answer.

This makes your notes much more useful later.

"Vendor says yes" and "we watched our scenario run successfully" are different pieces of evidence.

Record the difference.

Watch for these demo warning signs

A warning sign does not automatically eliminate a product.

It tells you where more investigation is needed.

Pay attention when:

• an important workflow is repeatedly answered with slides
• the presenter avoids the mobile interface
• a requirement is described but cannot be shown
• an integration is called "available" without explaining how it works
• an important capability depends on an undisclosed add-on
• roadmap functionality is discussed as though it exists today
• simple technician tasks require substantial navigation or data entry
• corrections require unusual administrator involvement
• the vendor cannot explain what happens offline
• the demonstration keeps moving away from your scenarios
• answers depend heavily on custom development
• the team cannot clearly explain what your organization would have to configure or maintain

Write the issue down.

Then determine whether it is a product limitation, an implementation question, a misunderstanding or simply something that needs another demonstration.

The CMMS demo checklist

Before ending the session, make sure you have addressed the areas that matter to your operation.

Work management

• [ ] Request creation
• [ ] Prioritization
• [ ] Work-order creation
• [ ] Assignment
• [ ] Technician execution
• [ ] Labor entry
• [ ] Parts entry
• [ ] Notes and photos
• [ ] Completion / closeout
• [ ] Follow-up work

Preventive maintenance

• [ ] PM setup
• [ ] Relevant triggers
• [ ] Procedures / checklists
• [ ] Automatic work generation
• [ ] Assignment
• [ ] Completion
• [ ] Follow-up corrective work
• [ ] Asset retirement / PM handling

Mobile

• [ ] Actual mobile interface shown
• [ ] Assigned work
• [ ] Asset history
• [ ] Procedures / checklists
• [ ] Photos
• [ ] Labor and parts
• [ ] Meter readings if required
• [ ] Offline use if required
• [ ] Synchronization after reconnecting

Assets

• [ ] Asset record
• [ ] Location hierarchy
• [ ] Parent / child relationships
• [ ] Work history
• [ ] PM history
• [ ] Parts
• [ ] Costs
• [ ] Documents / photos
• [ ] Relevant warranty/vendor information

Parts and inventory

• [ ] Find a part
• [ ] Quantity / location
• [ ] Issue part to work
• [ ] Inventory adjustment
• [ ] Reorder process
• [ ] Purchasing boundary
• [ ] Cost captured against work / asset

Reporting

• [ ] Backlog
• [ ] Overdue work
• [ ] PM compliance
• [ ] Asset history / cost
• [ ] Required management KPIs
• [ ] Multi-site reporting if required
• [ ] Ability to move from summary to source records

Integrations

For every required integration:

• [ ] Data exchanged is understood
• [ ] Direction of exchange is understood
• [ ] System of record is understood
• [ ] Frequency is understood
• [ ] Current availability is verified
• [ ] Configuration/custom work is understood
• [ ] Additional cost is understood

Administration and control

• [ ] Roles and permissions
• [ ] Audit trail
• [ ] Error correction
• [ ] User administration
• [ ] Approval workflows if required
• [ ] Required security controls

Commercial / implementation follow-up

• [ ] Product tier demonstrated
• [ ] Add-ons identified
• [ ] Third-party components identified
• [ ] Custom work identified
• [ ] Roadmap items identified
• [ ] Implementation questions recorded
• [ ] Pricing implications recorded
• [ ] Open questions assigned for follow-up

Do not add items simply to make the checklist longer.

Remove anything that does not matter to your operation.

Add anything important that is missing.

What should you know when the demo ends?

You should be able to answer:

1. Can technicians perform the important daily work without unnecessary friction?
2. Can supervisors see and control the work they are responsible for?
3. Does the system support the maintenance workflows that matter most?
4. Did we see those workflows or only hear about them?
5. Does mobile work where our technicians work?
6. Can the system represent our assets and their relationships?
7. Can we retrieve the information managers actually need?
8. Do required integrations appear practical?
9. Which requirements depend on configuration, add-ons, third parties or custom work?
10. Which capabilities remain unverified?
11. Which capabilities are future or roadmap items?
12. What would we need to prove in another session before making a decision?

A good demonstration leaves you with evidence.

Keep that evidence tied to the requirements you established before the vendor entered the room.

Then compare vendors on the work your maintenance organization actually needs them to support.

Next → How to Compare CMMS Solutions