Control de calidad en call centers: cómo funcionan las scorecards

Qué significa realmente el control de calidad en un call center

Todo equipo de soporte acaba haciéndose alguna versión de la pregunta "¿realmente lo estamos haciendo bien, o solo lo parece?". El control de calidad es la respuesta a esa pregunta convertida en proceso. Es la revisión sistemática de las interacciones de soporte -llamadas, chats, correos, tickets- frente a un estándar definido, de modo que "buen servicio" deja de ser una sensación y pasa a ser una puntuación que un manager puede señalar.

El mecanismo que subyace a casi todo programa de QA es la scorecard: un formulario de evaluación estructurado con categorías de puntuación ponderadas que un revisor -humano o, cada vez más, IA- completa tras leer o escuchar una conversación. Como dice Zendesk, las scorecards existen para "evaluar el desempeño del agente, identificar áreas de mejora y asegurar que tu equipo cumple los objetivos de la organización". El QA se sitúa junto a la planificación y previsión de plantillas bajo el término paraguas Workforce Engagement Management (WEM); la mayoría de los proveedores, incluido Zendesk, lo venden como uno de dos o tres módulos de esa suite.

Importa por razones que se acumulan a medida que crece un equipo. Un equipo de tres agentes puede recibir QA de un manager que simplemente... lee todo. Un equipo de treinta, no. Las scorecards junto con el muestreo son lo que permite que una función de QA produzca puntuaciones comparables entre cientos de agentes sin que un manager tenga que leer personalmente cada ticket. También son la materia prima del coaching: señalar que un agente concreto se salta siempre la frase de cierre, en lugar de una nota vaga de "sé más minucioso" en un 1:1. Y en industrias reguladas (servicios financieros, salud, cobro de deudas), las scorecards de QA suelen tener peso legal: una divulgación omitida no es una nota de estilo, es un fallo de cumplimiento.

El caso de negocio tampoco es abstracto. En la propia página del producto de QA de Zendesk, la cadena de radio Audacy reporta un aumento del 19% en la productividad de los agentes y un 15% en resoluciones en un solo contacto tras adoptar un QA estructurado; Kahoot! vio subir el CSAT 5 puntos porcentuales junto con un salto del 150% en cuántos tickets se revisaban realmente; Liberty reportó +2.3% en CSAT y +4% en su Internal Quality Score. Ninguno de esos números es QA por el QA en sí: son lo que ocurre cuando un equipo por fin puede ver sus propios puntos ciegos.

Cómo funciona realmente una scorecard de QA

Si se quitan los dashboards del proveedor, una scorecard es simplemente un promedio ponderado. Cada categoría -precisión, tono, empatía, gramática, resolución, cumplimiento- recibe una escala de puntuación y un peso de 0 a 100. La documentación de Zendesk es directa sobre las matemáticas: "Para calcular la puntuación de revisión de una interacción, multiplicas la puntuación de cada categoría por su peso y luego divides el total entre la suma de los pesos." Un equipo al que le importa más entender la causa raíz que el estilo de la documentación simplemente pondera más alto la causa raíz; la fórmula hace el resto.

La escala que elijas intercambia velocidad por matiz. Zendesk QA ofrece cuatro:

Dos mecanismos hacen la mayor parte del trabajo pesado en un programa de QA maduro. El primero es la categoría crítica: marca "informó la tarifa de cancelación" como crítica, y una puntuación fallida ahí lleva toda la revisión a 0%, sin importar lo cálida y bien escrita que fuera el resto de la respuesta. Esa es la palanca que usan los equipos regulados para asegurarse de que un fallo de cumplimiento no pueda quedar diluido por un buen tono. El segundo es el etiquetado de causa raíz: en lugar de simplemente puntuar "empatía: mal", el revisor elige un motivo predefinido de una lista, que es lo que realmente hace que los datos de QA sirvan para el coaching en vez de ser solo un número que el agente resiente.

El propio sistema AutoQA de Zendesk QA viene con ocho categorías predeterminadas que se puntúan automáticamente en el momento en que se cierra un ticket:

(Centro de ayuda de Zendesk)

Aquí está la matemática en miniatura: supongamos que Precisión pesa 40, Tono pesa 20 y Cumplimiento pesa 40. Un agente puntúa 90% en precisión, 100% en tono y 80% en cumplimiento. Ponderado, eso es (90×40 + 100×20 + 80×40) ÷ 100 = 88%. Cambia los pesos y el mismo desempeño subyacente produce un número final distinto, que es exactamente por qué la calibración (más abajo) importa tanto.

Muestreo: la matemática que dejó de funcionar sin hacer ruido

Durante la mayor parte de la historia del QA, un revisor humano no podía escuchar o leer cada interacción, así que los equipos construyeron toda la disciplina en torno al muestreo aleatorio: extraer un puñado de tickets por agente a la semana, puntuarlos, extrapolar.

El problema es que las matemáticas se ven bien a nivel de equipo y se desmoronan a nivel de agente. Leo Gasperin lo expuso con claridad en una publicación de LinkedIn describiendo a su antiguo equipo: dedicaban 200 horas al mes a revisar tickets contra criterios estrictos y aun así solo cubrían cerca del 5% del volumen total. Revisar 5-10 tickets a la semana de los aproximadamente 500 tickets mensuales de un agente no produce una lectura estadísticamente fiable sobre ese agente, aunque la tasa de muestreo general se vea aceptable en un dashboard de QA. Su solución, textualmente: "Auditar el 100% con agentes de IA configurados como evaluadores, y luego revisar solo los problemas." Una persona que comentó en la misma publicación, Shubhashree S., resumió el fallo en una frase: "el muestreo genera confianza, pero no claridad."

No es una queja marginal. En G2, una revisora de MaestroQA que trabaja como Executive Director describió el estado anterior directamente: "hacíamos QA sobre un muestreo aleatorio de tickets" antes de cambiar a una herramienta que le permitió a su equipo "hacer QA dirigidos" en su lugar. Es la misma historia desde otro ángulo en evaluagent, donde un Senior Advisor en soporte de aviación nombró exactamente el problema que el AutoQA con IA busca resolver: "resuelve el problema de la visibilidad limitada del muestreo de QA, y reduce el tiempo y el esfuerzo dedicados a las revisiones manuales."

Calibración: conseguir que los revisores realmente coincidan

Las scorecards solo funcionan si dos revisores que puntúan el mismo ticket llegan al mismo sitio. Ese ejercicio de alineación se llama calibración, y la propia definición de Zendesk es exactamente lo que suena: "la práctica de hacer que todos tus revisores puntúen el mismo lote de conversaciones y comparen sus puntuaciones y comentarios... asegura que tus revisores estén alineados en sus evaluaciones, ofreciendo feedback consistente a los agentes sin importar quién realice la revisión."

Mecánicamente, suele funcionar como "revisar primero, discutir después": los revisores puntúan de forma independiente, un manager marca una revisión como línea base, y el grupo se reúne para resolver las diferencias, a menudo con un líder de QA tomando la decisión final en cualquier disputa. Lo que realmente necesita alinearse rara vez son las cosas grandes; son los casos límite. ¿Cómo puntúas una categoría que nunca surgió en esta conversación en concreto? ¿Cuánto debería durar el feedback escrito? Las puntuaciones de calibración se mantienen deliberadamente fuera del Internal Quality Score en vivo del agente y viven en su propio dashboard, precisamente para que el ejercicio siga centrado en entrenar revisores en lugar de convertirse en un segundo canal de puntuación oculto. La mayoría de los equipos hace esto mensualmente.

El giro hacia una IA que revisa el 100% de las conversaciones

Todos los proveedores importantes de QA que he revisado están convergiendo en el mismo mensaje, y merece la pena nombrarlo con claridad: la IA revisando cada interacción, reemplazando por completo el muestreo manual, mientras mantiene la estructura de scorecard y calibración como columna vertebral debajo.

Zendesk QA (antes Klaus) lidera con AutoQA: puntúa el 100% de las conversaciones en voz, chat, correo y transcripciones de agentes de IA, y los administradores pueden escribir categorías personalizadas basadas en prompts en lenguaje simple, sin código. Su función Spotlight marca automáticamente el riesgo de abandono y las lagunas de conocimiento sin que un humano tenga que leer cada hilo marcado, y Real-time QA saca a la luz problemas mientras una conversación todavía está en curso, en lugar de después.

Lo que encuentro más revelador es AI Agent QA: los mismos estándares de puntuación usados en agentes humanos, aplicados a bots. Zendesk compara explícitamente las puntuaciones de agentes humanos y de IA lado a lado para ver dónde el bot necesita mejorar, lo que confirma en silencio algo que merece la pena asumir: en cuanto un agente de IA gestiona tickets reales, necesita también un proceso de QA, no un pase libre por ser software.

MaestroQA se ha alejado más de la etiqueta de "herramienta de QA" y ahora se llama a sí misma una plataforma de datos de conversación; su propia home page enmarca el giro directamente: "Empezamos como una empresa de QA para contact centers... Desde la llegada de ChatGPT en 2023, analizar datos de conversación se ha convertido en una prioridad a nivel de dirección." Su caso de estudio de DraftKings se plantea como un reemplazo total de las revisiones manuales de QA, y Brex reporta 20 veces más clientes en riesgo detectados tras reconstruir su proceso de QA en torno a la plataforma, un salto lo bastante grande como para que, según el caso de estudio, la COO de Brex le dijera al equipo "se acabó el QA manual" tras una sola vista previa.

Playvox, ahora parte de NICE, juega un papel similar dentro de una suite de workforce engagement más amplia: scorecards flexibles, calibración e integraciones nativas con Zendesk/Salesforce, aunque sus páginas de marketing bloquean activamente el scraping, así que trata los detalles sobre Playvox como orientativos más que verificados.

Los profesionales sobre el terreno respaldan más el enfoque de coaching que el de calificación. Una revisora de MaestroQA que trabaja como contratista independiente lo expresó bien: "deja de tratar las revisiones de calidad como un simple test de 'apto/no apto' y las convierte en una forma real de dar coaching a las personas." Y una analista de QA de verdad -no una manager, sino la persona que realmente hace la calificación día a día- describió dos años y medio usando MaestroQA "primero como agente, monitorizando mis puntuaciones de calidad, y ahora como Quality Analyst, haciendo toda la calificación", calificando el proceso de "extremadamente sencillo".

No está libre de fricción. Un Founder del sector de telecomunicaciones señaló un problema de coste real en G2: "las funciones de IA requieren una compra adicional que aumenta el coste de forma significativa"; presupuesta la puntuación con IA como una línea aparte sobre el producto de QA base, no como una mejora gratuita. Y un ejecutivo de Operaciones en evaluagent señaló una queja de UX más pequeña pero real desde el lado del agente: correos de notificación de puntuación que solo dicen que hubo una revisión, sin el resultado real, algo que describió como "inquietante" y que "me hace sentir ansioso, y me empuja a abrir Evaluagent de inmediato." Un programa de QA técnicamente riguroso puede aun así salir mal si el lado orientado al agente se siente como que lo llaman al despacho del director.

Cuando el agente evaluado es una IA, no una persona

Aquí es donde tengo números propios y reales que poner sobre la mesa, porque es exactamente la pregunta que un programa de QA tiene que responder en cuanto un agente de IA se une a la cola: no "¿suena bien la IA?", sino "¿aguanta frente a la misma scorecard que usarías con una persona?".

En una prueba con validación cruzada que realizamos sobre tráfico real de Zendesk para un equipo de ecommerce, la IA de eesel logró un 93% de precisión en triaje y un 100% de detección de spam sin falsos positivos, en una bandeja donde el spam suponía el 22% del volumen total. La precisión direccional de los borradores llegó al 88%, es decir, la sustancia de la respuesta iba por buen camino casi nueve de cada diez veces. Pero solo el 12% de los borradores se enviaron tal cual por los agentes, y la tasa de error factual se situó en el 7%. El rendimiento por categoría varió bastante: los borradores de devoluciones y reembolsos se calificaron como útiles el 93,8% de las veces, las reclamaciones de garantía el 96,4%, y tanto las consultas de producto como las búsquedas de estado de reembolso alcanzaron el 100%.

La brecha entre el 88% de precisión direccional y el 12% de adopción tal cual es la parte que merece la pena analizar. No era que los agentes no confiaran en el criterio de la IA: el patrón dominante era "echar un vistazo y reescribir": los agentes tomaban un borrador de 8-15 frases y lo recortaban a 1-3 frases antes de enviarlo. Al descomponer ese patrón de reescritura, cerca del 65% era pura edición de longitud y tono, solucionable entrenando al agente con las respuestas realmente enviadas por el equipo en el pasado. Otro 20% necesitaba datos a los que la IA simplemente aún no estaba conectada, como el estado en vivo de ERP o logística. Solo cerca de un 5% de las reescrituras ocurrieron porque el borrador era, directamente, factualmente incorrecto. Entrenar con una muestra de 200 respuestas recientes de agentes movió la adopción tal cual del 12% hacia el rango del 30-40% en pruebas de seguimiento.

Menciono esto porque es exactamente el tipo de patrón que una scorecard de QA de verdad está diseñada para sacar a la luz, y exactamente el tipo de patrón que resulta invisible si solo se muestrea un 5% de los tickets. Si tu programa de QA no puede decirte si los borradores de tu agente de IA están mal o simplemente son estilísticamente distintos a cómo escribe tu equipo, no estás midiendo realmente la calidad: estás midiendo una sensación con pasos extra.

Esa distinción aparece incluso antes de que un cliente vea una respuesta en vivo. Un prospecto que evaluaba eesel -un líder de soporte en una empresa belga- construyó su propia evaluación de 67 pruebas antes de confiar en la herramienta con tickets reales, calificando las respuestas de conocimiento como "sólidas" en general (finalmente se marchó por un motivo no relacionado: la velocidad del widget de chat, no la calidad de las respuestas). Eso es un proceso de QA en miniatura, ejecutado por un comprador en lugar de por un proveedor, y es el instinto que me gustaría que tuviera todo equipo que evalúa un agente de IA: no tomes "hace una buena demo" como tu scorecard.

Una scorecard de QA práctica que puedes construir esta semana

No necesitas una plataforma WEM para empezar. Una primera scorecard funcional necesita cuatro cosas:

1. Elige de 4 a 6 categorías que mapeen lo que realmente importa a tu negocio -precisión, tono, resolución, y una categoría crítica de cumplimiento si estás en un sector regulado. Menos categorías bien elegidas superan a un formulario inflado de 15 elementos que nadie completa de forma consistente.
2. Elige escalas binarias o de 3 puntos para empezar. Las escalas matizadas de 5 puntos suenan rigurosas, pero ralentizan las revisiones e introducen más desacuerdo entre revisores, exactamente lo que la calibración existe para arreglar. Empieza simple, añade matiz una vez que el programa esté funcionando.
3. Pondera lo que realmente impulsa los resultados, no lo que es más fácil de puntuar. Si el diagnóstico de causa raíz importa más para tu tasa de renovación que una respuesta perfectamente puntuada, pondéralo así: a la fórmula no le importa lo que sea conveniente de calificar.
4. Calibra antes de dar coaching. Haz una sesión de calibración con tus revisores sobre los mismos 10 tickets antes de que salga la primera puntuación real de alguien. El desacuerdo aquí es normal y esperado: es todo el sentido de hacerlo primero.

Una vez que esa scorecard exista para tus agentes humanos, aplícala también a tu agente de IA, incluyendo cualquier parte de tu stack que gestione escalados o automatización de call center. Las mismas categorías ponderadas, la misma regla crítica de cumplimiento, la misma disciplina de calibración. Un agente de IA al que nunca se le ha aplicado tu scorecard real está funcionando a base de intuición, igual que lo haría un empleado nuevo sin formar.

eesel y el control de calidad

Trabajo en la cola de soporte de eesel, y la respuesta honesta a "¿debería confiar en las respuestas de un agente de IA sin revisarlas?" es no: no deberías confiar en las respuestas de nadie sin revisarlas, sea humano o IA. Por eso eesel construye el QA dentro del propio despliegue en lugar de tratarlo como un programa aparte añadido después. Antes de que un agente responda a un ticket en vivo, el modo de simulación lo ejecuta contra tus propios tickets históricos, para que puedas ver la cobertura por tema y detectar lagunas antes de que un cliente las vea: lo más parecido a una scorecard de QA ejecutada antes del lanzamiento en lugar de después. Una vez en vivo, el enrutamiento basado en confianza actúa como una puerta de QA continua sobre cada respuesta: las respuestas de baja confianza se retienen como borrador para que las revise una persona en lugar de enviarse a ciegas, que es la misma lógica que aplica el AI Agent QA de Zendesk después del hecho, solo que trasladada antes en el proceso.

Si ya llevas un programa de QA con tu equipo humano y te estás planteando si un agente de IA podría estar a la altura del mismo listón, esa es exactamente la conversación que merece la pena tener: eesel es gratis para probar, y el precio es por uso, por ticket, en lugar de una tarifa fija por puesto, así que probarlo contra tu propia scorecard no requiere pasar antes por un proceso de compras.