Definire se utilizzare Claude per l’instradamento dei ticket

Ecco alcuni indicatori chiave che suggeriscono di utilizzare un LLM come Claude invece degli approcci ML tradizionali per il tuo compito di classificazione:
I processi ML tradizionali richiedono dataset etichettati massivi. Il modello pre-addestrato di Claude può classificare efficacemente i ticket con solo poche dozzine di esempi etichettati, riducendo significativamente i tempi di preparazione dei dati e i costi.
Una volta stabilito un approccio ML tradizionale, modificarlo è un’impresa laboriosa e intensiva in termini di dati. D’altra parte, man mano che il tuo prodotto o le esigenze dei clienti evolvono, Claude può facilmente adattarsi ai cambiamenti nelle definizioni delle classi o alle nuove classi senza un’estesa ri-etichettatura dei dati di addestramento.
I modelli ML tradizionali spesso faticano con i dati non strutturati e richiedono un’estesa ingegneria delle caratteristiche. La comprensione avanzata del linguaggio di Claude consente una classificazione accurata basata su contenuto e contesto, piuttosto che affidarsi a strutture ontologiche rigide.
Gli approcci ML tradizionali spesso si affidano a modelli bag-of-words o semplici corrispondenze di pattern. Claude eccelle nel comprendere e applicare regole sottostanti quando le classi sono definite da condizioni piuttosto che da esempi.
Molti modelli ML tradizionali forniscono poche informazioni sul loro processo decisionale. Claude può fornire spiegazioni leggibili dall’uomo per le sue decisioni di classificazione, costruendo fiducia nel sistema di automazione e facilitando un facile adattamento se necessario.
I sistemi ML tradizionali spesso faticano con gli outlier e gli input ambigui, classificandoli erroneamente frequentemente o utilizzando una categoria catch-all predefinita. Le capacità di elaborazione del linguaggio naturale di Claude gli permettono di interpretare meglio il contesto e le sfumature nei ticket di supporto, riducendo potenzialmente il numero di ticket mal instradati o non classificati che richiedono intervento manuale.
Gli approcci ML tradizionali tipicamente richiedono modelli separati o processi di traduzione estesi per ogni lingua supportata. Le capacità multilingue di Claude gli permettono di classificare ticket in varie lingue senza la necessità di modelli separati o processi di traduzione estesi, semplificando il supporto per basi clienti globali.

Costruire e distribuire il tuo flusso di lavoro di supporto LLM

Comprendere il tuo approccio di supporto attuale

Prima di tuffarsi nell’automazione, è cruciale comprendere il tuo sistema di ticketing esistente. Inizia investigando come il tuo team di supporto attualmente gestisce l’instradamento dei ticket. Considera domande come:
  • Quali criteri vengono utilizzati per determinare quale SLA/offerta di servizio viene applicata?
  • L’instradamento dei ticket viene utilizzato per determinare a quale livello di supporto o specialista del prodotto va un ticket?
  • Ci sono regole automatizzate o flussi di lavoro già in atto? In quali casi falliscono?
  • Come vengono gestiti i casi limite o i ticket ambigui?
  • Come il team prioritizza i ticket?
Più conosci su come gli umani gestiscono certi casi, meglio sarai in grado di lavorare con Claude per svolgere il compito.

Definire le categorie di intento dell’utente

Un elenco ben definito di categorie di intento dell’utente è cruciale per una classificazione accurata dei ticket di supporto con Claude. La capacità di Claude di instradare i ticket efficacemente all’interno del tuo sistema è direttamente proporzionale a quanto ben definite sono le categorie del tuo sistema. Ecco alcune categorie di intento dell’utente di esempio e sottocategorie.
  • Problema hardware
  • Bug software
  • Problema di compatibilità
  • Problema di prestazioni
  • Reset password
  • Problemi di accesso all’account
  • Richieste di fatturazione
  • Modifiche abbonamento
  • Richieste di funzionalità
  • Domande di compatibilità prodotto
  • Informazioni sui prezzi
  • Richieste di disponibilità
  • Domande how-to
  • Assistenza nell’uso delle funzionalità
  • Consigli sulle migliori pratiche
  • Guida alla risoluzione dei problemi
  • Segnalazioni di bug
  • Richieste di funzionalità
  • Feedback generale o suggerimenti
  • Reclami
  • Richieste di stato ordine
  • Informazioni di spedizione
  • Resi e cambi
  • Modifiche ordine
  • Assistenza installazione
  • Richieste di aggiornamento
  • Programmazione manutenzione
  • Cancellazione servizio
  • Richieste sulla privacy dei dati
  • Segnalazioni di attività sospette
  • Assistenza funzionalità di sicurezza
  • Domande sulla conformità normativa
  • Richieste sui termini di servizio
  • Richieste di documentazione legale
  • Guasti critici del sistema
  • Problemi di sicurezza urgenti
  • Problemi sensibili al tempo
  • Richieste di formazione sul prodotto
  • Richieste di documentazione
  • Informazioni su webinar o workshop
  • Assistenza integrazione
  • Domande sull’uso delle API
  • Richieste di compatibilità con terze parti
Oltre all’intento, l’instradamento e la prioritizzazione dei ticket possono anche essere influenzati da altri fattori come urgenza, tipo di cliente, SLA o lingua. Assicurati di considerare altri criteri di instradamento quando costruisci il tuo sistema di instradamento automatizzato.

Stabilire criteri di successo

Lavora con il tuo team di supporto per definire criteri di successo chiari con benchmark misurabili, soglie e obiettivi. Ecco alcuni criteri standard e benchmark quando si utilizzano LLM per l’instradamento dei ticket di supporto:
Questa metrica valuta quanto coerentemente Claude classifica ticket simili nel tempo. È cruciale per mantenere l’affidabilità dell’instradamento. Misura questo testando periodicamente il modello con un set di input standardizzati e puntando a un tasso di coerenza del 95% o superiore.
Questo misura quanto velocemente Claude può adattarsi a nuove categorie o pattern di ticket che cambiano. Testa questo introducendo nuovi tipi di ticket e misurando il tempo necessario al modello per raggiungere un’accuratezza soddisfacente (es. >90%) su queste nuove categorie. Punta all’adattamento entro 50-100 ticket campione.
Questo valuta la capacità di Claude di instradare accuratamente ticket in più lingue. Misura l’accuratezza dell’instradamento attraverso diverse lingue, puntando a non più di un calo del 5-10% nell’accuratezza per le lingue non primarie.
Questo valuta le prestazioni di Claude su ticket inusuali o complessi. Crea un set di test di casi limite e misura l’accuratezza dell’instradamento, puntando ad almeno l’80% di accuratezza su questi input sfidanti.
Questo misura l’equità di Claude nell’instradamento attraverso diverse demografiche di clienti. Controlla regolarmente le decisioni di instradamento per potenziali bias, puntando a un’accuratezza di instradamento coerente (entro il 2-3%) attraverso tutti i gruppi di clienti.
In situazioni dove minimizzare il conteggio dei token è cruciale, questo criterio valuta quanto bene Claude performa con contesto minimo. Misura l’accuratezza dell’instradamento con quantità variabili di contesto fornito, puntando al 90%+ di accuratezza con solo il titolo del ticket e una breve descrizione.
Questo valuta la qualità e rilevanza delle spiegazioni di Claude per le sue decisioni di instradamento. I valutatori umani possono assegnare punteggi alle spiegazioni su una scala (es. 1-5), con l’obiettivo di raggiungere un punteggio medio di 4 o superiore.
Ecco alcuni criteri di successo comuni che possono essere utili indipendentemente dal fatto che venga utilizzato un LLM:
L’accuratezza dell’instradamento misura quanto spesso i ticket vengono correttamente assegnati al team o individuo appropriato al primo tentativo. Questo è tipicamente misurato come percentuale di ticket correttamente instradati sul totale dei ticket. I benchmark del settore spesso puntano al 90-95% di accuratezza, anche se questo può variare in base alla complessità della struttura di supporto.
Questa metrica traccia quanto velocemente i ticket vengono assegnati dopo essere stati inviati. Tempi di assegnazione più rapidi generalmente portano a risoluzioni più veloci e migliorata soddisfazione del cliente. I sistemi best-in-class spesso raggiungono tempi di assegnazione medi sotto i 5 minuti, con molti che puntano a un instradamento quasi istantaneo (che è possibile con implementazioni LLM).
Il tasso di re-instradamento indica quanto spesso i ticket devono essere riassegnati dopo l’instradamento iniziale. Un tasso più basso suggerisce un instradamento iniziale più accurato. Punta a un tasso di re-instradamento sotto il 10%, con sistemi top-performing che raggiungono tassi del 5% o meno.
Questo misura la percentuale di ticket risolti durante la prima interazione con il cliente. Tassi più alti indicano instradamento efficiente e team di supporto ben preparati. I benchmark del settore tipicamente vanno dal 70-75%, con i top performer che raggiungono tassi dell’80% o superiori.
Il tempo medio di gestione misura quanto tempo ci vuole per risolvere un ticket dall’inizio alla fine. Un instradamento efficiente può ridurre significativamente questo tempo. I benchmark variano ampiamente per settore e complessità, ma molte organizzazioni puntano a mantenere il tempo medio di gestione sotto le 24 ore per problemi non critici.
Spesso misurati attraverso sondaggi post-interazione, questi punteggi riflettono la felicità complessiva del cliente con il processo di supporto. Un instradamento efficace contribuisce a una soddisfazione più alta. Punta a punteggi CSAT del 90% o superiori, con i top performer che spesso raggiungono tassi di soddisfazione del 95%+.
Questo misura quanto spesso i ticket devono essere escalati a livelli superiori di supporto. Tassi di escalation più bassi spesso indicano un instradamento iniziale più accurato. Punta a un tasso di escalation sotto il 20%, con sistemi best-in-class che raggiungono tassi del 10% o meno.
Questa metrica guarda a quanti ticket gli agenti possono gestire efficacemente dopo aver implementato la soluzione di instradamento. Un instradamento migliorato dovrebbe aumentare la produttività. Misura questo tracciando i ticket risolti per agente per giorno o ora, puntando a un miglioramento del 10-20% dopo aver implementato un nuovo sistema di instradamento.
Questo misura la percentuale di potenziali ticket risolti attraverso opzioni self-service prima di entrare nel sistema di instradamento. Tassi più alti indicano un triage pre-instradamento efficace. Punta a un tasso di deflection del 20-30%, con i top performer che raggiungono tassi del 40% o superiori.
Questa metrica calcola il costo medio per risolvere ogni ticket di supporto. Un instradamento efficiente dovrebbe aiutare a ridurre questo costo nel tempo. Mentre i benchmark variano ampiamente, molte organizzazioni puntano a ridurre il costo per ticket del 10-15% dopo aver implementato un sistema di instradamento migliorato.

Scegliere il modello Claude giusto

La scelta del modello dipende dai compromessi tra costo, accuratezza e tempo di risposta. Molti clienti hanno trovato claude-3-5-haiku-20241022 un modello ideale per l’instradamento dei ticket, poiché è il modello più veloce e conveniente nella famiglia Claude 3 pur fornendo ancora risultati eccellenti. Se il tuo problema di classificazione richiede una profonda expertise in materia o un grande volume di categorie di intento con ragionamento complesso, potresti optare per il modello Sonnet più grande.

Costruire un prompt forte

L’instradamento dei ticket è un tipo di compito di classificazione. Claude analizza il contenuto di un ticket di supporto e lo classifica in categorie predefinite basate sul tipo di problema, urgenza, expertise richiesta o altri fattori rilevanti. Scriviamo un prompt di classificazione dei ticket. Il nostro prompt iniziale dovrebbe contenere i contenuti della richiesta dell’utente e restituire sia il ragionamento che l’intento.
Prova il generatore di prompt sulla Console Claude per far scrivere a Claude una prima bozza per te.
Ecco un esempio di prompt di classificazione per l’instradamento dei ticket:
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.
        """
Analizziamo i componenti chiave di questo prompt:
  • Utilizziamo le f-string di Python per creare il template del prompt, permettendo al ticket_contents di essere inserito nei tag <request>.
  • Diamo a Claude un ruolo chiaramente definito come sistema di classificazione che analizza attentamente il contenuto del ticket per determinare l’intento principale e le esigenze del cliente.
  • Istruiamo Claude sulla formattazione corretta dell’output, in questo caso per fornire il suo ragionamento e analisi all’interno dei tag <reasoning>, seguito dall’etichetta di classificazione appropriata all’interno dei tag <intent>.
  • Specifichiamo le categorie di intento valide: “Support, Feedback, Complaint”, “Order Tracking” e “Refund/Exchange”.
  • Includiamo alcuni esempi (a.k.a. few-shot prompting) per illustrare come dovrebbe essere formattato l’output, il che migliora accuratezza e coerenza.
Il motivo per cui vogliamo che Claude divida la sua risposta in varie sezioni di tag XML è così che possiamo usare espressioni regolari per estrarre separatamente il ragionamento e l’intento dall’output. Questo ci permette di creare passi successivi mirati nel flusso di lavoro di instradamento dei ticket, come utilizzare solo l’intento per decidere a quale persona instradare il ticket.

Distribuire il tuo prompt

È difficile sapere quanto bene funziona il tuo prompt senza distribuirlo in un ambiente di produzione di test e eseguire valutazioni. Costruiamo la struttura di distribuzione. Inizia definendo la firma del metodo per avvolgere la nostra chiamata a Claude. Prenderemo il metodo che abbiamo già iniziato a scrivere, che ha ticket_contents come input, e ora restituiremo una tupla di reasoning e intent come output. Se hai un’automazione esistente che utilizza ML tradizionale, vorrai seguire quella firma del metodo invece.
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"""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
Questo codice:
  • Importa la libreria Anthropic e crea un’istanza client utilizzando la tua chiave API.
  • Definisce una funzione classify_support_request che prende una stringa ticket_contents.
  • Invia il ticket_contents a Claude per la classificazione utilizzando il classification_prompt
  • Restituisce il reasoning e l’intent del modello estratti dalla risposta.
Poiché dobbiamo aspettare che l’intero testo di ragionamento e intento sia generato prima del parsing, impostiamo stream=False (il default).

Valutare il tuo prompt

Il prompting spesso richiede test e ottimizzazione per essere pronto per la produzione. Per determinare la prontezza della tua soluzione, valuta le prestazioni basandoti sui criteri di successo e le soglie che hai stabilito in precedenza. Per eseguire la tua valutazione, avrai bisogno di casi di test su cui eseguirla. Il resto di questa guida assume che tu abbia già sviluppato i tuoi casi di test.

Costruire una funzione di valutazione

La nostra valutazione di esempio per questa guida misura le prestazioni di Claude lungo tre metriche chiave:
  • Accuratezza
  • Costo per classificazione
Potresti dover valutare Claude su altri assi a seconda di quali fattori sono importanti per te. Per valutare questo, dobbiamo prima modificare lo script che abbiamo scritto e aggiungere una funzione per confrontare l’intento previsto con l’intento effettivo e calcolare la percentuale di previsioni corrette. Dobbiamo anche aggiungere funzionalità di calcolo dei costi e misurazione del tempo.
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"""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
Analizziamo le modifiche che abbiamo fatto:
  • Abbiamo aggiunto l’actual_intent dai nostri casi di test nel metodo classify_support_request e impostato un confronto per valutare se la classificazione dell’intento di Claude corrisponde alla nostra classificazione dell’intento golden.
  • Abbiamo estratto le statistiche di utilizzo per la chiamata API per calcolare il costo basato sui token di input e output utilizzati

Eseguire la tua valutazione

Una valutazione appropriata richiede soglie e benchmark chiari per determinare cosa è un buon risultato. Lo script sopra ci darà i valori runtime per accuratezza, tempo di risposta e costo per classificazione, ma avremmo ancora bisogno di soglie chiaramente stabilite. Per esempio:
  • Accuratezza: 95% (su 100 test)
  • Costo per classificazione: 50% di riduzione in media (su 100 test) dal metodo di instradamento attuale
Avere queste soglie ti permette di dire rapidamente e facilmente su larga scala, e con empirismo imparziale, quale metodo è migliore per te e quali cambiamenti potrebbero dover essere fatti per adattarsi meglio ai tuoi requisiti.

Migliorare le prestazioni

In scenari complessi, può essere utile considerare strategie aggiuntive per migliorare le prestazioni oltre alle tecniche standard di ingegneria dei prompt e alle strategie di implementazione dei guardrail. Ecco alcuni scenari comuni:

Utilizzare una gerarchia tassonomica per casi con 20+ categorie di intento

Man mano che il numero di classi cresce, il numero di esempi richiesti si espande anche, rendendo potenzialmente il prompt ingombrante. Come alternativa, puoi considerare l’implementazione di un sistema di classificazione gerarchico utilizzando una miscela di classificatori.
  1. Organizza i tuoi intenti in una struttura ad albero tassonomico.
  2. Crea una serie di classificatori ad ogni livello dell’albero, abilitando un approccio di instradamento a cascata.
Per esempio, potresti avere un classificatore di livello superiore che categorizza ampiamente i ticket in “Problemi Tecnici”, “Domande di Fatturazione” e “Richieste Generali”. Ognuna di queste categorie può poi avere il suo proprio sotto-classificatore per raffinare ulteriormente la classificazione.
  • Pro - maggiore sfumatura e accuratezza: Puoi creare prompt diversi per ogni percorso genitore, permettendo una classificazione più mirata e specifica per il contesto. Questo può portare a una migliore accuratezza e gestione più sfumata delle richieste dei clienti.
  • Contro - latenza aumentata: Tieni presente che classificatori multipli possono portare a una latenza aumentata, e raccomandiamo di implementare questo approccio con il nostro modello più veloce, Haiku.

Utilizzare database vettoriali e ricerca di similarità per gestire ticket altamente variabili

Nonostante fornire esempi sia il modo più efficace per migliorare le prestazioni, se le richieste di supporto sono altamente variabili, può essere difficile includere abbastanza esempi in un singolo prompt. In questo scenario, potresti impiegare un database vettoriale per fare ricerche di similarità da un dataset di esempi e recuperare gli esempi più rilevanti per una data query. Questo approccio, delineato in dettaglio nella nostra ricetta di classificazione, ha dimostrato di migliorare le prestazioni dal 71% di accuratezza al 93% di accuratezza.

Tenere conto specificamente dei casi limite previsti

Ecco alcuni scenari dove Claude potrebbe classificare erroneamente i ticket (potrebbero essercene altri che sono unici alla tua situazione). In questi scenari, considera di fornire istruzioni esplicite o esempi nel prompt di come Claude dovrebbe gestire il caso limite:
I clienti spesso esprimono bisogni indirettamente. Per esempio, “Sto aspettando il mio pacco da oltre due settimane ormai” potrebbe essere una richiesta indiretta per lo stato dell’ordine.
  • Soluzione: Fornisci a Claude alcuni esempi reali di clienti di questi tipi di richieste, insieme a quale sia l’intento sottostante. Puoi ottenere risultati ancora migliori se includi una logica di classificazione per intenti di ticket particolarmente sfumati, così che Claude possa generalizzare meglio la logica ad altri ticket.
Quando i clienti esprimono insoddisfazione, Claude potrebbe prioritizzare l’affrontare l’emozione piuttosto che risolvere il problema sottostante.
  • Soluzione: Fornisci a Claude indicazioni su quando prioritizzare il sentimento del cliente o no. Può essere qualcosa di semplice come “Ignora tutte le emozioni del cliente. Concentrati solo sull’analizzare l’intento della richiesta del cliente e quali informazioni il cliente potrebbe star chiedendo.”
Quando i clienti presentano problemi multipli in una singola interazione, Claude potrebbe avere difficoltà nell’identificare la preoccupazione primaria.
  • Soluzione: Chiarisci la prioritizzazione degli intenti così che Claude possa meglio classificare gli intenti estratti e identificare la preoccupazione primaria.

Integrare Claude nel tuo flusso di lavoro di supporto più ampio

Un’integrazione appropriata richiede che tu prenda alcune decisioni riguardo a come il tuo script di instradamento dei ticket basato su Claude si inserisce nell’architettura del tuo sistema di instradamento dei ticket più ampio. Ci sono due modi in cui potresti farlo:
  • Basato su push: Il sistema di ticket di supporto che stai utilizzando (es. Zendesk) attiva il tuo codice inviando un evento webhook al tuo servizio di instradamento, che poi classifica l’intento e lo instrада.
    • Questo approccio è più scalabile per il web, ma ha bisogno che tu esponga un endpoint pubblico.
  • Basato su pull: Il tuo codice tira per gli ultimi ticket basandosi su una data programmazione e li instrада al momento del pull.
    • Questo approccio è più facile da implementare ma potrebbe fare chiamate non necessarie al sistema di ticket di supporto quando la frequenza di pull è troppo alta o potrebbe essere eccessivamente lento quando la frequenza di pull è troppo bassa.
Per entrambi questi approcci, dovrai avvolgere il tuo script in un servizio. La scelta dell’approccio dipende da quali API fornisce il tuo sistema di ticketing di supporto.