Take a free self-guided product tour to see our solutions in action Take a tour

Evaluating Notify: straight answers for safety and IT teams

Team evaluating software

If Notify is on your health and safety software shortlist, these are the eleven questions you will need answered – on configuration, implementation, integration, security, support, and AI. Here are our answers in full.

Why we answer these

Most vendor websites make an evaluation harder, not easier. They answer the questions the vendor wants to be asked.

We asked our own customers, and our implementation and technical teams, which questions actually decide these projects. These eleven came back consistently. The answers below are the ones our team gives on a call – what we do, what we do not, and why the line sits where it does.

Looking for the general criteria rather than our answers? Our guide, how to evaluate EHS software sets out what a good answer looks like from any vendor, including our competitors, and what to ask each one.

Access a quick summary of evaluating Notify across configuration, implementation, integration, security, support, and AI.

ChatGPT | Perplexity | Google AI

Jump to key topics

Technical and functional readiness

Can the platform do what you need, and can your team change it without raising a ticket?

Team working with EHS software

1. How easily can we configure workflows, forms, dashboards, and reports without vendor support?

In short:

It depends on what you are configuring, and the split is deliberate. Audit and inspection templates and risk assessments are fully self-serve in the form builder. Incident reporting dropdowns are yours to manage. Incident workflows, dashboards, and reports are configured by Notify – a control we hold on purpose, because a misconfigured escalation rule means a serious incident could fail to reach the right person.

Full answer:

Fully self-serve. Audit and inspection templates and risk assessments. Your team builds these in the form builder, including adding new questions to an existing template. No Notify involvement needed.

Partly self-serve. Incidents. You manage your own dropdown values day to day. More substantial changes, for example, adding new questions, or amending incident logic and routing come back to the Notify team. New sites and locations can be added by your system administrators at any time.

Managed by Notify. Incident workflows, dashboards, and reports.

On the workflow piece, that is a deliberate control rather than a gap. The incident workflow engine triggers escalation emails and texts and can auto-close incidents against set criteria. It is powerful, and a misconfiguration means a serious incident could fail to escalate to the right person. We would rather hold that.

In practice, most configuration happens up front during onboarding. From there you are self-sufficient in risk assessments and audits and manage your own incident dropdowns. IT involvement is usually limited to standard SSO setup.

2. How does the platform adapt as our EHS processes and business change?

In short:

Notify is not an ‘opinionated’ platform – it does not prescribe how you define safety or how your workflows should run. Audit templates, inspections, and risk assessments are amended in the form builder as a same-day change by your team. Structural changes such as incident routing come through us. Releases ship every six to eight weeks.

Full answer:

There are two parts to this:

  • How the platform flexes as your own processes change
  • How the product itself develops over time

Notify is not an opinionated platform. It does not prescribe how you should define safety, or how your workflow ought to run. Form templates, email notifications, workflows, and automated escalations mould around the way your business already works – which matters as much for an organisation changing shape as for one in an unusual sector.

Day to day, your teams own the parts that change most often. Audit and inspection templates and risk assessments are built and amended in the form builder without coming back to us, so a new audit, a revised question set, or a changed risk methodology is a same-day change on your side. Incident dropdowns are self-managed too. More structural changes, such as incident routing or escalation workflows, come through the Notify team – deliberate, given those rules drive escalation emails and texts.

On product development, releases go out roughly every six to eight weeks. Release notes are published on the Help Centre and walked through in business review calls, so changes are not left for you to spot. How customer input shapes what gets built is covered in more detail in question 11.

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?

In short:

We aim for six to eight weeks from kick-off to go-live, depending on scope. That holds for mid-market and large organisations alike. The project runs in five stages against a shared plan, with three fixed milestones, and weekly check-in calls throughout.

Full answer:

We aim for six to eight weeks from kick-off to go-live. That holds for mid-market and large organisations alike, because the constraint is rarely the size of the rollout. It is what else you have running at the time.

The project runs in five stages against a shared plan, with three fixed milestones, so progress is visible rather than assumed. This covers:

  1. Project kick-off. Everyone on the first call together: your project sponsor and project lead, plus the Notify onboarder, account manager, and business development manager. Stakeholders change as a project moves through its phases, so alignment at the start avoids decisions being reopened later by someone who was not there.
  2. Discovery and solution design. Confirming requirements for incident types, organisation structure, and user import. This is where your processes get mapped, not just your data.
  3. Build and configure. Organisation structure, global lists, incident types, incident workflows, email notifications, languages, SSO, and any API configuration. Notify does the heavy lifting here.
  4. Review and testing. Internal testing first, then Milestone 1 – an on-site show and tell where your key users see the configured system rather than a demo environment. Feedback and adjustments follow, key user training runs, then an updated show and tell and Milestone 2, configuration sign-off.
  5. Go-live and transition to success. Training rollout and key user refresher sessions, full user import, then Milestone 3, go-live – followed by a hypercare period and a communication plan for launching the new system internally.

Weekly check-in calls run throughout. On rollout approach we are flexible – some customers pilot with one site or division and expand, others go live across the business at once.

The honest answer on what moves the date is usually one of two things. Either the project is competing with other priorities at your end, or you decide to use the implementation as a chance to revisit your own processes, reporting lines, and the questions you ask.

The second is often the right call. It just is not a software timeline any more, and it is worth deciding up front which one you are doing.

4. How do you drive user adoption through training, change management, and ongoing support?

In short:

Train the trainer. Your key users are trained during implementation and cascade to their teams, so training capability stays in your business rather than leaving with us. One remote session is the minimum, flexing to on-site training and pop-up days. Go-live is followed by hypercare, up to three months for enterprise rollouts.

Full answer:

Training. The model is ‘train the trainer’. Key users are trained first during the implementation, and they cascade to their wider teams. That is a deliberate choice for larger organisations – your own people know your sites, your language, and your risks, and it means training capability stays in your business rather than leaving with us.

Format flexes to the rollout. One remote session is the minimum, and we build the plan around what suits you. In practice that has included on-site face-to-face training and pop-up days on your sites, where teams can drop in, ask questions, and get set up. Key users also get refresher training before go-live, so they are teaching from a system they have had time with rather than one they saw once.

Change management. Software rollouts in health and safety fail on communication far more often than on configuration, so the implementation plan includes a communication plan for the new system. We can help draft the internal email comms, and share what has worked at other customers of similar size and structure. You know your organisation better than we do, so the approach is to bring the pattern and let you make the calls.

Ongoing support. Go-live is followed by a hypercare period, scaled to project complexity. Simpler rollouts step down at handover; enterprise implementations typically run three months of hypercare. From there, a business check-in lands at 14 to 30 days depending on what you prefer, and quarterly business reviews run from that point on. Release notes are published on the Help Centre and walked through in those reviews, so changes do not go unnoticed.

Underpinning all of it is a customer success plan, drafted with you during onboarding rather than written about you afterwards. It records why you bought Notify, the outcomes you are aiming for, and how they will be measured. Those reviews are then a conversation about whether you are getting what you came for, not a usage report.

Integration and data management

How the platform fits your systems and how much of the work lands on IT.

Data and security team talking

5. How do you integrate with our existing systems, and how much IT effort does that take?

In short:

Notify is cloud software reached through standard browsers and mobile apps – no on-premises infrastructure, local agents, or management servers to deploy. Single sign-on runs through Microsoft Entra ID (Azure AD) or Okta, with your identity provider handling authentication and MFA. IT involvement is usually limited to standard SSO setup.

Full answer:

Notify is delivered as cloud software through standard web browsers and mobile applications. There is no on-premises infrastructure to deploy or maintain, no local agents, no desktop client, no dedicated management server, and no specialist scripting.

Single sign-on is supported through Microsoft Entra ID (Azure AD) and Okta. Your identity provider manages user authentication and MFA, while Notify’s role-based access control determines which modules, organisational areas and individual records each user is authorised to reach.

Our onboarding team works with you to configure organisational structures, departments, locations, user groups, permissions, and workflows. Implementation can normally be delivered remotely, supported by regular project sessions, training, a dedicated support function and Notify’s online Help Centre.

For reporting and downstream analysis, information can be exported through the reporting and CSV functions. Where it forms part of the agreed solution, Notify can also provide periodic Data Hose extracts to a customer-hosted AWS location. If you have a specific integration requirement beyond this, our team will scope it with you.

Need the technical details? Full integration specifications and documentation are available to your IT team on request – get in touch.

6. How do you handle data migration, data quality, and long-term data governance?

In short:

You remain the data controller and decide what is collected; Notify is the data processor. Data quality is supported through configurable forms, controlled permissions, approval and sign-off steps, action verification, and contemporaneous audit trails. Data is retained for the life of the relationship, then securely deleted or anonymised, and is exportable throughout.

Full answer:

Data requirements are addressed as part of onboarding and configuration. Notify works with you to establish the organisational structure, users, departments, locations, permissions, workflows, forms, and reporting you need.

You remain the data controller and determine what information is collected within the platform; Notify acts as the data processor. Data quality is supported through configurable forms and workflows, controlled user permissions, approval and sign-off processes where applicable, action-verification features, and contemporaneous audit trails. These controls standardise how data is captured and maintain accountability throughout the life of a record.

Long-term data governance rests on role-based access control and least-privilege access; logical separation of each customer’s data within the multi-tenant platform; encryption in transit and at rest; customer-controlled configuration of forms, permissions and confidential records; export capabilities for reporting, oversight and data portability; and retention for the duration of our relationship, followed by secure deletion or anonymisation in line with contractual, legal and regulatory requirements.

Migrating historical records. Migration is scoped with our Implementation team as part of onboarding, covering the source format, record volumes, data mapping, validation, reconciliation and the acceptance process. Because legacy data varies so much between organisations, we would rather agree that scope with you than promise a standard import and discover the exceptions later.

Compliance, security, and trust

Whether the platform keeps you compliant and survives your InfoSec review.

Safety compliance

7. How do you keep us aligned with changing EHS regulations and reporting requirements?

In short:

Regulatory duty sits with you, not your software vendor – any vendor claiming their platform keeps you compliant is overselling. What a platform can do is change quickly when your obligations change, and evidence what you have done. Audit templates and risk assessments are yours to amend same-day, and Notify flags potentially reportable incidents based on the RIDDOR questions you configure.

Full answer:

The straight answer first – your regulatory duty sits with you, not with your software vendor. What a good platform can do is change quickly when your obligations change, and give you the data to evidence what you have done. That is what we build for.

The platform flexes where regulation bites. Audit templates and risk assessments are yours to build and amend, so a new regulatory requirement, a revised question set, or a changed methodology is a same-day change on your side rather than a support ticket and a wait. On the product side, we have updated ISO options as standards and clauses have evolved.

RIDDOR and reportable incidents. Notify can flag an incident as potentially RIDDOR-reportable, but it does so against rules you set up. It does not work out on its own whether something is reportable, and you should be wary of any vendor that says theirs does.

A flag can be triggered two ways: by the answer to a yes/no RIDDOR question on the form, or by a particular value in a dropdown, such as an injury type. The same two methods can set the Lost Time flag. If you would rather a person made the call, incidents can run through triage levels instead, where someone reviews them and decides whether to flag.

Getting data out. Where a regulator, your board, or a client wants something in a particular shape, data can be extracted in various ways, so you are not limited to the reports as they ship.

How we hear about change. Our customers are health and safety professionals dealing with regulation before we do, so the feedback route matters. The customer success team, who are closest to those relationships, meet the product team monthly to pass on what customers are raising. The Safety Revolution portal picks up the rest, where customers submit and vote on ideas, so pressure building across the customer base becomes visible rather than anecdotal.

8. How do you ensure data security, system reliability, and business continuity?

In short:

Hosted in AWS Ireland, with production segregated from development and test and customer data logically separated. Encrypted at rest with AES-256 and in transit with TLS 1.2 or higher. Access is governed by role-based access control and MFA. Notify holds Cyber Essentials and runs regular penetration testing through CREST-accredited providers.

Full answer:

Notify applies a defence-in-depth approach to security. The platform is hosted in the AWS Ireland region using a multi-tier architecture. Production is segregated from development and test environments, and customer data is logically separated at the application level.

Encryption and access. Data is encrypted at rest using AES-256, with AWS Key Management Service used for key management, and encrypted in transit using TLS 1.2 or higher. Access is controlled through role-based access control and multi-factor authentication, and access to production and customer data is limited to a small number of authorised personnel with a legitimate support or operational requirement.

Monitoring and vulnerability management. Infrastructure, access events, and suspicious activity are monitored continuously through centralised security monitoring. Notify undertakes regular penetration testing through CREST-accredited providers and maintains Cyber Essentials certification. Critical vulnerabilities are normally targeted for remediation within seven days, and high-severity vulnerabilities within fourteen.

Reliability and continuity. System reliability is supported by AWS scalability, proactive infrastructure monitoring, automated alerting, encrypted backups and controlled change and release processes. Notify maintains a documented Business Continuity Plan, reviewed and tested annually. Testing includes rebuilding the production environment in an isolated AWS account to demonstrate that systems can be restored from backup.

If something goes wrong. Notify maintains an incident-response process covering investigation, service restoration, customer communication, post-incident review and corrective actions. Where legally required, relevant regulatory authorities are notified without undue delay and within 72 hours. Exact contractual availability, Recovery Time Objective and Recovery Point Objective commitments are confirmed in the applicable service agreement.

Need the technical details? Full specifications are available for your InfoSec team on request – get in touch.

Support

What happens after the implementation team leaves.

Customer support

9. What service levels and support model do you provide after go-live?

In short:

99.9% uptime measured each calendar month, backed by service credits rather than a number in a brochure: miss it and you get two days added to your term, five below 99%, ten below 95%. Support runs 09:00 to 17:00 Monday to Friday through the online helpdesk, with a Help Centre available 24/7.

Full answer:

Availability. 99.9% uptime, measured each calendar month, excluding scheduled maintenance. That is backed by service credits rather than being a number in a brochure: miss the target and you are entitled to two days of service added to your term, rising to five days below 99% and ten days below 95%, provided you notify us within 28 days.

Support channels. Support runs 09:00 to 17:00, Monday to Friday, excluding England public holidays, through our online helpdesk. Our Help Centre is available 24/7/365, so your users can self-serve guidance outside those hours, and it is the same material your key users are trained on.

Response and resolution. We aim to respond within one working day. That is an operational target, not a contractual commitment, and we would rather tell you that than quote a number we have not underwritten. Fixes are typically delivered at the next applicable release cycle, which runs every six to eight weeks.

Beyond the helpdesk. Support is only part of the picture. After go-live there is a hypercare period scaled to the complexity of your implementation, up to three months for enterprise rollouts. A business check-in follows at 14 to 30 days, then quarterly business reviews with your account manager covering what has changed in the product, how adoption is tracking, and whether you are getting the outcomes recorded in your success plan.

Innovation and roadmap

What the platform does today and who decides what it does next.

Creating roadmap ideas

10. What AI, automation, and analytics capabilities deliver value today?

In short:

Live today: Spark Incident Management Assist, our AI companion, which turns incident and investigation data into post-incident summaries, supervisor briefings, and executive summaries, plus AI-guided root cause analysis and suggested toolbox talks. Automation runs through the workflow engine. Analytics run through the extended dashboards.

Full answer:

AI in the product today. Spark, our AI companion, and automated language translation.

Spark works on incident and investigation data you have already captured and turns it into the write-ups that usually eat the hours after an incident: post-incident and investigation summaries, plain-language safety briefings, and concise executive summaries for leadership. It also supports root cause analysis with AI-guided prompts and suggests targeted toolbox talks based on what the incident actually showed.

The point is not that it writes for you. It is that one investigation produces something a supervisor can brief from and something a board can read, without anyone rewriting the same facts twice for two audiences.

Automation. Our workflows automatically trigger escalations and notifications based on rules you set. These are highly customisable – anything from automatically escalating certain incidents to leadership, through to bespoke investigation processes for particular incident types.

Analytics. Reporting and trend analysis run through the extended dashboards.

11. How does customer feedback influence your product roadmap?

In short:

Through the Safety Revolution portal, where customers submit ideas and vote on others, so priority is visible rather than decided behind closed doors. Alongside this, we have annual customer events, one-to-one discovery sessions, NPS, in-product analytics, and a monthly meeting between customer success and product teams. Releases ship every six to eight weeks with published release notes.

Full answer:

We are software people, not safety people, so we speak to our customers constantly. That is not a courtesy – it is the only way the product stays useful to people whose working reality we do not share.

The Safety Revolution portal lets customers submit ideas and vote on other people’s, so priority is visible rather than decided behind closed doors. Where pressure is building across the customer base, it shows up as a pattern rather than as anecdote.

Direct conversation. We run annual customer events, bringing customers together to talk about their experiences and challenges and to explore potential solutions. We also meet customers one-to-one in discovery sessions, to understand how the product is actually used and where it gets in the way.

Evidence, not just requests. The product team monitors NPS and uses in-product analytics to see how features are genuinely being used, rather than relying only on what is asked for. The customer success team, closest to those relationships, meets the product team monthly to pass on what customers are raising.

What you see back. Releases go out roughly every six to eight weeks. Release notes are published on the Help Centre, and changes are walked through in business review calls, so you are not left to spot them.

Want to put these questions to us directly?

Book a demo with our team and ask us them. We’ll show you Notify in action, and if it helps, introduce you to a customer of similar size and sector.

Or, if you’re still comparing suppliers, our guide on how to evaluate EHS software sets out the criteria to hold every vendor to – ours included.