El mercat de la notificació d’emergències ha crescut molt en pocs anys, i les demostracions comercials s’assemblen: un tauler acurat, un enviament massiu que arriba a l’instant i un gràfic de lliuraments. Amb això és difícil distingir-les.
Aquestes set preguntes sí que ajuden a fer-ho. Neixen de projectes en hospitals, ports, universitats i administracions, i apunten al mateix: la diferència entre una eina d’enviament i una eina de resposta.
1Què passa quan el destinatari no contesta?
És la pregunta que més separa uns proveïdors dels altres. Enviar és fàcil; el difícil és el que passa en el silenci.
Un sistema d’enviament et dirà quants missatges s’han lliurat. Un sistema de resposta escala al suplent en l’ordre definit, sense exigir que algú vigili el tauler. Si el procés depèn d’una intervenció manual, pregunta qui la farà durant una activació real.
2La confirmació és del lliurament o de la persona?
Que un SMS consti com a lliurat vol dir que ha arribat al terminal. No vol dir que algú l’hagi llegit ni que s’hi presentarà.
Pregunta per la recollida de resposta: si el destinatari pot confirmar des d’una trucada de veu sense instal·lar res, si aquesta confirmació apareix al tauler i si es pot diferenciar «accepto» de «no puc». En una activació de matinada, una trucada amb resposta pot ser especialment eficaç.
3On són les dades i sota quin marc?
Gestionaràs dades de contacte personals de la plantilla i, en molts casos, informació d’una entitat pública o d’un operador de serveis essencials.
Pregunta per la ubicació dels centres de dades, el compliment de l’Esquema Nacional de Seguretat i la categoria certificada. No et quedis en «complim el RGPD»: demana el certificat aplicable, el seu abast, la vigència i l’entitat que el va emetre.
4L’avís està connectat amb el procediment?
Avisar és el principi de la resposta, no la resposta.
Després de l’avís cal executar el pla: verificar, activar equips, prendre decisions condicionades, registrar evidències i tancar. Si la notificació no està connectada amb aquesta execució, tindràs l’avís traçat en una eina i les actuacions en una altra —o en paper—. En reconstruir l’incident caldrà creuar-les a mà.
5Entén el vostre marc normatiu?
Molts proveïdors internacionals ofereixen productes sòlids construïts per a altres contextos reguladors. Quan la conversa arriba a un pla d’autoprotecció, un PEMU, un catàleg autonòmic d’activitats obligades o un Pla d’Emergència Exterior, «és configurable» no sempre és suficient.
Configurable pot voler dir que ho hauràs de dissenyar tot des de zero. Pregunta si el proveïdor ja ha implantat el teu tipus de pla i demana un cas concret.
6En quines llengües, i qui respon el telèfon?
Són dues preguntes diferents que convé fer juntes.
Si operes en una comunitat amb llengua cooficial, l’avís s’ha de poder preparar en aquesta llengua sense improvisar la traducció durant l’incident. I pel que fa al suport: en una emergència a les tres de la matinada, importa saber si respondrà una persona, en quina llengua i amb quin temps d’atenció compromès.
7Es pot provar sense que sigui un incident real?
Un sistema de notificació d’emergències es fa servir poques vegades i sempre en el pitjor moment. Si la primera prova completa es fa durant una emergència, descobriràs els problemes al lloc equivocat.
Pregunta pel mode simulacre: si permet executar el procediment complet amb un registre separat, si mesura temps per tasca i si permet repetir l’exercici amb les correccions aplicades. La manera com el proveïdor tracta els simulacres diu molt de com entén el producte.
Una recomanació final
Demana la demostració amb les teves pròpies dades: rols reals, el teu pla i els teus temps. Una demostració estàndard la supera qualsevol; una demostració amb un procediment real mostra on encaixa malament el producte.
Si el proveïdor es resisteix a demostrar el sistema amb un escenari realista, això també és informació per decidir.
Prova VES amb el teu propi procediment
Comprova com encaixen la notificació multicanal, els escalats i l’execució traçable en un mateix flux.
