ElevenLabs confie son support à un agent IA : 22 000 tickets par mois, 65% sans intervention humaine

ElevenLabs traite plus de 22 000 demandes par mois avec son propre produit, ElevenAgents. Il ne s'agit pas d'une démo pour les clients, mais de la ligne de support opérationnelle de l'entreprise elle-même. Selon l'équipe, l'agent a mené à terme 65% des tickets au cours du dernier mois. Le délai moyen de première réponse est tombé à 60 secondes, alors qu'il se comptait auparavant en heures. 70% des conversations menées par l'IA ont reçu une évaluation positive, un score qui rejoint celui des opérateurs humains.

L'agent traite le texte, les captures d'écran et les PDF. Il est connecté à la plateforme de tickets, mène de longs échanges, recherche les données du compte, effectue des actions et escalade des cas vers les employés. Si les deux chiffres portent sur le même mois, le flux total avoisine 34 000 tickets (22 000 pour une part de 65%). Il s'agit de notre propre calcul, et non d'une déclaration de l'entreprise.

SOP comme code source de l'agent

La décision principale de l'équipe est banale, et c'est pour cela qu'elle fonctionne. Le support disposait déjà de procédures opérationnelles standard détaillées pour chaque grande catégorie : remboursements, modifications de facturation, questions sur le clonage vocal professionnel. Le travail d'ingénierie a consisté à traduire ce savoir dans un format que l'agent exécute de façon prévisible. Deux mécanismes d'ElevenAgents ont été nécessaires pour cela :

• Procedures transforment les SOP en workflows reproductibles. Les playbooks du support ont été transposés pour chaque grande catégorie de tickets.
• Structured Procedures servent aux opérations critiques, comme le remboursement d'argent. Chaque étape y est exécutée de manière déterministe, sans improvisation libre du modèle.
• Webhook tools donnent à l'agent les données en direct de l'utilisateur : formule d'abonnement, consommation de crédits, voix qui lui appartiennent. Sans cela, l'agent ne pourrait que conseiller ; avec, il résout le problème de bout en bout.

La frontière entre modèle flexible et procédure rigide passe là où l'erreur coûte de l'argent. Le modèle mène la conversation, mais c'est un scénario qui contrôle l'émission d'un remboursement.

Comment la qualité a été vérifiée avant la production

Avant l'activation, puis après chaque modification de configuration, l'équipe a utilisé trois outils :

• Channel behavior settings. L'utilisateur d'un canal e-mail veut obtenir une réponse en un minimum d'échanges et dans un format de correspondance professionnelle. Le client au téléphone attend un dialogue vivant, en temps réel, avec de nombreuses répliques. Un seuil distinct est défini pour chaque canal.
• Simulation tests. L'agent a été testé sur environ 50 des scénarios de support les plus fréquents. Ensuite, Architect, le constructeur d'agents en langage naturel, a corrigé le prompt système et les procédures jusqu'à ce que les tests passent de façon stable. L'ensemble est relancé après toute modification afin d'éviter une régression.
• Shadow mode. L'agent a travaillé sur du trafic réel dans le système de tickets, mais ses réponses n'étaient pas envoyées aux clients. Une fois la confiance acquise dans la qualité des réponses, il a été mis en production.

Architect, outil d'analyse des causes

Les employés du support utilisent Architect chaque jour pour comprendre où l'agent cale. Une seule requête en langage naturel produit une répartition des tickets par grandes catégories. On peut aussi demander pourquoi un cas précis a été transmis à un humain. La cause peut être une lacune dans la base de connaissances, un outil manquant ou une politique interne floue. Une fois la cause trouvée, Architect propose des correctifs.

Les changements passent eux aussi par Architect : il rédige et vérifie les mises à jour, puis crée de nouveaux simulation tests et les ajoute à l'ensemble commun. Ainsi, les nouvelles procédures sont validées immédiatement, et les anciennes ne cassent pas à bas bruit. Les humains restent dans la boucle : ils précisent les besoins des clients, mettent à jour les politiques et veillent à ce que l'agent ne se sur-spécialise pas sur un seul type de ticket. Architect prend en charge le reste, ce qui permet au support de suivre l'élargissement du portefeuille de produits.

Ce que l'on peut retenir de ce cas

Le schéma général est transposable à toute équipe de support :

1. Partez des SOP existantes pour les principales catégories de demandes. Sans procédures, il n'y a rien à automatiser pour l'instant.

2. Séparez le dialogue libre des actions irréversibles. Tout ce qui touche à l'argent et aux droits d'accès doit être formalisé en étapes déterministes.

3. Donnez à l'agent l'accès aux données du compte via des outils, faute de quoi la part de tickets entièrement résolus butera sur un plafond. 4.

Constituez un ensemble de 30–50 scénarios types et relancez-le après chaque modification du prompt ou d'une procédure. 5. Lancez l'agent en mode fantôme sur le flux réel avant de montrer ses réponses aux clients.

6. Prévoyez des réglages distincts pour l'e-mail, le chat et la voix : les attentes en matière de nombre d'échanges et de ton diffèrent.

La note humaine de 70% montre que la vitesse n'a pas été obtenue au prix de la qualité. Mais 65% de résolution de bout en bout signifie aussi qu'un tiers des tickets finit tout de même chez des humains, et c'est précisément là que les escalades fournissent la matière de la prochaine itération de l'agent.

Ce cas est publié dans le sillage d'une série de lancements d'ElevenLabs autour de sa plateforme d'agents. En septembre sont apparus ElevenAgents sur l'OpenAI Marketplace et Eleven v4 Turbo au sein d'ElevenAgents, et en août est sorti ElevenLabs MCP pour Claude. Le support de l'entreprise elle-même sert vitrine à la plateforme.