Cuando el número sube pero la operación empeora: señales de

El tablero festeja, el piso sufre: cómo notar la discrepancia sin caer en “opiniones”

Hay una escena repetida en soporte. En la reunión de performance, el tablero se ve impecable: AHT bajó, SLA se cumplió, productividad subió. Se escucha un “vamos bien”.

Y aun así, en el piso, el equipo está al límite. Supervisores apagando incendios. Clientes volviendo a contactar por lo mismo. Si te suena, no es “percepción”: es la discrepancia clásica entre eficiencia (mover más rápido) y efectividad (resolver de verdad).

Un KPI “bonito” es el que sube porque la forma de medirlo te empuja a producir ese número, aunque la realidad se deteriore. Una mejora real baja fricción para el cliente y para el equipo a la vez. Puede tardar más en reflejarse en el tablero, pero se nota en lo que no vuelve: reclamos repetidos, escalaciones, reaperturas.

Dos historias típicas: AHT baja, recontacto sube; resueltos suben, escalaciones suben

Caso realista (LatAm). Ecommerce en México, chat y WhatsApp. En abril, el AHT baja 18% (de 9.5 a 7.8 minutos) y los “tickets resueltos” suben 22%. En mayo, el recontacto a 7 días sube 9% y las escalaciones a L2 suben 14%.

La operación no se volvió mágicamente más eficiente. Se volvió más rápida para cerrar. Macros más agresivas. Menos contexto. Más “cualquier cosa nos escribes”. El trabajo no desapareció: se fue a la semana siguiente y a otro nivel.

La segunda historia es igual de común: “resueltos” se disparan porque cambiaste criterios de cierre o reetiquetaste backlog. El tablero celebra, pero QA empieza a marcar “resolución incompleta” y las reaperturas crecen. Es como presumir que bajaste de peso porque la báscula está mal calibrada: baja el número; no cambia la realidad.

Qué cuenta como ‘empeora la operación’: deuda, fricción y trabajo que se desplaza

Operación empeora cuando el trabajo no se elimina, solo se mueve:

En el tiempo: más recontactos.
De nivel: de L1 a L2.
De canal: de chat a email, de inbox a redes.
A “urgente”: todo se vuelve caso crítico porque se dejó pudrir.

Eso es deuda operativa: decisiones que hoy se ven eficientes pero mañana te cobran intereses.

Definición práctica: eficiencia es tiempo y volumen; efectividad es resolución y calidad. Puedes ser muy eficiente resolviendo mal. Y puedes ser efectivo tan lento que rompes la experiencia. El punto es medir ambas sin autoengaño.

La regla de oro: ningún KPI de eficiencia se interpreta sin su costo oculto

Regla simple que evita discusiones eternas: todo KPI de eficiencia necesita al menos dos guardarraíles de efectividad.

Si AHT baja: mira recontacto y escalación.
Si SLA mejora: mira backlog real y calidad.
Si productividad sube: mira reaperturas y quejas.

Cuando alguien diga “pero el número mejoró”, la respuesta profesional es: “perfecto, ¿qué costo oculto estamos pagando?”.

Señales de ‘KPI bonito’: cuándo el número sube por definición, incentivos o backlog (sin que nadie ‘haga trampa’)

La mayoría de los KPIs engañosos en soporte no nacen de mala intención. Nacen de tres cosas muy humanas:

movemos definiciones para ordenar el caos,
empujamos con incentivos,
movemos backlog para sobrevivir al pico.

El problema es interpretarlos después como si fueran “la verdad” sobre resolución.

Y ojo: si conviertes esto en cacería de brujas, pierdes. Si lo tratas como higiene de medición, ganas. Se puede ser duro con el dato sin ser injusto con la gente.

Cómo se fabrica una mejora sin querer: cambios de etiquetado, estados, macros y criterios de cierre

Primer mecanismo: se mueve la definición. Cambias estados, etiquetas, macros o el criterio de “resuelto”. A veces es necesario. Lo que quema es olvidar que rompiste la comparabilidad y seguir leyendo el tablero como si nada.

Modo de fallo típico: aparece una macro de cierre tipo “te comparto el enlace, cualquier cosa nos dices”. Suben “resueltos”, baja AHT, y a la semana sube recontacto. Nadie hizo trampa. El sistema premió un cierre rápido con ambigüedad.

Ejemplo de lectura correcta vs incorrecta:

Incorrecta: “AHT bajó 15%, felicidades”.
Correcta: “AHT bajó 15%, pero recontacto subió 8% y reaperturas 6%. Estamos moviendo trabajo a futuro”.

Tip que casi nadie hace (y debería): cuando cambies estados o macros, declara un quiebre de medición. Separa el “antes” y el “después” en el análisis. Esa frase te ahorra peleas y “milagros” falsos.

Incentivos que empujan cierres rápidos: volumen, AHT, SLA y ‘productividad’

Segundo mecanismo: incentivos. Bono, ranking, presión diaria o un “por favor bajen AHT” repetido lo suficiente. El equipo se adapta. No porque sea malo. Porque es inteligente.

Modo de fallo: recortar contexto, transferir antes, cerrar conversaciones con un mensaje que suena a cierre (aunque no resuelva). Desde afuera, sube productividad. Desde el cliente, crece el “no me ayudaron”. Desde el piso, crece el cansancio porque vuelven los mismos casos.

Mini caso. Operación de delivery en Colombia: sube el target de conversaciones por hora. Contactos atendidos suben 25% y el SLA de primera respuesta mejora. En paralelo, QA marca +11 puntos en “información incompleta” y escalaciones suben 12%.

La decisión madura no es “quiten el incentivo y ya”. Es: si vas a presionar velocidad, declara guardarraíles desde el día uno. Recontacto y escalación suelen ser los más honestos, porque no dependen de que el equipo “se sienta bien”: dependen de que el cliente deje de volver.

Aquí calza la Ley de Goodhart: cuando una métrica se vuelve objetivo, deja de ser buena métrica. Útil para explicar esto sin pelear con nadie: [1]

Backlog que se mueve: de tickets a recontactos, de L1 a L2, de canal a canal

Tercer mecanismo: el trabajo se desplaza.

El modo de fallo más visible: “bajamos backlog” cerrando tickets viejos con mensaje estándar. El backlog del sistema baja, la foto queda limpia, pero el backlog real aparece en WhatsApp con clientes molestos, en L2 con escalaciones, o aguas abajo en devoluciones/contracargos.

Otro patrón: cambias el enrutamiento para “balancear carga” y, sin querer, mandas lo complejo a un equipo menos preparado. Resultado: el AHT del equipo senior baja (reciben fácil) y el del equipo junior sube con más transferencias. En el total puede verse “mejor”, pero la operación queda más frágil.

Tip que salva semanas: cada vez que celebres una baja de backlog, pregúntate “¿en qué cola reaparece?”. Si no lo sabes, no lo celebres todavía.

Checklist de sospecha: preguntas rápidas para detectar inflación del KPI

Cuando sientas que el tablero miente, evita discutir “sensaciones”. Lleva la conversación a tres verificaciones rápidas:

¿Cambió algo de definición (estados, etiquetas, macros, criterio de cierre) en las últimas 4 semanas?
¿Cambió la presión o el incentivo (AHT, SLA, volumen) y coincide con la mejora?
Mientras este KPI “mejoró”, ¿qué costo oculto también se movió (recontacto, escalación, reaperturas, QA)?

Si dos de tres dan “sí”, estás frente a kpis de soporte que engañan. No porque haya villanos: porque mediste una cosa y optimizaste otra.

Cruces mínimos de evidencia: cómo validar si el KPI refleja resolución o solo movimiento de trabajo

El antídoto contra métricas vanity en customer support no es un proyecto eterno de analítica. Es un cruce mínimo de evidencia que obligue a mirar el mismo caso desde tres ángulos.

Piensa así: un KPI aislado es una foto. Una operación es una película. Si solo miras la foto que te conviene, siempre vas a “ganar”… hasta que el cliente te cobre la factura.

Triángulo mínimo: conversación (qué pidió), ticket (qué se registró), eventos (qué pasó después)

Tres esquinas, sin sofisticación innecesaria:

Conversación: qué pidió el cliente y qué entendió el agente. Aquí salen los “sí, pero no”: el cliente pedía reembolso y tú enviaste política genérica.

Ticket: qué quedó registrado. Categoría, subcategoría, motivo, estado final. Aquí se ven maquillajes involuntarios (etiquetar “consulta general” porque es rápido).

Eventos: qué pasó después. Recontacto por el mismo motivo, reapertura, escalación, devolución, cancelación, queja en otro canal.

Esto no prueba causalidad estadística. Pero sí detecta patrones operativos con suficiente confianza para no tomar decisiones a ciegas.

Señales duras vs señales blandas: qué pesa más cuando se contradicen

Cuando AHT baja y el equipo “se siente peor”, suelen chocar dos tipos de señales.

Señales blandas: percepción del piso, anécdotas, “se siente pesado”. No las descartes. Úsalas para elegir dónde mirar.

Señales duras: recontacto a 7 días por el mismo motivo, escalaciones, reaperturas, QA de resolución, quejas escaladas por el cliente.

Decisión simple: si las señales duras empeoran mientras la eficiencia mejora, casi siempre estás ante una optimización con costo oculto.

Tip útil para bajar el drama: cambia “yo siento” por “yo vi”. “Vi tres clientes que volvieron por lo mismo” abre la puerta a medir. “Siento que está peor” abre la puerta a pelear.

Muestreo rápido que sí cabe en operaciones: 10 casos, 3 cortes, 15 minutos

Este muestreo es deliberadamente pequeño. No busca precisión quirúrgica: busca dirección.

Toma 10 casos de la semana donde el KPI “mejoró” (AHT bajo, cierres recientes, casos dentro de SLA). Y aplica tres cortes:

Complejidad percibida: fácil/medio/difícil (dos personas deben coincidir; no te pongas académico).
Resultado real: resuelto a la primera, resuelto con ida y vuelta, no resuelto.
Costo oculto: transferencia, escalación, reapertura o recontacto.

Regla de decisión que vale oro: si 3 de 10 tienen costo oculto fuerte, no declares victoria. Investiga antes de subir targets.

Qué hacer cuando faltan datos: proxies operativos sin inventar precisión

Si no tienes eventos perfectos, usa proxies estables (y no los cambies cada semana).

Proxy útil: recontacto por el mismo motivo en 7 días. Si tu etiquetado es flojo, usa un proxy humano pero consistente: mismo cliente + palabras clave similares, o mismo flujo de producto.

Ejemplo típico: AHT baja 12% en chat. En conversación y ticket ves respuestas más cortas y más “te paso con el área”. En eventos/proxy, aparece transferencia en 4 de 10 casos. Lectura correcta: AHT bajó porque sacaste trabajo de la métrica, no porque resolviste mejor.

Otro: “resueltos” sube 20% tras cambiar criterio de cierre. Reaperturas suben 10% y recontacto 7%. Lectura correcta: tu tablero premió cerrar, no resolver.

Error común: perseguir el “FCR perfecto” sin acordar qué cuenta como “mismo motivo”. Mejor: define un proxy simple, que todos entiendan, y úsalo estable un mes. Ajustas después.

Para aterrizar cómo se malinterpretan métricas y por qué los tradeoffs importan, incluso fuera de soporte, esta pieza de precisión/recall lo explica bien: [2]

Comparar equipos o sucursales sin autoengañarte: mix de casos, estacionalidad y picos que cambian el tablero

Comparar equipos suena justo… hasta que recuerdas que no están jugando el mismo partido. El error más caro en operaciones de soporte es premiar o castigar con promedios sin controlar el mix de casos.

De ahí nacen incentivos tóxicos, rotación y una cultura de “evitar lo difícil”. Si alguna vez escuchaste “ese equipo es flojo” y ese mismo equipo atiende lo más complejo, ya viste el patrón.

El error más común: comparar promedios sin controlar el mix

El promedio es un gran mentiroso cuando cambia la composición.

Ejemplo que invierte conclusiones. Equipo A atiende 70% casos simples y 30% complejos. Tiempos: 6 min en simples y 18 min en complejos. AHT ≈ 9.6 min.

Equipo B atiende 40% simples y 60% complejos con los mismos tiempos por tipo. AHT ≈ 13.2 min.

Si comparas AHT global, A “gana”. Si comparas desempeño dentro de cada tipo de caso, son iguales. La diferencia es el mix.

Esto es donde te quemas: subes presión al equipo B para “bajar AHT”, y el equipo aprende a transferir o cerrar rápido lo complejo. El KPI baja y la operación empeora. Te disparas en el pie y luego te preguntas por qué cojeas.

Cuándo un equipo ‘mejora’ solo porque recibe casos más fáciles (o menos canales complejos)

Dos sesgos aparecen rápido:

Canal. Chat tiende a ser más rápido que voz, pero más propenso a cierres ambiguos. Email puede inflar tiempos por espera aunque la resolución sea buena.

Severidad/segmento. Enterprise, fraude, incidentes de pagos y problemas técnicos suelen ser más largos y con más riesgo. Si un equipo absorbe eso, su tablero de eficiencia se ve peor aunque esté protegiendo el negocio.

Idioma y horario también pesan. Turnos nocturnos pueden tener menos volumen, pero casos raros. Un sitio con más bilingües se come complejidad que otro ni ve.

Tip práctico: antes de mostrar un ranking, muestra el mix. Si no puedes mostrarlo, no muestres ranking.

Cómo leer picos y estacionalidad sin castigar al equipo que se comió el incendio

En picos, el SLA se puede sostener “a la fuerza” con respuestas rápidas pero poco resolutivas. Dos semanas después aparece el recontacto, y todo el mundo actúa sorprendido.

Lo sano es separar dos preguntas: “¿sobrevivimos el pico?” y “¿resolvimos bien?”. En picos priorizas contención, pero lo dices explícitamente. Luego haces limpieza de deuda.

Si trabajas con incidentes técnicos, ayuda pensar como monitoreo: no solo importa “estuvo arriba”, importa estabilidad y síntomas previos. Este marco se entiende bien acá: [3]

Reglas de decisión: qué comparaciones sí son justas (y cuáles se prohíben)

Comparaciones que deberías prohibir por defecto:

AHT global entre equipos sin buckets de complejidad/motivo.
Productividad entre canales distintos sin expectativas distintas.
Semanas con pico contra semanas normales como si fueran lo mismo.

Comparaciones que sí son justas sin ciencia de cohetes: compara en el mismo periodo y con 3–5 cortes mínimos (canal, motivo, severidad, segmento, turno). Y siempre con guardarraíles al lado: si un equipo “mejora” AHT pero empeora escalación/recontacto, esa mejora no se compara como si fuera sana.

Antes de la reunión ‘segura’: workflow de preguntas que separa señal de ruido (y evita decisiones impulsivas)

Estrategia de asignación	Mejor para	Ventajas	Riesgos	Recomendado cuando
Modo de Fallo: KPI por segmentación	Evitar decisiones 'peligrosas'	Aísla el problema, permite acciones quirúrgicas	Sobrecarga de datos, complejidad de análisis	KPI general mejora, pero subsegmentos empeoran. — Segmentar comparaciones, no subir targets de volumen sin guardarraíles
Volumen (Default)	Operaciones estandarizadas, baja variabilidad	Simplicidad, escalabilidad, métricas claras	Ignora complejidad, 'cherry-picking', baja calidad en casos difíciles	80%+ casos idénticos, bajo impacto de error
Complejidad/Habilidad	Casos variables, especialización requerida	Mejora calidad, optimiza expertos, alta satisfacción cliente	Cuellos de botella, desbalance de carga, requiere clasificador robusto	Casos de alto impacto, conocimiento específico
Rotativa/Equitativa	Desarrollo multifuncional, prevenir burnout	Carga justa, fomenta aprendizaje, reduce dependencia experto	Menor eficiencia inicial, asigna complejos a novatos, requiere supervisión	Equipo en entrenamiento, busca polivalencia
Disponibilidad (FCFS)	Picos impredecibles, respuesta rápida	Minimiza espera, alta reactividad, agilidad percibida	Desequilibrio carga, errores por prisa, no considera complejidad	Velocidad crítica, casos mayormente simples
Modo de Fallo: KPI por definición	Identificar métricas engañosas	Evita decisiones impulsivas, previene inflar números	Ignorar mejoras genuinas, parálisis por análisis	KPI mejora drásticamente sin cambios operativos. — Tabla tipo workflow_table con inputs, preguntas, señales y acciones
Híbrida (Volumen + Complejidad)	Operaciones grandes, mix de casos	Combina eficiencia y calidad, flexibilidad, uso óptimo recursos	Complejidad implementación, requiere reglas claras, monitoreo constante	Optimizar volumen y calidad con recursos variados
Modo de Fallo: KPI por incentivos	Detectar comportamientos no deseados	Corrige incentivos desalineados, previene daño	Desmotivar equipo, generar desconfianza	Nuevo incentivo, KPI anómalo. (Pausar incentivo, auditar muestra)

Esta tabla parece de “asignación”, pero úsala como herramienta de reunión: te obliga a declarar qué estás optimizando y qué riesgo aceptas.

Si hoy estás operando en Volumen (Default), no finjas que no existe el riesgo de cherry-picking (evitar casos difíciles) y de baja calidad en bordes. Si estás en Disponibilidad (FCFS) por picos, no te sorprendas cuando suban errores por prisa. Y si metes Complejidad/Habilidad, celebra la calidad… pero asume cuellos de botella y la necesidad de reglas claras.

Las filas “Modo de Falla” son, en realidad, frenos de mano:

KPI por segmentación: cuando el KPI general mejora pero un subsegmento se rompe. (Aquí muere el “promedio feliz”).
KPI por definición: cuando el KPI mejora drásticamente sin cambios operativos reales. Señal de portería movida.
KPI por incentivos: cuando un incentivo nuevo produce un KPI “milagroso”. Antes de festejar, audita.

Hay reuniones que hacen avanzar la operación, y otras que solo fabrican tranquilidad. La diferencia suele ser un ritual previo: un workflow de control que obliga a responder preguntas incómodas antes de fijar nuevos targets.

Los 5 cortes previos: definición, incentivo, backlog, mix, evidencia

Antes de concluir “mejoramos”, pasa el KPI por cinco cortes:

Definición: ¿cambió cómo se mide (estados, etiquetas, macros, criterio)?
Incentivo: ¿qué presión se ejerció y qué conducta empujó?
Backlog: ¿se resolvió o se movió a otra cola?
Mix: ¿cambió la composición de casos/canales?
Evidencia: ¿qué dice el cruce conversación–ticket–eventos (aunque sea proxy)?

Si esto suena a burocracia, piénsalo como cinturón de seguridad: no lo usas porque planeas chocar; lo usas porque eres adulto.

Decisiones seguras vs decisiones peligrosas según el diagnóstico

Decisiones seguras cuando detectas costo oculto:

Pausar o ajustar el incentivo por 2 semanas.
Auditar una muestra pequeña semanal y compartir aprendizajes (no culpables).
Segmentar comparaciones por complejidad/canal antes de mover targets.

Decisiones peligrosas en ese mismo contexto:

Subir targets de volumen o bajar AHT target sin guardarraíles explícitos.
Exigir “cero backlog” como objetivo único (invita a limpieza, no a resolución).
Cambiar definiciones a mitad del mes para “mejorar” el tablero (matas el aprendizaje).

Línea para desactivar tensión sin alargar la reunión: optimizar solo AHT es como apagar la alarma de humo para dormir mejor. El silencio mejora, el incendio también.

Modos de fallo del ritual: cuando el checklist se vuelve teatro y no control

Esto falla cuando:

Se llena el ritual, pero no cambia ninguna decisión.
Se usa para culpar, entonces todos aprenden a esconder señales.
Se declaran guardarraíles, pero se ignoran cuando estorban al número.

La vacuna es simple: el objetivo no es “ganar la reunión”. Es proteger la operación mientras aprendes.

Qué acordar como equipo: dos métricas ‘guardarraíl’ por cada métrica de eficiencia

Aterrízalo en una frase operativa: por cada métrica de eficiencia que empuje comportamiento (AHT, volumen, SLA), acuerda dos métricas guardarraíl (recontacto, escalación, reaperturas, QA/CSAT) y ponlas al mismo nivel de visibilidad. Si un guardarraíl cruza el umbral, no se suben targets aunque el tablero “se vea mejor”.

Qué cambiar mañana (sin rehacer todo): acuerdos mínimos de métricas y un experimento de 2 semanas

Cuando detectas que el tablero miente, el impulso típico es rediseñar todo el sistema de métricas. Suena valiente, pero muchas veces es una forma elegante de postergar.

Hay una vía más útil: acuerdos mínimos + un experimento corto que te diga si estabas optimizando lo equivocado.

Dos acuerdos de tablero: guardarraíles y definiciones que no cambian sin aviso

Acuerdo 1: por cada métrica de eficiencia que uses para presionar, define dos guardarraíles y dales el mismo “peso visual” en el tablero. No como nota al pie.

Acuerdo 2: definiciones estables. Si cambias qué significa “resuelto” o cómo se etiqueta, se anuncia, se documenta y se marca la fecha de quiebre. Si no, vas a discutir meses por una mejora que solo fue administrativa.

Un experimento seguro: bajar presión de volumen en un bucket y medir recontacto/escalación

Experimento de 2 semanas, seguro y revelador.

Hipótesis: si bajas la presión de volumen en un bucket complejo, mejora la resolución y baja el costo oculto, aunque el AHT suba un poco.

Elige un bucket de alta fricción (por ejemplo, “reembolsos con validación” o “incidentes de pago”). Durante 2 semanas, baja el target de conversaciones por hora solo ahí y habilita más contexto.

Éxito: recontacto por mismo motivo a 7 días baja ≥10% dentro del bucket, y escalaciones bajan o se mantienen. Guardarraíl: CSAT o QA no cae más de un umbral acordado (por ejemplo, 2 puntos).

Fracaso: AHT sube, pero recontacto no baja y escalaciones suben. Eso te dice que el cuello no era la presión: puede ser conocimiento, tooling, políticas o falta de autoridad para resolver.

Tradeoff explícito (para que nadie se sorprenda): proteges calidad mientras reajustas eficiencia, no al revés.

Cómo comunicar el cambio sin desmotivar: del ‘cumpliste número’ al ‘resolviste bien’

Si lo comunicas como “ahora vamos a ser más lentos”, te disparas en el pie. Comunícalo como “vamos a resolver mejor para que el cliente no vuelva”.

Frase que funciona con liderazgo y agentes:

“Durante dos semanas vamos a medir éxito como menos recontacto y menos escalación en este tipo de casos. Si el AHT sube un poco pero el cliente deja de volver, eso es mejora real, no maquillaje”.

Cierre con plan de lunes, sin épica.

Usa el workflow de la sección anterior para auditar un KPI que “mejoró” esta semana. Congela definiciones por 30 días. Pon dos guardarraíles por cada métrica de eficiencia. Y corre el experimento de 2 semanas en un bucket complejo.

Barra realista de producción: si solo haces una cosa bien, que sea esto. No subas targets hasta cruzar evidencia mínima en 10 casos. Ese pequeño freno suele ser la diferencia entre una operación que aprende y una que solo presume números.

Fuentes

blogempresas.masmovil.es — blogempresas.masmovil.es
analyticslane.com — analyticslane.com
dotcom-monitor.com — dotcom-monitor.com

Cuando el número sube pero la operación empeora: señales de que estás midiendo lo equivocado