We use cookies and similar technologies (Google Analytics, Meta Pixel, Microsoft Clarity) to measure traffic, improve our content, and understand how visitors use qhsetech.com. No optional analytics or advertising scripts are loaded unless you select Accept all. Clarity uses heatmaps and session replay to help us improve the site. Read our Privacy Policy.
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.
Updated 19 September 2026. Record the production plan, app version and permitted role for each demonstration. A privileged demo tenant or future roadmap is not evidence that the quoted package meets a requirement. Leave unproven results open and separate critical acceptance gates from weighted preferences.
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.
Repeatable offline test: one checklist, one photo, one action
Record the product, plan, app version, device, role and date. Use a dummy checklist with a required answer, one failed item, a photo and an assigned action. Record exactly what was downloaded while online. Start the inspection after disconnecting; separately test whether an already-open inspection can continue offline.
Force-close and reopen the app while still offline. Check the draft, photo and action. Reconnect once, then inspect the server record and export: compare the fields, attachment, timestamp and owner, and check for duplicate records. If conflicts are in scope, repeat with two devices and record how the competing edits are resolved.
Keep each result blank until observed. Record failures and steps the vendor could not demonstrate. A documentation claim can inform the test plan but does not count as a passed hands-on test.
Use the same requirements for up to three vendors. Start with equal weights, then agree your priorities before the demos. All outcomes begin as untested. These are your observations, not QHSEtech product test results.
Draft saved in this browser. This worksheet is not submitted to us. Use anonymized notes and export your work before clearing browser data.
Edit shared requirements and weights
A score uses only assessed requirements: weighted points ÷ maximum assessed points. Coverage shows how much of the total weight was assessed. A high score with low coverage is incomplete; unresolved must-pass requirements remain visible regardless of score.
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.
Example entry — illustrative, not a vendor test result
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.