journal

Esempio svolto: retrieval lato agente per un team di supporto

Un esempio svolto illustrativo di retrieval lato agente per un team di supporto. Team e numeri sono ipotesi, non un risultato di un cliente. Nessun bot per il cliente.

joseph j.founding engineer4 min di lettura

Esempio svolto. Questo è un esempio svolto illustrativo, non un risultato di un cliente: il team di supporto e i suoi numeri sono ipotesi. Mostra il retrieval lato agente, uno strumento che si colloca dietro l'agente di supporto, non davanti al cliente. L'agente pone una domanda in linguaggio semplice, riceve una risposta con fonte citata, resta nel ticket e invia la risposta.

Immagina un team CX e-commerce di media dimensione che vuole muovere il tempo di prima risposta sui ticket complessi. Questo post spiega in cosa consiste il design, cosa misurare e cosa non fa. Non riporta alcun risultato, perché non c'è nessun cliente dietro.

Il team è ipotetico, e lo è ogni numero che potresti aspettarti qui. Il design si basa sul lavoro di customer support che descriviamo su /ai-for/customer-support. Un'altra cosa subito: è solo assistenza all'agente. Nessun chatbot parla con un cliente in nessun momento.

#Cosa rallentava gli agenti?

Le risposte esistono. Trovarle non scala. Un ticket complesso significa che un agente apre la cronologia di Zendesk, un documento di prodotto e un PDF sulla policy di spedizione, poi mette insieme la risposta a mano. Anni di ticket passati contengono il precedente, e nessuno può cercare in quell'archivio nel tempo in cui un cliente aspetta.

Così la prima risposta restava in coda mentre l'agente cercava. Quell'attesa è il numero su cui il responsabile del supporto viene interrogato. Il tempo di prima risposta, non il volume di ticket.

L'ia può ridurre il tempo di prima risposta nel supporto clienti senza un chatbot?

Sì, è l'obiettivo. Uno strumento di retrieval interno permette agli agenti di fare domande in linguaggio semplice su ticket storici, documenti di prodotto e PDF di policy e ricevere una risposta con fonte citata. L'agente continua a scrivere e inviare la risposta. Un team misurerebbe il tempo di prima risposta sui ticket complessi prima e dopo, senza bot rivolti al cliente.

#In cosa consiste il design?

Uno strumento di retrieval interno su tre fonti: ticket storici, i documenti di prodotto e i PDF sulla policy di spedizione. Un agente digita una domanda come la porrebbe a un collega senior. La risposta torna con la fonte citata, così l'agente può verificarla prima che arrivi a un cliente.

  • Ricerca su tutti i ticket passati in un'unica query, non scheda per scheda.
  • Risposte con fonte citata, così l'agente verifica la fonte invece di fidarsi di una scatola nera.
  • Risposte basate sui PDF della policy di spedizione, dove vivono davvero le regole per i casi limite.
  • L'agente resta nel ticket. Lo strumento non risponde mai a un cliente in autonomia.

Formare il team di supporto fa parte del design, non è un passaggio di consegne alla fine. Il KPI da concordare è il tempo di prima risposta sui ticket complessi, misurato prima e dopo. Cosa muova lo diranno i tuoi dati, non questo post.

#Non è lo stesso di un bot di deflessione?

No, e la differenza è il punto centrale. Una strategia di deflection cerca di ridurre il volume di ticket rispondendo direttamente AI clienti. Questo design punta a un altro numero: il tempo di prima risposta, mettendo il retrieval dietro l'agente. Il cliente continua a parlare con una persona.

We are

Stennir costruisce AI che si colloca dietro i tuoi agenti di supporto: retrieval, smistamento, bozza-e-revisione, misurata sul tempo di prima risposta e sulla qualità della risoluzione.

We aren't

Stennir non è un fornitore di chatbot rivolti al cliente e non vende la deflessione come obiettivo; l'agente resta nel ticket e i tuoi clienti continuano a parlare con persone.

Strumenti come Zendesk AI, intercom fin o i suggerimenti di gorgias funzionano dentro le proprie mura: le tue macro, i tuoi articoli di aiuto, le tue risposte salvate. Questo design aggiunge il retrieval sul resto. I ticket storici, i documenti di prodotto, i PDF sulla policy di spedizione, i runbook. è lì che si nascondono le risposte AI ticket complessi.

I KPI che spostiamo sono il tempo di prima risposta e la qualità della risoluzione sui ticket complessi, non l'organico. Lo diciamo dal primo giorno e lo misuriamo.

— joseph j., founding engineer presso stennir

#Funzionerebbe per il nostro team di supporto?

Il test di idoneità è semplice. Le tue risposte vivono già in posti lenti da cercare? Anni di ticket, una pila di PDF di policy, documenti di prodotto che cambiano. Se gli agenti perdono minuti a cercare prima di ogni risposta complessa, è quel tempo che il retrieval vuole restituire.

Questo design rientra nel nostro lavoro di consulenza ia, con la formazione del team di supporto integrata dal lato formazione ia. Se vuoi vedere come si incastrano i pezzi, il journal ha altri esempi svolti come questo.

Se i tuoi agenti cercano risposte prima di ogni risposta complessa, è il ritardo a cui punta questo design. raccontaci cosa stai costruendo e ti diremo se il retrieval è la leva giusta, oppure no.

Dicci quale attività richiede più tempo.

30 minuti. Nessuna preparazione. Ti diremo con onestà se l'AI può aiutare e da dove iniziare.