A demonstration shows functionality. Seeing it does not establish that it solves your plant's problem. Use representative situations from your operation.
Don't let the vendor's demo script become your evaluation plan. Bring your own.
1. Prove how maintenance work gets created
An operator notices an abnormal condition on Line 2. Show how it becomes visible maintenance work, how equipment is identified, what information survives triage, and who decides what happens next.
2. Prove PM from trigger to completion
Use a task due every 500 operating hours. Show the origin, currency, work creation, missing-reading behavior, completion effect and incomplete-cycle handling. Record when simulated information is used.
3. Prove the technician workflow
Ask a representative technician to receive, understand, execute and complete work using the actual device pattern, including connectivity and shared-device conditions.
4. Prove the asset structure with real equipment
Use a representative plant → area → line → machine → subsystem → motor relationship. It is an example, not a prescribed hierarchy.
Don't inventory an asset just because the software has a field for it.
Read the asset-information evidence →
5. Prove what happens when a part isn't available
Follow a planned job with an unavailable part across the CMMS, inventory or ERP, planning and technician workflow.
6. Prove the integration—not the logo
Start with a business event. Ask what initiates the exchange, what data moves, which system is authoritative, how failures surface, and how records reconcile.
Workflow demonstrated. Actual integration not yet proven.
Read the integration evidence →
7. Prove what complete means
Check required findings, meter readings, failure information, parts, follow-up work, approvals and return-to-service responsibility. A software status does not necessarily establish operational state.
8. Prove one important report backward
Trace one report from its displayed result to each source event, timestamp, owner, inclusion rule and correction path.
Never trust an SLA dashboard until you know what real-world event sits behind every timestamp.
9. Prove the implementation requirements from you
Ask what data, configuration, process decisions, testing, training and governance your team must provide.
If this does not happen, who owns the fact that it did not happen?
Read the implementation evidence →
10. Prove how you'll know it works after implementation
Define the post-implementation test, owner, evidence and acceptance condition.
Go-live is not acceptance.
Read the acceptance evidence →
Use an evidence ladder
VENDOR ASSERTION → DOCUMENTATION → DEMONSTRATION → YOUR SCENARIO → TEST → OPERATIONAL EVIDENCE
These are not mandatory universal stages. Match the burden of proof to the decision consequence.
When you can't eliminate uncertainty, limit the commitment.
Read the bounded-commitment evidence →
Keep an evidence record
| Record | What to capture |
|---|---|
| Requirement | The operationally grounded statement. |
| Evidence requested | The proof requested. |
| Method | How evidence was produced, including simulations. |
| What we observed | A factual record. |
| Conditions | Data, configuration, device, connectivity and participants. |
| What remains uncertain | The boundary of the evidence. |
| Next decision | The action, test, term or limit required. |
A worked scenario: Machine 12
A single realistic situation can test several requirements at once. Ask the vendor to follow it end to end instead of touring a manufacturing module.
Machine 12 is approaching its runtime-based maintenance threshold. Production needs it through Wednesday. A Thursday-morning changeover creates a potential two-hour maintenance window. The job requires a replacement component and a technician with the appropriate skill. During the work, the technician discovers abnormal wear that requires corrective action.
Ask the vendor to show:
- Where the runtime comes from and how the work becomes due.
- How production context and the Thursday changeover can be considered alongside the due date.
- How the required component and a technician with the right skill are checked before the window.
- What the technician receives and records at the machine.
- How the abnormal wear is recorded so that similar findings can be recognized later, and how linked corrective work is created.
- How downtime and return to service are represented, and what becomes asset history.
- Which of this information flows to or from other systems, and which system owns it.
A product may support some steps internally and depend on integration for others. Record which steps were shown with real functionality and which were simulated or described.
Ten manufacturing demo scenarios
- Operator problem to maintenance work.
- PM trigger to completion.
- Technician receipt to completion.
- Representative equipment hierarchy.
- Unavailable part.
- One important information flow.
- Incomplete shift handoff.
- Inspection or condition finding to follow-up.
- One KPI traced to source events.
- One requirement through implementation and acceptance.
What a demo cannot prove
- clean production data
- working live integrations
- technician adoption
- implementation capacity
- provider execution
- reporting definitions
- usability at scale
- the expected operational outcome
A good demonstration can provide meaningful evidence. But the evidence is bounded. The demo is not the decision.
When you can't eliminate uncertainty, limit the commitment.
For the underlying request-to-history path, see Maintenance Work Order Software.