En algún momento pasa: llega el reporte del lunes y parece que el contact center se desordenó solo. Subieron los contactos, subió el AHT, el SLA se cayó, los abandonos explotaron y alguien suelta la frase peligrosa: “el equipo está flojo” o “la campaña nos reventó”. En Perú esto se siente seguido por la mezcla de quincenas, feriados, banca/retail/courier, y porque los cambios operativos a veces se hacen “rapidito”… y luego nadie los amarra al pico.
Lo incómodo es que, con picos semanales, el instinto suele fallar. Cuando el sistema se satura, hasta un equipo sólido se ve “malo” en los números. Y cuando el enrutamiento se rompe, la campaña parece culpable aunque el problema sea que el cliente terminó en la cola equivocada.
La idea acá es simple: antes de opinar, asegúrate de que todos estén mirando el mismo fenómeno (mismo intervalo, misma cola, mismo canal, mismas definiciones) y no un collage de métricas.
Un ancla concreta: imagina que todos hablan del “pico del jueves”, pero tú miras el día completo. Si el pico real fue de 10:00 a 12:00 en la cola de Ventas voz y tú lo comparas contra el promedio del jueves entero, vas a terminar corrigiendo lo que no está roto. Es como echarle la culpa al tráfico de Lima por un choque puntual en Javier Prado: el mapa importa, pero la hora también.
Qué hacer cuando “subió todo”: define el pico y el baseline comparable antes de opinar
El error #1: comparar con el promedio semanal sin controlar día/hora
Cuando alguien dice “subió todo”, normalmente está comparando contra un promedio semanal o mensual. Es cómodo… y traicionero. En contact center los picos semanales no se entienden en promedios; se entienden en intervalos.
Regla corta para cortar el drama: si no puedes ponerle hora, cola y canal al pico, todavía no tienes un pico. Tienes una sensación. Y las sensaciones sirven más para culpar que para decidir.
Detalle operativo que sí mueve la aguja: pide el intervalo exacto (15 o 30 minutos) donde “se rompió”. No el día. El intervalo.
Define el pico: volumen, espera, AHT, ventas o conversión (no todo es lo mismo)
Un “pico” puede ser tres cosas distintas que se ven parecidas en el dashboard:
- Demanda: suben los contactos ofrecidos (offered) en un intervalo comparable.
- Tiempo: el offered no sube, pero suben espera/ASA y cola (capacidad, adherence, fricción, routing).
- Resultado: el volumen cambia poco, pero cae conversión/FCR o sube recontacto; el AHT se infla como consecuencia.
Si mezclas estas lecturas, terminas pidiendo “bajen AHT” cuando el problema era complejidad real o clientes rebotando. Y un pico con “acciones correctivas” mal enfocadas casi siempre te regresa la semana siguiente.
Una definición práctica (no sagrada) ayuda: “pico semanal” = offered +15% vs control en la franja crítica, o ASA que se duplica en el mismo intervalo. El objetivo no es el número perfecto; es que el comité deje de discutir semántica.
Si necesitas alinear lenguaje de métricas para que nadie juegue con su propia calculadora, este marco ayuda: KPIs esenciales para medir en un contact center.
Ventanas comparables: mismo día de semana, misma franja, misma cola y mismas reglas
Tu baseline mínimo para evitar injusticias:
- mismo día de semana,
- misma franja,
- misma cola,
- mismo canal,
- mismas reglas de medición.
Comparar jueves 10:00–12:00 (semana actual) vs jueves 10:00–12:00 (semana anterior). Si puedes, añade dos semanas más para distinguir anomalía vs patrón.
Advertencia real (esto es donde te quemas): cambiar definiciones sin avisar. “Ahora AHT incluye ACW”, “fusionamos colas”, “cambiamos qué cuenta como contacto”… y el jueves “explotó”. Antes del análisis, acuerda definiciones básicas: qué cuenta como contacto, qué cuenta como abandono y cómo se calcula AHT.
Una ‘foto’ mínima para alinear a operaciones, WFM, QA y campañas
Una foto que funciona en la vida real (sin volverlo tesis): offered, handled, abandoned y ASA o SLA, por intervalos, separado por cola y canal.
Con eso se habilitan decisiones rápidas:
- offered subió → investigas demanda/mix.
- offered no subió, pero ASA/SLA sí se rompen → investigas capacidad, adherence, shrinkage, enrutamiento.
- números cambian “mágicamente” → primero medición.
Y sí: un calendario de eventos (campañas, cambios IVR, despliegues, feriados, cortes de back office) parece burocracia… hasta que te evita una semana de acusaciones cruzadas.
Triage de la semana: 6 comparaciones que separan demanda real de ruido de medición
| Estrategia de asignación | Mejor para | Ventajas | Riesgos | Recomendado cuando |
|---|---|---|---|---|
| Reglas de comparación: 'mismo día / hora / cola / canal' — semana actual vs. anterior | Detectar anomalías puntuales y específicas | Aísla impacto de variables externas o cambios recientes | Ignora tendencias estacionales o eventos únicos | Se busca una anomalía, no una tendencia general |
| Comparar Offered, Handled, Abandoned | Diagnóstico inicial: demanda vs. atención vs. pérdida | Identifica si el problema es volumen, capacidad o enrutamiento | No distingue causas de abandono (ej. short abandons) | Siempre, primer paso del triage semanal |
| Separar 'short abandons' del abandono total | Distinguir problemas de enrutamiento/IVR de problemas de espera | Enfoca acciones correctivas en el punto correcto del flujo | Requiere definición clara y consistente de 'short abandon' | Alto volumen de abandono, sospecha de IVR o cola |
| Comparar Offered vs. Capacidad (staffing, adherencia, shrinkage) | Identificar si el problema es de demanda o de recursos | Diferencia pico de demanda de caída de capacidad | Requiere datos precisos de staffing y adherencia en tiempo real | Sospecha de problema interno (ej. ausentismo, mala planificación) |
| Revisar cambios recientes en enrutamiento (IVR, colas, transfers) | Detectar fallos o efectos no deseados de configuraciones | Identifica rápidamente si un cambio reciente es el culpable | Complejo si hay muchos cambios o sistemas interconectados | Ha habido despliegues o modificaciones en el flujo de llamadas |
| Tradeoff: Velocidad del triage vs. Precisión | Equilibrar rapidez y profundidad del análisis | Permite un primer descarte rápido para enfocar investigación | Asumir demasiado puede llevar a conclusiones erróneas si no se valida | Se necesita una decisión rápida sobre la dirección de la investigación |
| Chequeo de cambios de medición/definición | Descartar ruido de medición antes de culpar a la operación | Evita análisis erróneos y decisiones basadas en datos falsos | Retrasa identificación de problemas reales si se abusa | Picos o caídas inexplicables en reportes |
Esta tabla es tu mapa de 20 minutos de triage: primero defines comparables (mismo día/hora/cola/canal), luego ubicas en qué parte del embudo se rompe (offered/handled/abandoned), separas “short abandons” para no culpar a la cola cuando el problema está en IVR, cruzas capacidad real, revisas enrutamiento y, antes de acusar a nadie, confirmas que no sea un cambio de medición.
El tradeoff es explícito: el triage gana velocidad con hipótesis razonables, pero deja claro qué vas a validar después. Si esperas precisión perfecta desde el minuto uno, llegas tarde a la decisión… y el pico ya se comió la reputación.
1) Mismo día/hora vs semana previa (no mes completo)
Compara el intervalo crítico contra el mismo intervalo de la semana previa (y, si puedes, 2–3 semanas). Un mes completo diluye la señal.
Ejemplo: “el martes fue horrible”. Si el martes 11:00–13:00 el offered sube 25% y el resto del día está normal, es un problema de franja. La respuesta rara vez es “contrata más”; suele ser “ajusta cobertura o evita disparar demanda en esa ventana”.
Para conectar esto con cobertura por turnos y SLA (sin inventar turnos a ojo), este enfoque ayuda: turnos 24/7, SLA, colas y cobertura.
2) Misma cola vs colas vecinas (efecto desplazamiento)
Si la cola A explota, mira la cola B que recibe transfers o rebotes. A veces el volumen total no sube tanto: se mueve.
Señal típica: celebran que “bajó Soporte”, pero subió “Otros” (o una cola comodín) y ahí se está enterrando el SLA. No desapareció; cambió de caja.
3) Mismo canal (llamada vs chat): el mix cambia el AHT
Separar canales no es detalle: es diagnóstico.
En voz, el AHT reacciona rápido a complejidad/fricción (hold, transfers, validaciones). En chat, el tiempo puede inflarse por asincronía y backlog, aunque el agente esté trabajando bien.
Si tu operación empuja chat para proteger voz, puedes terminar con “AHT peor” en ambos lados: voz por saturación, chat por acumulación.
Si estás revisando cómo tus herramientas afectan el flujo, suma ideas prácticas aquí: consejos y herramientas para mejorar la atención telefónica en Perú.
4) Ofrecido vs atendido vs abandonos (dónde ‘explota’ el embudo)
Este es el mapa rápido de “dónde se rompe”:
- Offered: lo que llega.
- Handled: lo que atiendes.
- Abandoned: lo que se cae.
Separarlos evita el diagnóstico flojo de “subió todo”. Y separar short abandons evita culpar a la espera cuando el problema está antes (opción IVR confusa, mensaje largo, error de enrutamiento).
Lecturas rápidas que suelen ser correctas:
- Offered sube y handled no acompaña → cuello en capacidad.
- Offered se mantiene y abandonos suben → ASA subió por adherence, shrinkage o routing.
5) Ingresos nuevos vs recontactos (pico por FCR)
Parte del pico puede ser demanda nueva; otra parte puede ser rebote de mala resolución. Si no separas recontacto, le atribuyes todo a la campaña cuando el pico es el eco de días anteriores.
Sin pedir perfección: arma un proxy por ventana (recontacto 24h/72h/7d) por motivo y canal. Si el jueves explota, revisa qué pasó el miércoles con el mismo motivo.
Para leer señales sin autoengañarte, esta línea de analítica aplicada encaja bien: medir y mejorar con call center analytics.
6) Medición: feriados, cambios de logging, duplicados
Antes de inventar una historia, descarta ruido.
En Perú, feriados y días puente cambian patrones de contacto, pero también turnos, cortes y disponibilidad del back office. Y un “ajuste” de dashboard o etiquetas puede fabricar picos falsos.
Valida lo básico: cambios de definición de contacto, ajustes de ACW, colas fusionadas, canal nuevo, duplicados por integraciones. Si el pico aparece el mismo día que alguien “mejoró el reporte”, sospecha.
Si tu equipo quiere ordenar esto con métricas de planificación (para que no dependa de intuición), aquí hay buen criterio: métricas clave para optimizar la planificación de turnos.
Si el volumen sí subió: desarma el pico por mix (motivos, canal, severidad y recontacto) antes de hablar de campañas
Aceptar que el volumen subió es el inicio. Lo que define si culpas a “la campaña” o ajustas operación es el mix.
He visto equipos pelear por AHT “alto” cuando lo que creció fue un motivo que naturalmente toma el doble. Pedir velocidad ahí es como pedirle a un bombero que apague el incendio “con más ganas”. Lo que necesitas es priorizar, preparar y enrutar mejor.
Motivos de contacto: 80/20 y ‘nuevos motivos’
Empieza simple: top motivos del día pico vs el día control, con participación y delta absoluto. No busques cien motivos; busca drivers. La mayoría de picos semanales se explican con 3–5.
Señal fuerte: “motivo nuevo” o crecimiento desproporcionado. Ejemplo: suben consultas por “estado de envío” por un incidente de courier. Ese motivo trae ansiedad, repreguntas y más hold; el AHT sube aunque el agente haga todo bien.
Cómo decirlo para que el comité actúe: “el motivo X aportó 40% del incremento total en 10:00–12:00”. Cambia la conversación de culpa a causa.
Canal y asincronía: por qué un shift a chat infla duración o backlog
El chat engaña si lo miras como voz.
Puedes gestionar más conversaciones, pero si el cliente responde tarde o se acumula backlog, el tiempo de ciclo crece. En el dashboard se ve como AHT peor, aunque el esfuerzo real esté bien distribuido.
Dos cuidados mínimos:
- no compares AHT de voz contra chat como si fueran equivalentes,
- mira backlog y tiempos de respuesta del chat, no solo duración promedio.
Si estás evaluando stack/costos para escalar canales, este contexto es útil sin prometer milagros: precios de software de contact center y factores reales.
Severidad/prioridad: cuando el pico es de casos complejos
No todo pico es “más gente llamando”. A veces el volumen sube poco, pero la complejidad sube mucho.
Sin ponerte técnico, mira proxies: más transfers, más hold, más consultas a supervisor, más ACW, más escalaciones.
Regla práctica: si suben escalaciones y transfers y cae la resolución en primer contacto, estás frente a complejidad o mala ruta; no a “gente lenta”.
Recontacto por cohortes: quién vuelve y en cuánto tiempo (24h/72h/7d)
Cuando hay recontacto, el volumen se vuelve bola de nieve. Atiendes el lunes, vuelven el martes, vuelven el miércoles más molestos… y el jueves explota. Ese patrón semanal es más común de lo que nos gusta aceptar.
Pensar en cohortes ayuda: clientes que contactaron por motivo X el lunes, cuántos vuelven en 24h, 72h y 7d. Si el pico se concentra en 72h, suele haber una promesa incumplida o un back office lento.
Y aquí el registro importa. Si tu CRM es pobre, el recontacto se vuelve invisible y terminas culpando a campaña. Vale tener claro este punto: CRM para call center y registro de contactos.
Regla práctica: qué mix change justifica culpar a demanda vs operación
Decision rule que funciona bien en comités: si el offered sube, pero 60% del incremento se explica por dos motivos nuevos o por un shift fuerte de canal, no es “demanda genérica”. Es un driver.
Ahí el plan no es “aprieten AHT”. Es atacar el driver: mensajes y expectativas, autoservicio bien puesto, priorización, coordinación con el área dueña del motivo, o enrutamiento para que caiga al skill correcto.
Si tus picos vienen por campañas y necesitas absorber sin romper reputación, esto complementa bien: absorber demanda en campañas sin perder reputación.
Reglas para no confundir capacidad con desempeño: cuando el pico es de staffing, shrinkage o adherence
Culpar desempeño cuando el problema es capacidad es el error más caro: es injusto y te empuja a decisiones que empeoran todo (más prisa → más errores → más recontacto → más volumen).
Acá manda una lectura combinada, no una métrica aislada.
Occupancy y colas: cómo luce una restricción de capacidad vs productividad
Patrón de restricción de capacidad: occupancy alta y sostenida, ASA alto, SLA bajo, cola creciendo. En ese escenario, aunque el AHT suba, suele ser síntoma.
Patrón más compatible con productividad/calidad: occupancy no está al límite, pero el AHT se dispara en una cola o segmento específico sin que offered cambie. Ahí sí tiene sentido mirar guías, conocimiento, QA y fricciones.
Para aterrizar ocupación con criterio (y no con folklore), este recurso es claro: mejorar la ocupación en un call center.
Shrinkage: dónde se pierde la semana sin que ‘nadie lo vea’
Shrinkage es tiempo no disponible para atender: breaks, capacitaciones, reuniones, coaching. En papel se controla. En la vida real, se te va la semana si cae en la franja crítica.
El shrinkage no planificado (ausentismo, caídas de sistema, fricción de herramientas) es el asesino silencioso: casi no se nota en promedio diario, pero en intervalos te revienta.
Traducción útil: no lo muestres como porcentaje semanal; muéstralo en 10:00–12:00 del día pico vs control. Ahí se acaban las discusiones abstractas.
Ausentismo y tardanzas: impacto real en intervalos críticos
Un 3% de ausentismo no suena terrible… hasta que cae en tu hora pico, en una cola con skills escasos.
Ejemplo simple: si en la franja crítica planificaste 50 agentes y se caen 5 por ausentismo y 3 por tardanza efectiva, perdiste 16% de capacidad justo cuando más duele. Si ya ibas al límite, eso te cambia el día.
Adherence vs schedule fit: el pico aparece donde forecast y horario no calzan
Adherence es cumplir horario. Schedule fit es que el horario calce con la demanda real.
Puedes tener adherence decente y aun así un pico semanal, porque el forecast o el diseño de turnos no calza con la forma del día. Esto pasa cuando “cubre bonito” el promedio, pero no cubre la punta.
Si el pico aparece siempre el mismo día y franja, sospecha de schedule fit antes de sospechar de “mal equipo”.
Para entender la lógica de capacidad/dimensionamiento (sin convertirlo en religión), aquí hay buen marco: dimensionamiento de call center.
Qué decisión tomar según el patrón (apoyos, rebalanceo, overtime, congelar cambios)
La decisión depende del patrón, no del susto:
- Meseta (se mantiene): refuerzo temporal en la franja, mover shrinkage fuera del pico, priorizar motivos para proteger el SLA donde más duele.
- Pulso (dos horas raras): validar drivers (incidente/campaña/cambio), revisar línea de tiempo, evitar “soluciones permanentes” a un problema breve.
Overtime compra aire rápido, pero si lo usas como muleta semanal, compras burnout para el próximo mes. Y meter gente ayuda si la demanda es real; si el problema era routing, solo estás echando agua a un balde roto.
Dos cosas que se rompen sin avisar: enrutamiento (IVR/colas/transfers) y cambios operativos que fabrican picos
El routing y los cambios pequeños son grandes fabricantes de picos semanales. Y lo peor: suelen romperse sin alarma.
Es raro que un equipo entero “se vuelva malo” el jueves a las 11:00 en punto. En cambio, es común que una regla quede mal publicada o que el IVR redirija distinto.
Señales de routing roto: suben transfers, suben recontactos, cae FCR, crece la cola ‘equivocada’
Las transferencias son huella digital.
Si sube el transfer rate y la cola destino se congestiona mientras la cola origen “se ve mejor”, tienes desplazamiento fabricado.
Otra señal: crece la cola equivocada. Clientes de Postventa entrando por Ventas porque el IVR quedó confuso o el mensaje empuja a la opción incorrecta. Resultado: doble castigo. Ventas pierde conversión y Postventa recibe recontacto de clientes frustrados.
Cambios pequeños, impacto grande: IVR, reglas de prioridad, horarios, mensajes
Los cambios que más rompen suelen ser aburridos:
- un ajuste de prioridad,
- un horario recortado sin avisar a web,
- un mensaje de campaña “llama ahora” sin coordinar franja,
- una validación extra que mete fricción.
Tip que salva reputación: pide siempre una línea de tiempo de cambios cruzada con el inicio del pico por intervalos. No “cosas que pasaron”; hora aproximada.
Efecto ‘desplazamiento’: el pico no desaparece, se mueve de cola/canal
Cuando se cambia routing, a veces el total de contactos queda similar. Entonces alguien dice “no hay pico”.
No: el pico se movió.
Si solo miras totales, celebras temprano y luego te preguntas por qué cayó NPS o subió abandono en otra cola. Lo mismo con chat: derivan tráfico para “proteger” voz, pero sin aumentar capacidad real; crece backlog, el cliente recontacta por voz, y terminas con el clásico doble canal con peor experiencia.
Modo de fallo de reporting: contactos duplicados, merge de colas, cambios de etiquetas
No todo es routing real. A veces el reporting fabrica el pico: duplicados por integración, colas fusionadas que rompen la serie histórica, etiquetas que “crean” un motivo nuevo.
Si tu operación cambió paneles o vistas, vale revisar impacto en lectura y decisiones (no por estética, por trazabilidad): Panel de Control Anura 6.0.
Qué validar antes de acusar “mala campaña”: línea de tiempo de cambios + métricas de fuga
Antes de decir “la campaña nos malogró la semana”, valida dos cosas:
- línea de tiempo: ¿el pico empieza después del mensaje o ya venía creciendo?
- métricas de fuga: transfer rate, short abandons, recontacto por ventana, y dónde crece la cola.
Regla simple que evita discusiones largas: si suben transfers y cae FCR, prioriza hipótesis de routing/definición antes que desempeño.
Tradeoff real: arreglar routing puede mejorar SLA pero bajar ventas (si mueves prioridades), o al revés. Por eso el objetivo debe estar claro. “Mejorar todo” es el camino directo a no mejorar nada.
Antes de la reunión: checklist de 10 preguntas que evitan culpar al equipo o a la campaña (y qué decisión habilita cada una)
La reunión de post mortem de picos semanales suele tener dos finales.
El final malo: sales con “aprieten AHT” y “pausen campaña” sin evidencia, y la próxima semana el pico regresa con amigos.
El final útil: sales con una decisión clara (aunque sea provisional) y con un plan de validación.
10 preguntas (con evidencia mínima) para cerrar hipótesis rápido
¿Cuál es el pico exacto (hora/cola/canal) y cuánto cambia? Export de 2–3 semanas comparables.
¿Subió offered o solo subieron tiempos? Offered/handled/abandoned + ASA o SLA por intervalos.
¿Dónde nació y a dónde se movió? Cola principal vs colas vecinas + transfers.
¿Cambió el mix de canal? % voz vs chat en la franja crítica.
¿Qué 3–5 motivos explican el delta? Participación + delta absoluto vs control.
¿Subió recontacto (24h/72h/7d) en esos motivos? Proxy por ventana.
¿El staffing real calzó con el plan en el intervalo crítico? Plan vs real por intervalos.
¿Cuánto shrinkage cayó en la franja crítica (planificado y no planificado)? Desglose por turno.
¿Qué cambió en IVR/colas/prioridades/scripts/horarios/políticas? Línea de tiempo.
¿Qué señal secundaria confirma tu hipótesis? Transfers, short abandons, FCR, backlog de chat (lo que aplique).
Un ajuste que hace que esto funcione de verdad: nombra un dueño de evidencia por bloque (Operaciones, WFM, QA, Tecnología). No para repartir culpas; para que la reunión no sea “yo creo que”.
Cómo presentar el hallazgo: ‘qué cambió’ → ‘qué evidencia’ → ‘qué decisión’
Tres líneas, sin novela:
- Qué cambió: “jueves 10:00–12:00 subió offered 18% en Postventa voz y ASA se duplicó”.
- Evidencia: “55% del incremento viene de 2 motivos de entregas; subieron transfers a Back office; cayó staffing real por ausentismo en esa franja”.
- Decisión: “reforzamos cobertura 48h y corregimos el IVR; validamos recontacto 72h para confirmar si hubo falla de resolución”.
Plantilla de salida: 3 acciones para 48h y 3 acciones para la próxima semana
En 48 horas, lo realista suele ser: alinear baseline/foto por intervalos, mover shrinkage fuera del pico, y congelar cambios mientras revisas routing si subieron transfers y short abandons.
Para la próxima semana: atacar el driver principal por motivo (con el área dueña), ajustar schedule fit donde el pico se repite, y mejorar definiciones/medición para que el próximo pico no te agarre discutiendo “qué cuenta”.
Cierro con un plan de lunes que sí se puede ejecutar sin prometer magia:
Primero, define el pico con hora, cola y canal, y arma el control con 2–3 semanas comparables.
Tres prioridades:
- separar demanda real de ruido de medición con el triage,
- atribuir el delta a drivers de mix y recontacto antes de tocar campañas,
- validar capacidad por intervalos con staffing real, shrinkage y adherence.
Barra realista de producción: si en una semana logras que la discusión pase de “quién tuvo la culpa” a “qué cambió y qué decisión tomamos”, ya ganaste más de la mitad del partido.