Siete preguntas antes de contratar un sistema de notificación de emergencias

El mercado de la notificación de emergencias ha crecido mucho en pocos años, y las demostraciones comerciales se parecen: un panel cuidado, un envío masivo que llega al instante y una gráfica de entregas. Con eso es difícil distinguir.

Estas siete preguntas sí ayudan a hacerlo. Nacen de proyectos en hospitales, puertos, universidades y administraciones, y apuntan a lo mismo: la diferencia entre una herramienta de envío y una herramienta de respuesta.

1¿Qué pasa cuando el destinatario no contesta?

Es la pregunta que más separa a unos proveedores de otros. Enviar es fácil; lo difícil es lo que ocurre en el silencio.

Un sistema de envío te dirá cuántos mensajes se entregaron. Un sistema de respuesta escala al suplente en el orden definido, sin exigir que alguien vigile el panel. Si el proceso depende de una intervención manual, pregunta quién la hará durante una activación real.

2¿La confirmación es de entrega o de la persona?

Que un SMS conste como entregado significa que llegó al terminal. No significa que alguien lo haya leído ni que vaya a acudir.

Pregunta por la recogida de respuesta: si el destinatario puede confirmar desde una llamada de voz sin instalar nada, si esa confirmación aparece en el panel y si se puede diferenciar «acepto» de «no puedo». En una activación de madrugada, una llamada con respuesta puede ser especialmente eficaz.

3¿Dónde están los datos y bajo qué marco?

Vas a manejar datos de contacto personales de la plantilla y, en muchos casos, información de una entidad pública o de un operador de servicios esenciales.

Pregunta por la ubicación de los centros de datos, el cumplimiento del Esquema Nacional de Seguridad y la categoría certificada. No te quedes en «cumplimos el RGPD»: solicita el certificado aplicable, su alcance, su vigencia y la entidad que lo emitió.

4¿El aviso está conectado con el procedimiento?

Avisar es el principio de la respuesta, no la respuesta.

Después del aviso hay que ejecutar el plan: verificar, activar equipos, tomar decisiones condicionadas, registrar evidencias y cerrar. Si la notificación no está conectada con esa ejecución, tendrás el aviso trazado en una herramienta y las actuaciones en otra —o en papel—. Al reconstruir el incidente habrá que cruzarlas a mano.

5¿Entiende vuestro marco normativo?

Muchos proveedores internacionales ofrecen productos sólidos construidos para otros contextos regulatorios. Cuando la conversación llega a un plan de autoprotección, un PEMU, un catálogo autonómico de actividades obligadas o un Plan de Emergencia Exterior, «es configurable» no siempre es suficiente.

Configurable puede significar que tendrás que diseñarlo todo desde cero. Pregunta si el proveedor ha implantado antes tu tipo de plan y pide un caso concreto.

6¿En qué idiomas, y quién responde el teléfono?

Son dos preguntas distintas que conviene hacer juntas.

Si operas en una comunidad con lengua cooficial, el aviso debe poder prepararse en esa lengua sin improvisar la traducción durante el incidente. Y respecto al soporte: en una emergencia a las tres de la mañana, importa saber si responderá una persona, en qué idioma y con qué tiempo de atención comprometido.

7¿Se puede probar sin que sea un incidente real?

Un sistema de notificación de emergencias se utiliza pocas veces y siempre en el peor momento. Si la primera prueba completa ocurre durante una emergencia, descubrirás los problemas en el lugar equivocado.

Pregunta por el modo simulacro: si permite ejecutar el procedimiento completo con un registro separado, si mide tiempos por tarea y si permite repetir el ejercicio con las correcciones aplicadas. La forma en que el proveedor trata los simulacros dice mucho de cómo entiende el producto.

Una recomendación final

Pide la demostración con tus propios datos: roles reales, tu plan y tus tiempos. Una demostración estándar la supera cualquiera; una demostración con un procedimiento real enseña dónde encaja mal el producto.