Routage des tickets

Prérequis

• Une clé API Claude et le SDK Python installé
• Un accès à votre système de gestion de tickets de support existant, ainsi qu'une bonne connaissance de celui-ci
• Un échantillon de tickets de support historiques pour les tests

Déterminer s'il convient d'utiliser Claude pour le routage des tickets

Voici quelques indicateurs clés montrant que vous devriez utiliser un « large language model » (grand modèle de langage), ou LLM, comme Claude plutôt que des approches de ML traditionnelles pour votre tâche de classification :

Construire et déployer votre workflow de support basé sur un LLM

Comprendre votre approche de support actuelle

Avant d'automatiser, il est essentiel de comprendre votre système de gestion de tickets existant. Commencez par examiner comment votre équipe de support gère actuellement le routage des tickets.

Posez-vous des questions telles que :

• Quels critères sont utilisés pour déterminer quel SLA/quelle offre de service est appliqué(e) ?
• Le routage des tickets sert-il à déterminer vers quel niveau de support ou quel spécialiste produit un ticket est dirigé ?
• Existe-t-il déjà des règles ou des workflows automatisés ? Dans quels cas échouent-ils ?
• Comment les cas limites ou les tickets ambigus sont-ils traités ?
• Comment l'équipe priorise-t-elle les tickets ?

Plus vous en savez sur la manière dont les humains traitent certains cas, mieux vous pourrez travailler avec Claude pour accomplir la tâche.

Définir les catégories d'intention utilisateur

Une liste bien définie de catégories d'intention utilisateur est essentielle pour une classification précise des tickets de support avec Claude. La capacité de Claude à router efficacement les tickets au sein de votre système est directement proportionnelle à la qualité de définition des catégories de votre système.

Voici quelques exemples de catégories et sous-catégories d'intention utilisateur.

Outre 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. Veillez à prendre en compte d'autres critères de routage lors de la construction de votre système de routage automatisé.

Établir des critères de réussite

Travaillez avec votre équipe de support pour définir des critères de réussite clairs avec des références, des seuils et des objectifs mesurables.

Voici quelques critères et références standard lors de l'utilisation de LLM pour le routage des tickets de support :

Voici quelques critères de réussite courants qui peuvent être utiles, qu'un LLM soit utilisé ou non :

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é que claude-haiku-4-5-20251001 était un modèle idéal pour le routage des tickets, car il s'agit du modèle le plus rapide et le plus économique de la famille Claude 4, tout en offrant d'excellents résultats. Si votre problème de classification nécessite une expertise métier approfondie, un grand nombre de catégories d'intention ou un raisonnement complexe, vous pouvez opter pour le modèle Sonnet, plus grand.

Construire un prompt solide

Le routage des tickets est un type de tâche de classification. Claude analyse le contenu d'un ticket de support et le classe dans des catégories prédéfinies en fonction du type de problème, de l'urgence, de l'expertise requise ou d'autres facteurs pertinents.

Rédigez un prompt de classification de tickets. Le prompt initial doit contenir le contenu de la demande de l'utilisateur et renvoyer à la fois le raisonnement et l'intention.

Voici un exemple de prompt de classification pour le routage des tickets :

def classify_support_request(ticket_contents):
    # Définir le prompt pour la tâche de classification
    classification_prompt = f"""You will be acting as a customer support ticket classification system. Your task is to analyze customer support requests and output the appropriate classification intent for each request, along with your reasoning.

        Here is the customer support request you need to classify:

        <request>{ticket_contents}</request>

        Please carefully analyze the above request to determine the customer's core intent and needs. Consider what the customer is asking for has concerns about.

        First, write out your reasoning and analysis of how to classify this request inside <reasoning> tags.

        Then, output the appropriate classification label for the request inside a <intent> tag. The valid intents are:
        <intents>
        <intent>Support, Feedback, Complaint</intent>
        <intent>Order Tracking</intent>
        <intent>Refund/Exchange</intent>
        </intents>

        A request may have ONLY ONE applicable intent. Only include the intent that is most applicable to the request.

        As an example, consider the following request:
        <request>Hello! I had high-speed fiber internet installed on Saturday and my installer, Kevin, was absolutely fantastic! Where can I send my positive review? Thanks for your help!</request>

        Here is an example of how your output should be formatted (for the above example request):
        <reasoning>The user seeks information in order to leave positive feedback.</reasoning>
        <intent>Support, Feedback, Complaint</intent>

        Here are a few more examples:
        <examples>
        <example 2>
        Example 2 Input:
        <request>I wanted to write and personally thank you for the compassion you showed towards my family during my father's funeral this past weekend. Your staff was so considerate and helpful throughout this whole process; it really took a load off our shoulders. The visitation brochures were beautiful. We'll never forget the kindness you showed us and we are so appreciative of how smoothly the proceedings went. Thank you, again, Amarantha Hill on behalf of the Hill Family.</request>

        Example 2 Output:
        <reasoning>User leaves a positive review of their experience.</reasoning>
        <intent>Support, Feedback, Complaint</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        Example 9 Input:
        <request>Your website keeps sending ad-popups that block the entire screen. It took me twenty minutes just to finally find the phone number to call and complain. How can I possibly access my account information with all of these popups? Can you access my account for me, since your website is broken? I need to know what the address is on file.</request>

        Example 9 Output:
        <reasoning>The user requests help accessing their web account information.</reasoning>
        <intent>Support, Feedback, Complaint</intent>
        </example 9>

        Remember to always include your classification reasoning before your actual intent output. The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """

Voici les composants clés de ce prompt :

• Le modèle de prompt est une f-string Python, ce qui permet d'insérer ticket_contents dans les balises <request>.
• Le prompt donne à Claude un rôle clairement défini en tant que système de classification qui analyse soigneusement le contenu du ticket pour déterminer l'intention et les besoins fondamentaux du client.
• Le prompt indique à Claude le format de sortie approprié, en l'occurrence fournir son raisonnement et son analyse dans des balises <reasoning>, suivis de l'étiquette de classification appropriée dans des balises <intent>.
• Le prompt spécifie les catégories d'intention valides : « Support, Feedback, Complaint », « Order Tracking » et « Refund/Exchange ».
• Le prompt inclut quelques exemples (c'est-à-dire du few-shot prompting) pour illustrer le format attendu de la sortie, ce qui améliore la précision et la cohérence.

Le fait que Claude divise sa réponse en sections de balises XML distinctes vous permet d'utiliser des expressions régulières pour extraire indépendamment le raisonnement et l'intention de la sortie. Cela vous permet de créer des étapes suivantes ciblées dans le workflow de routage des tickets, par exemple en utilisant uniquement l'intention pour décider vers quelle personne router le ticket.

Déployer votre prompt

Il est difficile de savoir si votre prompt fonctionne bien sans le déployer dans un environnement de test de production et sans exécuter des évaluations.

Construisez la structure de déploiement. Commencez par définir la signature de la méthode qui encapsule l'appel à Claude. Étendez la méthode que vous avez commencé à écrire précédemment, qui prend ticket_contents en entrée, afin qu'elle renvoie désormais un tuple reasoning et intent en sortie. Si vous disposez d'une automatisation existante utilisant du ML traditionnel, vous devrez plutôt suivre cette signature de méthode.

import re

# Créer une instance du client de l'API Claude
client = anthropic.Anthropic()

# Définir le modèle par défaut
DEFAULT_MODEL = "claude-haiku-4-5-20251001"


def classify_support_request(ticket_contents):
    # Définir le prompt pour la tâche de classification
    classification_prompt = f"""You will be acting as a customer support ticket classification system.
        ...
        ... The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """
    # Envoyer le prompt à l'API pour classer la demande d'assistance.
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # Utiliser la bibliothèque d'expressions régulières de Python pour extraire `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # De même, extraire également l'`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 :

• Crée une instance de client à l'aide de votre clé API.
• Définit une fonction classify_support_request qui prend une chaîne ticket_contents.
• Envoie ticket_contents à Claude pour classification à l'aide de classification_prompt.
• Renvoie le reasoning et l'intent du modèle extraits de la réponse.

Comme l'intégralité du texte de raisonnement et d'intention doit être générée avant l'analyse, l'exemple définit 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 si votre solution est prête, évaluez ses performances en fonction des critères de réussite et des seuils que vous avez établis précédemment.

Pour exécuter votre évaluation, vous avez besoin de cas de test sur lesquels l'exécuter. Le reste de ce guide suppose que vous avez déjà développé vos cas de test.

Construire une fonction d'évaluation

L'exemple d'évaluation de ce guide mesure les performances de Claude selon trois métriques clés :

• Précision
• Coût par classification

Vous devrez peut-être évaluer Claude sur d'autres axes en fonction des facteurs qui sont importants pour vous.

Pour évaluer cela, modifiez d'abord le script pour ajouter une fonction qui compare l'intention prédite à l'intention réelle et calcule le pourcentage de prédictions correctes. Ajoutez ensuite les fonctionnalités de calcul des coûts et de mesure du temps.

import re

# Créer une instance du client de l'API Claude
client = anthropic.Anthropic()

# Définir le modèle par défaut
DEFAULT_MODEL = "claude-haiku-4-5-20251001"


def classify_support_request(request, actual_intent):
    # Définir le prompt pour la tâche de classification
    classification_prompt = f"""You will be acting as a customer support ticket classification system.
        ...
        ...The reasoning should be enclosed in <reasoning> tags and the intent in <intent> tags. Return only the reasoning and the intent.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        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

    # Utiliser la bibliothèque d'expressions régulières de Python pour extraire `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # De même, extraire également `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    # Vérifier si la prédiction du modèle est correcte.
    correct = actual_intent.strip() == intent.strip()

    # Renvoyer reasoning, intent, correct et usage.
    return reasoning, intent, correct, usage

Voici le détail des modifications :

• La méthode classify_support_request prend désormais l'actual_intent issu des cas de test et le compare à la classification d'intention de Claude pour évaluer s'ils correspondent.
• La méthode extrait les statistiques d'utilisation de l'appel API pour calculer le coût en fonction des tokens d'entrée et de sortie utilisés.

Exécuter votre évaluation

Une évaluation correcte nécessite des seuils et des références clairs pour déterminer ce qui constitue un bon résultat. Le script précédent renvoie les valeurs d'exécution pour la précision, le temps de réponse et le coût par classification, mais vous avez toujours besoin de seuils clairement établis. Par exemple :

• Précision : 95 % (sur 100 tests)
• Coût par classification : réduction de 50 % en moyenne (sur 100 tests) par rapport à la méthode de routage actuelle

Disposer de ces seuils vous permet de déterminer rapidement et facilement, à grande échelle et avec un empirisme impartial, quelle méthode vous convient le mieux et quels changements pourraient être nécessaires pour mieux répondre à vos exigences.

Améliorer les performances

Dans des scénarios complexes, il peut être utile d'envisager des stratégies supplémentaires pour améliorer les performances au-delà des techniques de prompt engineering standard et des stratégies de mise en place de garde-fous. Voici quelques scénarios courants :

Utiliser une hiérarchie taxonomique pour les cas comportant plus de 20 catégories d'intention

À mesure que le nombre de classes augmente, le nombre d'exemples requis augmente également, ce qui peut rendre le prompt difficile à gérer. Comme alternative, vous pouvez envisager de mettre en place un système de classification hiérarchique utilisant une combinaison de classificateurs.

1. Organisez vos intentions dans une structure arborescente 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 premier niveau qui catégorise globalement les tickets en « Technical Issues » (problèmes techniques), « Billing Questions » (questions de facturation) et « General Inquiries » (demandes générales). Chacune de ces catégories peut ensuite avoir son propre sous-classificateur pour affiner davantage la classification.

• Avantages - plus de nuance et de précision : vous pouvez créer des prompts différents pour chaque chemin parent, ce qui permet une classification plus ciblée et spécifique au contexte. Cela peut conduire à une meilleure précision et à un traitement plus nuancé des demandes des clients.

• Inconvénients - latence accrue : sachez que plusieurs classificateurs peuvent entraîner une « latency » (latence) accrue, et Anthropic recommande de mettre en œuvre cette approche avec le modèle le plus rapide, Haiku.

Utiliser des bases de données vectorielles et la recherche par similarité pour gérer des tickets très variables

Bien que fournir des exemples soit le moyen le plus efficace d'améliorer les performances, si les demandes de support sont très variables, il peut être difficile d'inclure suffisamment d'exemples dans un seul prompt.

Dans ce scénario, vous pourriez utiliser une base de données vectorielle pour effectuer des recherches par 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écrite en détail dans la recette de classification, a permis d'améliorer les performances de 71 % à 93 % de précision.

Tenir compte spécifiquement des cas limites attendus

Voici quelques scénarios dans lesquels Claude peut mal classifier des tickets (il peut en exister d'autres propres à votre situation). Dans ces scénarios, envisagez de fournir dans le prompt des instructions explicites ou des exemples sur la manière dont Claude doit gérer le cas limite :

Intégrer Claude dans votre workflow de support global

Une intégration correcte nécessite que vous preniez certaines décisions concernant la manière dont votre script de routage de tickets basé sur Claude s'intègre dans l'architecture de votre système de routage de tickets global. Il existe deux façons de procéder :

• Mode 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 route le ticket.
  • Cette approche est plus évolutive à l'échelle du web, mais nécessite que vous exposiez un point de terminaison public.
• Mode pull : votre code récupère les derniers tickets selon un calendrier donné et les route au moment de la récupération.
  • Cette approche est plus facile à mettre en œuvre, mais peut effectuer des appels inutiles au système de tickets de support lorsque la fréquence de récupération est trop élevée, ou être excessivement lente lorsque la fréquence de récupération est trop faible.

Pour chacune de ces approches, vous devez encapsuler votre script dans un service. Le choix de l'approche dépend des API fournies par votre système de gestion de tickets de support.