Définir s’il faut utiliser Claude pour le routage des tickets

Voici quelques indicateurs clés qui suggèrent que vous devriez utiliser un LLM comme Claude au lieu d’approches ML traditionnelles pour votre tâche de classification :
Les processus ML traditionnels nécessitent des jeux de données étiquetées massifs. Le modèle pré-entraîné de Claude peut efficacement classifier les tickets avec seulement quelques dizaines d’exemples étiquetés, réduisant significativement le temps de préparation des données et les coûts.
Une fois qu’une approche ML traditionnelle a été établie, la changer est une entreprise laborieuse et intensive en données. D’autre part, à mesure que votre produit ou les besoins de vos clients évoluent, Claude peut facilement s’adapter aux changements dans les définitions de classes ou aux nouvelles classes sans ré-étiquetage extensif des données d’entraînement.
Les modèles ML traditionnels ont souvent du mal avec les données non structurées et nécessitent une ingénierie de caractéristiques extensive. La compréhension avancée du langage de Claude permet une classification précise basée sur le contenu et le contexte, plutôt que de s’appuyer sur des structures ontologiques strictes.
Les approches ML traditionnelles s’appuient souvent sur des modèles de sac de mots ou une correspondance de motifs simple. Claude excelle dans la compréhension et l’application de règles sous-jacentes lorsque les classes sont définies par des conditions plutôt que par des exemples.
De nombreux modèles ML traditionnels fournissent peu d’aperçu sur leur processus de prise de décision. Claude peut fournir des explications lisibles par l’homme pour ses décisions de classification, construisant la confiance dans le système d’automatisation et facilitant l’adaptation facile si nécessaire.
Les systèmes ML traditionnels ont souvent du mal avec les valeurs aberrantes et les entrées ambiguës, les classifiant mal fréquemment ou les dirigeant vers une catégorie fourre-tout. Les capacités de traitement du langage naturel de Claude lui permettent de mieux interpréter le contexte et les nuances dans les tickets de support, réduisant potentiellement le nombre de tickets mal routés ou non classifiés qui nécessitent une intervention manuelle.
Les approches ML traditionnelles nécessitent typiquement des modèles séparés ou des processus de traduction extensifs pour chaque langue supportée. Les capacités multilingues de Claude lui permettent de classifier les tickets dans diverses langues sans le besoin de modèles séparés ou de processus de traduction extensifs, rationalisant le support pour les bases de clients globales.

Construire et déployer votre workflow de support LLM

Comprendre votre approche de support actuelle

Avant de plonger dans l’automatisation, il est crucial de comprendre votre système de ticketing existant. Commencez par enquêter sur la façon dont votre équipe de support gère actuellement le routage des tickets. Considérez des questions comme :
  • Quels critères sont utilisés pour déterminer quel SLA/offre de service est appliqué ?
  • Le routage des tickets est-il utilisé pour déterminer vers quel niveau de support ou spécialiste produit un ticket va ?
  • Y a-t-il des règles automatisées ou des workflows déjà en place ? Dans quels cas échouent-ils ?
  • Comment les cas limites ou les tickets ambigus sont-ils gérés ?
  • Comment l’équipe priorise-t-elle les tickets ?
Plus vous en savez sur la façon dont les humains gèrent certains cas, mieux vous serez capable de travailler avec Claude pour faire la tâche.

Définir les catégories d’intention utilisateur

Une liste bien définie de catégories d’intention utilisateur est cruciale pour une classification précise des tickets de support avec Claude. La capacité de Claude à router les tickets efficacement dans votre système est directement proportionnelle à la qualité de définition des catégories de votre système. Voici quelques exemples de catégories d’intention utilisateur et sous-catégories.
  • Problème matériel
  • Bug logiciel
  • Problème de compatibilité
  • Problème de performance
  • Réinitialisation de mot de passe
  • Problèmes d’accès au compte
  • Demandes de facturation
  • Changements d’abonnement
  • Demandes de fonctionnalités
  • Questions de compatibilité produit
  • Information de prix
  • Demandes de disponibilité
  • Questions comment faire
  • Assistance d’utilisation de fonctionnalités
  • Conseils de meilleures pratiques
  • Guidance de dépannage
  • Rapports de bugs
  • Demandes de fonctionnalités
  • Retour général ou suggestions
  • Plaintes
  • Demandes de statut de commande
  • Information d’expédition
  • Retours et échanges
  • Modifications de commande
  • Assistance d’installation
  • Demandes de mise à niveau
  • Planification de maintenance
  • Annulation de service
  • Demandes de confidentialité des données
  • Rapports d’activité suspecte
  • Assistance de fonctionnalités de sécurité
  • Pannes système critiques
  • Problèmes de sécurité urgents
  • Problèmes sensibles au temps
  • Demandes de formation produit
  • Demandes de documentation
  • Information de webinaire ou atelier
  • Assistance d’intégration
  • Questions d’utilisation API
  • Demandes de compatibilité tierce partie
En plus de l’intention, le routage et la priorisation des tickets peuvent également être influencés par d’autres facteurs tels que l’urgence, le type de client, les SLA, ou la langue. Assurez-vous de considérer d’autres critères de routage lors de la construction de votre système de routage automatisé.

Établir les critères de succès

Travaillez avec votre équipe de support pour définir des critères de succès clairs avec des benchmarks mesurables, des seuils, et des objectifs. Voici quelques critères standard et benchmarks lors de l’utilisation de LLMs pour le routage de tickets de support :
Cette métrique évalue à quel point Claude classifie de manière cohérente des tickets similaires au fil du temps. C’est crucial pour maintenir la fiabilité du routage. Mesurez ceci en testant périodiquement le modèle avec un ensemble d’entrées standardisées et visez un taux de cohérence de 95% ou plus.
Ceci mesure à quelle vitesse Claude peut s’adapter à de nouvelles catégories ou à des motifs de tickets changeants. Testez ceci en introduisant de nouveaux types de tickets et en mesurant le temps qu’il faut au modèle pour atteindre une précision satisfaisante (par exemple, >90%) sur ces nouvelles catégories. Visez une adaptation dans les 50-100 tickets d’échantillon.
Ceci évalue la capacité de Claude à router précisément les tickets dans plusieurs langues. Mesurez la précision de routage à travers différentes langues, visant pas plus qu’une baisse de 5-10% de précision pour les langues non-primaires.
Ceci évalue la performance de Claude sur des tickets inhabituels ou complexes. Créez un ensemble de test de cas limites et mesurez la précision de routage, visant au moins 80% de précision sur ces entrées difficiles.
Ceci mesure l’équité de Claude dans le routage à travers différentes démographies de clients. Auditez régulièrement les décisions de routage pour des biais potentiels, visant une précision de routage cohérente (dans les 2-3%) à travers tous les groupes de clients.
Dans les situations où minimiser le nombre de tokens est crucial, ce critère évalue à quel point Claude performe avec un contexte minimal. Mesurez la précision de routage avec des quantités variables de contexte fourni, visant 90%+ de précision avec juste le titre du ticket et une brève description.
Ceci évalue la qualité et la pertinence des explications de Claude pour ses décisions de routage. Les évaluateurs humains peuvent noter les explications sur une échelle (par exemple, 1-5), avec l’objectif d’atteindre un score moyen de 4 ou plus.
Voici quelques critères de succès communs qui peuvent être utiles indépendamment de l’utilisation d’un LLM :
La précision de routage mesure à quelle fréquence les tickets sont correctement assignés à l’équipe ou à l’individu approprié du premier coup. Ceci est typiquement mesuré comme un pourcentage de tickets correctement routés sur le total des tickets. Les benchmarks de l’industrie visent souvent 90-95% de précision, bien que cela puisse varier selon la complexité de la structure de support.
Cette métrique suit à quelle vitesse les tickets sont assignés après avoir été soumis. Des temps d’assignation plus rapides mènent généralement à des résolutions plus rapides et une satisfaction client améliorée. Les systèmes de classe mondiale atteignent souvent des temps d’assignation moyens de moins de 5 minutes, avec beaucoup visant un routage quasi-instantané (ce qui est possible avec les implémentations LLM).
Le taux de re-routage indique à quelle fréquence les tickets doivent être réassignés après le routage initial. Un taux plus bas suggère un routage initial plus précis. Visez un taux de re-routage en dessous de 10%, avec les systèmes les plus performants atteignant des taux aussi bas que 5% ou moins.
Ceci mesure le pourcentage de tickets résolus lors de la première interaction avec le client. Des taux plus élevés indiquent un routage efficace et des équipes de support bien préparées. Les benchmarks de l’industrie vont typiquement de 70-75%, avec les meilleurs performeurs atteignant des taux de 80% ou plus.
Le temps de traitement moyen mesure combien de temps il faut pour résoudre un ticket du début à la fin. Un routage efficace peut significativement réduire ce temps. Les benchmarks varient largement par industrie et complexité, mais de nombreuses organisations visent à maintenir le temps de traitement moyen sous 24 heures pour les problèmes non-critiques.
Souvent mesurés par des sondages post-interaction, ces scores reflètent le bonheur global du client avec le processus de support. Un routage efficace contribue à une satisfaction plus élevée. Visez des scores CSAT de 90% ou plus, avec les meilleurs performeurs atteignant souvent des taux de satisfaction de 95%+.
Ceci mesure à quelle fréquence les tickets doivent être escaladés vers des niveaux plus élevés de support. Des taux d’escalade plus bas indiquent souvent un routage initial plus précis. Efforcez-vous d’avoir un taux d’escalade en dessous de 20%, avec les systèmes de classe mondiale atteignant des taux de 10% ou moins.
Cette métrique examine combien de tickets les agents peuvent gérer efficacement après l’implémentation de la solution de routage. Un routage amélioré devrait augmenter la productivité. Mesurez ceci en suivant les tickets résolus par agent par jour ou heure, visant une amélioration de 10-20% après l’implémentation d’un nouveau système de routage.
Ceci mesure le pourcentage de tickets potentiels résolus par des options de libre-service avant d’entrer dans le système de routage. Des taux plus élevés indiquent un triage pré-routage efficace. Visez un taux de déviation de 20-30%, avec les meilleurs performeurs atteignant des taux de 40% ou plus.
Cette métrique calcule le coût moyen pour résoudre chaque ticket de support. Un routage efficace devrait aider à réduire ce coût au fil du temps. Bien que les benchmarks varient largement, de nombreuses organisations visent à réduire le coût par ticket de 10-15% après l’implémentation d’un système de routage amélioré.

Choisir le bon modèle Claude

Le choix du modèle dépend des compromis entre coût, précision, et temps de réponse. De nombreux clients ont trouvé claude-3-5-haiku-20241022 un modèle idéal pour le routage de tickets, car c’est le modèle le plus rapide et le plus rentable de la famille Claude 3 tout en délivrant d’excellents résultats. Si votre problème de classification nécessite une expertise approfondie du domaine ou un grand volume de catégories d’intention avec un raisonnement complexe, vous pouvez opter pour le modèle Sonnet plus large.

Construire un prompt solide

Le routage de tickets est un type de tâche de classification. Claude analyse le contenu d’un ticket de support et le classifie dans des catégories prédéfinies basées sur le type de problème, l’urgence, l’expertise requise, ou d’autres facteurs pertinents. Écrivons un prompt de classification de tickets. Notre prompt initial devrait contenir le contenu de la demande utilisateur et retourner à la fois le raisonnement et l’intention.
Essayez le générateur de prompts sur la Console Claude pour que Claude écrive un premier brouillon pour vous.
Voici un exemple de prompt de classification de routage de tickets :
def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""Vous agirez comme un système de classification de tickets de support client. Votre tâche est d'analyser les demandes de support client et de produire la classification d'intention appropriée pour chaque demande, ainsi que votre raisonnement.

        Voici la demande de support client que vous devez classifier :

        <request>{ticket_contents}</request>

        Veuillez analyser soigneusement la demande ci-dessus pour déterminer l'intention principale et les besoins du client. Considérez ce que le client demande et ses préoccupations.

        D'abord, écrivez votre raisonnement et analyse de comment classifier cette demande à l'intérieur des balises <reasoning>.

        Ensuite, produisez l'étiquette de classification appropriée pour la demande à l'intérieur d'une balise <intent>. Les intentions valides sont :
        <intents>
        <intent>Support, Retour d'information, Plainte</intent>
        <intent>Suivi de Commande</intent>
        <intent>Remboursement/Échange</intent>
        </intents>

        Une demande ne peut avoir QU'UNE SEULE intention applicable. N'incluez que l'intention qui est la plus applicable à la demande.

        Comme exemple, considérez la demande suivante :
        <request>Bonjour ! J'ai eu internet fibre haute vitesse installé samedi et mon installateur, Kevin, était absolument fantastique ! Où puis-je envoyer mon avis positif ? Merci pour votre aide !</request>

        Voici un exemple de comment votre sortie devrait être formatée (pour l'exemple de demande ci-dessus) :
        <reasoning>L'utilisateur cherche des informations pour laisser un retour positif.</reasoning>
        <intent>Support, Retour d'information, Plainte</intent>

        Voici quelques exemples supplémentaires :
        <examples>
        <example 2>
        Exemple 2 Entrée :
        <request>Je voulais écrire et vous remercier personnellement pour la compassion que vous avez montrée envers ma famille pendant les funérailles de mon père ce week-end passé. Votre personnel était si attentionné et serviable tout au long de ce processus ; cela nous a vraiment enlevé un poids des épaules. Les brochures de visite étaient magnifiques. Nous n'oublierons jamais la gentillesse que vous nous avez montrée et nous sommes si reconnaissants de la façon dont les procédures se sont déroulées sans accroc. Merci, encore, Amarantha Hill au nom de la Famille Hill.</request>

        Exemple 2 Sortie :
        <reasoning>L'utilisateur laisse un avis positif de son expérience.</reasoning>
        <intent>Support, Retour d'information, Plainte</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        Exemple 9 Entrée :
        <request>Votre site web continue d'envoyer des pop-ups publicitaires qui bloquent tout l'écran. Il m'a fallu vingt minutes juste pour finalement trouver le numéro de téléphone pour appeler et me plaindre. Comment puis-je possiblement accéder aux informations de mon compte avec tous ces pop-ups ? Pouvez-vous accéder à mon compte pour moi, puisque votre site web est cassé ? J'ai besoin de savoir quelle est l'adresse en dossier.</request>

        Exemple 9 Sortie :
        <reasoning>L'utilisateur demande de l'aide pour accéder aux informations de son compte web.</reasoning>
        <intent>Support, Retour d'information, Plainte</intent>
        </example 9>

        Rappelez-vous de toujours inclure votre raisonnement de classification avant votre sortie d'intention actuelle. Le raisonnement devrait être enfermé dans des balises <reasoning> et l'intention dans des balises <intent>. Retournez seulement le raisonnement et l'intention.
        """
Décomposons les composants clés de ce prompt :
  • Nous utilisons les f-strings Python pour créer le template de prompt, permettant au ticket_contents d’être inséré dans les balises <request>.
  • Nous donnons à Claude un rôle clairement défini comme système de classification qui analyse soigneusement le contenu du ticket pour déterminer l’intention principale et les besoins du client.
  • Nous instruisons Claude sur le formatage de sortie approprié, dans ce cas pour fournir son raisonnement et analyse à l’intérieur des balises <reasoning>, suivi par l’étiquette de classification appropriée à l’intérieur des balises <intent>.
  • Nous spécifions les catégories d’intention valides : “Support, Retour d’information, Plainte”, “Suivi de Commande”, et “Remboursement/Échange”.
  • Nous incluons quelques exemples (a.k.a. prompting few-shot) pour illustrer comment la sortie devrait être formatée, ce qui améliore la précision et la cohérence.
La raison pour laq uelle nous voulons que Claude divise sa réponse en diverses sections de balises XML est pour que nous puissions utiliser des expressions régulières pour extraire séparément le raisonnement et l’intention de la sortie. Cela nous permet de créer des étapes suivantes ciblées dans le workflow de routage de tickets, comme utiliser seulement l’intention pour décider vers quelle personne router le ticket.

Déployer votre prompt

Il est difficile de savoir à quel point votre prompt fonctionne sans le déployer dans un environnement de production de test et exécuter des évaluations. Construisons la structure de déploiement. Commencez par définir la signature de méthode pour envelopper notre appel à Claude. Nous prendrons la méthode que nous avons déjà commencé à écrire, qui a ticket_contents comme entrée, et maintenant retourner un tuple de reasoning et intent comme sortie. Si vous avez une automatisation existante utilisant le ML traditionnel, vous voudrez suivre cette signature de méthode à la place.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    classification_prompt = f"""Vous agirez comme un système de classification de tickets de support client.
        ...
        ... Le raisonnement devrait être enfermé dans des balises <reasoning> et l'intention dans des balises <intent>. Retournez seulement le raisonnement et l'intention.
        """
    # Send the prompt to the API to classify the support request.
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    return reasoning, intent
Ce code :
  • Importe la bibliothèque Anthropic et crée une instance client utilisant votre clé API.
  • Définit une fonction classify_support_request qui prend une chaîne ticket_contents.
  • Envoie le ticket_contents à Claude pour classification utilisant le classification_prompt
  • Retourne le reasoning et l’intent du modèle extraits de la réponse.
Puisque nous devons attendre que tout le texte de raisonnement et d’intention soit généré avant l’analyse, nous définissons stream=False (la valeur par défaut).

Évaluer votre prompt

Le prompting nécessite souvent des tests et une optimisation pour être prêt pour la production. Pour déterminer la préparation de votre solution, évaluez la performance basée sur les critères de succès et seuils que vous avez établis plus tôt. Pour exécuter votre évaluation, vous aurez besoin de cas de test pour l’exécuter. Le reste de ce guide assume que vous avez déjà développé vos cas de test.

Construire une fonction d’évaluation

Notre exemple d’évaluation pour ce guide mesure la performance de Claude le long de trois métriques clés :
  • Précision
  • Coût par classification
Vous pourriez avoir besoin d’évaluer Claude sur d’autres axes selon les facteurs qui sont importants pour vous. Pour évaluer ceci, nous devons d’abord modifier le script que nous avons écrit et ajouter une fonction pour comparer l’intention prédite avec l’intention actuelle et calculer le pourcentage de prédictions correctes. Nous devons aussi ajouter la fonctionnalité de calcul de coût et de mesure de temps.
import anthropic
import re

# Create an instance of the Claude API client
client = anthropic.Anthropic()

# Set the default model
DEFAULT_MODEL="claude-3-5-haiku-20241022"

def classify_support_request(request, actual_intent):
    # Define the prompt for the classification task
    classification_prompt = f"""Vous agirez comme un système de classification de tickets de support client.
        ...
        ...Le raisonnement devrait être enfermé dans des balises <reasoning> et l'intention dans des balises <intent>. Retournez seulement le raisonnement et l'intention.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # Get the usage statistics for the API call for how many input and output tokens were used.
    reasoning_and_intent = message.content[0].text

    # Use Python's regular expressions library to extract `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # Similarly, also extract the `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

      # Check if the model's prediction is correct.
    correct = actual_intent.strip() == intent.strip()

    # Return the reasoning, intent, correct, and usage.
    return reasoning, intent, correct, usage
Décomposons les modifications que nous avons faites :
  • Nous avons ajouté l’actual_intent de nos cas de test dans la méthode classify_support_request et mis en place une comparaison pour évaluer si la classification d’intention de Claude correspond à notre classification d’intention dorée.
  • Nous avons extrait les statistiques d’utilisation pour l’appel API pour calculer le coût basé sur les tokens d’entrée et de sortie utilisés

Exécuter votre évaluation

Une évaluation appropriée nécessite des seuils et benchmarks clairs pour déterminer ce qui est un bon résultat. Le script ci-dessus nous donnera les valeurs d’exécution pour la précision, le temps de réponse, et le coût par classification, mais nous aurions encore besoin de seuils clairement établis. Par exemple :
  • Précision : 95% (sur 100 tests)
  • Coût par classification : 50% de réduction en moyenne (sur 100 tests) par rapport à la méthode de routage actuelle
Avoir ces seuils vous permet de dire rapidement et facilement à grande échelle, et avec un empirisme impartial, quelle méthode est la meilleure pour vous et quels changements pourraient être nécessaires pour mieux s’adapter à vos exigences.

Améliorer la performance

Dans des scénarios complexes, il peut être utile de considérer des stratégies supplémentaires pour améliorer la performance au-delà des techniques d’ingénierie de prompts standard et des stratégies d’implémentation de garde-fous. Voici quelques scénarios communs :

Utiliser une hiérarchie taxonomique pour les cas avec 20+ catégories d’intention

À mesure que le nombre de classes grandit, le nombre d’exemples requis s’étend aussi, rendant potentiellement le prompt difficile à manier. Comme alternative, vous pouvez considérer implémenter un système de classification hiérarchique utilisant un mélange de classificateurs.
  1. Organisez vos intentions dans une structure d’arbre taxonomique.
  2. Créez une série de classificateurs à chaque niveau de l’arbre, permettant une approche de routage en cascade.
Par exemple, vous pourriez avoir un classificateur de niveau supérieur qui catégorise largement les tickets en “Problèmes Techniques,” “Questions de Facturation,” et “Demandes Générales.” Chacune de ces catégories peut alors avoir son propre sous-classificateur pour affiner davantage la classification.
  • Avantages - plus grande nuance et précision : Vous pouvez créer différents prompts pour chaque chemin parent, permettant une classification plus ciblée et spécifique au contexte. Cela peut mener à une précision améliorée et une gestion plus nuancée des demandes client.
  • Inconvénients - latence augmentée : Soyez avisé que plusieurs classificateurs peuvent mener à une latence augmentée, et nous recommandons d’implémenter cette approche avec notre modèle le plus rapide, Haiku.

Utiliser des bases de données vectorielles et la recherche de similarité pour gérer des tickets hautement variables

Malgré que fournir des exemples soit la façon la plus efficace d’améliorer la performance, si les demandes de support sont hautement variables, il peut être difficile d’inclure assez d’exemples dans un seul prompt. Dans ce scénario, vous pourriez employer une base de données vectorielle pour faire des recherches de similarité à partir d’un jeu de données d’exemples et récupérer les exemples les plus pertinents pour une requête donnée. Cette approche, détaillée dans notre recette de classification, a été montrée pour améliorer la performance de 71% de précision à 93% de précision.

Tenir compte spécifiquement des cas limites attendus

Voici quelques scénarios où Claude peut mal classifier les tickets (il peut y en avoir d’autres qui sont uniques à votre situation). Dans ces scénarios, considérez fournir des instructions explicites ou des exemples dans le prompt de comment Claude devrait gérer le cas limite :
Les clients expriment souvent des besoins indirectement. Par exemple, “J’attends mon colis depuis plus de deux semaines maintenant” peut être une demande indirecte de statut de commande.
  • Solution : Fournissez à Claude quelques exemples réels de clients de ces types de demandes, ainsi que quelle est l’intention sous-jacente. Vous pouvez obtenir de meilleurs résultats encore si vous incluez une justification de classification pour des intentions de tickets particulièrement nuancées, pour que Claude puisse mieux généraliser la logique à d’autres tickets.
Quand les clients expriment de l’insatisfaction, Claude peut prioriser adresser l’émotion plutôt que résoudre le problème sous-jacent.
  • Solution : Fournissez à Claude des directions sur quand prioriser le sentiment client ou non. Cela peut être quelque chose d’aussi simple que “Ignorez toutes les émotions client. Concentrez-vous seulement sur l’analyse de l’intention de la demande du client et quelle information le client pourrait demander.”
Quand les clients présentent plusieurs problèmes dans une seule interaction, Claude peut avoir de la difficulté à identifier la préoccupation principale.
  • Solution : Clarifiez la priorisation des intentions pour que Claude puisse mieux classer les intentions extraites et identifier la préoccupation principale.

Intégrer Claude dans votre workflow de support plus large

Une intégration appropriée nécessite que vous preniez quelques décisions concernant comment votre script de routage de tickets basé sur Claude s’intègre dans l’architecture de votre système de routage de tickets plus large. Il y a deux façons de faire ceci :
  • Basé sur push : Le système de tickets de support que vous utilisez (par exemple Zendesk) déclenche votre code en envoyant un événement webhook à votre service de routage, qui classifie ensuite l’intention et la route.
    • Cette approche est plus web-scalable, mais nécessite que vous exposiez un endpoint public.
  • Basé sur pull : Votre code tire pour les derniers tickets basé sur un horaire donné et les route au moment du pull.
    • Cette approche est plus facile à implémenter mais pourrait faire des appels inutiles au système de tickets de support quand la fréquence de pull est trop élevée ou pourrait être trop lente quand la fréquence de pull est trop basse.
Pour l’une ou l’autre de ces approches, vous devrez envelopper votre script dans un service. Le choix d’approche dépend de quelles APIs votre système de ticketing de support fournit.