Notificaciones en una app empresarial: cuándo usar email, push o bandeja interna
Cuando cada evento genera email, push y aviso interno, el usuario recibe tres mensajes sobre lo mismo y termina silenciando el sistema. El diseño correcto comienza por una decisión de negocio: qué necesita saber esa persona, cuándo pierde valor el aviso, qué acción debe realizar y qué información puede mostrarse. Solo después se elige canal y tecnología.
Lo esencial, antes de empezar
- La bandeja interna conserva contexto, el push interrumpe y el email alcanza a quien no entra: cada canal resuelve una necesidad distinta.
- Clasifica eventos por urgencia, persistencia, acción y sensibilidad antes de elegir el canal.
- Mantén preferencias de la app separadas de permisos del dispositivo y no sustituyas un canal por otro sin una regla y consentimiento válidos.
- Un identificador de evento, deduplicación y estado de la acción evitan avisos repetidos y métricas engañosas.
Asigna una función distinta a cada canal
| Canal | Fortaleza | Límite |
|---|---|---|
| Bandeja interna | Registro persistente con contexto, filtros y estado | El usuario debe entrar en la app |
| Push | Interrumpe cuando la información pierde valor con el tiempo | Depende de permiso, dispositivo, foco y entrega |
| Llega fuera de la app y admite contexto o conservación | No garantiza lectura inmediata y puede filtrarse |
Apple recuerda en su guía de gestión de notificaciones que el usuario controla permisos y modos de concentración. Android recomienda ofrecer ajustes y organiza avisos en canales configurables por el usuario. Por eso el push no debe ser el único registro de una tarea empresarial.
Usa una matriz de urgencia, persistencia, acción y sensibilidad
- 01
Urgencia
¿Qué impacto tiene que la persona vea el aviso mañana en lugar de ahora?
- 02
Persistencia
¿Debe quedar como tarea, estado o historial dentro de la aplicación?
- 03
Acción
¿Existe una acción concreta, segura y disponible para esa persona?
- 04
Sensibilidad
¿Puede mostrarse el texto en pantalla bloqueada, email reenviado o vista compartida?
| Situación | Canal base | Refuerzo posible |
|---|---|---|
| Tarea con plazo de días | Bandeja | Resumen por email |
| Acceso sospechoso | Push discreto y email | Registro en la app |
| Informe disponible | Bandeja | Email si se eligió |
| Caída operativa crítica | Push | Email y registro |
| Cambio menor de estado | Bandeja | Ninguno |
| Comunicación larga | Enlace al contexto en la app |
Muestra en push solo lo necesario. El detalle sensible debe aparecer tras abrir la app y verificar permisos. Una acción rápida en pantalla bloqueada solo es adecuada si su efecto es claro, autorizado y razonablemente reversible.
Diseña preferencias en dos capas
- Categoría: seguridad, tareas, aprobaciones, actividad, informes o novedades.
- Canal por categoría: bandeja, push, email u otro aprobado.
- Entrega inmediata o resumen, frecuencia y franja silenciosa.
- Proyectos, clientes, sedes o equipos relevantes.
- Idioma, zona horaria y dispositivo.
- Avisos esenciales que no pueden ocultarse, con motivo documentado.
La preferencia interna y el permiso del dispositivo son estados distintos. La app puede tener push activado y el sistema operativo bloquearlo. Registra ambos y explica el efecto. No actives email automáticamente porque el push esté denegado: usa la elección y las reglas aplicables a ese canal.
Android señala que el usuario conserva el control de los canales tras crearlos. Elige categorías estables y comprensibles; un canal técnico por cada evento crea ajustes que serán difíciles de mantener.
Modela un evento una vez y registra cada entrega
| Entidad | Qué contiene |
|---|---|
| Evento | Identidad, tipo, objeto, fecha, sensibilidad y caducidad |
| Destinatario | Usuario, rol, permisos y contexto |
| Regla | Urgencia, canales y prioridad |
| Preferencia | Elección por categoría y canal |
| Entrega | Intento y estado por email, push o bandeja |
| Acción | Visto, abierto, completado, descartado o expirado |
Email, push y bandeja deben apuntar al mismo identificador de evento. Abrir un push puede marcar el aviso como visto y cancelar un recordatorio. No confundas enviado con entregado ni abierto con resuelto.
Firebase separa métricas de envío, recepción, impresión y apertura, y documenta límites de cobertura en su informe de entrega de FCM. La fuente de verdad del negocio debe ser la acción: aprobación realizada, tarea completada o incidencia atendida.
Agrupa, colapsa y caduca los avisos
- Agrupa cambios repetidos: «10 novedades en el expediente» puede ser mejor que diez interrupciones.
- Colapsa avisos reemplazables, pero conserva en la bandeja los eventos que necesitan trazabilidad.
- Añade caducidad: un aviso de «actúa hoy» no debe entregarse dos días tarde.
- Antes de recordar, relee el estado: una tarea cerrada no debe seguir generando mensajes.
- Respeta zona horaria y silencio; define excepciones solo para eventos realmente críticos.
El enlace debe abrir el expediente exacto después de verificar sesión y permiso. Si el objeto ya cambió, muestra su estado actual. Un diseño de roles y permisos evita que la notificación revele o abra información fuera del alcance del usuario.
Mide utilidad y prueba los fallos de entrega
| Métrica | Lectura útil |
|---|---|
| Entrega e impresión | Cobertura técnica, con límites de cada plataforma |
| Tiempo hasta acción | Si el canal ayuda a actuar antes |
| Sin acción necesaria | Ruido generado por reglas pobres |
| Duplicados evitados | Efecto de deduplicación y agrupación |
| Preferencias desactivadas | Categorías o frecuencias molestas |
| Tarea vencida pese al aviso | Fallo del proceso, contenido o canal |
- Permiso push denegado o retirado.
- Token de dispositivo caducado o usuario con varios dispositivos.
- Email rechazado, filtrado o retrasado.
- Usuario sin permiso para el objeto al abrir el enlace.
- Evento repetido, fuera de orden o entregado tras caducar.
- Aplicación inactiva durante un periodo largo.
Para flujos específicos de agenda, la guía sobre recordatorios de citas y reprogramación profundiza en confirmación y excepciones sin convertir cada aviso de la app en un recordatorio comercial.
Fuentes y referencias
Documentación oficial y referencias de mercado consultadas para verificar los puntos que cambian con el tiempo.
