Seven questions before buying an emergency notification system

The emergency notification market has grown a great deal in a few years, and the sales demos all look alike: a polished dashboard, a mass send that arrives instantly, and a delivery chart. That makes it hard to tell products apart.

These seven questions do help. They come from projects in hospitals, ports, universities and public administrations, and they all point at the same thing: the difference between a sending tool and a response tool.

1What happens when the recipient does not answer?

This is the question that separates providers most. Sending is easy; what is hard is what happens in the silence.

A sending system will tell you how many messages were delivered. A response system escalates to the backup contact in the defined order, without requiring anyone to watch the dashboard. If the process depends on manual intervention, ask who will be performing it during a real activation.

2Is the confirmation from the device or from the person?

An SMS marked as delivered means it reached the handset. It does not mean anyone read it, or that they are coming.

Ask how responses are collected: whether the recipient can confirm from a voice call without installing anything, whether that confirmation appears on the dashboard, and whether «I accept» can be distinguished from «I can’t». During an activation in the middle of the night, a call that captures a response can be particularly effective.

3Where is the data, and under which framework?

You will be handling personal contact details of your staff and, in many cases, information belonging to a public body or an essential services operator.

Ask about the location of the data centres, compliance with the Spanish National Security Framework and the certified category. Do not settle for «we are GDPR compliant»: request the applicable certificate, its scope, its validity period and the body that issued it.

4Is the alert connected to the procedure?

Alerting is the beginning of the response, not the response.

After the alert you have to execute the plan: verify, activate teams, take conditional decisions, record evidence and close. If notification is not connected to that execution, you will have the alert traced in one tool and the actions in another — or on paper. Reconstructing the incident will mean cross-referencing them by hand.

5Do they understand your regulatory framework?

Many international providers offer solid products built for other regulatory contexts. When the conversation turns to a self-protection plan, a municipal emergency plan, a regional catalogue of activities subject to obligations or an External Emergency Plan, «it’s configurable» is not always enough.

Configurable can mean you will have to design the whole thing from scratch. Ask whether the provider has implemented your type of plan before, and ask for a specific case.

6In which languages, and who answers the phone?

These are two different questions worth asking together.

If you operate in a region with a co-official language, the alert has to be preparable in that language without improvising the translation during the incident. As for support: in an emergency at three in the morning, it matters whether a person will answer, in which language, and with what committed response time.

7Can it be tested without a real incident?

An emergency notification system is used rarely and always at the worst possible moment. If the first full test happens during an emergency, you will discover the problems in the wrong place.

Ask about drill mode: whether it lets you run the full procedure with a separate record, whether it measures time per task, and whether you can repeat the exercise with the corrections applied. How a provider treats drills says a lot about how they understand the product.

One final recommendation

Ask for the demo using your own data: real roles, your plan and your timings. Anyone can pass a standard demo; a demo built on a real procedure shows you where the product fits badly.