A veces el tablero parece un reloj suizo y la operación, una licuadora. Los KPIs “mejoran”, pero suben quejas, escalados y cansancio. Ese choque suele ser evidencia sucia en dashboards: no te faltan datos; lo que tienes no representa lo que realmente pasó en el flujo.
En ops, “sucia” no siempre es “incorrecta”. Es más traicionera: se ve coherente, pasa la vista rápida y aun así te empuja a una mala decisión. Y cuando el dashboard se ve “serio”, bajamos defensas.
Lo vi en un equipo que recortó turnos nocturnos porque “bajó el volumen”. Dos semanas después: backlog, escalados, NPS abajo. La demanda no había caído; lo que cambió fue el conteo: reaperturas y handoffs contados distinto, más un ajuste de ventana que planchó picos. El tablero no “mintió” en un sentido técnico. Solo dejó de significar lo que todos creían.
La promesa de este texto es simple: detectar señales sin convertir tu agenda en una auditoría eterna. Decidir bien con evidencia imperfecta, pero con el riesgo acotado.
Qué hacer 10 minutos antes de la reunión cuando el tablero “se ve perfecto”
Si el dashboard entra a la reunión “demasiado ordenado”, no lo celebres todavía. En soporte y operaciones, lo perfecto a veces es maquillaje de un flujo imperfecto: merges, reaperturas, cambios de canal, definiciones que se movieron medio centímetro. Así nace la mala decisión “razonable”.
Definición operativa para usar hoy: evidencia sucia (en soporte/ops) es cuando el KPI se mueve por cómo se capturan, agrupan o cierran los casos (campos, estados, ventanas y reglas) más que por un cambio real en demanda o calidad de servicio. No es “dato falso”; es dato que ya no representa lo que crees que representa.
Ejemplo típico y doloroso: el tablero muestra SLA 95% estable y “volumen -12%” tres semanas. La tentación: recortar turnos y congelar horas extra. Dos días después, explota el backlog y suben escalados. ¿Qué pasó? No cayó la demanda: subieron reaperturas (que tu vista contaba como “nuevo” en Created) y además cambió la regla de cierre (Solved vs Closed). El tablero estaba estable… sobre una definición que ya no era la misma.
La frase que cambia el tono de la reunión es esta: “¿Qué tendría que ser cierto para que este KPI sea confiable hoy?”. No es filosofía; es contrato. Si el equipo no puede decirlo en voz alta, estás discutiendo números sin contexto.
En soporte, dos supuestos suelen ser los que más te salvan (o te hunden). Uno: que un “ticket” equivale a un problema único, no a un duplicado o recontacto. Dos: que el reloj del tiempo (FRT/TTR/SLA) empieza y termina igual que la semana pasada (Created/Assigned, Solved/Closed). Cuando esos supuestos se rompen, el KPI sigue viéndose “bien” y por eso es peligroso.
Tip operativo: si nadie puede recitar el contrato del KPI sin abrir documentación, ponlo donde sí se usa: una nota visible en el dashboard con definición + fecha de última modificación + dueño. No es burocracia; es un detector de incendios.
Y una regla de oro para evitar la parálisis: no vas a validar todo. Valida lo que te puede romper. En 10 minutos, céntrate en tres zonas que suelen generar evidencia sucia en dashboards: (1) qué cuenta como caso (ticket vs conversación, merges), (2) qué evento inicia y termina el tiempo (Created/Assigned/Solved/Closed), (3) qué ventana estás mirando (24h vs 7 días; hora local vs UTC). Con eso, muchas “mejoras” se caen solas.
Ahora la decisión: si el KPI dispara decisiones difíciles de revertir (headcount, bonos, ranking público, cierre de canal, recorte de horario), pausa y valida evidencia. Si la decisión es reversible en 24–72h (priorización temporal, refuerzo puntual, routing con rollback), actúa con guardrails y pon fecha de revisión.
El error caro es usar “validación” como excusa para discutir infinito. La validación existe para evitar una mala decisión irreversible, no para bloquear toda acción.
Señales 1 y 2: cuando el volumen miente (duplicados y “tickets fantasma”)
Cuando el tablero dice “subió el volumen” o “bajó el volumen”, la pregunta no es “¿cuánto?” sino “¿qué estamos contando?”. En soporte, un ticket puede ser un problema real, un recontacto, un hilo duplicado por canal, una reapertura, un handoff entre niveles, o un merge mal hecho. Y eso altera el denominador de productividad, SLA, tiempos y hasta el humor del equipo.
Por eso la evidencia sucia en dashboards es tan peligrosa: te empuja a mover staffing, horarios y objetivos con números que parecen sólidos.
Señal 1: duplicados que maquillan performance
Mecanismo: los duplicados inflan “Created” y deforman promedios. Si muchos duplicados se cierran rápido (macro + “Solved”), pueden mejorar artificialmente productividad (tickets resueltos por agente/día), SLA (porcentaje dentro de objetivo) y TTR promedio (porque entran “pelotas chiquitas” que bajan el promedio). Es como medir tu velocidad en autopista… ignorando el tráfico de la ciudad.
Anclas concretas que no requieren ciencia de datos. Primero: revisa si existe acción/campo tipo “Merge / Fusionar / Vincular como duplicado” y, más importante, si se usa con criterio consistente. Cuando el merge es “a gusto del agente”, tu volumen se vuelve elástico.
Segundo: compara Created vs solicitantes únicos (unique requesters) en el mismo rango. Si Created sube 20% pero únicos sube 2–3%, tienes humo. En operaciones multicanal es común ver 8–20% de duplicados en semanas con cambios de canal o campañas. Con 18% de duplicados, un equipo puede pasar de 22 a 26 tickets/agente/día “en el tablero” sin resolver más problemas únicos. Y el SLA puede subir 3–5 puntos si esos duplicados caen en el bucket de “resuelto en minutos”.
Los duplicados nacen por razones bastante humanas: clientes ansiosos que escriben por WhatsApp y luego por email; bots o formularios que abren ticket nuevo cuando el cliente responde a un hilo existente; agentes que abren nuevo porque su métrica o su cola los empuja a hacerlo.
Cómo se siente en la trinchera: “no se siente más trabajo, pero el tablero dice que sí” o lo contrario. Cómo se ve en el tablero: picos de Created sin correlato en clientes únicos, más un aumento raro de resoluciones en <10 minutos mientras CSAT o recontactos no mejoran.
Tip práctico: si solo puedes agregar un contrapeso al volumen, que sean contactos únicos y recontacto en 24h. No son perfectos, pero bajan el riesgo de decidir por ruido.
Señal 2: “tickets fantasma” por reaperturas, merges y handoffs mal contados
El “ticket fantasma” no es inventado: es un caso real que se cuenta como si fuera nuevo (o se cuenta dos veces) por cómo viaja en el flujo.
Tres modos de fallo que se repiten:
Primero, reaperturas. Un ticket pasa de Solved/Closed a Open porque el cliente responde o porque falló la solución. Si tu reporting lo cuenta como “nuevo ingreso” o lo mete de nuevo en SLA como si empezara de cero, inflas demanda y distorsionas tiempos.
Segundo, merges inconsistentes. Al fusionar, el ticket “hijo” puede quedar resuelto con duración mínima, y el “padre” hereda comentarios. Resultado: suben los “resueltos rápidos” y baja el TTR promedio… aunque la complejidad real estaba en el padre.
Tercero, handoffs (Nivel 1 → Nivel 2 → Producto) que crean un ticket nuevo en otro grupo o herramienta y dejan ambos vivos. El tablero ve dos casos donde el cliente vive uno.
Anclas simples para detectar el fantasma: revisa secuencias de estados tipo Open → Pending → Solved/Closed → Reopened/Open y cambios de propiedad (Group/Queue, “Assigned team”, flags de escalamiento). La señal humana clásica es: “cerramos más, pero los clientes vuelven por lo mismo”. La señal de tablero: sube “Solved” y también sube Reopen rate o “reply after solved”.
Para validar rápido sin convertirte en auditor, usa tres cortes que se pueden hacer en 15 minutos con muestreo y sentido común: (1) agrupa mentalmente por cliente + motivo + 24h y mira si el mismo cliente aparece 3–4 veces por lo mismo; (2) mira mix por canal: si WhatsApp sube +30% y email cae -25%, suele ser migración o fricción, no crisis; (3) revisa si aumentó el combo “Solved” + “Reopened”: estás cerrando rápido y reabriendo rápido.
Regla de decisión: si duplicados estimados >10% o si el Reopen rate sube más de 2 puntos vs la semana anterior, no uses volumen ni productividad para recortar staffing. Úsalos para abrir una corrección de captura/merge y ajustar colas temporalmente.
Ejemplo con números (Argentina): una operación ve “Volumen semanal +22%” y decide pedir horas extra. Al cortar por problema único (cliente+motivo+24h) encuentran: Created 12.200, duplicados estimados ~14% (≈ 1.708), casos únicos aproximados 10.492.
La decisión cambia: antes, se planifica +12% de capacidad por “demanda”. Después, la demanda real era +6% y el resto era duplicación por un cambio de copy en WhatsApp (“si no responde, escriba de nuevo”). Se ajusta el mensaje y se define una regla operativa: si el cliente recontacta por el mismo motivo en 24h, se une al ticket original y se registra como recontacto (no como caso nuevo). Resultado: baja el “volumen” sin tocar servicio, y las horas extra se guardan para picos reales.
Advertencia real: a veces “duplicados” son un incidente auténtico (pago caído, login roto). Unir todo puede esconder severidad. Si la duplicación se concentra en un motivo y, además, suben escalados o quejas, trátalo como señal de incidente: agrupa para contar bien, pero escala para arreglar la causa.
Señales 3 y 4: rankings que castigan al mejor (mix de clientes y cambios de segmentación)
Los rankings son el tipo de evidencia sucia en dashboards más explosivo: en segundos se vuelve política. “Esta sucursal es mala”, “este equipo no rinde”, “cambiemos al líder”. El problema es que muchas veces el ranking no mide desempeño; mide qué trabajo te tocó y bajo qué etiquetas te midieron.
El antídoto no es dejar de medir. Es pedir comparabilidad mínima. Si no, terminas castigando al que se comió lo difícil y premiando al que tuvo una semana tranquila.
Señal 3: sesgo de mix que vuelve injusta la comparación
El mix mueve el KPI aunque la habilidad sea igual. Dos equipos pueden seguir el mismo proceso, pero uno atiende más clientes nuevos, más casos complejos o un producto más inestable. Eso impacta TTR, SLA y recontacto.
No necesitas veinte segmentos para verlo. Con dos cortes simples suele bastar: clientes nuevos vs recurrentes, y casos simples vs complejos (por motivo, severidad, o si requiere escalamiento). Luego mira un KPI sensible a dificultad (TTR o SLA de resolución) dentro de cada segmento, no solo el promedio global.
Ejemplo de cómo cambia el ranking cuando controlas por mix. Globalmente: Sucursal A SLA 88%, Sucursal B SLA 92% → “B es mejor”. Pero al abrir por “nuevos+complejos” aparece otra historia: A SLA 84%, B SLA 76%. En “recurrentes+simples” casi empatan: A 95%, B 96%. El ranking global estaba premiando el mix, no la ejecución donde más duele.
Regla de decisión: si la diferencia del ranking se explica por composición (como cuando una sucursal tiene >15 puntos más de “nuevos+complejos”), no tomes acciones estructurales (bonos, recortes, cambios de jefatura) sin ver el KPI dentro de segmentos comparables.
Señal 4: segmentación cambiante que mueve KPIs sin mover servicio
La segmentación cambia cuando alguien “mejora el formulario”, agrega categorías, redefine severidad o entrena al equipo a etiquetar distinto. El servicio puede ser el mismo, pero el tablero parece otro.
Dos escenarios comunes. Uno: se redefine severidad para dar visibilidad (“marquen más cosas como alta”). Si el SLA cambia por severidad (objetivos distintos), mueves el cumplimiento sin mover un proceso. Dos: se cambia el catálogo de motivos (antes “Pagos”, ahora “Pago rechazado / Devolución / Contracargo”). Durante 2–3 semanas, cada agente etiqueta a su manera y el tablero mezcla peras con manzanas.
Señales rápidas (sin estadística avanzada): si en las últimas 4 semanas se creó/modificó un campo como Motivo/Severidad/Tipo de cliente; si sube “Sin categoría / Other / N/A”; si aparece una categoría nueva que “se come” a la vieja.
Aquí te quemas de una forma distinta: usas rankings como si fueran estables y luego “ajustas objetivos” cada vez que el tablero se mueve. Eso destruye confianza. El equipo siente que juega un partido donde cambian el tamaño del arco.
Prueba rápida que cualquiera entiende: rehace el ranking dentro de 4 celdas (Nuevo vs Recurrente) × (Simple vs Complejo) y compara el top global contra el top en la celda más crítica (muchas veces, Nuevos+Complejos). Si el #1 global cae a #7 en esa celda, tu ranking global estaba premiando el mix.
Tradeoff (porque se usa mal): controlar por mix gana cuando quieres justicia comparativa (bonos, coaching, diagnóstico de capacidad). No controlar por mix gana cuando necesitas ver la experiencia promedio que vive el cliente “como viene”, sin excusas. Controlar por mix también puede volverse escondite (“me tocó difícil, no me midas”). Señal de abuso: cada mes cambian los segmentos o siempre hay una explicación nueva.
Regla para cerrar esa puerta: si una sucursal está consistentemente mal dentro de los mismos segmentos (tres semanas seguidas en Recurrentes+Simples), entonces sí es ejecución y es accionable. Si solo está “mal” en el promedio global por recibir más complejos, la acción no es castigo: es redistribución, soporte extra o ajuste de objetivos.
Ejemplo operativo: RR.HH. ve “Sucursal A última en SLA” y propone recortar bono. Acción sana: pausa 48h, re-ranking por segmentos y ver si cambió severidad. Resultado típico: A atiende 2× más Nuevos+Complejos y, además, hubo cambio de clasificación. En lugar de castigar, reasignas casos complejos, ajustas capacitación y dejas el ranking global para monitoreo, no para incentivos.
Señales 5 y 6: picos que no son picos (ventanas temporales, calendario y cambios de medición)
Un pico en el tablero activa modo “incendio”: horas extra, apagar canales, mover gente de proyectos, prometer SLAs imposibles. A veces corresponde. Muchas veces es un espejismo creado por ventanas, calendario y definiciones. Y ahí pagas dos veces: por reaccionar a algo que no existía y por cansar al equipo con falsas alarmas.
Señal 5: picos semanales ‘perfectos’ que son efectos de ventana o calendario
Cuando el pico es “demasiado educado” (siempre lunes, siempre fin de mes), sospecha de calendario antes de suponer crisis.
Dos anclas rápidas. Una: el selector de rango y el huso horario del reporting. Clásico: el tablero está en UTC y la operación vive en hora local; el “lunes” del tablero arranca el domingo por la tarde para tu equipo. La otra: procesos de “cierre por lote” (back office) o limpiezas de cola a una hora fija.
Ejemplo típico: la semana “cierra” domingo 00:00, pero el back office hace cierres y merges el lunes 9:00. Resultado: el tablero muestra pico de “Solved” el lunes (cierres en lote) y el fin de semana se ve “descontrolado” en Open porque nadie tocó esos estados. Modo de fallo: decides reforzar fin de semana porque el domingo se ve fatal, pero el problema real era el proceso de cierre, no la demanda.
Regla práctica para decidir si el pico es real: en las próximas 24 horas, compara casos creados vs casos que cambiaron de estado. Si el pico viene de cambios de estado de casos viejos, no es demanda nueva. Es contabilidad del flujo.
Señal 6: cambio de medición que simula mejora o crisis
Esta es la reina de la evidencia sucia en dashboards: el KPI cambia porque cambiaste el cronómetro, no porque cambiaste el desempeño.
Ancla 1: ¿TTR/SLA se mide hasta Solved o hasta Closed? En muchas herramientas, Solved es “resuelto operativamente” y Closed llega después (a veces por automatización). Cambiar el “End” te mueve el KPI sin tocar la operación.
Ancla 2: ¿el reloj empieza en Created o en Assigned/First touch? Si cambias a Assigned, todo lo que sucede en cola antes de asignación deja de existir en el KPI… y luego te preguntas por qué el backlog “aparece” de la nada.
Ejemplo: antes TTR = Created → Solved. Después TTR = First agent reply → Solved. Si tu cola tarda 90 minutos en primera respuesta en horas pico, acabas de “mejorar” TTR en ~90 minutos sin mejorar nada. Y si lo presentas como experiencia del cliente, estás vendiendo una ilusión con corbata.
Excepción (válida): a veces cambiar definiciones es correcto, por ejemplo para separar “tiempo en espera del cliente” vs “tiempo en manos del agente”. El tradeoff es claro: ganas una métrica más justa para el equipo, pero pierdes comparabilidad histórica. Si lo haces, pon asterisco, fecha de corte y corre 2–4 semanas en paralelo para no romper lectura.
Tres pruebas rápidas cuando el tablero grita “pico” o “caída” de un día para otro: mirar por cohorte (casos creados hoy vs antiguos reactivados), mirar por día-hora (si el salto pega en el borde del corte), y pedir el KPI con el otro inicio/fin solo para ver sensibilidad. Si el pico se desinfla con cohortes y coincide con el corte, era artefacto. Si se mantiene en cohortes nuevas y además suben contactos únicos, es real.
Regla de decisión para no caer en extremos: si el pico afecta seguridad, fraude o clientes VIP, actúa inmediato (refuerzo temporal, freeze de cambios) y valida en paralelo. Si solo amenaza costos o métricas internas, valida 24 horas y aplica guardrails reversibles mientras tanto.
Señal de que reaccionaste a un artefacto: subiste capacidad, pero contactos únicos no suben; el pico se mueve con el corte; y el equipo dice “no se sintió como pico”. En ese caso, deshaz el cambio, documenta la causa (ventana/definición) y deja una nota visible en el dashboard para que el próximo lunes no te vuelva a morder.
Señal 7 y el tradeoff central: cuándo confiar en automatización vs exigir criterio humano (muestreo + handoff)
| Estrategia de asignación | Mejor para | Ventajas | Riesgos | Recomendado cuando |
|---|---|---|---|---|
| Automatización total | Tareas repetitivas, alto volumen, bajo impacto de error | Máxima eficiencia, velocidad, bajo costo operativo | Errores sistémicos no detectados, sesgos amplificados, falta de contexto | Costo de error < beneficio de velocidad. volumen crítico |
| Auto + Muestreo aleatorio (spot-check) | Validación de calidad en procesos estables | Equilibrio costo/beneficio, detección de desviaciones, mejora continua | Muestra no representativa, muestreo insuficiente, falsos negativos | Confianza estadística sin inspección total. procesos maduros |
| Auto + Muestreo por excepción (reglas) | Identificar anomalías, casos fuera de rango | Foco en problemas reales, optimiza recursos humanos | Reglas incompletas, falsos positivos/negativos, sesgo en definición | Criterios claros para 'anormal'. alto volumen de datos |
| Validación humana total | Decisiones críticas, datos sensibles, alta complejidad | Precisión, juicio contextual, adaptabilidad | Lento, costoso, inconsistencia, fatiga | Costo de error catastrófico. volumen manejable |
| Criterios explícitos para decidir entre automatización y validación humana | Definir nivel de confianza requerido por tarea | Claridad, consistencia, reduce ambigüedad | Criterios mal definidos, rigidez excesiva, no considera matices | Establecer/revisar procesos. alta variabilidad de tareas |
| Handoff/Gobernanza (corrección y documentación) | Cualquier error detectado, mejora de procesos | Aprendizaje, evita repetición, trazabilidad | Falta de seguimiento, documentación deficiente, resistencia al cambio | Ciclo de mejora continua. responsabilidad clara |
| Tabla workflow (señal→prueba→dueño→acción→corrección) | Mapear respuesta a señales de evidencia sucia | Claridad operativa, asignación de responsabilidades, acción rápida | Complejidad inicial, falta de actualización, resistencia a seguir | Necesidad de protocolo de respuesta rápida. escalabilidad |
| Cómo documentar una excepción (qué se escribe y para quién) | Casos únicos, desviaciones justificadas | Transparencia, base para auditorías, evita 'soluciones rápidas' | Burocracia excesiva, uso indebido, falta de estandarización | Justificar decisión fuera de proceso estándar. evitar repetición |
La señal 7 incomoda porque no es “dato malo”: es dato demasiado perfecto.
Señal 7: la métrica es ‘demasiado perfecta’ (cero ruido) y nadie puede explicar el porqué
Si tu SLA sube todos los días igual, o la productividad queda plana mientras cambia el mix de canales, desconfía. La operación real tiene ruido: feriados, cambios de turno, incidentes, gente nueva, días raros. Cuando todo se ve liso, suele ser porque alguien filtró, promedió, “suavizó” o cambió la definición.
La prueba humana (rápida y brutal) es pedir un caso que “represente el promedio”. Si el promedio es 6 horas, que alguien describa un caso típico de 6 horas: qué lo demoró, en qué estado estuvo, qué handoff hubo. Si nadie puede, la métrica está desconectada del flujo.
Aquí aparece el tradeoff central del cuadro: automatización total te da velocidad y consistencia, pero también puede darte una mentira consistente. El muestreo aleatorio (spot-check) funciona cuando el proceso es estable y quieres detectar desvíos sin revisar todo. El muestreo por excepción (reglas) sirve para alto volumen: te enfocas en lo raro (reaperturas altas, cierres demasiado rápidos, tickets sin categoría, saltos de severidad). Y hay decisiones donde la única respuesta sana es validación humana total: datos sensibles, impacto alto, costo de error catastrófico.
El punto práctico es que esto no se sostiene sin dos piezas más: criterios explícitos (cuánta confianza necesitas por tarea) y handoff/gobernanza (quién corrige, cómo se documenta, cómo evitamos que vuelva). Sin handoff, detectas evidencia sucia en dashboards… y la vuelves a sufrir el mes siguiente.
Marco de trabajo para decidir sin fe ciega: tres niveles. “Actuar” cuando definición estable y muestreo coincide con la trinchera. “Actuar con guardrails” cuando hay señales pero no concluyentes (cambios parciales, con límite y fecha de revisión). “Pausar y validar” cuando hay señales fuertes: definiciones que cambiaron, duplicados altos, segmentación inestable o perfección sin explicación.
Validar no es auditoría de tres semanas. Un muestreo mínimo viable de 15–30 casos, bien elegidos (del mejor día, del peor, del día promedio), suele mostrarte si hay duplicados, reaperturas raras, cierres automáticos sospechosos o handoffs que parten el caso.
Tip para evitar guerras de anécdotas: cuando presentes el muestreo, no lleves “el caso extremo” que solo sirve para pelear. Lleva tres: uno típico, uno malo, uno bueno. Cambia la discusión de “tu historia vs la mía” a “patrón vs excepción”.
Y cuando encuentres el problema, que no se pierda. Una documentación mínima (una pantalla) suele alcanzar: qué pasó, impacto estimado, ventana afectada, workaround mientras se arregla, dueño del fix, fecha de revisión y cómo se valida (con muestreo). La regla no es “documenta todo”; es “documenta lo que, si se repite, te hace tomar otra mala decisión”.
Cierre: cómo salir de la reunión con una decisión buena aunque la evidencia sea imperfecta
No vas a limpiar toda la evidencia sucia en dashboards antes de la próxima reunión. La meta no es pureza: es decidir bien con riesgo acotado.
Duplicados inflan volumen y maquillan promedios. Reaperturas, merges y handoffs crean “tickets fantasma”. El mix vuelve injustos rankings sin control de dificultad. Cambios de segmentación mueven KPIs sin mover servicio. Picos “perfectos” suelen ser cortes y calendario. Cambios de medición simulan mejoras o crisis. Y una métrica demasiado perfecta, sin historia, suele estar desconectada.
La salida práctica es cerrar la reunión con tres frases que ordenan sin pelear: “Hoy creemos que X no refleja la demanda real”. “No creemos Y hasta controlar por mix/definición”. “En 48 horas validamos con muestreo y revisamos inicio/fin”.
Eso te deja con una decisión hoy (con guardrails si hace falta) y con aprendizaje mañana. Porque el tablero puede verse perfecto. La operación no perdona. Y tu equipo, menos.