How to Choose Safety Software: 12 Demo Questions

Most safety software demos look good. The vendor drives, the data is clean, every screen loads fast and every report is already filled in. Then the system goes live, and the first supervisor on a night shift cannot find the near-miss form on a phone.

This guide is for group HSE and EHS directors, plant heads and the people who sit on the selection panel. It gives 12 questions to ask in a safety software demo, what a good answer looks like, and a scoring sheet. It is the hands-on companion to our enterprise EHS software RFP checklist: the RFP decides who gets a demo; these questions decide who gets the contract. It is general information, not legal advice.

Why demos mislead

A standard vendor demo shows the best path through the product with data the vendor prepared. It rarely shows what your people will do every day: report from the floor with gloves on, find an overdue action, or answer an auditor's question about one injury from two years ago. The fix is simple. Write your own scenarios, send them in advance, and ask the vendor to run them live, in their system, with you watching.

Testing with real users does not need a large study. Usability researcher Jakob Nielsen reported that a first test with five participants found about 85% of the usability problems, and recommended running several small tests rather than one big one. Two or three of your supervisors trying the reporting screen during the demo will tell you more than an hour of slides.

Before the demo: three things to prepare

Three real scenarios. For example: a near miss reported by a contractor on a phone; a lost-time injury that needs an investigation, root cause and corrective actions with owners; and a monthly group report with lost days, near misses and recordable injuries by country and site.
Your structure. A simple chart of your group, regions, countries and sites, and who should see what. Ask the vendor to set up a small copy of it.
One messy file. An anonymised extract of your current incident spreadsheet or register. How a vendor handles your real data says more than its sample data. See safety software vs spreadsheets for why that history matters.

12 questions to ask in a safety software demo

Reporting and adoption

1. "Show me a worker reporting a near miss on a phone, with a photo, start to finish." Time it. OSHA's recommended practices ask employers to establish a process for workers to report injuries, illnesses, close calls and hazards, and to remove barriers to participation such as language, education or skill levels. ISO 45001 clause 5.4 likewise asks organisations to remove or minimise obstacles to worker participation. If reporting takes many screens, people will stop reporting.

2. "What happens to the report next?" Ask to see who is notified, how it is reviewed, and how the reporter knows it was acted on. A report that disappears into a queue teaches people not to report again.

3. "Show me the same screen for a site manager, a country manager and a contractor." Good systems change what each person sees and can do based on their role and their place in the organisation.

Investigation and actions

4. "Take this lost-time injury through investigation, root cause and corrective actions." Look for actions with owners, due dates, reminders and evidence of closure attached to the action, and for lessons learned that other sites can see. Our guide to incident investigation and CAPA across many sites covers what good looks like.

5. "Show me every overdue action in one country, then open one." If finding overdue actions needs an export to Excel, the system will not close the loop.

Group view and data quality

6. "Click a number on the group dashboard and take me to the records behind it." Every KPI (lost days, near misses, recordable injuries, training hours) should drill down to site and then to the individual records. If a number cannot be traced, it cannot be defended to a board or an assurance provider.

7. "Who changed this severity rating, when, and what was it before?" Ask for the audit trail on a real record. Changes to injury classifications and dates are exactly what auditors, insurers and courts ask about later.

8. "Can you produce our legal injury log from the records?" In the United States, for example, OSHA requires recordable cases to be entered on the 300 Log and 301 Incident Report within seven calendar days, and allows records on a computer if it can produce equivalent forms when needed. Ask the same question for each country where you operate.

Access, security and data

9. "How is access restricted, and where is it enforced?" Ask whether a country manager is blocked on the server from other countries' records, not just hidden in the menu, and whether two-step verification is available. See role-based access for EHS software.

10. "Show me your data processing terms." Incident records include health data. Under GDPR Article 28, a processor needs the controller's written authorisation before using sub-processors, must support audits, and must delete or return the personal data at the end of the service, at the controller's choice. Under Article 33, a processor must tell the controller about a personal data breach without undue delay. Our EHS vendor DPA guide lists the clauses to check.

Rollout and audits

11. "How do our last two years of records get in, and who does the work?" Ask for the migration plan, who maps your old categories to the new ones, and how long until every site is working in the system. Without history, trend charts restart at zero.

12. "Our ISO 45001 auditor arrives next month. Show me the evidence for one clause." ISO 45001 requires documented information to be controlled, including access, version control and retention. A system that can show records organised by clause saves days before every audit; see ISO audit evidence by clause.

A simple scoring sheet

Score each question from 0 to 3 during the demo, not afterwards. Weight the questions that matter most to you; the example below doubles reporting and the group view because adoption and data quality decide whether the rest is used.

Area	Questions	Example weight	Score 0–3
Reporting and adoption	1–3	×2	☐
Investigation and actions	4–5	×1.5	☐
Group view and data quality	6–8	×2	☐
Access, security and data	9–10	×1.5	☐
Rollout and audits	11–12	×1	☐

Use this rule for each score: 0 = not shown or "on the roadmap"; 1 = possible with workarounds or custom work; 2 = shown live with some extra steps; 3 = shown live, on your scenario, quickly.

After the demo: a short pilot

For a group, a demo is a shortlist tool, not a decision. Before signing, run a short pilot at one or two sites with your own forms and users. Check three things at the end: how many reports came in compared with the old method, how many actions were closed on time, and whether the site manager would keep the system. Then plan the rollout to every site; see EHS system rollout across many sites.

Red flags

The vendor will not run your scenarios live, or asks to "follow up" on most questions.
Dashboards are screenshots, or numbers cannot be opened to the records behind them.
Access rules are a menu setting, not enforced on the server.
Migration of your history is your job, or priced separately with no plan.
Core features you asked about are described as "coming soon" with no date.
No clear answer on sub-processors, breach notification or returning your data at the end.

Frequently asked questions

What should I ask in a safety software demo?

Ask the vendor to run your own scenarios live: a worker reporting a near miss on a phone, an injury taken through investigation and corrective actions, a group dashboard drilled down to records, the audit trail on one record, how access is enforced, how your history is migrated and how ISO evidence is shown by clause.

How is a demo different from an RFP?

An RFP collects written answers from many vendors to build a shortlist. A demo tests a few shortlisted systems live against your scenarios and users. Use the RFP checklist first, then these 12 questions with the two or three vendors left.

How many people should attend a safety software demo?

Keep the panel small but include the people who will use it: an HSE lead, one or two supervisors who report from the floor, a site manager, and someone from IT or data protection. Usability research suggests a handful of real users finds most problems.

Should we run a pilot after the demo?

For a multi-site group, yes. A short pilot at one or two sites with your own forms shows whether reporting goes up, actions get closed and site managers want to keep the system, before you commit every site.

How AccelSafety answers these questions

AccelSafety is built for groups with many sites. Workers report incidents, near misses and hazards from the Android or iPhone app with photos. Every record sits in one hierarchy from group to region, country, cluster and site; each user sees only their part of it, enforced on the server, with two-step verification and a full audit trail. Investigations include root cause and lessons learned, actions are tracked to closure, and group KPIs such as lost days, near misses, recordable injuries and training manhours drill back to the source records. Evidence can be worked by ISO 45001 clause, and environmental data flows into AccelGreen, free with AccelSafety. Accel migrates your last two years of files, your team works in the system from the day after installation, the full history is in within 7 days, guaranteed, and users are unlimited. Book a demo and bring your own three scenarios: we will run them live.

How to choose safety software: 12 questions to ask in a demo