L'ia pour une base de connaissances support. L'ia pour une base de connaissances support est un outil de récupération interne que vos agents interrogent en langage courant. Il cherche dans votre historique de tickets, vos docs produit et vos politiques en une seule requête, et renvoie une réponse qui cite sa source. Il reste derrière l'agent. Le client continue de parler à un humain.
Vos agents passent la moitié de leur service à chercher dans la documentation. C'est la plainte à guetter dans votre propre équipe. La réponse existe quelque part : dans un ancien ticket, une spécification produit ou une politique de livraison que personne n'a ouverte depuis janvier. La trouver est devenu le travail.
#Pourquoi mes agents passent-ils la moitié de leur temps à chercher dans les docs ?
Parce que la réponse est éparpillée dans des systèmes qui ne se parlent pas. La règle de remboursement est dans un PDF de politique. Le cas limite qui la contredit est enterré dans un ticket Zendesk résolu de 2023. Le comportement du produit est dans une page confluence écrite par un ancien pm. Un agent sur un ticket complexe doit vérifier trois endroits, deviner lequel est à jour, et espérer.
Que fait concrètement l'ia pour une base de connaissances support ?
Elle indexe vos tickets, vos docs produit et vos politiques, puis laisse un agent poser une seule question en langage courant et obtenir une seule réponse. La réponse renvoie vers le document et le passage exact d'où elle vient, pour que l'agent puisse la vérifier en un clic. C'est interne. Les clients n'y touchent jamais et continuent de parler à un humain.
La citation, c'est la partie qui compte. Une réponse sans source, c'est une supposition que l'agent doit encore vérifier. Une réponse qui renvoie vers le passage d'origine, c'est un fait que l'agent confirme en un clic, puis colle dans sa réponse. On relie chaque réponse au document dont elle vient exactement pour cette raison.
#Qu'est-ce que cela change au délai de première réponse ?
à titre d'illustration, prenons une équipe support e-commerce mid-market imaginaire, pas un client. Un outil de recherche qui interroge les anciens tickets, la documentation produit et les politiques de livraison en une seule requête aide surtout sur les tickets difficiles, ceux où l'agent ouvrait six onglets avant d'écrire un mot. Une équipe dans cette situation mesurerait le délai de première réponse sur les tickets complexes avant et après.
Les tickets simples sont déjà rapides : la réinitialisation de mot de passe, le où-est-ma-commande. Ce qui freine, c'est le ticket complexe qui demande un cas limite de politique et un traitement passé. Réduisez le temps de recherche sur ceux-là et la moyenne bouge. page de cas d'usage support client détaille la forme complète de la conception.
Si vous entendez cette phrase de la bouche de votre propre responsable support, la couche de recherche est le point de départ, avant tout outil de réponse.
#N'est-ce pas juste un chatbot côté client ?
We are
On construit une couche de récupération qui reste derrière votre agent, pour qu'un humain lise la réponse sourcée, la vérifie, et rédige la réponse dans son propre ton.
We aren't
On ne construit pas un chatbot côté client qui répond tout seul et espère avoir bien compris la politique devant une personne déjà énervée.
Un bot côté client place le modèle entre votre marque et un client en colère. Une mauvaise réponse sur un remboursement, là, c'est une erreur publique. La récupération reste un cran en retrait. L'agent obtient la réponse sourcée, l'agent décide, l'agent répond. L'humain reste dans la boucle là où l'enjeu est le plus fort, et le modèle fait la fouille là où ce n'est que fastidieux.
#Ce que voit l'agent
- Une seule barre de recherche, en langage courant, pas un champ de mots-clés.
- Une seule réponse, tirée à la fois des tickets, des docs et des politiques.
- Une citation sur chaque réponse, avec un lien vers le passage source.
- Aucun client n'y touche jamais. C'est un outil d'assistance à l'agent, pas un chatbot.
L'outil lit votre historique non structuré. La politique d'expédition qui est un PDF, le ticket résolu qui est un fil de discussion, le doc produit qui est une page wiki. Il n'a pas besoin que vous nettoyiez ou restructuriez quoi que ce soit d'abord. C'est tout l'intérêt de la récupération plutôt que de construire une énième base de connaissances à la main et de la maintenir à jour pour toujours. On écrit sur d'autres missions comme celle-ci dans le journal.
Si vos agents cherchent plus qu'ils ne répondent, on devrait d'abord cartographier où vit réellement votre connaissance avant de construire quoi que ce soit. réservez un appel découverte de 30 min et on parcourra vos tickets, vos docs et vos politiques, puis on vous dira où une couche de récupération fait bouger le délai de première réponse, et où ça ne change rien.
