Transformer vos procédures support en agent IA testé

Cette méthode a d'abord été publiée sur G2 AI blueprints.

Quel problème cette méthode résout-elle ?

Les équipes CX e-commerce qui font tourner des agents IA sur des boutiques Shopify passent des semaines à configurer leurs automatisations intention par intention. Les politiques changent sans cesse (délais de retour, heures limites d'expédition, promotions de haute saison), la configuration se désynchronise, et les tickets hors script ou à demandes multiples finissent chez un humain. Maintenir l'automatisation devient un second métier, et le BFCM révèle chaque faille au pire moment.

Comment ça marche ?

1. Rassemblez vos procédures support actuelles, vos macros, vos politiques de retour et de livraison, ainsi qu'un échantillon de quelques centaines de tickets récents issus de votre helpdesk.
2. Connectez Yuma à votre boutique Shopify et à votre helpdesk (Gorgias, Zendesk ou équivalent) pour que l'agent puisse lire les commandes, le suivi et l'historique client, et exécuter des actions backend comme les annulations, les remboursements et les modifications d'adresse.
3. Demandez à Yuma de rédiger un Handbook à partir de ces procédures et de vos anciens tickets : un document lisible qui couvre le ton de marque, les politiques et un playbook par sujet. Vous gérez plusieurs boutiques ou marques ? Donnez à chaque marque sa propre section de ton dans le même Handbook.
4. Connectez Claude à Yuma via MCP et lancez les prompts d'audit du Handbook pour comparer le Handbook à vos documents de politique. Demandez-lui de signaler les contradictions, les cas limites manquants et les règles obsolètes, puis de proposer des modifications. Relisez chaque modification avant de l'accepter.
5. Écrivez des tests pour chaque playbook à partir de vrais tickets, avec la réponse et l'action attendues. Lancez-les, corrigez le Handbook partout où un test échoue, et relancez jusqu'à ce qu'ils passent.
6. Publiez le Handbook. Rien n'est en ligne tant qu'un humain ne l'a pas publié. Commencez par un sous-ensemble de sujets ou une partie du volume de tickets, et lisez les transcriptions chaque jour pendant la première semaine.
7. Étendez le même Handbook aux playbooks sortants déclenchés par des événements de commande (retards d'expédition, problèmes de livraison, paniers abandonnés par e-mail et SMS) et aux appels téléphoniques là où Voice est activé.
8. Quand une politique change, modifiez la section concernée du Handbook, relancez les tests et publiez. L'agent applique le changement dès le ticket suivant, sans aucune reconfiguration.

Quel est le plus grand bénéfice ?

Maintenir l'automatisation revient à maintenir de la documentation, et non plus des arbres de décision. Petlibro atteint 79 % d'automatisation avec Yuma, et Yuma intervient sur 64 % des demandes clients de Tediber. Un seul Handbook versionné pilote l'e-mail et le chat entrants, les messages sortants et le téléphone : un changement de politique atteint donc chaque canal dès le ticket suivant, et les tests par playbook détectent les régressions avant que vos clients ne les voient. Une mise en place qui demandait des semaines de configuration intention par intention se résume à rédiger, tester et valider un seul document.

Que faut-il pour la mettre en place ?

Déroulez les étapes 1 à 6 sur vos propres tickets avec un essai gratuit de Yuma de 30 jours avant de vous engager dans un déploiement. Copiez les prompts d'audit et de test dans un projet ou une skill Claude pour que toute l'équipe puisse les réutiliser. Énoncez chaque politique une seule fois dans le Handbook et faites-y référence depuis les playbooks : une modification ne laisse ainsi jamais de copie périmée derrière elle. Ajoutez un test pour chaque nouveau cas limite avant de publier la correction. Laissez Claude ou ChatGPT lire le Handbook et proposer des modifications via MCP, mais gardez une validation humaine sur chaque publication. Intégrez à vos tests les consultations de statut de commande et de suivi, puisque la plupart des tickets « où est ma commande ? » dépendent de données Shopify en temps réel. Avant novembre, rejouez dans vos tests les tickets de la semaine de pic du BFCM de l'an dernier, comme une répétition générale.

Quelles sont les limites ?

La qualité des réponses dépend de la qualité du Handbook : des politiques vagues ou contradictoires produisent des réponses vagues. Les actions backend exigent les bonnes autorisations Shopify et helpdesk. Les tickets hors des politiques documentées sont toujours transférés à des agents humains, par conception. Les taux d'automatisation varient selon la complexité du catalogue, la répartition des tickets et le niveau de documentation des politiques. Voice et certains canaux sortants peuvent dépendre de votre offre et de leur disponibilité.

Les prompts de cette méthode

Utilisez-les avec Claude connecté à Yuma via le MCP Yuma. Remplacez tout ce qui est entre [crochets]. Claude propose, un humain relit et publie dans Yuma.

Prompt 1 : auditer le Handbook face à vos politiques

Lis notre Handbook Yuma actuel et compare-le avec ces documents de politique : [colle ou joins la politique de retour, la politique de livraison, la garantie, les conditions des promotions, les procédures].

Renvoie :
1. Contradictions : tous les endroits où le Handbook dit autre chose que les documents de politique. Cite les deux versions.
2. Lacunes : politiques, cas limites ou catégories de produits que le Handbook ne couvre pas.
3. Règles obsolètes : dates, prix, heures limites, transporteurs ou promotions qui semblent expirés.
4. Doublons : règles énoncées à plusieurs endroits, qui finiront par diverger. Indique l'endroit unique où chaque règle devrait figurer.

Pour chaque problème, propose la modification exacte du Handbook. N'applique rien.

Prompt 2 : trouver ce que vos clients demandent et que le Handbook ne couvre pas

Recherche nos tickets Yuma des [30] derniers jours. Trouve les questions ou demandes :
- que le Handbook ne couvre pas, ou
- auxquelles les agents humains ont répondu autrement que ce que dit le Handbook.

Regroupe-les par sujet, avec un total par sujet et 2 exemples d'ID de ticket pour chacun. Classe-les par volume. Pour les 5 premiers, propose un ajout au Handbook.

Prompt 3 : écrire des tests pour chaque playbook

Pour le playbook [nom du playbook] de notre Handbook, écris [10] tests à partir de vrais tickets Yuma dans la mesure du possible. Pour chaque test, indique :
- le message du client (tiré d'un vrai ticket, sans données personnelles)
- la réponse attendue, dans le ton de notre marque
- l'action attendue (remboursement, annulation, modification d'adresse, escalade, aucune)
- pourquoi ce cas compte (fréquent, cas limite ou risque élevé)

Inclus au moins 2 cas délicats : un ticket avec plusieurs demandes et un ticket qui doit être escaladé à un humain.

Prompt 4 : appliquer un changement de politique sans risque

Notre politique change : [décris le changement, par ex. « le délai de retour passe de 30 à 14 jours pour les articles soldés à partir du 1er novembre »].
1. Liste chaque section du Handbook et chaque playbook concernés.
2. Propose les modifications exactes, en énonçant la nouvelle règle une seule fois et en y renvoyant ailleurs.
3. Écris 3 nouveaux tests qui échoueraient avec l'ancienne règle et passeraient avec la nouvelle.

N'applique rien. Je relirai et publierai.

Prompt 5 : répétition générale avant la haute saison

Trouve nos tickets Yuma de [la semaine du BFCM de l'an dernier, par ex. du 24 novembre au 2 décembre]. Donne les 10 principaux types de demandes par volume et, pour chacun, dis-moi si le Handbook actuel contient un playbook qui le traite. Signale tout type de demande sans playbook ou sans tests.

Les règles à garder

• Claude propose, un humain publie. Ne laissez jamais une modification passer en ligne sans relecture.
• Ajoutez un test pour chaque nouveau cas limite avant de publier la correction.
• Enregistrez ces prompts dans un projet ou une skill Claude pour que n'importe qui dans l'équipe puisse les relancer.

Les outils de cette méthode

• Yuma AI
• Claude
• Shopify
• Gorgias