Qué estás comparando (y qué no): demanda, conversaciones y rendimiento no son lo mismo
Un ranking en una reunión tiene un superpoder raro: convierte números en “ganadores” y “perdedores” en 30 segundos. El problema es que muchas veces nadie definió qué juego se está jugando. Y ahí nacen casi todos los errores al comparar sucursales, conversaciones y rendimiento: mezclas conceptos distintos y terminas castigando a quien recibió el trabajo difícil (o premiando al que tuvo la semana fácil).
Para operar sin pelearte con el tablero, separa tres capas. No es filosofía, es higiene.
Demanda (inputs). Lo que entra y no controlas del todo: pedidos, devoluciones, reclamos, leads, “no llegó mi envío”. Anclas: número de pedidos, visitas/foot traffic, tickets creados.
Conversaciones (interacciones). El tráfico de comunicación para gestionar esa demanda: chats, llamadas, WhatsApp, transferencias, mensajes internos. Anclas: canal, duración, número de contactos por cliente.
Rendimiento (outputs/outcomes). Lo que logras con esa gestión: resolución al primer contacto (FCR), tiempo de primera respuesta, tiempo de resolución, CSAT, ventas recuperadas, devoluciones evitadas. Anclas: estado del caso (resuelto/reabierto), CSAT, FCR.
El matiz importa porque una sucursal puede “perder” en conversaciones y “ganar” en resultado. Si tu ranking no dice qué mide, el equipo se queda discutiendo el termómetro en vez de bajar la fiebre.
Ejemplo simple, de los que pasan todos los meses: dos sucursales reciben la misma demanda.
Norte: 100 pedidos → 40 conversaciones → 90 entregas a tiempo (90%).
Sur: 100 pedidos → 80 conversaciones → 90 entregas a tiempo (90%).
Si rankeas por conversaciones, Sur “es ineficiente”. Si rankeas por cumplimiento, empatan. Si rankeas por pedidos, mides mercado/flujo, no equipo.
El dato incómodo: Sur podría estar absorbiendo más ansiedad del cliente (“¿me confirmas?”), o un proceso más confuso, o peor tracking. Nada de eso necesariamente es culpa del equipo local.
Advertencia de incentivos (esta es donde te quemas): cuando conviertes una métrica en trofeo, la gente aprende a optimizar el trofeo. Si premias “menos conversaciones”, aparecerán cierres rápidos, derivaciones “mágicas” o clientes empujados a autoservicio aunque no resuelva. El tablero se ve mejor; el cliente, no.
Regla de decisión para que el ranking no sea entretenimiento: si no puedes escribir en una frase “hoy comparo carga / calidad de servicio / resultado de negocio”, no publiques ranking. Quédate en modo diagnóstico y mira motivos, recontacto y resultado por caso.
Tip práctico (cero burocracia, 100% defensa): en cada tablero agrega una línea de contexto con tres cosas: campañas, incidentes y cambios de flujo (bot, ruteo, horarios). Es la diferencia entre comparar una semana normal contra una semana con “lluvia torrencial” y llamarlo performance.
Error #1 y #2: tratar el volumen de conversaciones como intención (y no como fricción o recontacto)
El volumen de conversaciones es una señal fuerte, pero no es una sentencia. Dice “hubo interacción”. No dice “qué tan interesados” ni “qué tan bien estamos”.
Error #1: confundir volumen con intención. A veces el cliente no está más dispuesto a comprar; está más perdido. Un cambio en la página de envíos, una política nueva de cambios, un botón reubicado en checkout y aparecen 30% más “¿cómo hago…?” sin que cambie la demanda real. Si solo miras conversaciones totales, celebras (o castigas) el síntoma.
Si quieres un ejemplo de este autoengaño, está calcado en ventas y conversación: medir “más chats” como si fuera “más intención” suele ser confundir ruido con señal. Este caso lo resume bien desde otro ángulo: [1]
Error #2: usar conversaciones como proxy de productividad. “Atendieron 120 conversaciones, ganaron”. Pero 120 conversaciones pueden ser 120 “hola, ¿hay stock?” de 20 segundos, o 120 casos con transferencias, comprobantes, fraude y logística. Comparar por cantidad atendida es como comparar gimnasios por cuánta gente cruza la puerta: algunos entran a entrenar, otros a preguntar dónde está el baño.
Un ancla que casi siempre ordena la conversación: separa casos únicos de conversaciones. Los casos te hablan de demanda y rendimiento; las conversaciones te hablan de fricción y costo operativo.
Ejemplo (misma demanda, distinto recontacto): dos sucursales tienen 200 pedidos en una semana y el mismo mix de productos.
Sucursal A: 70 conversaciones, 60 casos únicos, FCR 85%. Recontacto a 7 días: 15%.
Sucursal B: 140 conversaciones, 62 casos únicos, FCR 84%. Recontacto a 7 días: 45%.
La demanda es casi la misma, el rendimiento por caso es parecido… pero B tiene el doble de conversaciones por fricción/recontacto. Si premias “más conversaciones atendidas”, acabas pagando un bono por un proceso que está haciendo agua.
Cómo separar intención de ruido sin abrir una auditoría infinita:
Primero, mira si el top de motivos cambió o solo creció el volumen. Si el motivo dominante sigue siendo “estado del pedido” y lo único que subió fue el conteo, sospecha fricción (tracking confuso, información escondida, mensajes automáticos que no aclaran nada).
Segundo, revisa recontacto a 7 días por motivo. Si el recontacto explota en un motivo repetible (estado del pedido, cambio, devolución), no es “más intención”: es “volvieron porque no quedó resuelto”.
Tercero, mira transferencias/derivaciones y a dónde van. Una subida de transferencias suele ser ruteo mal armado, permisos/herramientas faltantes o casos complejos entrando por el canal equivocado. No es un tema de “ganas”; es un tema de flujo.
Monitoreo mínimo que realmente paga dividendos (y evita discusiones eternas):
- Conversaciones por caso único (o por pedido): te mide fricción.
- Recontacto por motivo (7 días como base; 3 días si tu retail es rápido): te mide resolución real.
- Tasa de transferencia (y destino): te mide ruteo/especialización.
Routing: este es el sitio donde una sucursal “pierde” sin culpa. Si una sede recibe más por reglas de derivación (ubicación, horario fuera de atención, idioma, VIP, producto), va a acumular conversaciones difíciles. No lo llames productividad baja; llámalo mezcla de demanda.
Regla de decisión para frenar conclusiones automáticas: si el recontacto por motivo supera 25% en 7 días (para motivos repetibles), no rankees por volumen de conversaciones. Abre diagnóstico: motivo → recontacto → transferencia → resolución.
Tradeoff real (para no castigar lo correcto): no todo recontacto es malo. En garantías, financiación o trámites con terceros, el cliente vuelve porque el proceso es largo, no porque el equipo sea flojo. Regla práctica: si el motivo requiere espera externa (proveedor, banco, logística), sepáralo y no lo midas igual que un motivo “instantáneo”.
Tip práctico: cuando discutas recontacto, acompáñalo con un estado simple: “en espera del cliente/tercero” vs “pendiente interno”. Evita la pelea por “quién tarda” cuando el reloj está en manos de otro.
Modo de fallo típico: presionas por “cerrar más rápido” para bajar conversaciones. La semana siguiente baja el tiempo de atención… pero sube recontacto y aparecen reabiertos. Lo verás en “reabierto” y en comentarios tipo “me cerraron sin resolver”. No ganaste eficiencia; moviste el problema de carpeta.
Error #3 y #4: contar mal conversaciones y casos (duplicados, reabiertos y multicanal) rompe la atribución
Hay rankings que salen mal por una razón poco glamorosa: estás contando cosas distintas como si fueran equivalentes. Ahí el ranking deja de medir operación y empieza a medir “cómo registra cada sucursal” o “qué tan caótica es tu integración”.
Error #3: elegir mal la unidad de análisis.
Usa conversación cuando la pregunta es de capacidad: staffing, turnos, saturación por canal, horarios pico.
Usa caso cuando la pregunta es de atribución y rendimiento: qué fricción existe, quién resolvió, qué motivos duelen, cómo cambia el recontacto. Anclas: ID de caso, motivo/razón, estado (abierto/resuelto/reabierto).
Si tu objetivo es comparar desempeño entre sucursales, casi siempre conviene partir desde casos únicos y usar conversaciones como explicación (“este caso demandó 3 contactos”), no como marcador principal.
Error #4: duplicados que inflan carga y deforman atribución. Tres fuentes típicas:
Reintentos del cliente. No le llegó confirmación, vio “leído” sin respuesta, el bot no resolvió y reenvía. Terminas con 2–4 conversaciones por lo mismo.
Transferencias internas. Derivas a Facturación o Logística y el sistema cuenta cada tramo como conversación nueva (y a veces como caso nuevo si cambia de bandeja).
Multicanal. Abre formulario web, manda WhatsApp “por si acaso” y además llama. Si lo cuentas como tres casos, le inventaste demanda al negocio.
Impacto (antes/después, y cómo te cambia el ranking): Centro muestra 180 conversaciones y Este 140. Suena a que Centro “trabaja más”. Pero al consolidar:
Centro: 180 conversaciones → 120 casos únicos.
Este: 140 conversaciones → 130 casos únicos.
Si bonificabas por “menos conversaciones por agente”, Centro quedaba mal sin serlo. Si asignabas más gente por conversaciones, ibas a sobrestaffear Centro y dejar corto a Este. La decisión sale “lógica” y, aun así, es incorrecta.
Reglas de deduplicación suficientemente buenas (sin convertir esto en ingeniería):
Ventana corta (reintentos obvios). Agrupa como el mismo caso si es el mismo cliente y el mismo motivo dentro de 30–60 minutos. Captura “mandé dos veces” y “no vi respuesta”.
Ventana de recontacto (para medir resolución). Si el cliente vuelve por el mismo motivo dentro de 3–7 días, cuéntalo como recontacto asociado al caso (no como caso nuevo), salvo que haya un evento nuevo claro, como un pedido diferente.
Reabiertos con sentido. Separa reabierto por “falta de resolución” vs “espera externa/confirmación”. Si no separas, la sucursal que documenta bien y deja el caso “en espera” parece peor que la que cierra y reabre a golpes.
Regla de decisión para no pelearte con el tablero: si más del 15–20% de tus casos tienen más de una conversación en menos de 60 minutos, no uses “conversaciones” para comparar desempeño entre sucursales. Primero estabiliza dedupe o, mínimo, muestra “casos únicos” al lado.
Tradeoff (porque deduplicar también miente):
Deduplicar demasiado puede ocultar fricción real (un cliente que tuvo que escribir 5 veces en 2 días es un problema que quieres ver). Deduplicar poco castiga a la sucursal que registra mejor o atiende multicanal.
Regla práctica: si tu objetivo es comparar rendimiento, prioriza no castigar por registro (consolidación a caso); si tu objetivo es reducir carga, mantén conversaciones visibles pero explícitalas como “interacciones por caso”. Dos vistas, una discusión.
Ejemplo operativo: suben “conversaciones” 35% en Sur pero “casos únicos” casi no se mueven. Miras transferencias y descubres que el estado “Derivado a logística” está abriendo una conversación nueva cada vez. Ajustas el flujo o el reporte y el ranking vuelve a reflejar casos reales; de paso, queda claro que el problema de fondo eran retrasos, no “ineficiencia”.
Error caro: cambiar definiciones sobre la marcha “para que cierre”. Hoy reabiertos cuentan como caso nuevo, mañana no; hoy WhatsApp entra como conversación, mañana como ticket. Con eso no comparas sucursales: comparas versiones del reporte.
Si sospechas reintentos por integración (duplicados por reenvío), esta guía ayuda a reconocer el patrón y auditar registros sin perder la paciencia: [2]
Error #5 y #6: comparar sin normalizar por mix de demanda y sin respetar variabilidad (picos y muestras chicas)
Aun si cuentas perfecto, puedes comparar injusto. El ranking queda prolijo, pero mezcla trabajos distintos con clientes distintos.
Error #5: comparar sin normalizar por mix de demanda. No todas las sucursales reciben el mismo tipo de trabajo. Una carga más postventa (cambios, garantías), otra más primeras compras, otra más entregas. Ese mix cambia duración, recontacto y dificultad.
Ejemplo (cómo se invierte el ranking al pasar de volumen a tasa):
Sucursal A: 500 conversaciones y 2.000 pedidos → 25 conversaciones por 100 pedidos.
Sucursal B: 300 conversaciones y 600 pedidos → 50 conversaciones por 100 pedidos.
En volumen, A “pierde”. En tasa por pedido, B tiene el doble de fricción por unidad de operación.
El denominador correcto depende de la pregunta, no del capricho del tablero:
- Por pedidos/transacciones: buen default si el soporte nace de la operación. Te engaña si los pedidos no son comparables (productos simples vs instalación/financiación).
- Por casos únicos: excelente para hablar de fricción y servicio. Te engaña si tu taxonomía de motivos es inestable o el multicanal no está consolidado.
- Por visitas/foot traffic: útil en retail físico para entender “conversaciones por 100 visitas”. Te engaña con eventos locales, zona turística o campañas de calle.
Regla de decisión: si el soporte nace de la operación, usa por pedido; si nace de fricción/servicio, usa por caso único; si nace de comportamiento en tienda, usa por visita. Y cuando hay discusión, muestra dos tasas juntas (por pedido y por caso) en lugar de forzar una sola verdad.
Error #6: ignorar variabilidad (picos y muestras chicas). Una campaña, una caída de sistema o un feriado te distorsiona todo. Y una sucursal con poco volumen puede quedar primera o última por puro azar.
Guardrails simples:
Ventana estable: compara 4 semanas como base. Usa 8 semanas si hay estacionalidad fuerte o volumen bajo. Si cambias la ventana cada reunión, tu ranking es plastilina.
Umbral mínimo: si un motivo tiene menos de 80 casos únicos en 4 semanas (ajústalo), no rankees por ese motivo; monitorea y etiqueta “muestra chica”.
Una técnica operativa que salva discusiones: define baseline y separa días “especiales”. Baseline = semanas sin campaña y sin incidentes. Pico = Hot Sale, caída de sistema, cambio de política. Así logras dos lecturas: comparas baseline contra baseline para gestión, y analizas picos como eventos para aprender.
Esto también tiene trampa: excluir picos mejora justicia, pero puede convertirse en excusa para esconder problemas (“siempre estamos en campaña”). Regla práctica: si el “pico” ocurre más de 2 veces al mes o dura más de 7 días, deja de llamarlo pico: es parte del sistema y debe entrar al baseline.
Tradeoff adicional: segmentar por motivos mejora justicia, pero destruye comparabilidad si las etiquetas no son consistentes. Si cada sucursal usa nombres distintos (“cambio”, “devolución”, “postventa”, “no me gustó”), un ranking por motivo parece preciso y es humo.
Regla de decisión para segmentar: segmenta solo motivos con definición clara y uso consistente (top 5 + auditoría rápida). Si no, usa una categoría paraguas (“postventa”) y apóyate en 3 casos reales para explicar diferencias, en lugar de un ranking fino que no se sostiene.
Ejemplo operativo: el lunes ves que Oeste “empeoró” 20% en conversaciones por 100 pedidos. Miras calendario y hubo promo local; en el tablero sube “horarios de entrega”. Separas esa semana del baseline, haces corte de campaña y ajustas el mensaje de confirmación/ruteo a logística en horas pico. El baseline vuelve a ser comparable y el pico se convierte en aprendizaje, no en regaño.
Para marcos más amplios de comparación multisucursal sin caer en trampas de denominadores: [3] y [4]
Error #7 (y modos de fallo): automatizaciones, objetivos y comparativos que amplifican sesgos entre sucursales
| Estrategia de asignación | Mejor para | Ventajas | Riesgos | Recomendado cuando |
|---|---|---|---|---|
| Manual (Gerente) | Casos VIP, complejos, o sensibles | Control total, personalización, conocimiento cliente | Sesgos, ineficiencia, no escala | Volumen bajo, personalización crítica |
| Round Robin | Distribución equitativa de carga | Simplicidad, equidad percibida | Ignora habilidad, disponibilidad, especialización | Tareas homogéneas, equipos con habilidades similares |
| Por Capacidad/Disponibilidad | Maximizar productividad, reducir espera | Optimiza recursos, agilidad | Burnout, no considera complejidad caso | Volumen variable, necesidad de respuesta rápida |
| Por Especialización/Habilidad | Casos con requisitos técnicos/conocimiento específico | Mejora calidad, resolución rápida | Cuellos de botella, sobrecarga expertos, falta cross-training | Flujos complejos, roles definidos |
| Basada en Reglas (Automatizada) | Alto volumen, tareas repetitivas | Eficiencia, consistencia, reduce error humano | Amplifica sesgos si reglas son defectuosas, gaming del sistema | Estandarización y escalabilidad son clave |
| Híbrida (Manual + Automatizada) | Balance eficiencia y control humano | Flexibilidad, optimización, supervisión excepciones | Complejidad gestión, conflictos prioridad | Necesidad de automatización y personalización |
| Regla de decisión: volver a baseline | Contener efectos negativos de automatizaciones fallidas | Estabiliza operación, previene mayor daño | Pérdida temporal de eficiencia, requiere re-evaluación | Se activa la Regla de decisión: cuándo pausar cambios/automatizaciones y volver a baseline |
| PAUSAR y auditar reglas | Detectar y corregir sesgos o fallos en automatizaciones | Evita amplificación de errores, mejora equidad | Interrupción temporal, resistencia al cambio | Lista de señales de alerta que sugieren gaming o efecto secundario de automatización |
La tabla no es para “elegir la mejor” estrategia; es para recordar que cada forma de asignar trabajo cambia el ranking aunque nadie lo note.
Si asignas Manual (Gerente), ganas control para casos VIP, pero introduces sesgos (“a quién le doy lo fácil”, “a quién le doy al cliente enojado”). Útil con volumen bajo; peligroso cuando ya no puedes mirar todo.
Round Robin se siente justo porque reparte, pero no mira especialización ni disponibilidad real. Funciona cuando las tareas son homogéneas; se rompe cuando hay diferencias fuertes de habilidad o permisos.
El ruteo por Capacidad/Disponibilidad suele bajar espera y subir throughput. También quema gente si no considera complejidad: el sistema siempre encuentra al “disponible” y lo convierte en aspiradora de problemas.
Por Especialización/Habilidad mejora calidad y velocidad de resolución en flujos complejos. El precio es el cuello de botella: si solo dos personas saben resolver X, el ranking termina premiando a quien no recibe X.
La asignación Basada en Reglas (Automatizada) escala y estandariza, pero amplifica sesgos si las reglas están mal (o si el equipo aprende a “jugar” el sistema). La Híbrida suele ser la más realista: automatizas lo repetible y dejas excepciones al criterio humano, sabiendo que eso agrega complejidad de gestión.
Y luego están las dos filas más importantes cuando todo se ve “demasiado bien”: volver a baseline y PAUSAR y auditar reglas. Son el freno de mano. No se usan por deporte; se usan cuando el tablero empieza a mentir.
Modos de fallo frecuentes (se sienten sutiles, pero pegan fuerte):
Drift por canal: bajan llamadas y suben chats por un botón nuevo, un horario, o una automatización que empuja canal. El ranking “mejora” sin que el servicio mejore.
Cambio de mix: una sucursal “mejora” porque dejó de recibir casos difíciles (por especialización, por capacidad, por reglas). Si no controlas mix, premias suerte.
Mejoras demasiado perfectas: huelen a conteo/integración o a incentivo mal puesto. La operación real rara vez mejora 20% de la noche a la mañana sin costo en otra parte.
Dos banderas rojas fáciles de detectar:
- Conversaciones caen 30% semana a semana sin cambio en pedidos/visitas.
- CSAT sube mientras recontacto sube (sesgo de encuesta, cierre prematuro, o encuestas solo en casos fáciles).
Regla de contención (vale oro): si tras un cambio grande de automatización/ruteo una métrica mejora >15% sin movimiento equivalente en su “pareja natural” (bajan conversaciones sin bajar demanda, o sube CSAT con suba de recontacto), pausa, audita y vuelve a baseline.
Pausar cuesta; seguir con ilusión cuesta más.
Tip práctico: antes de desplegar cambios de asignación, define 2–3 “parejas naturales” que siempre vas a mirar juntas: conversaciones ↔ casos únicos; CSAT ↔ recontacto; primera respuesta ↔ reabierto. Es un cinturón de seguridad para el comparativo.
Para sostener la parte de sesgos y autoengaño por métricas (sin caer en dogmas): [5] y [6]
Checklist de 15 minutos antes de la reunión: cómo evitar ‘premiar’ a la sucursal equivocada
No busca perfección. Busca consistencia. Y te evita el clásico “premiar por volumen” (ese primo que aparece en todas las familias aunque nadie lo invitó).
Piensa esto como un cierre de seguridad antes de tomar decisiones con impacto: bonos, staffing, presión al equipo, cambios de proceso.
En 15 minutos, lo mínimo que te salva:
Define qué rankeas hoy: carga, calidad o resultado. Define unidad: conversación para carga, caso para rendimiento. Haz un dedupe rápido de reintentos con ventana corta. Separa reabiertos por espera externa vs mala resolución. Mira recontacto por motivo (no solo total). Normaliza por el denominador relevante (pedidos, casos únicos o visitas). Marca campañas/incidentes y separa baseline de picos. Aplica mínimos: ventana default de 4 semanas y umbral de casos para rankear.
Regla de stop (la que te ahorra vergüenzas): si no puedes explicar en una frase tu unidad y tu denominador, no rankees hoy. Monitorea y define acciones pequeñas; no toques bonos, staffing o comparativos “duros”.
Decisión segura: entrenar un motivo con recontacto alto y estable en 4 semanas. Decisión a posponer: recortar personal o cambiar incentivos justo después de una automatización con “mejora perfecta”.
Plan de lunes, realista: rehace una comparación por caso único y normaliza por pedidos. Luego fija ventana de recontacto, mínimo de muestra y regla de baseline. No prometas “arreglar la medición” en una semana; promete dejar de decidir grande con señal sucia desde mañana.
Fuentes
- calypso.ms — calypso.ms
- appmaster.io — appmaster.io
- spark.mishipay.com — spark.mishipay.com
- getin.mx — getin.mx
- cio.com — cio.com
- echometerapp.com — echometerapp.com