QHSE software demo checklist
Send a real workflow to the vendor before the meeting. The goal is to leave with evidence that your team can complete it, plus a written list of what still needs configuration or confirmation.
This is an editorial buying checklist. Adapt the steps to your requirements; it is not a certification or a guarantee that a product meets them.
1. Prepare one real workflow
Choose a recent inspection or incident and remove personal or confidential information. Bring the form, an example attachment, the approval rule and the report you actually need. Include one exception, such as an overdue action or rejected closure. Ask every vendor to use the same material.
2. Start as a frontline user
Use the role and device that your team would receive. Create a record, attach a photo, correct a mistake and assign an action. Record where the user needs help. A demonstration performed entirely by an administrator does not establish the frontline experience.
3. Disconnect deliberately
First ask what must be downloaded or synchronized. Switch to airplane mode, open the prepared workflow and add data and an attachment. Close and reopen the app, reconnect and check the resulting record. Ask how failures, duplicate submissions and conflicting edits are handled. Record exactly which steps were shown.
4. Follow the finding to closure
Assign a due date and an owner. Show an overdue action, delegate it, submit incomplete evidence and reject it. Then approve the corrected work. Check who receives notifications and whether the history shows the changes. A dashboard count alone is not evidence of a complete process.
5. Check access with separate roles
Use a worker, supervisor and administrator account. If health records are in scope, use dummy data and test the access boundary explicitly. Ask what contractors can submit and view. Record the license type required for each action, not just for logging in.
6. Change a rule and move the data
Ask your prospective administrator to change a form or approval rule. Identify anything that needs vendor services. For an integration, request the exact connector or API operation, data direction, failure handling and support owner. Export a complete sample record, its attachments and history, then inspect the files.
7. Turn the demonstration into a written scope
List the modules and seat types used in the demo. Separate subscription, configuration, migration, integrations, training and support costs. Ask which demo features are excluded from the quote. Tie implementation milestones to agreed workflows and name the person responsible for accepting each one.
Keep a decision record
For each requirement, record the result as demonstrated, partly demonstrated, not demonstrated, or outside the quoted scope. Add the screen or exported file that supports it, the proposed plan, the unresolved question, an owner and a response date. Leave unknowns open rather than converting them into a score.
| Requirement | Result | Evidence / follow-up |
|---|---|---|
| Offline photo attachment | Partly demonstrated | Capture shown; reconnection test still needed. Ask the vendor to repeat it on the intended device. |
Compare the first year on the same basis
Add annual subscription, initial configuration, migration, integrations and training. Keep internal staff time and optional services visible as separate estimates. Document currency, tax treatment, contract term and renewal assumptions. A missing price is an open question, not a zero.
Before selecting a vendor, resolve the requirements that would stop your team from working. A polished presentation should not outweigh an untested critical workflow.