How to choose EHS software: the 30-minute evaluation framework
A practical, no-vendor-call framework for evaluating EHS software. The 5 dimensions that matter — and the 10 questions that disqualify a vendor in the first demo.
QEHS Ethos Team
Founding team
The QEHS Ethos Team built the QEHS platform after a decade managing EHS programs in heavy industry. We write about safety culture, regulatory strategy, and how software can get out of the way.
13 min read
Reviewed by QEHS Ethos Team — Founding team
Most EHS software evaluations take three to six months and involve a 50-question RFP that every vendor answers the same way. This guide proposes a faster path: five dimensions, ten dealbreaker questions, and a 30-minute live demo script that surfaces real platform depth versus slide-deck claims.
Dimension 1: Configurability. Can a super-admin build a new inspection type without vendor involvement? Ask the vendor to build a simple module — three fields, one workflow, one report — during the demo. If they defer to "professional services," disqualify. A true no-code platform lets super-admins author modules in minutes using a visual Composer. Look for field blocks that are typed (text, number, date, select, user, location) and capability blocks that add behaviour (computed fields, conditional visibility, repeaters).
Dimension 2: Workflow. Does the platform have a visual state machine with guards, approvals, SLAs, and side-effects? Or does it just move records through status labels? A real workflow engine can branch on record data ("if severity = high, require director approval"), escalate overdue items, and trigger side-effects (email, webhook, record creation). Test this by asking the vendor to add an approval step with a 48-hour SLA and an auto-escalation rule.
Dimension 3: Evidence grade. Every record should be auditor-ready on creation — immutably timestamped, user-attributed, and region-pinned. The platform should produce signed evidence bundles (ZIP with timestamped manifest) that survive chain-of-custody challenges. Ask whether the audit log is tenant-level and SIEM-exportable. For more on audit readiness, see the audit management use case and the ISO 45001 guide.
Dimensions 4 and 5 cover data residency and integration depth — both are table-stakes for enterprise buyers. The platform should pin data to a specific region and offer SSO (SAML + OIDC), SCIM provisioning, and a published subprocessor list. For integration evaluation, start with the integrations directory.
The ten dealbreaker questions are the ones that disqualify a vendor in the first demo, and they are the ones that do not need a 50-question RFP to answer. Each question is binary on a platform behaviour, not a vendor claim, and a vendor who answers with a roadmap is a vendor who fails the question. The questions are: can a super-admin build a module live, does the workflow engine escalate on SLA, is the audit log tenant-level and SIEM-exportable, is the data region-pinned, does the mobile app capture offline, is the report builder live against the data, is the integration bidirectional, is SCIM provisioning automated, is the evidence bundle signed, and is the configuration stored as versioned data. Ten questions, ten platform behaviours, and the vendor who passes eight is the vendor who makes the shortlist.
The 30-minute demo script is the one that turns the five dimensions into a test, and it is the one that separates the slide deck from the platform. The first ten minutes are the configurability test: ask the vendor to build a three-field inspection module with a fail guard and a photo field, live, in the demo. The second ten minutes are the workflow test: ask the vendor to add an approval step with a 48-hour SLA and an auto-escalation, and to show the escalation fire on an overdue item. The last ten minutes are the evidence test: ask the vendor to export a signed evidence bundle from a record created in the demo, with the manifest and the timestamps. A vendor who completes the script in 30 minutes is a vendor who has the platform; a vendor who defers any step to a follow-up is a vendor who has the deck.
The scoring rubric is the one that keeps the committee honest, and it is the one that survives the post-demo debate. Each of the five dimensions is scored on a three-point scale — passes live, passes with configuration, fails or deferred — and the score is recorded with the evidence: the screenshot of the built module, the config step for the workflow, the exported bundle. A score without evidence is an opinion, and the committee that scores on opinion is the committee that re-litigates the decision after the contract. The rubric is the artefact that makes the decision defensible to the procurement, the IT security review, and the finance sign-off, and the artefact is the one that does not depend on who was most persuasive in the room.
The RFP shortcut is the one that saves the three-to-six-month evaluation, and it is the consequence of the ten questions. A 50-question RFP that every vendor answers the same way is a document that does not disqualify anyone, and the procurement that runs it is the procurement that buys on price because it could not buy on distinction. The ten dealbreaker questions, sent in writing before the demo and answered in writing, are the RFP — the vendor who fails three is out before the demo, and the vendor who passes eight is in the shortlist without a 50-question document. The shortcut is not a less-rigorous evaluation; it is a more-rigorous one, because the questions are binary on behaviour rather than generous on claim.
The total cost of ownership is the number that decides the five-year decision, and it is the one the licence hides. The TCO is the licence plus the implementation plus the integration plus the configuration plus the training plus the ongoing vendor dependency, and the platform that needs a vendor for every new module carries the dependency into every year. A no-code platform that a super-admin configures is a platform whose five-year TCO is the licence plus a small internal headcount, and a configured-by-vendor platform is a platform whose five-year TCO is the licence plus a growing professional-services invoice. The TCO comparison that the buyer runs before the contract is the comparison that prevents the re-platform at year three.
- Send the ten dealbreaker questions in writing a week before the demo, and ask for a written answer per question — the answers are the first filter and the demo is the second.
- Hand the vendor the demo script — build a module, add an SLA workflow, export an evidence bundle — and run the script in 30 minutes, with the committee watching the screen and not the deck.
- Score each of the five dimensions on the three-point rubric, attach the screenshot or the config step as evidence, and record the score in the rubric before the post-demo debate.
- Call one reference customer in the industry at the scale, and ask the reference the dimension the vendor scored lowest on, not the dimension the vendor scored highest on.
- Read the contract for the data-residency clause, the termination export right, and the audit-log access, and treat the absence of any of the three as a disqualifier regardless of the demo score.
The framework is the one that collapses a three-to-six-month evaluation into a week, and the one that does it without losing the rigour. The five dimensions, the ten questions, the 30-minute script, and the scoring rubric are the four artefacts that make the decision, and the four together are the evaluation a committee can run without a vendor on the call. The platform that passes the framework is the platform that a safety or quality leader runs without a vendor on retainer, and the platform that fails it is the one that earns the vendor more than it earns the leader. For the related deep dive, see the QEHS software buying guide and the no-code platform post; for the standards the platform should evidence, the ISO 45001 certification guide.
The implementation-timeline red flag is the one a buyer catches in the reference call, and it is the one that confirms or denies the demo. A reference who says the implementation took six months and the vendor built every module is a reference whose platform was configured-by-vendor, regardless of what the demo showed. A reference who says the super-admin built the first module in the first week is a reference whose platform was no-code in practice and not just in the deck. The reference call is the validation of the demo, and the question about who built the modules is the one that turns a demo claim into a platform fact. The post-implementation review — a check at six months that the platform is still configurable without the vendor — is the one that confirms the choice held, and the check is the one that catches the drift before the second audit.