Que hace
El agente de IA realiza el trabajo del ingeniero de QA de soporte: cada mañana recupera los diálogos cerrados en las últimas 24 horas, verifica cada respuesta según una rúbrica fija y elabora un informe para el team lead. El objetivo de la automatización es cerrar la brecha entre los estándares de soporte declarados y lo que realmente llega a los clientes.
Proceso paso a paso
- Extracción del helpdesk de los diálogos cerrados en las últimas 24 horas — mínimo el 10% del volumen diario, muestra estratificada por agentes y categorías de solicitudes.
- Procesamiento de cada diálogo mediante la rúbrica de QA: precisión de la resolución, tono de comunicación, cumplimiento de scripts, cumplimiento del SLA, corrección de las etiquetas de clasificación, exhaustividad de la respuesta.
- Puntuación de cada criterio según una escala y puntuación global del diálogo con una cita justificativa del texto de la respuesta.
- Elaboración del informe diario: respuestas de referencia, respuestas con desviaciones, tendencias generales por agentes y categorías de la semana anterior.
- Envío del informe al team lead por Slack o por correo electrónico con enlaces directos a cada ticket en el helpdesk para una revisión rápida.
- Repetición del ciclo cada día laborable sin omisiones y sin el «se nos olvidó este lunes».
Rúbrica de QA — qué se verifica
- Precisión: si la respuesta resuelve el problema del cliente en esencia.
- Tono: si corresponde al tone of voice declarado de la marca.
- Scripts: si se utilizaron las formulaciones aprobadas para situaciones estándar.
- SLA: si el agente cumplió con los estándares de tiempo de primera respuesta y cierre del ticket.
- Etiquetas: si las categorías de solicitud están correctamente asignadas para el análisis posterior.
- Exhaustividad: si el asunto está resuelto sin cabos sueltos ni suposiciones implícitas.
Qué NO hace la automatización
- No reemplaza el análisis en vivo. El agente de IA señala las respuestas que se desvían de la rúbrica; la conclusión final — por qué y qué hacer al respecto — corresponde al team lead.
- No forma a los agentes en tiempo real. El informe muestra qué falló en las últimas 24 horas; el coaching, la actualización de scripts y los 1:1 son trabajo del responsable, no del script.
- No edita las respuestas. La verificación se realiza sobre los diálogos ya enviados; durante el intercambio con el cliente, la automatización no interviene.
Como funciona
La arquitectura está construida como un escenario custom-code con LLM-evaluator e integración directa en la API del helpdesk. El componente central es el evaluator, que recibe como entrada el texto del diálogo y la descripción YAML de la rúbrica, y como salida entrega un JSON estructurado con puntuaciones y citas-justificaciones por cada criterio.
Flujo técnico
El script se ejecuta según un calendario, extrae datos del helpdesk, los procesa a través del LLM con un prompt fijo de rúbrica y escribe el resultado en la base de informes. El modelo no solo otorga una puntuación, sino también una cita del diálogo que justifica la evaluación, para que el team lead no tenga que resolver la pregunta «por qué el AI tomó esa decisión».
Componentes de la solución
Componente | Rol |
|---|---|
Helpdesk API | Fuente de diálogos cerrados con metadatos (agente, categoría, SLA) |
Scheduler | Ejecución del escenario diariamente en una ventana fija |
Sampler | Muestra estratificada del 10% por agentes y categorías |
LLM evaluator | Evaluación por rúbrica, citas-justificaciones |
Storage | Historial de evaluaciones para tendencias y auditoría |
Reporter | Compilación del informe y envío a Slack o por correo |
Pasos de implementación
- Fijación de la rúbrica. El equipo de Grow2.ai junto con el team lead de soporte formaliza los criterios de calidad vigentes en formato YAML: para cada punto se formula una pregunta y una escala. Sin este paso, la automatización no tiene sentido: el modelo verifica lo que está escrito, no lo que «todos saben de memoria».
- Conexión al helpdesk. Se crea un token de servicio con permisos read-only sobre los diálogos cerrados del período seleccionado. La integración funciona con cualquier helpdesk que tenga API para exportar conversaciones.
- Calibración del evaluator. El evaluator se ejecuta sobre una muestra histórica de diálogos y los resultados se comparan con las evaluaciones manuales del team lead. Las discrepancias se analizan y la rúbrica y el prompt se ajustan. El objetivo es la concordancia entre las evaluaciones del modelo y las del team lead en la mayoría de los casos.
- Configuración de la muestra. El Sampler toma el 10% del volumen diario y estratifica: al menos un diálogo por agente activo por semana y al menos un diálogo por cada categoría principal de solicitudes.
- Formato del informe. El team lead junto con el equipo de Grow2.ai acuerdan la estructura del correo diario: qué se destaca en el top, qué métricas van en el resumen, qué gráficos para 7 y 30 días.
- Lanzamiento en piloto. Durante dos semanas, el evaluator trabaja en paralelo con la auditoría manual: esto permite detectar discrepancias y ajustar la rúbrica sin riesgo para el production.
- Transición a production. La auditoría manual se conserva solo para casos límite y escalaciones; la verificación rutinaria pasa a la automatización.
Cómo el modelo otorga una evaluación fundamentada
El prompt del evaluator está estructurado de forma explícita: primero el modelo lee la rúbrica y el diálogo, luego por cada criterio extrae una cita concreta de la respuesta del agente, y solo después asigna la puntuación. Este esquema con citas-justificaciones reduce la probabilidad de alucinaciones y hace la evaluación verificable: el team lead ve en qué basó su decisión el modelo y puede aceptar o impugnar la conclusión rápidamente.
Requisitos previos
Para la implementación se necesita una infraestructura mínima pero concreta y la disposición del equipo.
Accesos y datos
- API de helpdesk con permisos de lectura de conversaciones cerradas — Zendesk, Intercom, Freshdesk, HelpScout, Front o cualquier sistema con conversations endpoint.
- Historial de conversaciones cerradas del último mes en un volumen suficiente para la calibración (varios cientos de registros).
- Los criterios de calidad actuales en cualquier formato: google-doc, página de Notion o acuerdo verbal del team lead. La formalización en YAML estará a cargo del equipo de implementación.
- Canal de entrega del informe: Slack workspace con permiso para crear una integración de bot o correo de trabajo del team lead.
Disposición del equipo
- El team lead de soporte está dispuesto a dedicar 4–6 horas en la primera semana para fijar la rúbrica y 2–3 horas por semana durante el primer mes para la calibración.
- El responsable de soporte está de acuerdo en que la automatización elimina la rutina de selección y evaluación, pero no reemplaza el análisis manual de casos complejos.
- Los agentes han sido informados sobre la transición a un QA regular y entienden que se revisan conversaciones ya cerradas, no el trabajo en tiempo real.
Plazos
La implementación completa lleva 2–4 semanas:
- Semana 1: fijación de la rúbrica, conexión al helpdesk, primera ejecución con datos históricos.
- Semana 2: calibración del evaluator, acuerdo sobre el formato del informe.
- Semanas 3–4: piloto en modo paralelo con auditoría manual y transición a production.
Tras el lanzamiento, la automatización funciona sin intervención; el equipo de Grow2.ai permanece disponible para el soporte de la rúbrica y los prompts.
Problemas
- Revisión — cuello de botella
- Calidad inconsistente
FAQ
¿Cuánto tiempo llevará el lanzamiento?
El lanzamiento completo toma 2–4 semanas para un equipo de soporte de 5–20 agentes. Semana 1 — fijación de la rúbrica y conexión al helpdesk, semana 2 — calibración del evaluator, semanas 3–4 — piloto en paralelo con auditoría manual y transición a producción. Los plazos se extienden si los criterios de calidad vigentes existen solo en la cabeza del team lead y es necesario discutirlos y documentarlos previamente.
¿No tenemos una rúbrica de QA formalizada — es un bloqueador?
No, la ausencia de una rúbrica formal es un punto de partida normal. En la primera semana, el equipo de Grow2.ai realiza una sesión de trabajo con el team lead, fija los criterios vigentes (con los que actualmente se evalúan las respuestas de manera informal) y los convierte en YAML. No se necesita un proyecto separado de desarrollo de rúbrica; todo se ajusta al plazo general de implementación.
¿Cuáles son los riesgos y qué puede fallar?
Tres riesgos principales. El primero — discrepancia entre las evaluaciones del modelo y del team lead en casos límite; se resuelve con calibración sobre una muestra histórica. El segundo — cambio de la rúbrica sin actualizar el YAML; entonces la automatización evalúa con criterios desactualizados. El tercero — caída de la API del helpdesk; el evaluator registra los errores y reintenta, pero la automatización no es responsable de la disponibilidad de servicios de terceros.
¿Funciona para nuestra industria?
Es adecuado para SaaS/Tech como segmento principal y de forma universal para cualquier industria con canales de soporte de texto — e-commerce, fintech, edtech, servicios B2B. La automatización opera con el texto de los diálogos y la rúbrica; la industria en sí no afecta el funcionamiento del evaluator. Las particularidades del sector se incorporan en la rúbrica de calidad y los scripts de respuesta.
¿Se puede verificar el 100% de los tickets, y no solo el 10%?
Técnicamente — sí, pero raramente aporta un incremento de valor. El 10% de una muestra estratificada por agentes y categorías es estadísticamente suficiente para detectar desviaciones sistémicas en la calidad. El 100% se justifica en industrias reguladas con requisitos de compliance — en ese caso, el volumen de llamadas LLM y el costo se recalculan según el flujo diario real de diálogos.
¿Qué ocurre con la privacidad y los datos personales en los diálogos?
Antes de enviarlo al LLM, el evaluator procesa el diálogo a través del filtro PII: los correos electrónicos, teléfonos, números de tarjeta e identificadores de clientes se reemplazan por placeholders. Para equipos con requisitos GDPR, el procesamiento se configura en la región EU y la retención de logs se ajusta al reglamento. Los diálogos originales se almacenan en el lado del helpdesk y no se duplican dentro de la automatización.
Quieres esto en tu negocio?
Reserva una auditoria gratuita — te mostraremos como funcionara esta automatizacion para ti.