La reunión ganada, la semana perdida: el síntoma de que la verdad está siendo castigada
Hay una escena que se repite más de lo que nos gusta admitir. Lunes, comité de operación, tablero impecable: SLA en verde, AHT bajando, “todo bajo control”. Viernes: escalaciones al doble, backlog envejecido, supervisores haciendo malabares para que el turno no reviente. La reunión se ganó. La semana se perdió.
En soporte esto aparece con una elegancia casi ofensiva. En el reporte, “SLA 92%” y “AHT -8%” suenan a historia de éxito. En el piso, el backlog crece, el recontacto sube y el equipo empieza a “cerrar” tickets que vuelven a abrirse. La consecuencia es silenciosa pero letal: más trabajo por el mismo trabajo.
Cuando pasa, no estás frente a falta de datos. Estás frente a una cultura de datos que premia la presentación.
“Premiar presentación” es reconocer que el número luzca bien, aunque el sistema esté peor. Se premia el control visual, no la verdad operativa. “Premiar verdad” es lo contrario: se reconoce al equipo que trae evidencia incómoda con contexto, aunque el tablero se ensucie, porque ese es el único camino para decidir mejor.
El costo no es solo de métricas vanidosas. Es de seguridad psicológica y de algo más fino: la capacidad de percibir el error antes de que te explote. Marcello de Souza lo plantea con una frase que pica: el mayor riesgo no es equivocarse, es perder la capacidad de notar el error. Si quieres esa idea bien desarrollada: [1]
La buena noticia: esto puede cambiar en semanas, no en años, si cambias hábitos y reglas de decisión. No necesitas comprar otra herramienta ni rediseñar todo el BI. Necesitas rituales donde se discuten decisiones (no gráficas) y reglas que vuelven seguro decir: “esto se ve bien, pero está mal”.
El patrón que delata el maquillaje: métricas perfectas, escalaciones en aumento
Cuando una operación vive el combo de “tablero limpio” y “turno incendiado”, casi siempre aparece el mismo patrón.
Primero, una mejora demasiado rápida en una métrica vulnerable (SLA o AHT). Después, se disparan señales que cuesta más esconder: backlog aging real, recontacto, escalaciones. Y al final dirección se entera tarde y con sorpresa, como si hubiera sido magia negra. No lo fue: fue contabilidad creativa del día a día.
Regla práctica para ahorrar discusiones: cuando veas un salto de desempeño sin una explicación operativa simple, asume que cambió el comportamiento antes de asumir que mejoró el sistema. A veces la mejora existe, sí. Pero si no puedes narrarla en dos frases con hechos (“qué cambió, dónde, y qué costo tuvo”), lo más probable es que el equipo aprendió a jugar el juego.
El truco no suele ser “mentir” en grande. Es optimizar decisiones pequeñas para que el reporte cuente una historia conveniente. Como ponerle filtro a una foto: sigues siendo tú, pero ya no eres confiable como evidencia.
Qué se rompe primero cuando premias la presentación (y cómo se ve en soporte y ops)
No falla de golpe. Primero se rompe el lenguaje. Luego se rompe el flujo. Al final se rompe el juicio. Y cuando te das cuenta, tu operación está corriendo una carrera de velocidad con los zapatos mal amarrados, pero celebrando porque el “promedio” mejoró.
En soporte y operaciones, el incentivo a verse bien suele nacer de una mezcla peligrosa: bonos atados a un número, presión de liderazgo por “no traer problemas”, y lectura literal del dashboard como si fuera el piso mismo. No se miente con descaro; se aprende a sobrevivir.
El primer quiebre suele ser el etiquetado “creativo”. Cambias categoría y cambias el SLA que aplica, la ruta de atención y la historia. Microescenario: “Incidente crítico” tiene SLA estricto. Con presión por “poner todo en verde”, mágicamente hay menos críticos y más “consultas generales”. El SLA mejora… y las escalaciones con producto suben porque los casos críticos siguieron siendo críticos, solo que ahora llegaron tarde a la ruta correcta.
Aquí te quemas si lo tratas como “problema de capacitación”. A veces lo es, pero muchas veces es incentivo. Si castigas al equipo cuando etiqueta “lo feo”, el equipo aprende a etiquetar “lo bonito”. La corrección real es cambiar la conversación: la etiqueta no se audita para regañar, se audita para entender carga, causas y rutas.
El segundo quiebre son las colas invisibles: “en seguimiento”, “pendiente”, “esperando al cliente” (aunque el cliente ya respondió), o trabajos paralelos fuera del SLA. Es la fábrica del fenómeno dashboards bonitos y decisiones malas. Se “cumple SLA” moviendo el problema a una carpeta que no cuenta. El reporte mejora, pero la operación empeora en dos cosas muy concretas: carga acumulada (fatiga) y variabilidad (planificación imposible).
Si quieres una imagen clara de esto, la idea del “nadie lo vio venir” está muy bien contada aquí: [2]
El tercer quiebre es el más caro: decisiones reactivas disfrazadas de estrategia. Se ajusta staffing por SLA sin mirar backlog aging. Se exige bajar AHT sin mirar recontacto. Se cambia el guion por CSAT sin mirar sesgo de encuesta. Esto es donde la organización confunde “tener datos” con “decidir bien”. Andre Arpi lo dice sin anestesia: decidir con datos mal estructurados puede ser peor que decidir sin datos, porque te da falsa confianza y te empuja a apalancar lo equivocado: [3]
Señales tempranas: cuando el tablero no calza con el turno
No necesitas un proyecto para detectar el problema. Necesitas ojos y una lista corta de señales que cualquiera en el turno reconoce.
Si tu cultura de datos que premia la presentación está ganando, se nota así:
- El SLA mejora mientras el backlog total o el backlog aging empeora.
- El AHT baja, pero suben recontacto, transferencias o escalaciones.
- Disminuyen los “casos difíciles” en el reporte, pero aumentan las quejas internas de complejidad.
- Crece el “esperando al cliente” y los supervisores sienten que pasan el turno persiguiendo respuestas.
- El CSAT se ve estable, pero se endurecen comentarios cualitativos por canales no encuestados.
- El turno reporta cansancio y “sensación de caos” aunque el tablero luzca estable.
Si te identificas con varias, no es para deprimirse. Es normal cuando llevas tiempo premiando presentación. La pregunta útil es: ¿qué vas a cambiar primero para que el tablero deje de ser máscara y vuelva a ser herramienta?
Qué conviene medir y en qué sí confiar: una jerarquía de evidencia para decidir sin maquillaje
| Estrategia de asignación | Mejor para | Ventajas | Riesgos | Recomendado cuando |
|---|---|---|---|---|
| Métricas de Eficiencia Operativa (AHT, SLA, Backlog Aging) | Optimizar recursos y procesos internos | Cuantificables. controlables. impacto en costos | Fácilmente maquillables (ej. cerrar tickets sin resolver) | Mejorar productividad. reducir costos. con reglas de calidad |
| Métricas de Resultado (CSAT, NPS) | Impacto final en cliente/negocio | Reflejan experiencia real. difíciles de manipular directamente | Lentas. atribución compleja. muchos factores | Visión holística de servicio. decisiones estratégicas |
| Métricas de Comportamiento (Recontacto, Escalaciones) | Identificar fricciones y puntos de dolor | Señales tempranas de problemas. accionables | Maquillables (ej. desviar llamadas). no resuelven causa | Entender por qué clientes actúan. optimización de procesos |
| Framework de Jerarquía de Evidencia | Evaluar confiabilidad de señales de datos | Lenguaje común para calidad de datos. evita decisiones débiles | Requiere disciplina/entrenamiento. percibido como burocrático | Cultura premia presentación sobre verdad. fomentar pensamiento crítico |
| Análisis de Causa Raíz (5 Porqués) | Entender origen de problemas complejos/recurrentes | Va más allá de síntomas. previene recurrencia | Consume tiempo/recursos. superficial si no se profundiza | Problemas persistentes que métricas no resuelven |
| Reglas de Decisión 'Si/Entonces' | Automatizar decisiones. estandarizar respuestas | Reduce sesgos. acelera decisiones. auditable | Rigidez. requiere mantenimiento. oculta problemas si la regla es mala | Consistencia en decisiones repetitivas. escalar operaciones |
| Métricas de Vanidad (ej. interacciones, likes) | Motivación superficial. reportes sin profundidad | Fáciles de obtener/presentar. sensación de progreso | No reflejan valor real. desvían atención. incentivan maquillaje | NUNCA para decisiones críticas. solo comunicación superficial |
Cuando una empresa dice “somos data driven” pero evita mirar lo incómodo, termina siendo data blind con un PowerPoint bonito. Fast Company lo plantea con claridad: los datos amplifican la experiencia, pero solo si estás dispuesto a ver lo que duele: [4]
La salida no es dejar de medir. La salida es acordar una jerarquía de evidencia: un lenguaje compartido para distinguir entre señales para monitorear y señales aptas para decidir.
En la práctica, esto te protege de dos trampas típicas.
La primera: usar métricas de eficiencia (SLA/AHT) como si fueran la verdad del servicio. Son útiles, cuantificables, controlables. Pero si no están amarradas a calidad, son maquillables. El clásico: cerrar tickets sin resolver para que “salga el número”. Si vas a usarlas para decisiones, exige siempre una contraseñal de calidad (muestreo, reabiertos, recontacto por causa) y una de carga (aging real).
La segunda: usar métricas de resultado (CSAT/NPS) como si fueran el volante del día a día. Son más difíciles de manipular directamente y reflejan experiencia final, pero son lentas y la atribución es compleja. Sirven para dirección y decisiones estratégicas; para operar por semana necesitas señales líderes que te avisen antes.
Por eso las métricas de comportamiento (recontacto, escalaciones) son oro… con advertencia. Son señales tempranas y accionables, pero también se pueden “administrar” cambiando definiciones, desviando contactos o evitando rutas formales. Úsalas para encontrar fricciones y causas, no para castigar.
Aquí entra el framework de jerarquía de evidencia: no como burocracia, sino como pregunta disciplinada. “¿Qué tan fácil es manipular esta señal con comportamiento local?” y “¿qué tendría que ver para creerla?” Cuando la cultura de datos que premia la presentación ya está instalada, ese lenguaje despersonaliza la discusión: deja de ser “me estás acusando” y pasa a ser “esta evidencia es débil, pidamos respaldo”.
Cuando el problema es recurrente, el análisis de causa raíz (5 Porqués) evita el juego de whack-a-mole. Consume tiempo, sí. Y si lo haces superficial, es teatro. Pero cuando tu operación lleva meses “mejorando números” sin mejorar realidad, necesitas ir a la causa, aunque sea incómodo.
Y cuando una decisión es repetitiva, las reglas de decisión “Si/Entonces” te dan consistencia y auditabilidad. Funcionan bien para escalar operaciones, pero tienen dos riesgos reales: rigidez (se vuelven religión) y mantenimiento (nadie las revisa hasta que rompen algo). Una regla mala puede ocultar un problema durante semanas con una sonrisa verde.
Sobre las métricas de vanidad: son útiles para comunicación superficial (“miren cuántas interacciones”), pero no para decisiones críticas. Si te aferras a ellas, te va a pasar lo mismo que con un auto: la música suena perfecto… hasta que ves que ibas sin gasolina.
Un tip que cambia la conversación: antes de discutir si una métrica subió o bajó, pregúntense si esa métrica puede ser manipulada con comportamiento local. Si la respuesta es sí, entonces nunca debería ser la única base de una decisión.
Y para combinar líderes y rezagadas sin autoengaño, una mezcla sana en soporte es: una señal de resultado (CSAT), una de comportamiento (recontacto o escalaciones por causa) y una de carga (backlog aging). Si solo miras rezagadas, llegas tarde. Si solo miras líderes, te puedes engañar.
Rituales y handoffs que vuelven seguro decir la verdad: reglas de juego entre líderes, analistas y supervisores
El dashboard rara vez es el villano. El villano es el momento en que alguien interpreta el tablero, lo convierte en narrativa, y lo usa para premiar o castigar. Ese traspaso de interpretación y decisión define si tu cultura de datos premia la presentación o premia la verdad.
Construir una cultura basada en datos es trabajo de personas, no de gráficas: roles, hábitos y expectativas claras. Google lo explica desde ese ángulo, sin misterio: [5]
Lo que funciona en el mundo real es crear un espacio formal donde traer evidencia incómoda no sea un acto de valentía personal, sino una parte normal del trabajo. Y esto no se logra pidiendo “transparencia”. Se logra cambiando el sistema de recompensas y la forma de discutir.
Regla de liderazgo que se nota en una semana: cuando alguien trae una mala noticia con evidencia, tu primera reacción es tu política real. Si preguntas “¿quién la regó?”, acabas de entrenar maquillaje. Si preguntas “¿qué regla nos falta o qué supuesto estaba mal?”, acabas de entrenar verdad.
El ajuste más potente es cambiar la reunión semanal: en vez de revisar métricas, revisar decisiones tomadas con esas métricas. En lugar de “SLA subió”, preguntas: “decidimos priorizar X para bajar escalaciones, ¿qué pasó en realidad?”. La métrica deja de ser juicio moral y se vuelve evidencia para aprender.
El segundo ritual que corta la narrativa son los casos centinela: una muestra pequeña, repetible y representativa (incluye reabiertos, “esperando al cliente”, casos de alto impacto). Veinte minutos con ocho casos reales suele explicar más que cuarenta diapositivas. El objetivo no es cazar culpables; es detectar si la operación está pagando costo oculto por verse bien.
Advertencia real: si conviertes QA en policía, el equipo aprende a esconder errores y a evitar casos difíciles. Si lo conviertes en aprendizaje, el equipo empieza a traer los casos feos temprano, que es justo lo que necesitas.
El tercer ritual es la conversación de excepciones: lo que el dashboard promedia. Incidentes masivos, cambios de producto, campañas, picos estacionales, un proveedor que falló. La operación lo siente; el promedio lo aplana. Bastan tres preguntas: qué pasó, cuánto duró y qué indicador dejó de ser confiable durante esa ventana. Eso evita decisiones duras basadas en métricas fuera de contexto.
Y luego vienen los incentivos. Si haces ranking individual por AHT o por cierres, el sistema se vuelve un videojuego mal diseñado: la gente encuentra el glitch y lo explota. Mueve el reconocimiento hacia salud del sistema: reducción de recontacto por causa, reducción de escalaciones reales, mejora de backlog aging con controles de calidad. Son señales que obligan a colaborar, no a competir por verse bien.
Modos de fallo: cuando el dashboard es perfecto y la decisión es mala
Hay un tipo de fracaso especialmente irritante. El tablero estaba perfecto. La decisión se tomó “con datos”. Y aun así el cliente sufre y la operación se quema. No es mala suerte. Es fragilidad del sistema de evidencia.
Cinco modos de fallo comunes en soporte y ops, y cómo se ven cuando ya estás dentro:
Optimizar AHT y destruir resolución real. Síntoma: AHT baja, suben recontacto, transferencias o escalaciones. El equipo “va rápido”, pero deja deuda. La prueba que no falla es revisar una muestra de cierres rápidos y ver si el cliente tuvo que volver.
Cumplir SLA moviendo el problema. Síntoma: SLA en verde, crecen “pendientes”, “seguimiento”, backlog real y escalaciones. El número cumple; la realidad se acumula. Si no tienes visibilidad de esas colas, no es que no existan: es que no las estás mirando.
CSAT alto por sesgo de encuesta. Síntoma: CSAT sube mientras cae la tasa de respuesta, o mientras se endurecen comentarios por otros canales. No es que la gente esté más feliz; es que dejó de contestar (o contesta un segmento distinto).
Productividad por cierre superficial. Síntoma: suben cierres por agente, baja tiempo por caso, suben reabiertos o duplicados. Esto se disfraza de “eficiencia”, pero es retrabajo diferido.
Bajar escalaciones por redefinición. Síntoma: “bajan” escalaciones, pero producto reporta más urgencias por fuera, o aparecen rutas paralelas. Cambió el conteo, no el dolor.
Para detectar esto antes, funciona un freno simple: un premortem corto antes de decisiones que mueven capacidad, prioridades o políticas. En 10 minutos, el equipo asume que la decisión fracasó en dos semanas y nombra por qué. Luego acuerdan dos señales que deberían empeorar si esas causas aparecen (recontacto, aging, escalaciones por causa) y un límite de seguridad para corregir temprano.
Lo más útil aquí es una figura con permiso explícito para hacer la pregunta incómoda: “¿esta métrica se puede maquillar? ¿con qué otra señal la cruzamos?”. Cuando esa pregunta se vuelve normal, la cultura empieza a cambiar.
Plan de 2 semanas para cambiar decisiones, sin rehacer toda tu analítica
Esto no es un programa anual. Es un cambio de hábitos que cabe en el calendario real.
En la primera semana, elige dos decisiones recurrentes que hoy se estén tomando con un solo KPI (ajustar staffing, mover prioridades del backlog, cambiar macros). Para cada una, acuerda evidencia mínima: una señal de carga, una de calidad y una de comportamiento. Y define un límite de seguridad: algo que, si empeora, obliga a pausar o corregir.
En paralelo, instala una muestra pequeña de casos centinela. No para “auditar personas”, sino para verificar que la historia del dashboard se sostiene al mirar realidad.
En la segunda semana, corre dos ciclos de reunión centrada en decisiones (no en métricas): uno a mitad de semana y otro al cierre. Mantén un registro corto y visible: qué decidimos, qué esperábamos ver, qué vimos. Si hubo picos o eventos, agrega una conversación breve de excepciones para no castigar al equipo por un promedio engañoso.
Para sostenerlo, necesitas soltar algo. Recorta al menos una métrica de vanidad del tablero semanal. Y pausa el ranking individual basado en una métrica manipulable (aunque sea como piloto). Si todo es prioridad, nada es prioridad.
Criterios observables al final de dos semanas: en las reuniones ya se escucha “no sabemos aún” sin castigo, seguido de “qué evidencia falta”. Y al menos una decisión cambia por contraste de señales: no recortas personal pese a SLA verde porque recontacto y aging lo desaconsejan, o aceptas un SLA un poco menos “bonito” para bajar deuda operativa.
Cierre simple para este lunes: toma una decisión real de la semana y pásala por tu jerarquía de evidencia. Acordar evidencia mínima, instalar un límite de seguridad que nadie pueda ignorar, y correr dos ciclos de revisión de decisiones. Si haces eso, ya le quitaste poder a la presentación y se lo devolviste a la operación.
Fuentes
- marcellodesouza.com.br — marcellodesouza.com.br
- observatoriorh.com — observatoriorh.com
- andrearpi.com — andrearpi.com
- fastcompany.mx — fastcompany.mx
- cloud.google.com — cloud.google.com