El mapa de notificaciones, también llamado matriz de notificaciones, es el documento que enumera, antes del desarrollo, cada aviso que envía el sistema: el evento que lo dispara, quién lo recibe, por qué canal, en qué momento, con qué texto, qué pasa si no llega y quién no debe recibirlo. En la app de salud que estamos modelando, tiene 78 notificaciones, y el usuario puede desactivar solo 3. Hecho antes del código, evita avisos a quien está de licencia, códigos por WhatsApp detenidos a la espera de la aprobación de Meta y datos sensibles en la pantalla bloqueada del celular.
Qué es un mapa de notificaciones#
El mapa de notificaciones es el documento que enumera todos los avisos que envía un sistema, uno por fila, antes de que alguien escriba el código. Cada fila dice qué dispara el aviso, quién lo recibe, por qué canal, en qué momento, con qué texto y qué pasa si no llega. Sale del alcance del proyecto y sirve como especificación para quien programa y como guion para quien prueba. Algunos equipos lo llaman matriz de notificaciones.
En el documento de alcance, los avisos suelen aparecer dispersos, en una frase como "se avisa al cliente" en medio de la descripción de un módulo. El mapa junta todas esas frases en un solo lugar y hace que cada una responda las mismas preguntas.
Cada notificación recibe un código fijo, como AUTH-01 o PAG-03, que acompaña al aviso en el código fuente, en los registros del servidor y en las pruebas. Cuando un aviso sale del producto, su código se retira y no se vuelve a usar.
El tamaño del mapa depende del producto. En la app de salud que estamos modelando, tiene 78 notificaciones, para el paciente, para el médico y para el equipo que opera la plataforma. En un sistema de informes técnicos que mapeamos, tiene dos, las dos por correo y las dos de acceso a la cuenta. Los dos mapas están completos. El mapa es uno de los documentos que entregamos antes del desarrollo en todo proyecto de software a medida que envía avisos.
Qué tiene que decir cada fila del mapa#
Una fila completa responde siete preguntas: qué evento dispara el aviso, quién lo recibe, por qué canal, cuándo sale, qué dice el texto, qué pasa si la entrega falla y quién, aunque participe del evento, no debe recibirlo. Cuando una de ellas queda en blanco, la respuesta termina dándola quien está programando, en medio de la tarea.
- El evento. El hecho del sistema que dispara el aviso, escrito como ocurre: "el pago fue aprobado", y no solo "aviso de pago".
- Quién lo recibe. El perfil y, a veces, la persona exacta, como el responsable del caso, o todos los administradores cuando el caso todavía no tiene responsable.
- El canal. Correo, push, WhatsApp, SMS o el aviso dentro del propio sistema.
- Cuándo. En el momento, a una hora fija, un tiempo antes de una cita o después de un plazo vencido.
- El texto. El asunto y el cuerpo, con las variables marcadas. Las notificaciones de acceso a la cuenta y las que explican dinero tienen el texto escrito en el propio mapa.
- Si falla. Lo que hace el sistema cuando el aviso no llega: intenta otro canal, guarda el aviso en el sistema o no hace nada, porque el aviso es opcional.
- Quién no lo recibe. La persona que, por la lógica del evento, lo recibiría, y que por una regla no debe recibirlo.
El fragmento de abajo junta filas de mapas reales, con el texto acortado.
| Evento | Quién lo recibe | Canal | Cuándo | Si falla | Quién no lo recibe |
|---|---|---|---|---|---|
| Código de verificación en el registro y en el inicio de sesión | quien está entrando | WhatsApp o SMS, a elección de la persona | en el momento, con validez corta | falló el WhatsApp y el código sale por SMS, sin que la persona haga nada | nadie además del dueño del número |
| Recordatorio de consulta | paciente | push y correo | 24 h y 30 min antes, los dos ajustables | el aviso también queda en el centro de notificaciones de la app | no sale si la consulta fue cancelada o ya empezó |
| Recordatorio de consulta | médico | push | 1 h y 10 min antes, ajustables | quien no permitió push lo recibe por correo | no sale si la consulta fue cancelada o ya empezó |
| Correo de la cuenta cambiado | dueño de la cuenta | correo, a la dirección anterior | en el momento | sin segundo canal | la dirección nueva, que puede estar en manos de quien tomó la cuenta |
| Nueva denuncia recibida | administradores activos de la empresa | correo, sin nada del relato | apenas llega el relato | sin segundo canal | quien denunció, que no deja contacto |
| Caso asignado | el nuevo responsable | correo | en el momento | sin segundo canal | quien se asignó el caso a sí mismo |
| Falla en el pago o en la transferencia | administrador | en el panel, en el navegador y por correo, que no se puede desactivar | en el momento | el aviso queda en la campanita del panel | el operador de la plataforma |
La primera fila es del código por WhatsApp que estamos incorporando en Helpe, un marketplace brasileño de servicios locales. Las demás vienen de la app de salud que estamos modelando y del canal de denuncia anónimo que estamos construyendo.
Por qué hacer el mapa antes del código#
El mapa va antes del código porque casi toda notificación depende de una regla de negocio y de un canal con plazos y costos propios, y las dos cosas cambian lo que se construye. Descubrirlo en medio del desarrollo cuesta pantallas y base de datos rehechas, o una entrega detenida a la espera de la aprobación de otra empresa.
La regla aparece primero en la columna "quién lo recibe". Para dejar de avisarle a quien está de vacaciones, el sistema tiene que tener ese dato guardado. En la devolución de GT sobre el prototipo, en septiembre, el cliente pidió un período de vacaciones en el registro del operador y que el operador inactivo saliera de la operación. La ausencia se convirtió en una lista de períodos, con vacaciones, licencia médica y otras licencias en el mismo mecanismo, y la regla del aviso quedó escrita: el operador de licencia o inactivo no recibe checklist ni notificación, y el que está de licencia no puede iniciar sesión en la app durante el período. Esa regla solo funciona si la base de datos guarda la situación de cada persona, por eso tiene que estar decidida antes de construir el registro.
El canal trae plazos que no dependen del equipo de desarrollo. En Helpe, el código de verificación por WhatsApp depende de que Meta apruebe la plantilla de mensaje de autenticación, y el alcance de la actualización dice por escrito que, sin esa aprobación, el envío por WhatsApp no funciona en producción. Antes de eso, el inicio de sesión por SMS de Helpe tuvo que pasar por la revisión de la propia AWS para enviar SMS en Brasil. Son etapas que entran en el cronograma al comienzo del proyecto.
La cantidad también cambia cuando alguien lee todo el alcance buscando avisos. Cuando el alcance de la app de salud todavía tenía una tabla propia de avisos, enumeraba 39 eventos. Leyéndolo módulo por módulo y pasando por las revisiones, el mapa llegó a 78. En la misma lectura, dos eventos del alcance, "pago aprobado" y "consulta confirmada", se convirtieron en una sola notificación, porque ocurren en el mismo momento y mandarían dos mensajes sobre el mismo hecho. Y un recordatorio que el alcance listaba como opcional pasó a ser esencial, porque su plazo lo fija la ley y el paciente no puede desactivarlo.
Los tiempos del recordatorio quedan ajustables en la configuración, porque el negocio cambia esos números con el uso. El criterio para decidir qué se vuelve configuración está en cuándo parametrizar una regla de negocio.
Quién no debe recibir la notificación#
"Quién no lo recibe" es la columna que más protege al sistema, y la que casi nadie pide. Suele cubrir cuatro casos: quien salió de la operación, quien no puede ser identificado, quien ya sabe del hecho y la dirección que puede estar en manos de quien tomó la cuenta.
Quien salió de la operación. En GT, el checklist y la notificación ni siquiera llegan a la app del operador de licencia o inactivo.
Quien no puede ser identificado. En el canal de denuncia anónimo que estamos construyendo, quien denuncia recibe cero notificaciones. No deja contacto y sigue el caso por el número de protocolo. Los avisos van solo al equipo de la empresa, por correo, sin nada del contenido del relato. El diseño completo está en cómo garantizar el anonimato en un canal de denuncias.
Quien ya sabe. En el mismo canal, el aviso de caso asignado no sale cuando la persona se asigna el caso a sí misma. Mientras el caso está marcado con mensaje nuevo, los mensajes siguientes no generan otro aviso.
La dirección que pudo haber sido tomada. En la app de salud, el aviso de que cambió el correo de la cuenta va al correo anterior. El aviso de que se cambió el segundo factor va al correo de la cuenta y nunca al medio nuevo. Si alguien tomó la cuenta y cambió el contacto, el dueño real igual se entera.
Qué pasa cuando la notificación no llega#
Cuando la notificación no llega, el sistema hace lo que el mapa indicó: intenta otro canal, guarda el aviso dentro del sistema o no hace nada, si el aviso es opcional. Y ninguna regla del negocio depende de que la persona haya visto el aviso.
En Helpe, si el código por WhatsApp falla, sale por SMS automáticamente, sin que el usuario tenga que pedirlo de nuevo. En la app de salud, cuando un push esencial no se entrega, se activa el correo, y quien no permitió push en el celular recibe por correo todo aviso esencial que sería solo push, como el recordatorio del médico. El aviso opcional no se reenvía.
En la app de salud, lo que cuenta es el horario agendado y la presencia registrada en la sala, y no si el paciente leyó el recordatorio. La directriz 4.5.4 de la App Store dice lo mismo de otra forma: las notificaciones push no pueden ser obligatorias para que la app funcione.
El correo también falla en silencio, cuando cae en spam. Según las directrices de Google para remitentes, todo dominio que envía correo a Gmail necesita autenticación SPF o DKIM y tiene que mantener la tasa de spam por debajo del 0,3%. Quien envía más de 5.000 mensajes por día también necesita DMARC. Esa configuración del dominio entra en la lista de tareas junto con el mapa.
Cómo elegir el canal de cada notificación#
El canal se elige por lo que el aviso necesita, como llegar a todos, llegar en el momento o quedar guardado, y por la limitación de cada canal.
Correo. Todos los perfiles lo tienen, y es el canal de los enlaces seguros, los códigos y el contenido largo. También es el canal de respaldo cuando el push falla.
Push. Llega en el momento y aparece en la pantalla bloqueada. En un sistema web, Android lo recibe por el navegador, y en el iPhone el web push solo existe desde iOS 16.4, para sitios agregados a la pantalla de inicio, y el pedido de permiso tiene que partir de un toque de la persona, como anunció WebKit en febrero de 2023. Cuando el push en el iPhone es esencial para el producto, la decisión vuelve a la pregunta de app o sistema web.
WhatsApp. Meta tiene reglas para la empresa que inicia la conversación. Según la documentación de la plataforma de WhatsApp Business, cuando se cierra la ventana de atención de 24 horas, la empresa solo puede enviar plantillas de mensaje aprobadas. Cada plantilla se clasifica como autenticación, utilidad o marketing, y la revisión puede tardar hasta 24 horas. El código de verificación tiene que usar la plantilla de autenticación, con texto fijo. En la app de salud, WhatsApp quedó fuera de los avisos y sirve solo como contacto del equipo de operación para dudas generales.
SMS. Llega a cualquier celular, con poco espacio. Según la documentación del servicio de SMS de AWS, un mensaje cabe en 160 caracteres cuando usa solo el alfabeto GSM, y en 70 cuando tiene cualquier carácter fuera de él. En portugués, la tilde de "não" y el acento de "você" quedan fuera, y en español también quedan fuera letras como la "á" y la "í". Un mensaje más largo se divide en partes, y cada parte se cobra. En la app de salud, el SMS lleva solo el código de verificación.
Dentro del producto. Es el aviso que aparece dentro del sistema, en una campanita o en un centro de notificaciones, con leído y no leído. En una reunión de descubrimiento en septiembre, un cliente puso "historial de notificaciones" en la lista de lo que quería. En el mapa, ese pedido se convierte en una decisión: quién tiene centro, qué entra en él y por cuánto tiempo queda guardado.
Qué no se convierte en notificación#
Notificar no es "mandar un correo por todo". El mapa también decide qué no se convierte en aviso: lo que la persona ya está viendo en la pantalla, la repetición del mismo asunto, la campaña de marketing y el dato sensible.
Las directrices de interfaz de Apple dan el ejemplo del propio Mail: cuando llega un mensaje a la bandeja que la persona está mirando, la app solo agrega el mensaje a la lista, sin notificación. Las mismas directrices piden no enviar varias notificaciones sobre lo mismo, aunque la persona no haya respondido, porque puede terminar desactivando todas las notificaciones de la app.
En la app de salud, eso se convirtió en regla escrita: los mensajes de una conversación en 2 minutos se convierten en un solo aviso, los avisos de operación del mismo tipo se agrupan en 10 minutos, y el aviso que se repite por un pendiente sale como máximo una vez por día.
Las campañas también quedan fuera. En la app de salud, ningún módulo envía novedades de la empresa. La directriz 4.5.4 de la App Store solo permite push de promoción o marketing cuando la persona aceptó recibirlo, mediante un texto de consentimiento dentro de la app, y tiene cómo darse de baja.
Y el contenido sensible no va en el aviso. Las directrices de Apple piden no incluir información sensible, personal o confidencial en una notificación, porque no hay forma de saber quién está cerca de la pantalla. En la app de salud, el push y el correo nunca llevan datos clínicos, motivo de consulta, documentos ni el nombre del paciente. El push muestra fecha, hora y el acceso directo, y el contenido queda dentro de la app, después del inicio de sesión.
Preguntas frecuentes#
¿Todo sistema necesita un mapa de notificaciones?#
Todo sistema que envía algún aviso lo necesita, aunque el mapa salga chico. En un sistema de informes técnicos que mapeamos, tiene dos notificaciones, las dos por correo y las dos de acceso a la cuenta. Escribirlo dejó registrado que el cliente final no recibe nada automático y que el enlace del informe lo envía el administrador. Sin el mapa, esa decisión habría quedado en manos de quien estuviera programando.
¿Quién hace el mapa de notificaciones?#
Lo hacemos nosotros, a partir del alcance validado y antes del desarrollo. El mapa sale en dos pasadas: primero el documento completo, después un informe de cobertura que verifica si cada evento del alcance tiene una fila en el mapa y si cada fila del mapa viene de algo que el alcance describe. El cliente revisa quién recibe cada aviso, el tono de los textos y qué se puede desactivar.
¿Se pueden enviar notificaciones por WhatsApp en cualquier sistema?#
Se puede, con tres condiciones. Fuera de la ventana de 24 horas que abre el último mensaje del usuario, la empresa solo puede enviar una plantilla de mensaje aprobada por Meta. El código de verificación usa una plantilla propia de autenticación, con texto fijo. Y el envío pasa por un proveedor de la API oficial, que cobra por los envíos: en Helpe, el panel ganó un acceso directo a la cuenta del proveedor, donde el equipo sigue el saldo. El plazo de la aprobación depende de Meta, por eso entra en el cronograma como dependencia.
¿El usuario puede desactivar las notificaciones?#
Puede desactivar las configurables, como el pedido de reseña o la sugerencia de volver a agendar. Las transaccionales, que cubren el acceso a la cuenta, el dinero y el avance del servicio, salen siempre. En la app de salud que estamos modelando, de las 78 notificaciones, 75 son transaccionales y 3 son configurables.
¿Se puede ver el historial de notificaciones dentro del sistema?#
Sí, con un centro de notificaciones, que guarda dentro del sistema lo que cada persona recibió, con leído y no leído. En la app de salud que estamos modelando, todo aviso push y por correo también entra en el centro. El mapa define quién tiene centro y por cuánto tiempo guarda los avisos.
Fuentes#
- Meta, WhatsApp Business Platform, plantillas de mensajes (aprobación, categorías y plazo de revisión): https://developers.facebook.com/docs/whatsapp/business-management-api/message-templates/
- Meta, WhatsApp Business Platform, plantillas de autenticación: https://developers.facebook.com/docs/whatsapp/business-management-api/authentication-templates/
- Meta, WhatsApp Cloud API, envío de mensajes (ventana de atención de 24 horas): https://developers.facebook.com/docs/whatsapp/cloud-api/guides/send-messages/
- WebKit, "Web Push for Web Apps on iOS and iPadOS", 16 de febrero de 2023: https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/
- Apple, Human Interface Guidelines, Notifications: https://developer.apple.com/design/human-interface-guidelines/notifications
- Apple, App Store Review Guidelines, revisión del 8 de junio de 2026 (directriz 4.5.4): https://developer.apple.com/app-store/review/guidelines/
- AWS End User Messaging SMS, límites de caracteres: https://docs.aws.amazon.com/sms-voice/latest/userguide/sms-limitations-character.html
- Google, directrices para remitentes de correo: https://support.google.com/a/answer/81126
Próximo paso#
Si tu sistema va a avisar a clientes, equipo o proveedores, el mapa de notificaciones entra junto con el alcance en nuestros proyectos de software a medida, antes de la primera línea de código. En Helpe, el canal lo decidió el público: mucha gente ahí casi no usa el correo en el día a día, y por eso el inicio de sesión es por SMS.