CMMS Pilot Checklist: Test the Workflow Before You Commit

Write the decision before starting the trial

Define the decision the pilot must support. Perhaps you are replacing a spreadsheet, introducing preventive-maintenance scheduling, or standardizing two buildings. Name the team, workflows, and constraints being evaluated. Include the candidate plan, relevant add-ons, and the people who will decide whether the evidence is sufficient.

Create a pass condition for each essential requirement. For example, a technician can complete a job from the intended phone and the supervisor can retrieve the correct asset history. Give optional preferences a separate list. This prevents an attractive secondary feature from obscuring a missing essential workflow.

Build a small but representative test set

Use a handful of assets and tasks chosen for variety, not a large import chosen for volume. Include routine work, a recurring job, a request with missing information, and a job reassigned between users. If your process uses parts, meter readings, attachments, or approvals, add examples that exercise them.

Use clearly marked test records and appropriate sample information. Avoid loading confidential operating details into an evaluation account unless your organization has approved that use. Record the expected result for each task so different vendors are assessed against the same scenario.

• One request submitted by a non-technician.
• One complete technician work order with a useful completion note.
• One recurring task and its next due occurrence.
• One asset-history lookup and one data export.
• One relevant failure or exception, such as a rejected input or interrupted connection.

Let each role do its own work

Ask requesters, technicians, and supervisors to use their own intended roles. Do not run every test as an administrator. Observe whether they can locate the right asset, understand the next action, correct a mistake, and tell whether work was saved. Capture questions and workarounds rather than coaching every action away.

Give the vendor a chance to explain configuration choices, then rerun the affected task. Distinguish a training issue from a missing capability. Record whether the solution requires a different plan, custom work, or an ongoing administrative step.

Test the conditions that can change the result

If offline work matters, prepare the required records while online, disconnect the device, complete the relevant actions, and verify the result after reconnecting. If several sites matter, check location access and reporting with users assigned to different sites. If an integration matters, request a concrete data-flow demonstration or mark it unverified.

Check exports independently. Open the file and confirm identifiers, dates, statuses, relationships, and the details needed for reporting or migration. The presence of an Export button is not evidence that the output will satisfy your needs.

Close with a decision record

Summarize each requirement as demonstrated, unmet, or unresolved, with links to notes or screenshots your organization is permitted to retain. Add the required plan, implementation responsibilities, estimated costs, and open questions. Avoid inventing a numerical score that hides a failed essential requirement.

Choose a next action: proceed, proceed only after named issues are resolved, extend a specific test, or decline the product. Use our comparison pages to document remaining alternatives. Request shortlist help if the pilot shows that your original requirements need a different set of candidates.