Routage des tickets

Déterminez si vous devez utiliser Claude pour le routage des tickets

Voici quelques indicateurs clés montrant que vous devriez utiliser un LLM comme Claude à la place des approches ML traditionnelles pour votre tâche de classification :

Construisez et déployez votre flux de travail d'assistance LLM

Comprenez votre approche actuelle du support

Avant de vous lancer 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 d'assistance gère actuellement le routage des tickets.

Posez-vous 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 quel niveau d'assistance ou quel spécialiste produit reçoit le ticket ?
• Y a-t-il des règles ou des flux de travail automatisés 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 saurez sur la façon dont les humains gèrent certains cas, mieux vous pourrez travailler avec Claude pour accomplir la tâche.

Définissez les catégories d'intention de l'utilisateur

Une liste bien définie de catégories d'intention de l'utilisateur est cruciale pour une classification précise des tickets d'assistance avec Claude. La capacité de Claude à acheminer les tickets efficacement dans votre système est directement proportionnelle à la qualité de la définition des catégories de votre système.

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

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é.

Établissez les critères de succès

Travaillez avec votre équipe d'assistance pour définir des critères de succès clairs avec des repères mesurables, des seuils et des objectifs.

Voici quelques critères et repères standards lors de l'utilisation d'LLM pour le routage des tickets d'assistance :

Voici quelques critères de succès courants qui peuvent être utiles indépendamment du fait qu'un LLM soit utilisé ou non :

Choisissez le bon modèle Claude

Le choix du modèle dépend des compromis entre le coût, la précision et le temps de réponse.

De nombreux clients ont trouvé claude-haiku-4-5-20251001 un modèle idéal pour le routage des tickets, car c'est le modèle le plus rapide et le plus rentable de la famille Claude 4 tout en offrant d'excellents résultats. Si votre problème de classification nécessite une expertise approfondie en matière de sujet ou un grand volume de catégories d'intention avec un raisonnement complexe, vous pouvez opter pour le modèle Sonnet plus grand.

Construisez une invite solide

Le routage des tickets est un type de tâche de classification. Claude analyse le contenu d'un ticket d'assistance 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.

Écrivons une invite de classification de tickets. Notre invite initiale doit contenir le contenu de la demande de l'utilisateur et retourner à la fois le raisonnement et l'intention.

Voici un exemple d'invite de classification de routage de tickets :

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    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.
        """

Décomposons les composants clés de cette invite :

• Nous utilisons les f-strings Python pour créer le modèle d'invite, permettant à ticket_contents d'être inséré dans les balises <request>.
• Nous donnons à Claude un rôle clairement défini en tant que système de classification qui analyse attentivement le contenu du ticket pour déterminer l'intention et les besoins fondamentaux du client.
• Nous instruisons Claude sur le formatage approprié de la sortie, dans ce cas pour fournir son raisonnement et son analyse à l'intérieur des balises <reasoning>, suivis de l'étiquette de classification appropriée à l'intérieur des balises <intent>.
• Nous spécifions les catégories d'intention valides : « Support, Feedback, Complaint », « Order Tracking » et « Refund/Exchange ».
• Nous incluons quelques exemples (alias few-shot prompting) pour illustrer comment la sortie doit être formatée, ce qui améliore la précision et la cohérence.

La raison pour laquelle nous voulons que Claude divise sa réponse en différentes sections de balises XML est que nous pouvons 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 flux de travail de routage des tickets, comme l'utilisation uniquement de l'intention pour décider à qui acheminer le ticket.

Déployez votre invite

Il est difficile de savoir comment fonctionne bien votre invite sans la déployer dans un environnement de test en production 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-haiku-4-5-20251001"

def classify_support_request(ticket_contents):
    # Define the prompt for the classification task
    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.
        """
    # 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 en 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 en utilisant le classification_prompt
• Retourne le reasoning et 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 d'analyser, nous définissons stream=False (la valeur par défaut).

Évaluez votre invite

L'élaboration d'invites nécessite souvent des tests et une optimisation pour être prête pour la production. Pour déterminer la préparation de votre solution, évaluez les performances en fonction des critères de succès et des seuils que vous avez établis précédemment.

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

Construisez une fonction d'évaluation

Notre exemple d'évaluation pour 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, nous devons d'abord modifier le script que nous avons écrit et ajouter une fonction pour comparer l'intention prédite avec l'intention réelle et calculer le pourcentage de prédictions correctes. Nous devons également ajouter la fonctionnalité de calcul des coûts et de mesure du temps.

import anthropic
import re

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

# Set the default model
DEFAULT_MODEL="claude-haiku-4-5-20251001"

def classify_support_request(request, actual_intent):
    # Define the prompt for the classification task
    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,
        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 apportées :

• Nous avons ajouté le actual_intent de nos cas de test dans la méthode classify_support_request et configuré 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 en fonction des jetons d'entrée et de sortie utilisés

Exécutez votre évaluation

Une évaluation appropriée nécessite des seuils et des repères 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 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 à votre méthode de routage actuelle

Avoir ces seuils vous permet de déterminer 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 répondre à vos exigences.

Améliorez les performances

Dans les scénarios complexes, il peut être utile de considérer des stratégies supplémentaires pour améliorer les performances au-delà des techniques standard d'ingénierie d'invites et des stratégies de mise en œuvre de garde-fous. Voici quelques scénarios courants :

Utilisez une hiérarchie taxonomique pour les cas avec 20+ catégories d'intention

À mesure que le nombre de classes augmente, le nombre d'exemples requis augmente également, ce qui peut rendre l'invite difficile à gérer. Comme alternative, vous pouvez envisager de mettre en œuvre un système de classification hiérarchique en 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 haut niveau 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 de nuance et de précision : Vous pouvez créer différentes invites pour chaque chemin parent, permettant une classification plus ciblée et contextuelle. Cela peut conduire à une précision améliorée et à une gestion plus nuancée des demandes des clients.

• Inconvénients - latence accrue : Sachez que plusieurs classificateurs peuvent entraîner une latence accrue, et nous recommandons de mettre en œuvre cette approche avec notre modèle le plus rapide, Haiku.

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

Malgré le fait que fournir des exemples soit le moyen le plus efficace d'améliorer les performances, si les demandes d'assistance sont hautement variables, il peut être difficile d'inclure suffisamment d'exemples dans une seule invite.

Dans ce scénario, vous pourriez utiliser une base de données vectorielle pour effectuer des recherches de similarité à partir d'un ensemble 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 notre recette de classification, s'est avérée améliorer les performances de 71 % de précision à 93 % de précision.

Tenez compte spécifiquement des cas limites attendus

Voici quelques scénarios où Claude peut mal classer les tickets (il peut y en avoir d'autres qui sont uniques à votre situation). Dans ces scénarios, envisagez de fournir des instructions explicites ou des exemples dans l'invite de la façon dont Claude doit gérer le cas limite :

Intégrez Claude dans votre flux de travail d'assistance plus large

Une intégration appropriée nécessite que vous preniez certaines décisions concernant la façon dont votre script de routage des tickets basé sur Claude s'intègre dans l'architecture de votre système de routage des tickets plus large. Il y a deux façons de procéder :

• Basé sur le push : Le système de tickets d'assistance que vous utilisez (par exemple Zendesk) déclenche votre code en envoyant un événement webhook à votre service de routage, qui classe ensuite l'intention et l'achemine.
  • Cette approche est plus évolutive sur le web, mais vous devez exposer un point de terminaison public.
• Basé sur le pull : Votre code extrait les derniers tickets en fonction d'un calendrier donné et les achemine au moment du pull.
  • Cette approche est plus facile à mettre en œuvre mais pourrait faire des appels inutiles au système de tickets d'assistance lorsque la fréquence de pull est trop élevée ou pourrait être excessivement lente lorsque la fréquence de pull est trop faible.

Pour l'une de ces approches, vous devrez envelopper votre script dans un service. Le choix de l'approche dépend des API que votre système de ticketing d'assistance fournit.