Cette méthode a d'abord été publiée sur G2 AI blueprints.
Quel problème cela résout-il ?
Les tags du support comptent les tickets par catégorie, mais ils ne peuvent pas montrer qu'un pic de « problèmes de livraison » vient en réalité d'un seul SKU, d'une seule modification du catalogue ou d'un seul partenaire logistique. Les premiers signaux ressemblent à du bruit : quelques clients mentionnent le même problème étrange, les tickets sont tagués puis clôturés, et le schéma reste invisible jusqu'à ce qu'il apparaisse dans les remboursements, les rétrofacturations et les avis. À ce stade, des centaines de commandes peuvent être touchées.
Comment ça marche ?
- Traitez un petit groupe inhabituel comme une hypothèse, pas comme du bruit. Deux ou trois tickets sur le même article manquant, la même mauvaise variante ou le même composant abîmé suffisent pour commencer.
- Connectez Claude à Yuma via le Yuma MCP pour que Claude puisse rechercher et lire vos conversations de tickets en langage naturel.
- Lancez les prompts d'audit de cause profonde. Demandez à Claude d'analyser toutes les conversations des derniers jours, de trouver chaque mention du problème (y compris les reformulations et les autres langues), de les compter et de les regrouper par produit, SKU, date de commande, entrepôt et transporteur.
- Demandez chaque ID de ticket correspondant avec une citation d'une ligne. Vérifiez vous-même un échantillon et écartez les faux positifs avant que quoi que ce soit ne sorte de l'équipe support.
- Apportez le dossier de preuves aux ops, à la planification des stocks ou à votre 3PL : le comptage, les regroupements et des exemples de tickets. Laissez-les remonter à la cause profonde, qu'il s'agisse d'une modification du catalogue ou d'un lot, d'une erreur de préparation ou d'un problème de transporteur.
- Récupérez toutes les commandes concernées dans Shopify à partir du SKU et de la période identifiés.
- Configurez un playbook sortant Yuma pour envoyer un message à chaque client concerné par e-mail ou SMS avant que la plupart n'écrivent. Expliquez ce qui s'est passé, confirmez la correction et ajoutez un geste, comme une remise sur la prochaine commande.
- Ajoutez un playbook au Handbook pour que l'agent réponde de façon cohérente aux nouveaux tickets sur ce problème, puis relancez la requête chaque semaine pour vérifier que le volume baisse.
Quel est le plus grand bénéfice ?
Le support devient un système d'alerte précoce pour les opérations. Un schéma qui mettrait des semaines à ressortir via les tags et les tableaux de bord est prouvé en quelques jours à partir d'une poignée de plaintes, avec des preuves au niveau du ticket sur lesquelles les ops peuvent agir. Les clients concernés apprennent la correction avant même de remarquer le problème, ce qui transforme une vague de tickets, de remboursements et de mauvais avis en moment de fidélisation.
Que faut-il pour la mettre en place ?
Demandez toujours les ID de tickets et des citations, et ne transmettez jamais un comptage généré par l'IA sans en avoir vérifié un échantillon. Recherchez les reformulations et les autres langues, pas seulement des mots-clés exacts. Commencez par une période courte, puis élargissez-la une fois le schéma confirmé. Comparez avec une période de référence pour distinguer un vrai pic du bruit habituel. Copiez les prompts d'audit dans un projet ou un skill Claude pour que toute l'équipe puisse les relancer. Essayez-le sur vos propres tickets avec un essai gratuit de Yuma de 30 jours.
Quelles sont les limites ?
La méthode suppose que les tickets passent par Yuma avec l'accès MCP activé. Les résultats ne couvrent que les conversations dont Yuma dispose : les tickets traités en dehors sont ignorés. La correspondance par l'IA peut inclure des faux positifs ou manquer des mentions formulées de façon inhabituelle, la relecture humaine reste donc obligatoire. Confirmer la cause profonde dépend toujours des données des ops, des stocks et du 3PL, hors de l'outillage support. Les très longues périodes peuvent devoir être découpées en lots.
Les prompts de cette méthode
Utilisez-les avec Claude connecté à Yuma via le Yuma MCP. Remplacez tout ce qui est entre [crochets].
Prompt 1 : analyser et compter
Recherche toutes les conversations de tickets support dans Yuma du [date de début] au [date de fin].
Trouve chaque ticket où le client mentionne [le problème, par ex. « un article manquant dans un lot » / « mauvaise couleur reçue » / « couvercle abîmé »]. Inclus les reformulations, les fautes d'orthographe et les autres langues, pas seulement les mots-clés exacts.
Renvoie :
1. Le nombre total de tickets correspondants et le nombre de clients distincts.
2. Une répartition par produit, SKU ou variante, date de commande, entrepôt et transporteur, quand ces données sont disponibles.
3. Une comparaison avec la même durée juste avant le [date de début], pour que je voie s'il s'agit d'un pic ou d'un volume normal.
4. Ton verdict en deux phrases : s'agit-il d'un problème isolé ou d'un schéma qui mérite une escalade, et pourquoi.
Prompt 2 : les preuves à vérifier
Liste chaque ticket correspondant avec : ID du ticket, date, numéro de commande s'il est présent, SKU ou produit s'il est présent, et une citation d'une ligne du client qui montre le problème.
Marque toute correspondance dont tu n'es pas sûr comme « incertaine » pour que je la vérifie en premier. Ne supprime pas les correspondances incertaines.
Prompt 3 : synthèse pour l'escalade
Rédige une courte synthèse pour notre équipe ops, stocks et logistique :
- Ce que les clients signalent, avec leurs mots (2 ou 3 citations)
- Combien de tickets et de clients, sur quelle période, et comment cela se compare à la référence
- Autour de quels SKU, dates, entrepôts ou transporteurs les correspondances se regroupent
- Les pistes les plus probables pour trouver la cause profonde, uniquement d'après les tickets
- Les ID de tickets qu'ils peuvent ouvrir pour vérifier
Reste sous les 200 mots. Ne spécule pas au-delà de ce que montrent les tickets.
Prompt 4 : suivi hebdomadaire
Relance le Prompt 1 sur les 7 derniers jours. Compare avec la semaine précédant la mise en ligne de la correction et dis-moi si les mentions de [le problème] baissent, stagnent ou continuent d'augmenter.
Les règles à garder
- Vérifiez toujours vous-même un échantillon d'ID de tickets avant de partager des chiffres en dehors du support.
- Commencez par une période courte, puis élargissez-la une fois le schéma confirmé.
- Enregistrez ces prompts dans un projet ou un skill Claude pour que toute l'équipe puisse les relancer.
