ElevenLabs delega su soporte en un agente de IA: 22 000 tickets al mes, el 65% sin intervención humana

ElevenLabs resuelve más de 22 000 solicitudes al mes con su propio producto, ElevenAgents. No se trata de una demo para clientes, sino de la línea de soporte real de la propia compañía. Según el equipo, el último mes el agente llevó hasta el final el 65% de los tickets. El tiempo medio de primera respuesta bajó a 60 segundos; antes se medía en horas. El 70% de las conversaciones gestionadas por la IA obtuvo una valoración positiva, lo que coincide con la puntuación de los operadores humanos.

El agente trabaja con texto, capturas de pantalla y PDF, está conectado a la plataforma de tickets, mantiene conversaciones largas, busca datos de la cuenta, ejecuta acciones y escala casos a los empleados. Si ambas cifras corresponden al mismo mes, el flujo total ronda los 34 000 tickets (22 000 con una cuota del 65%). Es un cálculo nuestro, no una declaración de la compañía.

Los SOP como código fuente del agente

La decisión principal del equipo es aburrida y, por eso mismo, funciona. El soporte ya tenía procedimientos estándar detallados para cada categoría importante: reembolsos, cambios de facturación y consultas sobre clonación profesional de voz. El reto de ingeniería consistió en traducir ese conocimiento a un formato que el agente ejecute de forma predecible. Para ello hicieron falta dos mecanismos de ElevenAgents:

• Procedures convierten los SOP en flujos de trabajo repetibles. Los playbooks de soporte se trasladaron para cada categoría principal de tickets.
• Structured Procedures se aplican a las operaciones críticas, como la devolución de dinero. Cada paso se ejecuta de forma determinista, sin improvisación libre del modelo.
• Webhook tools dan al agente datos en vivo del usuario: el plan de suscripción, el consumo de créditos y las voces que le pertenecen. Sin ellas, el agente solo podría dar consejos; con ellas, resuelve el problema de principio a fin.

La frontera entre el modelo flexible y el procedimiento rígido está donde un error cuesta dinero. El modelo conduce la conversación, pero un guion controla la emisión del reembolso.

Cómo se comprobó la calidad antes de producción

Antes de la activación y después de cada cambio de configuración, el equipo usó tres herramientas:

• Channel behavior settings. Quien escribe por correo quiere una respuesta en el mínimo de turnos y con formato de correspondencia profesional. El cliente por voz necesita un diálogo natural en tiempo real, con muchas más intervenciones. Cada canal tiene su propio listón.
• Simulation tests. El agente se probó con unos 50 de los escenarios de soporte más frecuentes. Después, Architect, el constructor de agentes en lenguaje natural, ajustó el prompt del sistema y los procedimientos hasta que las pruebas se superaban de forma estable. El conjunto se vuelve a ejecutar tras cualquier cambio para evitar regresiones.
• Shadow mode. El agente trabajó con tráfico real dentro del sistema de tickets, pero sus respuestas no llegaban a los clientes. Cuando hubo confianza en la calidad de las respuestas, se activó en producción.

Architect como herramienta para analizar causas

Los empleados de soporte usan Architect cada día para entender dónde se atasca el agente. Una sola consulta en lenguaje natural devuelve un desglose de los tickets por categorías principales. También se puede preguntar por qué un caso concreto acabó en manos de una persona. La causa puede ser un vacío en la base de conocimiento, una herramienta que falta o una política interna poco clara. Una vez identificada la causa, Architect propone correcciones.

Los cambios también pasan por Architect: redacta y verifica las actualizaciones, y luego crea nuevos simulation tests y los añade al conjunto común. Así, los procedimientos nuevos se comprueban de inmediato y los antiguos no se rompen sin que nadie se dé cuenta. Las personas siguen dentro del circuito: aclaran las necesidades de los clientes, actualizan las políticas y vigilan que el agente no se sobreajuste a un solo tipo de ticket. Architect se encarga del resto, lo que permite al soporte mantener el ritmo de una cartera de productos en expansión.

Qué se puede aprovechar de este caso

El esquema general es trasladable a cualquier equipo con soporte:

1. Empiece por los SOP existentes de las categorías de consulta más frecuentes. Si no hay procedimientos, todavía no hay nada que automatizar.

2. Separe el diálogo libre de las acciones irreversibles. Todo lo relacionado con dinero y permisos de acceso debe diseñarse como pasos deterministas.

3. Dé al agente acceso a los datos de la cuenta mediante herramientas; de lo contrario, la proporción de tickets resueltos por completo topará con un techo. 4.

Reúna un conjunto de 30–50 escenarios típicos y ejecútelo después de cada cambio en el prompt o en un procedimiento. 5. Lance el agente en modo sombra sobre el flujo real antes de mostrar las respuestas a los clientes.

6. Configure por separado el correo, el chat y la voz: las expectativas sobre el número de turnos y el tono son distintas.

La valoración humana del 70% indica que la velocidad no se ha comprado a costa de la calidad. Pero un 65% de resolución de extremo a extremo significa que, aun así, un tercio de los tickets acaba en manos de personas, y es ahí donde las escaladas aportan material para la siguiente iteración del agente.

El caso se publica en medio de una serie de lanzamientos de ElevenLabs en torno a su plataforma de agentes. En septiembre aparecieron ElevenAgents en OpenAI Marketplace y Eleven v4 Turbo dentro de ElevenAgents, y en agosto salió ElevenLabs MCP para Claude. El soporte de la propia compañía sirve de escaparate para la plataforma.