How to use this guide
Bring the questions to the demo, then follow up in writing. Vendors may struggle to get through eleven questions in a short demo, so keep track of which ones were answered properly, which got half an answer, and which weren’t reached. Ask for the rest by email afterwards.
Agree your weightings before you see the answers. Decide which categories matter most to your organisation first, or you will unconsciously weight them towards whoever answered best.
Take questions 5, 6 and 8 to IT and InfoSec early. Integration, data, and security are where deals stall at contract stage. Finding the problem in week two isn’t too painful; finding it in month four can be.
Ask every vendor what they cannot do. Every platform has limits. A supplier who is transparent about theirs and can explain the reasoning gives you a fair idea of how they will handle things once you are a customer.
Technical and functional readiness
Can the platform do what you need, and can your team change it without raising a ticket?
1. How easily can we configure workflows, forms, dashboards, and reports without vendor support?
Why this matters: The gap between “configurable” and “configurable by you” can be where many EHS projects stall. If every form change is a chargeable change request, the system freezes at go-live and can stops matching how you work.
What a good answer looks like – from any vendor:
- Named roles in your team who can make changes, not just “it’s configurable”
- A clear line between what your admins can do and what genuinely needs the vendor
- Changes that can be made without waiting for a release cycle
Worth asking: Whether your own administrators could add a new question to an audit template, and what would need to come back to the vendor.
2. How does the platform adapt as our EHS processes and business change?
Why this matters: You are not buying for the organisation you are today. Acquisitions, new sites, new sectors, and new regulations all arrive within the contract term, and a platform that only fits today’s process becomes the thing everyone works around.
What a good answer looks like – from any vendor:
- A platform that adapts to your process rather than requiring you to adopt theirs
- The changes you make most often are the ones you can make yourself
- Multi-site, multi-entity, and multi-language handled natively, not by workarounds
- Honest limits – every platform has them
Worth asking: What happens if you acquire a business that runs a different incident process.
Implementation and adoption
How quickly you get value, and whether the frontline actually uses it.
3. What is your typical implementation approach and timeline for an organisation of our size?
Why this matters: Every vendor will give you a timeline. The detail behind it matters more – how the project is phased, how much of your own team’s time it needs, and what tends to cause delays.
What a good answer looks like – from any vendor:
- Phases with real durations, and milestones you sign off
- An explicit estimate of your team’s effort
- Candour about the two or three things that most often delay projects
Worth asking: How much of your own team’s time the project needs, and who from the vendor you would be working with.
4. How do you drive user adoption through training, change management, and ongoing support?
Why this matters: An EHS platform only pays back if the people doing the work actually use it. Low frontline adoption is one of the most common reasons systems get replaced.
What a good answer looks like – from any vendor:
- Training that reaches the frontline, not just the safety team
- Capability that stays in your business after the implementation team leaves
- A communication plan treated as part of the rollout, not an afterthought
Worth asking: Who trains your users in year two, once the implementation team has moved on.
Integration and data management
How the platform fits your systems, and how much of the work lands on IT.
5. How do you integrate with our existing systems, and how much IT effort does that take?
Why this matters: If the platform does not connect to your other systems, someone ends up keeping the same user list in two places and typing the same data twice. Your IT team will want to know how much of that work lands with them.
What a good answer looks like – from any vendor:
- Single sign-on and user provisioning as standard, not chargeable extras
- Named identity providers, not “we support SSO”
- Documented integration specifications you can ask for
- A realistic estimate of what your IT team actually has to do
Worth asking: Which systems the vendor has already connected to, and how many days of your IT team’s time to allow for.
6. How do you handle data migration, data quality, and long-term data governance?
Why this matters: Your incident history is a legal record as well as your trend data. Migration is a common cause of delay at go-live, and it is worth knowing early how you would get the data back out if you ever changed supplier.
What a good answer looks like – from any vendor:
- Clarity on what gets scoped, who owns validation, and what sign-off looks like
- Honesty about what does not migrate cleanly, and why
- Retention and archiving you control, aligned to your own policy
- A clear exit route: full export, in a usable format, on demand
Worth asking: What you would get back if you ever moved supplier, in what format, and how long it would take.
Compliance, security, and trust
Whether the platform keeps you compliant, and survives your InfoSec review.
7. How do you keep us aligned with changing EHS regulations and reporting requirements?
Why this matters: Regulations and standards change, and so do the reports you have to produce. It is worth establishing early how much of keeping up to date is the vendor’s responsibility and how much is yours.
What a good answer looks like – from any vendor:
- Audit trails that would stand up to an inspector or a tribunal
- A clear statement of where vendor responsibility ends and yours begins
Worth asking: How you would evidence compliance if an inspector turned up, and what the system can produce.
8. How do you ensure data security, system reliability, and business continuity?
Why this matters: Security reviews hold up lots of software purchases. InfoSec teams want certificates, test reports, and a data processing agreement they can read.
What a good answer looks like – from any vendor:
- Certifications named and current, with certificates available on request
- Data location stated plainly, and a data processing agreement ready to sign
- Independent penetration testing on a stated cycle, by an accredited provider
- Continuity commitments that are tested, not just documented
Worth asking: What documentation the vendor can send your InfoSec team, and how quickly.
Support
What happens after the implementation team leaves.
9. What service levels and support model do you provide after go-live?
Why this matters: Service levels are worth checking in the contract itself. Look at the support hours, the response times, and what remedy you have if the vendor misses them.
What a good answer looks like – from any vendor:
- An uptime figure with a remedy attached, and terms you can read before contract stage
- Support hours stated plainly, including what happens outside them
- Honesty about which commitments are contractual and which are targets
- Support included, not sold as a premium tier for basic service
Worth asking: Whether the uptime figure carries a remedy, and whether the response time is contractual or a target.
Innovation and roadmap
What the platform does today, and who decides what it does next.
10. What AI, automation, and analytics capabilities deliver value today?
Why this matters: Almost every vendor now has something to say about AI. Ask which features are live in the product today, which are in beta, and which are still on the roadmap, and ask to see the live ones working.
What a good answer looks like – from any vendor:
- Live capabilities demonstrated, clearly separated from roadmap
- A stated outcome – for example, time saved or risks surfaced earlier
- Clarity on whether your data is used to train shared models
- AI you can switch off, with a human decision point where it matters
Worth asking: Which AI features are live in the product today, and whether your data is used to train shared models.
11. How does customer feedback influence your product roadmap?
Why this matters: You may want something the product doesn’t yet do. It is worth knowing how requests are captured, how they get prioritised, and whether you would be told what happened to yours.
What a good answer looks like – from any vendor:
- A named route for requests, and a way to see what happened to yours
- Specific examples of customer-originated features that shipped
- A visible release cadence and published release notes
- Honesty that not everything gets built and how priorities are set
Worth asking: How you would find out what happened to a feature request after you submitted it
How does Notify answer these?
We put these eleven questions to our own team and published the answers in full. Read our answers: Evaluating Notify: straight answers for safety and IT teams.
Evaluating across multiple sites? Our guide, 7 questions to ask when choosing SHEQ software for multi-site operations covers what the product needs to do day-to-day. The eleven above cover what the vendor needs to do.