Le contexte
Une équipe support N1 de 25 agents traite environ 2 500 tickets/mois chez un éditeur SaaS B2B. Chaque ticket demande en moyenne :
- 3 minutes pour comprendre le contexte (relire l'historique client, identifier le produit, vérifier le contrat)
- 5-12 minutes pour rédiger une réponse adaptée
- 2-5 minutes pour vérifier qu'elle est cohérente avec la base de connaissances et le ton de la marque
Soit 10-20 minutes par ticket. Multiplié par 2 500 → 500-800 heures/mois sur du support N1, dont une part importante est répétitive (questions récurrentes, copier-coller adapté de réponses passées).
Sous pression de croissance, le directeur support a 2 choix : (a) recruter 8-15 agents supplémentaires pour absorber la croissance prévue (coût ~600 k€/an chargé), (b) accepter une dégradation du SLA et la perte de NPS qui suit.
Le mécanisme LMbox
L'éditeur déploie LMbox M, intégrée à son outil de ticketing (Zendesk, Jira Service Desk, Salesforce Service Cloud, Freshdesk).
- Connecteurs : ticketing existant (via API), Confluence/Notion (base de connaissances produit), Slack #support (3 ans d'historique), DataConnector custom sur Salesforce CRM (contrats clients, plans souscrits, contexte commercial).
- Le module Helpdesk Assistant packagé : pour chaque nouveau ticket, l'IA produit en 8 secondes :
- Résumé du contexte : qui est le client, quel plan, contrats actifs, tickets précédents (5 derniers cités)
- 3 réponses candidates rédigées avec le ton de votre marque, basées sur les 50 réponses les plus performantes du past
- Étiquetage automatique : produit concerné, urgence, catégorie (bug, demande, formation, escalation)
- Suggestion de routage si le ticket doit être escaladé (N2 spécialiste, account manager, équipe produit)
- L'agent valide, personnalise, envoie. Il n'écrit plus from scratch — il édite et signe.
Tous les contrats clients restent dans le LAN de l'éditeur. Aucun fournisseur cloud (OpenAI, Anthropic) ne voit la liste de vos clients ni leurs problématiques. Critique pour les éditeurs européens qui vendent à des clients eux-mêmes sensibles (santé, finance, défense).
Le calcul de ROI
Pour une équipe de 25 agents support traitant 2 500 tickets/mois :
| Métrique | Avant LMbox | Avec LMbox |
|---|---|---|
| Temps moyen par ticket | 12 min | 4 min |
| Tickets/mois traités à effectif constant | 2 500 | 7 500 |
| Délai moyen de première réponse | 4 h | 25 min |
| CSAT (Customer Satisfaction Score) | 78 | 87 |
| Taux d'escalade au N2 | 18 % | 9 % |
| Capacité produite à effectif constant | 100 % | 300 % |
Économie : équipe de 25 absorbe la charge d'une équipe de 75. À 65 k€/ETP chargé, 3,2 M€/an d'évitement d'embauches par rapport au scénario de croissance linéaire.
L'investissement LMbox (Box M : 25 k€ + 9,6 k€/an) est amorti en moins d'un mois.
Les pré-requis
- Outil de ticketing avec API stable (Zendesk, Salesforce SC, Freshdesk, Jira SD, ServiceNow). Les outils maison anciens demandent un connecteur custom (3-6 semaines).
- Base de connaissance produit maintenue à jour. Une KB qui date de 18 mois donne des réponses obsolètes — LMbox révélera vite ce manque, à corriger côté produit.
- 3 ans d'historique de tickets résolus minimum pour avoir suffisamment d'exemples de réponses gagnantes. Sinon les premières suggestions sont moins pertinentes.
- Politique de tone-of-voice documentée. Sans cette documentation explicite, l'IA répond en mode neutre — utilisable mais sans la patte de la marque.
- Buy-in de l'équipe support : ce n'est pas un outil pour remplacer les agents, c'est un copilote. Le pitcher comme tel évite la résistance et accélère l'adoption.
Le déploiement
- Semaines 1-2 : indexation du ticketing + KB. Calibrage des 3 réponses candidates sur 200 tickets historiques (l'agent comparait sa réponse réelle avec les suggestions IA).
- Semaines 3-4 : pilote sur 5 agents volontaires. Mesure : temps moyen, CSAT, taux d'utilisation des suggestions.
- Semaines 5-8 : déploiement complet. Formation 2 h/agent. Création d'un canal Slack #lmbox-support pour partager les suggestions étonnantes (ou ratées).
- Semaines 9-12 : amélioration continue. L'équipe enrichit progressivement la KB sur les sujets où l'IA donne des réponses faibles.
- Continu : monitoring des métriques. KPI principal : nombre de tickets/agent/jour, qui doit doubler en 3 mois.
Les limites & ce que ça ne fait pas
- L'IA ne ferme jamais un ticket à votre place. L'agent envoie, l'agent signe, l'agent reste responsable de la qualité de la réponse. C'est le seul mode défendable juridiquement et professionnellement.
- Sur les tickets très atypiques (bug architectural rare, demande d'évolution complexe, conflit commercial), l'IA peut produire des suggestions hors-sujet. L'agent doit pouvoir ignorer les 3 suggestions et écrire from scratch — c'est important pour préserver le sens d'autonomie.
- Les clients enterprise très sensibles (banque, défense) demandent souvent un audit du chemin de données : « est-ce que ma question passe par OpenAI ? ». La réponse claire « non, tout reste en LAN éditeur » est un argument commercial fort. Sans LMbox, c'est dur de le promettre proprement.
- Le risque de complaisance : un agent qui valide trop vite la suggestion sans la lire vraiment. Le management doit instaurer un sampling qualité (5-10 % des tickets revus par un lead) pour préserver le standard.