Umbrales de reasignación de conversaciones cuando un operador se ausenta: tabla de disparo, responsable y evidencia

Cuando un operador se ausenta, la conversación no se cae sola: queda abierta, el cliente sigue escribiendo y nadie contesta. El problema operativo no es la ausencia en sí, es no tener definido a partir de qué momento esa conversación deja de ser de esa persona y pasa a ser de otro. Sin umbral escrito, cada supervisor improvisa: algunas conversaciones se reasignan demasiado pronto (el operador vuelve y encuentra su bandeja desarmada) y otras demasiado tarde (el cliente ya se fue).

El caso típico: en una rotisería con dos personas en el turno de mediodía, una sale a hacer una entrega y vuelve cuarenta minutos después. En el medio entraron seis pedidos y dos consultas de horario. Si nadie definió que a los 10 minutos de silencio del operador la conversación se reasigna, esos seis pedidos se contestan cuando el operador vuelve, con el cliente ya pidiendo en otro lado. Esta página es la tabla que falta: qué señal dispara la reasignación, con qué número, quién la ejecuta y qué queda registrado. No es una recomendación de producto ni una comparación de herramientas: son umbrales para que el equipo los adopte y los ajuste con sus propios datos. La lógica es siempre la misma: primero se mide, después se decide con un número, y recién al final se automatiza lo que ya funciona a mano.

Cómo se lee esta tabla

Cada fila es un escenario de ausencia con su umbral. La columna "señal" es lo que hay que mirar. La columna "umbral" es el número a partir del cual se actúa, expresado en la unidad en la que la señal se mide (minutos de silencio, minutos desde la última actividad del operador, cantidad de conversaciones abiertas). La columna "regla de disparo" dice qué pasa exactamente cuando se cruza ese umbral. La columna "responsable" dice quién lo ejecuta: el propio operador, el supervisor de turno o el sistema. La columna "evidencia" es lo que tiene que quedar registrado para poder auditar después si la reasignación se hizo bien.

Dos advertencias antes de usar la tabla. La primera: los umbrales son de arranque, no definitivos. Se calibran con los datos del propio negocio, y el punto de partida razonable es el tiempo de primera respuesta que el equipo ya sostiene en horario normal. La segunda: la ausencia no siempre es del operador. Un cliente que escribe y no recibe respuesta también es una conversación que se está enfriando, y a veces el operador está presente pero la conversación quedó trabada esperando un dato del cliente. La tabla separa los dos casos porque se resuelven distinto.

Por qué el umbral no puede ser uno solo

Un equipo que usa un único umbral para todo termina con dos problemas opuestos. Si el umbral es corto, las conversaciones se mueven antes de que el operador pueda contestar y el cliente recibe respuestas de dos personas distintas sobre el mismo tema. Si el umbral es largo, el cliente espera de más y el operador que vuelve encuentra una bandeja que ya no reconoce. La tabla resuelve esto separando tres dimensiones: quién dejó de responder (el operador o el cliente), por qué (ausencia declarada, no declarada o simple demora) y qué se está esperando (una respuesta simple o un dato que depende de otra área).

La dimensión que más se subestima es la última. Una conversación donde el operador prometió averiguar algo y todavía no tiene la respuesta no se arregla reasignándola a otro operador que tampoco tiene el dato. Se arregla reasignándola a quien puede resolver el dato, que muchas veces no está en la bandeja. Por eso esa fila de la tabla tiene un responsable distinto y un umbral que depende de lo que el operador le haya dicho al cliente.

Cómo se calcula el umbral de cada equipo

Los números de la tabla son puntos de partida. Para calibrarlos con datos propios hay que medir primero el tiempo de primera respuesta real del equipo en horario normal y en horario pico, y usar ese valor como referencia. La fórmula es simple:

• Paso 1: medir el tiempo de primera respuesta de las últimas dos semanas, separando horario pico de horario valle.
• Paso 2: tomar el percentil 75 de cada grupo, no el promedio. El promedio esconde las conversaciones que se fueron al fondo de la bandeja.
• Paso 3: el umbral de reasignación por silencio del cliente se fija en ese percentil 75, redondeado hacia arriba.
• Paso 4: el umbral de operador ausente se fija en la mitad del tiempo de primera respuesta del horario pico. Si en pico el equipo responde en 12 minutos, el umbral de ausencia es 6.
• Paso 5: revisar los umbrales cada vez que cambie la dotación del turno o el volumen de mensajes.

Ejemplo concreto para ver cómo se aplica. Un consultorio con dos secretarias mide que en horario de mañana el 75 % de las primeras respuestas sale en 8 minutos o menos, y en horario de tarde en 14 minutos o menos. Con esos datos, el umbral de silencio del cliente queda en 8 minutos a la mañana y 14 a la tarde. El umbral de operador ausente, la mitad del pico, queda en 4 y 7 minutos. Si a la semana siguiente entra una secretaria nueva y el tiempo de primera respuesta sube a 20 minutos, el umbral también sube: no se fuerza al equipo a un número que no puede sostener.

Qué NO se reasigna (y por qué)

La tentación cuando un operador se ausenta es mover todo. Eso rompe la continuidad de las conversaciones que ya estaban encaminadas y genera que el cliente explique dos veces lo mismo. Hay tres casos donde la regla correcta es no reasignar:

• Conversaciones donde el cliente no respondió el último mensaje del operador. No hay urgencia: el cliente tiene el control. Se marcan para seguimiento y se cierran o se reprograman según el plazo definido.
• Conversaciones que están esperando un dato del propio cliente (documentación, una foto, un comprobante). Reasignarlas no acelera nada porque el cuello de botella no está del lado del negocio.
• Conversaciones que ya tienen una reasignación previa en las últimas 24 horas. Moverlas otra vez genera más confusión que esperar. En ese caso escala a supervisor, que decide si las toma él.

El criterio general: se reasigna la conversación donde el cliente está esperando algo del negocio. Se deja quieta la conversación donde el negocio está esperando algo del cliente.

Qué queda registrado y para qué sirve

La columna de evidencia de la tabla no es burocracia: es lo que permite responder después tres preguntas que siempre aparecen. La primera, si la reasignación se hizo a tiempo o tarde, comparando la hora del disparador con la hora de la reasignación. La segunda, si el operador ausente tenía una carga de conversaciones razonable o estaba desbordado, lo que cambia si el problema es la persona o la dotación del turno. La tercera, si el cliente recibió respuesta dentro del umbral después de la reasignación, que es la única medida que importa desde afuera.

Para que esa evidencia sirva, las marcas de tiempo tienen que ser las del mensaje, no las del registro interno del sistema. Un mensaje puede insertarse en la base en un momento muy distinto al que se envió o se recibió, sobre todo si hubo una migración o una importación de historial. Si el análisis se hace con la fecha de inserción, cualquier distribución de horarios va a dar un resultado falso. La regla es usar siempre la marca temporal del mensaje y no la del registro.

Cómo se automatiza sin romper nada

La automatización de la reasignación se hace en tres etapas, y ninguna se saltea. En la primera, el supervisor ejecuta la reasignación a mano siguiendo la tabla, y anota cada caso. En la segunda, cuando el criterio ya está claro y los casos anotados coinciden con la tabla, se automatiza solo la marca de "sin atender" y la reasignación sigue siendo manual. En la tercera, se automatiza la reasignación completa para los escenarios más predecibles (operador que no inició sesión, ausencia declarada) y se deja manual todo lo que involucre juicio, como la conversación que espera un dato interno.

El error más común es automatizar la reasignación antes de tener el criterio escrito. Cuando eso pasa, el sistema mueve conversaciones con una lógica que nadie definió, los operadores desconfían de la bandeja y terminan trabajando por fuera del sistema. La tabla existe justamente para que la automatización tenga una regla que el equipo ya probó a mano.

Errores frecuentes al fijar umbrales

• Usar un solo umbral para todo el día. El horario pico y el valle tienen tiempos de respuesta distintos y necesitan umbrales distintos.
• Fijar el umbral por lo que tarda el operador más rápido. El umbral se fija por lo que el equipo sostiene de forma consistente, no por el mejor caso.
• No distinguir ausencia declarada de ausencia no declarada. La primera se planifica, la segunda se detecta.
• Reasignar sin avisarle al operador original. Cuando vuelve, encuentra su bandeja cambiada y pierde tiempo reconstruyendo qué pasó.
• Medir la reasignación por cantidad de conversaciones movidas y no por tiempo de respuesta posterior. Mover mucho no es mejor.
• Dejar la conversación reasignada sin titular claro. Una conversación que pasó por tres manos sin dueño termina sin respuesta.
• No revisar los umbrales cuando cambia la dotación del turno. Un umbral calibrado para cinco operadores no sirve para tres.

Cómo saber que los umbrales están bien puestos

Un juego de umbrales está bien calibrado cuando pasan tres cosas al mismo tiempo. Primero, la cantidad de reasignaciones por turno es baja y estable: si sube todos los días, el umbral es demasiado corto o la dotación es insuficiente. Segundo, el tiempo de primera respuesta después de una reasignación es igual o mejor que el tiempo de primera respuesta normal: si es peor, la conversación está cayendo en una bandeja que no la atiende. Tercero, los operadores no reclaman por conversaciones que les sacaron antes de poder contestarlas: eso indica que el umbral está cortando conversaciones que iban a resolverse solas.

Cuando alguna de las tres señales falla, se ajusta un solo umbral por vez y se mide una semana antes de tocar el siguiente. Cambiar varios umbrales juntos hace imposible saber cuál fue el que mejoró o empeoró el resultado. Si después de dos ajustes la señal sigue igual, el problema probablemente no sea el umbral sino la cantidad de gente en el turno, y ahí la tabla no ayuda: hay que revisar la dotación.

Si el equipo atiende WhatsApp con una herramienta que sugiere respuestas y permite reasignar conversaciones entre operadores, la tabla se aplica igual: los umbrales son del negocio, no de la herramienta. Wando, por ejemplo, tiene bandeja multiagente y sugerencias de IA que el equipo aprueba, pero los números de esta tabla los define cada negocio con sus propios datos.