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.
Saved evaluations
Available in this browser only. No account or email is needed. Export scorecards before clearing browser data.
- Current scorecard: Vendor 1 / Vendor 2 / Vendor 3
Saved 9/30/2026, 1:53:31 PM · General worksheet
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 24 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.
Before the demo: scope and decision ownership
- Which problem triggers this purchase, and what evidence shows it exists?
- Which workflow, sites and user roles belong in the first release?
- Which requirements are essential, preferred or outside this purchase?
- Who can accept a result, reject a gap and approve the contract?
- Which records and decisions stay in another system?
- What baseline will we use to assess whether the new process helps?
Bring to the decision meeting: A one-page brief approved by the people who own the process and the purchase.
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.
Review the vendor documentation before the offline testModule questions: turn a feature name into a demo task
A feature name is the beginning of a requirement. Open only the modules in your purchase. Ask the vendor to name the product and edition, its proposed approach, dependencies and complete cost, and treat roadmap commitments as future scope, not an available capability.
Core platform and field access
- Which roles may submit, review, administer and export each record?
- What changes when a user moves site, changes role or leaves?
- Which screens, custom fields, notifications and exports support our required languages?
- Which mobile tasks need preparation or connectivity, and how is server receipt confirmed?
- Who can change a form or approval path, and what happens to records created under an earlier version?
Suggested demo task: Move a user between two sites, change a local form and complete one task on the proposed device.
Evidence to keep: The named edition, role matrix, local configuration, required languages and actual connectivity conditions.
Quality management
- Can a user retrieve the approved instruction that applied when a record was created?
- How are a nonconformance, containment decision and corrective action connected?
- Can a reviewer reject closure and retain the reason and earlier evidence?
- What happens to acknowledgements or training when a controlled document changes?
- Which quality, manufacturing and laboratory records remain in separate applications?
Suggested demo task: Revise a procedure after a nonconformance, reject an incomplete action and inspect the affected training.
Evidence to keep: Linked versions, disposition, action ownership, reviewer decisions and the boundary with manufacturing or laboratory systems.
Health and safety
- Can a frontline worker or contractor report through the proposed access route?
- How are incomplete, duplicate or confidential submissions handled?
- Can investigators record a cause, supporting evidence and a challenged conclusion?
- Which risk, permit, exposure and training workflows require separate applications?
- What evidence is required before an action is closed or reopened?
Suggested demo task: Use a synthetic near miss, assign follow-up, change the reviewer and demonstrate a restricted record.
Evidence to keep: The original report, access decisions, investigation history and verification of the proposed action.
Environmental records
- Who owns each meter, sample, waste movement or other source record?
- How are units, missing readings and substituted estimates identified?
- Can a reviewer trace a corrected reading through calculations and reports?
- How are site-specific obligations, reminders and supporting records maintained?
- Which chemical, waste or emissions tasks require a specialist module or external system?
Suggested demo task: Correct a sample reading after review and trace its effect on a site report.
Evidence to keep: Units, source records, revisions, responsible reviewers and links to the applicable reporting requirement.
ESG and sustainability reporting
- Which entities, periods, frameworks and versions are in the quoted scope?
- Can a contributor show the source and method behind a reported number?
- How are estimates and supplier-provided values distinguished and replaced?
- Can reviewers request a correction without losing the original submission?
- What can an external reviewer inspect or export under the proposed permissions?
Suggested demo task: Request a metric from two entities, reject an unsupported submission and consolidate a corrected value.
Evidence to keep: The reporting boundary, calculation method, source evidence, approval and change history.
Analytics, AI and integrations
- How is each dashboard metric defined, including its denominator and exclusions?
- Which source system owns an identifier when two systems disagree?
- What detects failed, delayed or duplicate transfers and who resolves them?
- Which AI outputs show their source, uncertainty and correction history?
- Which connectors, API limits, environments and maintenance services are included?
Suggested demo task: Send a duplicate message through a proposed interface and challenge an AI-generated summary against its source.
Evidence to keep: The interface specification, error ownership, source links and the human review required before use.
Security, information ownership and recovery
- Where are production records, backups and support-access locations documented?
- Which identity, permission and access-log controls apply to the offered deployment?
- What do supplied assurance reports cover, and what period or exceptions apply?
- Who restores each component, and what evidence supports the proposed recovery arrangements?
- How are retention, export, post-contract access and deletion responsibilities agreed?
Suggested demo task: Withdraw access, attempt a restricted action and inspect a representative export and recovery record.
Evidence to keep: Controls and assurance material scoped to the actual service, configuration and records, reviewed by your responsible specialists.
Commercial scope and service
- Does the offer name every application, edition and role used in the demonstration?
- How are occasional users, contractors, new sites and archived records charged?
- Which implementation, migration, training and integration deliverables are included?
- What support languages, hours, escalation routes and response commitments are offered?
- What changes at renewal, expansion or contract exit, and which prices remain unknown?
Suggested demo task: Ask the vendor to price the demonstrated workflow, then add a site and an external participant.
Evidence to keep: An itemised offer, implementation responsibilities, support terms and explicit growth and exit assumptions.
Questions about specialist assurance, regulated records and reporting scope should be defined with the people responsible for those decisions. A vendor template, certificate logo or generated explanation does not establish that your intended process meets its obligations.
Your vendor demo scorecard
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.
New evaluation. A different set of vendors starts a separate scorecard; earlier observations are not copied or overwritten. Find earlier work under Saved evaluations.
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.
| 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.
Before you sign: operations and acceptance
List every essential requirement whose result is partial, unmet or untested, with an owner and a next action. A working demonstration in a different edition does not resolve the requirement in your quote. If you change a requirement, document why and who approved the change.
Operations and acceptance questions
- Can a sample migration reconcile record counts, attachments and history?
- Who administers access, changes templates, trains users and handles support?
- What does the proposed pilot include, cost and require from our team?
- Which essential requirements remain partial, unmet or untested?
- What evidence and approval are required before purchase or expansion?
Bring to the decision meeting: A reconciled sample migration, named operating owners and an acceptance plan tied to the tested configuration, with remaining gaps explicitly assigned.
Frequently asked questions
Are all of these questions mandatory requirements?
No. They organise the buying decision. Select the workflows and modules relevant to your purchase, and have the responsible people define essential requirements, preferences and exclusions. A specialist tool should not be rejected for an unrelated module that is outside the agreed scope.
Can we select the highest-scoring vendor?
Review essential requirements and evidence gaps first. A score can summarise preferences, but should not conceal an unmet requirement, an untested workflow or a feature quoted in a different edition.
Does configurable mean demonstrated?
No. Native, configured or integrated describes how the vendor proposes to deliver a requirement. Demonstrated, partial, unmet or untested describes the evidence you collected. Record the application, effort and cost, then test the configured workflow and retain the result.
How should AI features be evaluated in a demo?
Choose a defined task, use approved sample data and inspect source traceability, permissions, errors and human correction. Do not treat generated text as verified evidence or an accountable approval.
Who should attend the demo?
Include the people who perform and accept the workflow, plus the technical or specialist reviewers needed for the selected requirements. Test the relevant roles and exceptions; a fixed attendee count is not proof of sufficient coverage.