Exemple détaillé. Ceci est un exemple détaillé et illustratif, pas un résultat client : l'équipe support et ses chiffres sont des hypothèses. Il montre la recherche côté agent, un outil qui se place derrière l'agent support, pas devant le client. L'agent pose une question en langage courant, obtient une réponse sourcée, reste sur le ticket et envoie la réponse.
Imaginez une équipe CX e-commerce mid-market qui veut faire bouger le délai de première réponse sur les tickets complexes. Cet article présente en quoi consiste le design, ce qu'il faut mesurer et ce qu'il ne fait pas. Il ne rapporte aucun résultat, car aucun client n'est derrière.
L'équipe est hypothétique, et tout chiffre que l'on pourrait attendre ici l'est aussi. Le design s'appuie sur le travail de support client décrit sur /ai-for/customer-support. Une chose de plus d'emblée : c'est de l'assistance à l'agent uniquement. Aucun chatbot ne parle à un client à aucun moment.
#Qu'est-ce qui ralentissait les agents ?
Les réponses existent. Les trouver ne passe pas à l'échelle. Un ticket complexe, c'est un agent qui ouvre l'historique Zendesk, une doc produit et un PDF de politique de livraison, puis assemble la réponse à la main. Des années de tickets passés contiennent le précédent, et personne ne peut fouiller cette archive dans le temps qu'un client attend.
La première réponse restait donc en file d'attente pendant que l'agent cherchait. Cette attente, c'est le chiffre sur lequel le responsable support se fait interroger. Le délai de première réponse, pas le volume de tickets.
L'ia peut-elle réduire le délai de première réponse du support sans chatbot ?
Oui, c'est l'objectif. Un outil de recherche interne permet aux agents de poser des questions en langage courant sur les tickets historiques, la doc produit et les PDF de politique, et d'obtenir une réponse sourcée. L'agent rédige et envoie toujours la réponse. Une équipe mesurerait le délai de première réponse sur les tickets complexes avant et après, sans bot face au client.
#En quoi consiste le design ?
Un seul outil de recherche interne couvrant trois sources : les tickets historiques, la documentation produit et les PDF de politique de livraison. Un agent tape une question comme il le ferait à un collègue senior. La réponse revient avec la source citée, pour que l'agent puisse la vérifier avant qu'elle ne parte au client.
- Une recherche sur tous les tickets passés en une seule requête, pas onglet par onglet.
- Des réponses sourcées, pour que l'agent vérifie la source au lieu de faire confiance à une boîte noire.
- Des réponses ancrées dans les PDF de politique de livraison, là où vivent réellement les règles des cas limites.
- L'agent reste sur le ticket. L'outil ne répond jamais seul à un client.
Former l'équipe support fait partie du design, ce n'est pas une passation en fin de parcours. Le KPI à convenir est le délai de première réponse sur les tickets complexes, mesuré avant et après. Ce qu'il fait bouger, ce sont vos propres données qui le diront, pas cet article.
#N'est-ce pas la même chose qu'un bot de déviation ?
Non, et la différence est tout l'intérêt. Une stratégie de déflexion cherche à réduire le volume de tickets en répondant directement aux clients. Ce design vise un autre chiffre : le délai de première réponse, en plaçant la recherche derrière l'agent. Le client parle toujours à une personne.
We are
Stennir construit une ia qui se place derrière vos agents support : recherche, triage, rédaction-relecture, mesurée sur le délai de première réponse et la qualité des réponses apportées.
We aren't
Stennir n'est pas un éditeur de chatbot face au client et ne vend pas la déviation comme objectif ; l'agent reste sur le ticket et vos clients continuent de parler à des humains.
Des outils comme Zendesk AI, intercom fin ou les suggestions de gorgias fonctionnent à l'intérieur de leurs propres murs : vos macros, vos articles d'aide, vos réponses enregistrées. Ce design ajoute la recherche sur le reste. Les tickets historiques, la documentation produit, les PDF de politique de livraison, les runbooks. C'est là que se cachent les réponses aux tickets complexes.
Les KPIS que nous faisons bouger sont le délai de première réponse et la qualité des réponses apportées sur les tickets complexes, pas les effectifs. Nous le disons dès le premier jour et nous le mesurons.
#Est-ce que ça marcherait pour notre équipe support ?
Le test d'adéquation est simple. Vos réponses vivent-elles déjà dans des endroits lents à fouiller ? Des années de tickets, une pile de PDF de politique, une documentation produit qui évolue. Si vos agents perdent des minutes à chercher avant chaque réponse complexe, c'est ce temps que la recherche est censée rendre.
Ce design fait partie de notre travail de conseil en ia, avec la formation de l'équipe support intégrée depuis notre volet formation à l'ia. Si vous voulez voir comment les pièces s'assemblent, le journal contient d'autres exemples détaillés comme celui-ci.
Si vos agents cherchent des réponses avant chaque réponse complexe, c'est le délai que ce design vise. dites-nous ce que vous construisez et nous vous dirons si la recherche est le bon levier, ou si elle ne l'est pas.
