4dim / Notas
A quién le toca el chat que acaba de entrar
Con tres personas atendiendo, dos contestan el mismo chat y el que entró a las once de la noche no lo ve nadie. Dónde se engancha el reparto —y las dos formas de engancharlo mal—, cómo se lleva la vuelta por turno y qué serializa dos mensajes simultáneos.
Tres personas y un chat nuevo
Si atiendes clientes por WhatsApp con más de una persona, esta nota te dice cómo repartir las conversaciones sin que nadie se pise y sin que ninguna se quede sin atender. Con el mecanismo completo, que es más corto de lo que parece.
El problema aparece cuando entra la tercera persona al equipo. Con una sola, todo lo que llega es suyo y no hay nada que repartir. Con tres pasan dos cosas, y las dos cuestan dinero.
La primera: entra un chat y las tres lo ven. Dos contestan a la vez. El cliente recibe dos saludos distintos de la misma tienda y alguien queda como que no sabe lo que hace.
La segunda es peor porque no se ve. Entra un chat a las once de la noche, no es de nadie en particular, y por la mañana está enterrado bajo quince conversaciones más. Nadie lo abrió. Nadie sabe que existió.
Una conversación sin dueño no es de todos. Es de nadie.
Dónde se engancha el reparto
Aquí está la decisión que de verdad importa, y que casi nadie cuenta. No es «con qué criterio se reparte»: es en qué momento exacto se dispara.
Lo primero que sale es engancharlo al nacer la conversación. Cuando se abre un hilo nuevo, se le pone dueño. Parece lo natural y está mal por dos motivos que solo se descubren usándolo.
Uno: las campañas también abren hilos. Una promoción a quinientos contactos abre quinientas conversaciones. Repartirlas sería regalarle al equipo quinientas conversaciones que nadie pidió y que nadie va a contestar, porque el cliente todavía no ha dicho nada.
Dos: solo alcanzaría a los hilos nuevos. El cliente que escribió hace tres meses, cuyo hilo se cerró y que hoy vuelve, no abre una conversación nueva: reabre la suya. Con el reparto colgado del nacimiento, ese cliente vuelve a quedarse sin dueño. Y ese es justo el que un CRM promete no perder.
Así que la regla no es «al nacer». Es «cuando entra un mensaje de cliente y la conversación no tiene dueño». En Connection eso vive en un solo sitio, la función por la que pasa obligatoriamente todo mensaje que llega del webhook de Meta —la dirección a la que Meta manda lo que escriben tus clientes—. Una puerta, una regla, los dos casos cubiertos.
La vuelta por turno, y por qué el orden es por id
El reparto de un equipo es una vuelta: primero, segundo, tercero, y otra vez el primero. Tiene tres detalles que parecen menores y que son la diferencia entre repartir bien y repartir mal.
El contador no se reinicia nunca. Es un número que solo sube. A quién le toca sale de dividir ese número entre cuántos son ahora y quedarse con el resto. Al hacerlo con el tamaño actual del equipo, que entre o salga alguien no rompe la vuelta: sigue donde iba. Si se reiniciara, cada cambio de equipo devolvería el turno al primero de la lista, y esa persona acabaría llevándose el doble que las demás.
La lista va ordenada por identificador, no por nombre. Parece arbitrario y es lo contrario. Si el orden dependiera del nombre, renombrar a alguien reordenaría la vuelta y habría quien se saltara varios turnos sin que nadie entendiera por qué. El identificador no cambia nunca.
El equipo vacío no gasta turno. Se mira si hay gente antes de mover el contador. Gastarlo en un equipo sin nadie dejaría un hueco en la vuelta siguiente: alguien se saltaría su conversación sin que hubiera atendido ninguna.
Un reparto que se equivoca no da error. Da una injusticia, y se descubre meses después, cuando alguien cuenta.
Por eso esa cuenta —la aritmética sola, sin base de datos delante— vive aparte y tiene prueba propia. Es la única parte del reparto que puede fallar en silencio: seguiría asignando a alguien del equipo siempre, y nadie notaría nada.
Dos mensajes a la vez, y quién los serializa
Dos clientes escriben en el mismo segundo. Si el turno se lleva a mano —leer el número, sumarle uno, guardarlo— las dos operaciones leen el mismo número y le toca a la misma persona. Es la carrera clásica, y en un día flojo no se nota nunca.
La solución no es un candado nuestro. Es pedirle el número a la base de datos en la misma operación que lo sube, y dejar que sea ella la que ponga a los dos en fila. Postgres bloquea esa fila hasta que la operación termina, así que la segunda espera y se lleva el número siguiente. No hay nada que sincronizar en la aplicación.
Y el reparto ocurre dentro de la misma transacción que guardó el mensaje. Hacerlo después, por separado, abriría una rendija: un fallo entre medias dejaría el mensaje guardado y la conversación sin dueño, que es exactamente el estado que todo esto existe para evitar.
La última línea es la que lo cierra del todo. La asignación se escribe con la condición «y solo si sigue sin dueño» puesta otra vez, aunque ya se haya comprobado antes. Es redundante a propósito: es lo que impide pisar a nadie aunque el razonamiento de arriba se rompa algún día.
Cuatro veces que no se reparte, y ninguna es un error
Un reparto que no reparte suele ser correcto. Estas son las cuatro situaciones, y conviene conocerlas porque explican el 90 % de los «no me está asignando».
| Situación | Qué pasa | Por qué está bien |
|---|---|---|
| La bandeja no tiene el reparto encendido | No se asigna | Es una decisión del negocio, no un fallo |
| La conversación ya tiene dueño | Se deja como está | El cliente que vuelve sigue con quien lo atendió |
| El equipo está vacío | No se asigna y no se gasta turno | Es un reparto que aún no puede repartir |
| El equipo ya no existe | No se asigna | El hilo queda a la vista de todos, como antes |
El segundo caso merece un renglón aparte porque es una regla de negocio disfrazada de detalle técnico: una conversación con dueño no se le quita a nadie. El cliente que vuelve tres meses después sigue hablando con la persona que lo atendió, que se acuerda de él.
Lo que el reparto no comprueba, a propósito
El reparto no mira si a la persona que le tocó le alcanza el rol para ver esa bandeja. Puede parecer un descuido y es una decisión, con dos razones.
La conversación nunca desaparece: el dueño del negocio ve todas las bandejas siempre, así que siempre hay alguien que puede reasignarla. Y bloquear en silencio desde el fondo del proceso que recibe los mensajes dejaría al negocio con el reparto apagado sin que nadie se lo hubiera dicho.
El aviso va donde se puede hacer algo con él: en la pantalla que configura el reparto, mientras alguien lo está configurando. No en un registro que nadie lee.
Qué hacer entonces
- Cuenta cuántas personas atienden. Con una, no necesitas reparto. Con dos ya lo necesitas, aunque todavía no duela.
- Comprueba cuándo se dispara el reparto de tu herramienta. Si se dispara al abrir la conversación, tus campañas van a repartir cientos de hilos vacíos y tus clientes que vuelven van a quedarse sin dueño. Pregúntalo antes de comprar.
- Pide ver el reparto de la última semana por persona. Si una se lleva el doble que las demás, el contador se está reiniciando en cada cambio de equipo.
- Decide qué pasa con el cliente que vuelve. Que siga con quien lo atendió es lo que casi todo negocio quiere, pero es una elección: conviene que esté hecha a propósito y no por omisión.
- Revisa las bandejas que no ve nadie. El reparto puede estar funcionando y aun así dejar conversaciones invisibles: eso es otro problema, y tiene su propia nota.
Esta nota sale de nuestro trabajo en AI-CRM Connection.