Desarrollo

Notificaciones en un CRM: canales, estados y seguimiento

Un aviso enviado no es un aviso recibido, y un aviso recibido no es un aviso leído. Esta nota ordena qué decidir antes de sumar notificaciones a un CRM: qué canales usar, qué conviene registrar de cada una y cómo comprobar que funcionan.

Por qué el canal no es el primer problema

Es habitual empezar discutiendo si corresponde WebSocket, push o correo. Esa decisión depende de algo previo: qué evento merece interrumpir a una persona y qué debe quedar registrado. Si el evento no está definido, ningún canal lo va a resolver. Un cambio de etapa en el pipeline, una tarea asignada y un comentario del equipo son eventos distintos y probablemente no tengan el mismo tratamiento.

La segunda decisión es quién puede ver qué. Un aviso sobre una oportunidad debería respetar los mismos permisos que el registro original; si no, el canal se convierte en una filtración silenciosa. Antes de construir cualquier integración conviene tener claros los roles y los datos que cada uno puede consultar.

Canales: qué aporta cada uno

Conviene tratarlos como complementarios y no como alternativas. Cada uno tiene un lugar distinto dentro del flujo de trabajo del equipo.

En la aplicación, con conexión persistente

Sirve para cambios que se miran mientras se trabaja: el pipeline que se mueve, la tarea que aparece, el comentario del colega. La especificación de WebSockets del WHATWG describe un canal bidireccional que se mantiene abierto entre cliente y servidor, lo que permite que el servidor envíe datos sin que el cliente pregunte. Ese comportamiento es el que hace posible actualizar una pantalla sin recargar.

La contrapartida es que la conexión puede cortarse y hay que gestionar la reconexión, sin asumir que el orden de los mensajes se conservó.

Notificación push al dispositivo

Tiene sentido cuando la persona no está frente al sistema. La documentación de Firebase Cloud Messaging sobre la vigencia de los mensajes aclara un punto importante: el identificador que devuelve el envío indica que el mensaje fue aceptado para su entrega, no que haya llegado al dispositivo. Además, un mensaje puede expirar y, si el equipo está apagado o sin conexión, la entrega puede quedar pendiente.

Por eso un push sirve para avisar, no para certificar que alguien se enteró.

Correo

Aporta cuando hace falta una constancia que se pueda consultar después: resúmenes periódicos, documentación de un proceso, comunicación con alguien externo a la organización. No está pensado para la inmediatez y no debería usarse como reemplazo de un aviso operativo urgente.

Bandeja dentro del propio CRM

Funciona como respaldo de los demás canales: si el push no llegó o el correo quedó en una carpeta olvidada, el registro sigue ahí. Es también el lugar natural para que una persona marque el aviso como revisado.

Estados: aceptación, entrega y lectura

Vale la pena distinguir tres momentos, porque miden cosas diferentes y no siempre están disponibles:

  • Aceptación

    El sistema tomó el mensaje y respondió sin error. Es el estado más fácil de obtener y el menos útil si se interpreta como entrega.

  • Entrega

    Requiere la confirmación del dispositivo o del servidor de destino. Cuando el equipo está offline o el mensaje expira, este estado puede no llegar nunca, y eso es esperable, no un fallo del sistema.

  • Lectura

    Solo es verificable si la aplicación registra la apertura o si la persona marca el aviso. Fuera de la propia aplicación, no hay forma confiable de saberlo, y no conviene inventarla.

Documentar cuál de estos estados tiene cada canal permite explicar después por qué un aviso "enviado" no llegó a tiempo, sin atribuir fallas que en realidad eran parte del comportamiento normal del sistema.

Diseño: lo que conviene definir antes de programar

Evento y registro. Definir qué ocurre, qué datos mínimos lo describen y dónde queda asentado. El aviso es una consecuencia del evento, no el evento mismo.

Permisos y destinatarios. Quién debería recibirlo según su rol y qué parte de la información puede ver. Un aviso con más datos de los necesarios es un problema de permisos disfrazado de simplicidad.

Preferencias del usuario. Qué recibe cada persona y por qué canal, con la posibilidad de ajustarlo dentro de los límites que fija la empresa.

Deduplicación. Evitar que el mismo hecho genere varios avisos, ya sea porque se reintentó el envío o porque dos servicios lo detectaron a la vez.

Reintentos controlados. Con límite, con espera creciente y con registro de cada intento. Sin ese control, un fallo de red puede convertirse en una ráfaga de mensajes repetidos.

Reconexión. Definir qué pasa al volver de una desconexión: si se piden los eventos perdidos, si se recarga el estado o si solo se retoman los nuevos.

Seguimiento sin inventar métricas

No hace falta compararse con un benchmark externo para saber si las notificaciones funcionan. Alcanza con medir lo propio y con el mismo criterio en el tiempo. Algunas preguntas útiles:

  • ¿Cuántos eventos se generaron y cuántos avisos derivaron de cada uno?
  • ¿Qué proporción de envíos fue aceptada, entregada y marcada como revisada, según el canal?
  • ¿Cuántos avisos se descartaron o se silenciaron, y por qué?
  • ¿Hubo duplicados o ráfagas que obligaron a intervenir a mano?

Las respuestas sirven para ajustar la cantidad de avisos y el canal elegido. Un sistema que envía demasiado termina ignorado, y uno que envía muy poco obliga a revisar el CRM a mano.

Pruebas antes de depender de esto

Conviene probar los casos incómodos y no solo el camino feliz: dispositivo sin conexión, sesión vencida, cambio de rol a mitad de una operación, dos personas editando el mismo registro y servidor que reinicia mientras hay avisos en cola. Cada prueba debería registrar qué se esperaba y qué ocurrió.

También conviene revisar qué ve una persona nueva en el equipo la primera vez que abre el sistema: si la bandeja aparece con avisos antiguos sin contexto, la función pierde sentido desde el inicio.

Fuentes consultadas

Las fuentes se citan como referencia técnica del tema; su contenido puede actualizarse. El resto del artículo es análisis de diseño y no atribuye resultados a ninguna implementación.

¿Estás definiendo notificaciones para tu CRM?

Escribinos y repasamos qué eventos registrar, qué canales usar y qué conviene probar antes de depender del sistema.

Escribir al equipo Ver más de desarrollo