Diseña preferencias de notificaciones con conmutadores por evento, horas de silencio, resúmenes y seguimiento de entrega para que las personas se mantengan informadas sin sentirse spameadas.
La mayoría de la gente no odia las notificaciones. Odian ser interrumpidos sin una buena razón. Cuando las alertas llegan demasiado seguido, se repiten o aparecen en el momento equivocado, los usuarios dejan de leer y empiezan a ignorarlas.
El problema central normalmente no es el volumen. Es la desconexión. Lo que es urgente para tu sistema puede ser irrelevante para una persona. Un representante de ventas puede necesitar una asignación de cliente de inmediato, pero no un “consejo semanal” a las 21:07. Cuando todo parece igualmente importante, nada lo es.
La gente apaga las notificaciones por razones previsibles: son demasiado frecuentes, no relevantes para su rol, mal sincronizadas (sueño, reuniones, trayecto), poco claras sobre qué hacer a continuación o confusas respecto a su origen.
Las alertas útiles reducen trabajo. El ruido añade trabajo. Una buena notificación responde a tres preguntas rápido: ¿Qué pasó? ¿Importa para mí? ¿Qué debo hacer ahora?
También hay un costo oculto cuando los usuarios desactivan todo por frustración: se pierden el único mensaje que realmente importa. Una cuenta bloqueada, un fallo de pago o una advertencia de seguridad se ignoran porque el usuario se dio de baja tras semanas de pings de poco valor. Así lo “molesto” se convierte en “ticket de soporte”.
Unas buenas preferencias de notificación hacen una cosa: dar control con opciones claras y hacer el comportamiento predecible. Si un usuario apaga un tipo de alerta, debería permanecer apagado. Si configura horas de silencio, la app debe respetarlas siempre, en todos los canales.
Las buenas preferencias empiezan con una pregunta: ¿qué intenta seguir el usuario y qué puede esperar?
Si alguien activa alertas para “nuevos pedidos”, generalmente quiere “avísame rápido para poder actuar”. Si quiere “consejos semanales de producto”, significa “lo leeré cuando tenga tiempo”. Construye los ajustes en torno a esa intención, no en torno a tu lista de eventos internos.
Mantén el número de eventos pequeño y distinto. Si tienes cinco variantes de “estado cambiado”, la mayoría de la gente o desactivará todo o lo dejará todo activo y luego se arrepentirá. Agrupa eventos similares en una opción clara, y divide solo cuando la acción siguiente sea realmente distinta.
Los valores por defecto importan más de lo que muchos equipos creen. Para cualquier cosa no crítica, empieza silencioso por defecto y deja que la gente se suscriba. Un usuario nuevo debería poder no hacer nada y aún así sentirse respetado.
Usa lenguaje llano. Evita términos como “workflow”, “ciclo de vida del ticket” o “webhook failure” a menos que tus usuarios usen esas palabras. Escribe las etiquetas como alguien se las explicaría a un compañero.
Cuando alguien toca un interruptor, debe entender tres cosas:
Antes de construir una larga lista de preferencias, decide qué eventos merecen realmente una configuración. La mayoría de las pantallas de ajustes molestan porque ofrecen opciones para eventos ruidosos y de bajo valor, mientras que los pocos que importan están enterrados.
Empieza agrupando eventos por propósito para que la gente pueda predecir lo que recibirá:
Dentro de cada grupo, separa eventos en críticos, informativos y promocionales. Crítico significa que se requiere acción o el riesgo es alto. Informativo significa “bueno saberlo”. Promocional significa “agradable de tener”. Para cada evento, define urgencia y retraso aceptable. Un fallo de pago puede necesitar entrega instantánea. Un informe semanal puede esperar al resumen.
Ten cuidado con los eventos que “nunca se permiten desactivar”. Si algo debe permanecer activo, mantén la lista muy corta y explica por qué (normalmente seguridad y ciertas alertas de facturación). Todo lo demás debería estar bajo control del usuario.
Una regla práctica: escribe una frase por evento que diga qué pasó y por qué importa. Ejemplo: “Un nuevo dispositivo inició sesión en tu cuenta, para que puedas detectar accesos sospechosos.” Si no puedes escribir esa frase sin sonar vago, el evento probablemente no merece su propio conmutador.
Los conmutadores por evento funcionan cuando se corresponden con momentos que a los usuarios realmente les importan. Si el evento les puede costar dinero, tiempo o confianza, merece su propio interruptor. Si es mayormente “FYI”, considera agruparlo en un resumen en vez de añadir otro conmutador.
Nombra los conmutadores como eventos reales, no como áreas de producto. “Pago fallido” es más claro que “Actualizaciones de facturación”. Esa es la diferencia entre preferencias que se sienten respetuosas y un laberinto de ajustes.
Debajo de cada conmutador, muestra una línea de ejemplo del aspecto del mensaje. Fija expectativas y facilita la decisión.
Los conmutadores por categoría solo ayudan cuando las categorías son obvias y estables. “Security”, “Billing” y “Account access” suelen ser claras. “Product updates” o “Activity” a menudo ocultan demasiado.
Evita dependencias ocultas. Si apagar “Comentarios” también desactiva “Menciones”, dilo ahí mismo. Mejor aún, sepáralos. Las sorpresas son las que hacen desconfiar de toda la pantalla.
Añade una pausa global que no borre elecciones. “Pausar todas las notificaciones por 1 hora / 1 día / hasta que lo reactive” es una válvula de seguridad para días ocupados, mientras mantiene intactas las configuraciones por evento.
Horas de silencio debe significar una cosa: no recibir mensajes no urgentes durante las horas que el usuario indique.
Las zonas horarias son lo que hace que las horas de silencio se sientan “bien” o “rotas”. Algunas personas viajan y quieren que las horas sigan su ubicación actual. Otras desean un horario fijo de “casa” incluso en viajes. Ofrece ambas opciones con etiquetas claras como “Usar mi zona horaria actual” y “Usar mi zona horaria de casa”.
Las horas de silencio también necesitan excepciones claras. Los usuarios aceptan saltos cuando son raros y fáciles de entender. Mantén la lista de excepciones corta y basada en riesgo, no en marketing:
Los casos límite importan. El horario de verano puede desplazar el horario una hora, así que muestra el próximo “silencio empieza” y “silencio termina” en la interfaz.
Para fines de semana, evita que los usuarios tengan que construir dos horarios desde cero. Proporciona un simple interruptor “Solo días laborables”, o permite seleccionar días con un toque.
Los preajustes ayudan a completar la configuración rápido: “Noche (22:00 a 8:00)” más “Personalizado”. Haz los preajustes editables después de seleccionarlos para que nunca parezcan una trampa.
Un resumen es una promesa: “Te mantendremos informado, solo que sin interrumpirte.” Funciona mejor para actualizaciones ruidosas y de baja urgencia como reacciones, actividad rutinaria o estadísticas diarias. Funciona mal para algo que bloquea trabajo, necesita respuesta rápida o tiene fecha límite.
Una opción de resumen debe empezar separando eventos en dos cubos. Mantén en tiempo real los eventos de alta urgencia (alertas de seguridad, pagos, aprobaciones, caídas). Pasa a resumen los eventos de alto volumen (hilos de comentarios muy activos, actividad de seguidores, resúmenes rutinarios).
Mantén las opciones de frecuencia familiares:
Deja que los usuarios elijan la hora de envío del resumen y confirma la zona horaria. Un resumen que llega a las 3:00 AM se siente roto, aunque sea “correcto”.
La claridad supera a los controles sofisticados. Etiqueta cada evento como “En tiempo real” o “Resumen” para que los usuarios no tengan que adivinar. Si cambiar un evento lo mueve al resumen, dilo junto al control.
Una vista previa quita ansiedad. Muestra una pequeña muestra de lo que contendrá el resumen: algunos encabezados, contadores y los elementos más importantes. Por ejemplo: “3 comentarios nuevos, 2 cambios de estado, 1 mención”, con fragmentos cortos.
“Enviado” solo significa que tu app entregó un mensaje a un proveedor. A los usuarios les importa qué pasó después. Para una alerta crítica, “lo intentamos” no es lo mismo que “lo recibiste”.
Un modelo simple luciría así:
Cuando algo falla, registra la razón cuando sea posible. “Fallado” es demasiado vago. Mejores ejemplos son bloqueado (filtrado por la operadora), rebotado (buzón rechazó), dirección/número inválido, o token expirado (token de push ya no válido). Aunque no obtengas detalles perfectos de todos los proveedores, guarda lo que sí sabes.
Los fallos temporales necesitan reglas de reintento. Un valor por defecto razonable son reintentos limitados con backoff para no spamear a los proveedores ni agotar baterías. Por ejemplo: reintentar después de 1 minuto, luego 5, luego 30, y luego marcarlo como fallado. Errores permanentes como “número inválido” no deben reintentarse.
Para mensajes críticos, muestra un estado simple al usuario. Si alguien dice “No recibí el código de restablecimiento”, una línea visible como “SMS falló: número inválido” evita frustración y ayuda a corregir el problema.
Mantén una auditoría para soporte y cumplimiento. Registra para quién era el mensaje, qué canal se eligió, marcas de tiempo para cada estado y el último error conocido.
Trata las preferencias de notificación como lógica de producto, no como un montón de interruptores. Si construyes antes las reglas, la UI y el sistema de envío se mantendrán coherentes al añadir más eventos.
Empieza con un inventario de lo que podrías notificar. Para cada evento, decide cuán urgente es y qué canales tienen sentido (push, email, SMS). Luego elige valores por defecto para que la mayoría no necesite tocar la configuración.
Una comprobación práctica: si no puedes explicar un conmutador en una frase corta, probablemente combina varios eventos y debe dividirse.
Asegúrate de que cada envío pase por el mismo punto de decisión. Ahí aplicas las opciones del usuario, las horas de silencio y la lógica de resúmenes antes de que algo salga del sistema.
Almacena preferencias en una estructura que coincida con cómo piensa la gente: por evento, por canal y por temporización. Añade programación para horas de silencio y ventanas de resumen, incluyendo manejo de zona horaria y excepciones para alertas críticas. Registra la cadena completa: intento de envío, respuesta del proveedor (entregado, rebotado, fallado) y acciones del usuario (bajas, cambios).
Ejemplo: un usuario desactiva el email de “consejos semanales” pero mantiene el email de “alertas de seguridad”, con horas de silencio de 22:00 a 7:00. Tus reglas aún deben permitir un email urgente de restablecimiento de contraseña a las 2:00, mientras que los mensajes de baja prioridad esperan al resumen de la mañana.
La mayoría de la gente no odia recibir actualizaciones. Odian sentirse atrapados, confundidos o ignorados. Unos cuantos errores de diseño pueden convertir la pantalla de preferencias en un lugar que el usuario visita una vez, se enfada y nunca vuelve.
Patrones comunes:
Dos correcciones previenen la mayor parte de esto. Primero, que cada control responda a una sola pregunta: qué evento, en qué canal, con qué temporización. Mantén nombres concretos, como “Factura nueva pagada” en vez de “Facturación”. Segundo, trata la entrega como algo más que “enviado”, o reclamarás éxito incluso cuando un email rebotó o un push no llegó al dispositivo.
Antes de lanzar las preferencias, haz una revisión rápida como un usuario real. Finge que estás cansado, ocupado y solo quieres dejar de recibir ruido sin perder algo importante.
Empieza por el evento más ruidoso. Si alguien no puede desactivar un disparador molesto sin perder alertas críticas, la configuración parecerá injusta.
Luego verifica los tiempos. Los usuarios no deberían tener que adivinar si un mensaje llegará ahora, más tarde en un resumen o nunca. La UI debe decirlo claramente y el texto de vista previa debe coincidir con lo que realmente ocurre.
Lista de control antes del lanzamiento:
Las horas de silencio son donde se cuela la confusión. El control debería mostrar una ventana simple como “22:00 a 7:00” y explicar qué ocurre con las notificaciones bloqueadas (silenciadas, retrasadas o movidas al siguiente resumen). Si permites excepciones, etiquétalas en palabras llanas como “Permitir siempre alertas de seguridad”.
Finalmente, prueba el ciclo desde la acción hasta la prueba. Si un usuario reporta “No lo recibí”, tu sistema debe responder: ¿se puso en cola, se pasó al proveedor, se entregó al dispositivo o se rechazó?
Maya lidera un equipo de soporte de 12 personas. Quiere saber de todo lo que pueda poner en riesgo los datos del cliente, pero no quiere que su teléfono suene por cada comentario, emoji o actualización rutinaria. Además, suele estar en reuniones, así que necesita una configuración silenciosa por defecto y ruidosa solo cuando sea necesario.
Sus preferencias son:
Usa un resumen para el ruido de fondo como actividad de tickets, cambios de estado y comentarios no urgentes. Si algo se vuelve urgente, es una alerta, no parte del resumen.
Las horas de silencio están en días laborables de 21:00 a 7:00 en su zona horaria local, con una excepción: las alertas de seguridad saltan las horas de silencio. Si hay un inicio de sesión sospechoso a las 2:00, lo recibe.
El seguimiento de entrega es donde su configuración deja de sentirse una suposición. Cuando Maya solicita un restablecimiento de contraseña, puede ver que se entregó a su proveedor de correo, no solo que la app marcó “enviado”. Por otro lado, el email de la factura mensual de un cliente muestra un rebote, así que el equipo sabe que no llegó al buzón.
Cuando alguien dice “No lo recibí”, soporte tiene un camino claro:
Empieza con una lista escrita de eventos. Para cada evento, decide si es crítico (seguridad, facturación, acceso a cuenta) u opcional (comentarios, likes, consejos). Si no puedes explicar por qué existe un evento en una frase, probablemente no pertenece a tu primera versión.
Escribe etiquetas dirigidas al usuario como si hablaras con una persona ocupada. Mantenlas específicas (“Nuevo inicio de sesión desde un dispositivo nuevo”) y añade una vista previa de una línea (“Te avisaremos de inmediato por seguridad de la cuenta”).
Antes de lanzar, añade registro de entrega para que soporte pueda responder la verdadera pregunta: “¿me llegó?” Rastrea el camino desde creado hasta en cola, hasta la entrega o el fallo, más abierto cuando esté disponible.
Si estás construyendo el centro de preferencias dentro de una plataforma no-code como AppMaster, ayuda tratar las notificaciones como funciones de producto de primera clase: define eventos, almacena configuraciones por usuario en PostgreSQL y mantén un paso de decisión compartido en tu lógica de negocio. AppMaster (appmaster.io) está diseñado para este tipo de lógica de app, donde las reglas de backend y los ajustes de UI deben mantenerse alineados a medida que el producto crece.
Lanza a un pequeño porcentaje primero y observa las tasas de baja, el uso de “pausar todo”, tickets de soporte sobre alertas faltantes y los temas detrás de las quejas. Si un evento provoca la mayoría de las bajas, arregla ese evento antes de añadir más.
¿Por qué los usuarios apagan las notificaciones incluso cuando la función es útil?Porque la alerta no coincide con la intención del usuario. La gente tolera notificaciones frecuentes cuando realmente les ayudan a actuar, pero las desactivan cuando los mensajes son repetitivos, irrelevantes o llegan en el momento equivocado.
¿Cuáles deberían ser los ajustes de notificación por defecto para un usuario nuevo?Por defecto, silencio para todo lo no crítico y deja que los usuarios se suscriban. Mantén activados por defecto los elementos críticos como seguridad y ciertas alertas de facturación, y haz el resto fácil de controlar para que los nuevos usuarios se sientan respetados sin tocar la configuración.
¿Cómo sé si tengo demasiados conmutadores de notificación?Agrupa eventos similares cuando la siguiente acción es la misma, y divide solo cuando la decisión cambia. Una buena regla: si no puedes explicar el conmutador en una frase corta que incluya qué pasó y qué hacer, probablemente sea demasiado vago o demasiado amplio.
¿Cuál es la mejor manera de etiquetar las preferencias de notificación para que sean comprensibles?Nombra los conmutadores como eventos reales con resultados claros, no como áreas del producto. “Pago fallido” o “Nuevo inicio de sesión desde un dispositivo nuevo” establece expectativas, mientras que etiquetas como “Actualizaciones” o “Actividad” obligan al usuario a adivinar y suelen provocar desactivaciones.
¿Qué notificaciones nunca debería permitirse que los usuarios desactiven?Úsalo solo para alertas raras y de alto riesgo, principalmente seguridad y ciertas fallas de facturación que podrían bloquear a alguien o detener el servicio. Si debes mantener algo activado, explica la razón en lenguaje llano para que parezca protector, no controlador.
¿Cómo deberían comportarse las horas de silencio para evitar confundir a los usuarios?Las horas de silencio deben retrasar o silenciar constantemente las notificaciones no urgentes durante la ventana elegida, permitiendo una lista corta de excepciones para eventos de alto riesgo. Además, deben manejar las zonas horarias correctamente para que la misma configuración no parezca “rota” cuando alguien viaja o cambia el horario de verano.
¿Cuándo debería ofrecer un resumen en lugar de notificaciones en tiempo real?Ofrece resúmenes para actualizaciones de alto volumen y baja urgencia como actividad rutinaria, reacciones o estadísticas de fondo, y mantén lo urgente en tiempo real. La clave es la previsibilidad: los usuarios no deberían recibir simultáneamente resumen y notificación en tiempo real por el mismo evento a menos que lo dejes claro.
¿Cuál es la diferencia entre “enviado” y “entregado” y por qué importa?“Enviado” solo significa que entregaste el mensaje a un proveedor, no que el usuario lo recibió. Rastrea estados posteriores como entregado, rebotado, bloqueado o destino inválido para que soporte pueda responder “¿llegó a ti?” y los usuarios puedan corregir problemas como un correo equivocado o un token de push caducado.
¿Cómo debo manejar los reintentos cuando falla la entrega de una notificación?Usa reintentos limitados con backoff para fallos temporales y luego marca el mensaje como fallido con una razón accionable. No reintentes errores permanentes como un número de teléfono inválido, y evita repeticiones rápidas que parezcan spam o agoten la batería.
¿Cómo implemento preferencias de notificación sin crear un sistema enmarañado?Almacena preferencias por usuario según evento, canal y temporización, y hace que todas las notificaciones pasen por un único punto de decisión que aplique esas reglas antes de enviar. En AppMaster, esto suele significar modelar las preferencias en PostgreSQL y hacer cumplir horas de silencio, resúmenes y excepciones en un único proceso de negocio para que la UI y el backend sigan coherentes al crecer.
21 ene 2026
8 min
20 ene 20268 min
20 ene 20268 minExperimente con AppMaster con plan gratuito.
Cuando esté listo, puede elegir la suscripción adecuada.
