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 e riceve una risposta con fonte citata in un'unica query. nessun bot rivolto al cliente. l'agente resta nel ticket e invia la risposta.
ne abbiamo consegnato uno a un team cx e-commerce di media dimensione. il tempo di prima risposta sui ticket complessi è sceso del 40%. questo post è la prova concreta: cosa abbiamo costruito, cosa è cambiato e cosa no.
il cliente è anonimo. il 40% è il risultato effettivamente ottenuto dall'incarico, basato sul lavoro di customer support che descriviamo su /ai-for/customer-support. un'altra cosa da chiarire subito: si è trattato solo di assistenza all'agente. nessun chatbot ha mai parlato con un cliente.
#cosa rallentava gli agenti?
le risposte esistevano già. trovarle non scalava. un ticket complesso significava un agente che apriva lo storico su zendesk, un documento di prodotto e un pdf sulla policy di spedizione, per poi ricostruire la risposta a mano. quattro anni di ticket passati contenevano il precedente. nessuno poteva cercare in quattro anni di ticket nel tempo che 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'ai può ridurre il tempo di prima risposta nel customer support senza un chatbot?
sì. uno strumento di retrieval interno permette agli agenti di porre domande in linguaggio semplice su ticket storici, documenti di prodotto e pdf di policy, e ottenere un'unica risposta con fonte citata. è sempre l'agente a scrivere e inviare la risposta. per un team cx e-commerce di media dimensione questo ha ridotto del 40% il tempo di prima risposta sui ticket complessi, senza alcun bot rivolto al cliente.
#cosa abbiamo consegnato esattamente?
uno strumento di retrieval interno su tre fonti: 4 anni di 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 4 anni di 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 faceva parte della costruzione, non un passaggio di consegne finale. il kpi che ci eravamo impegnati a spostare era il tempo di prima risposta sui ticket complessi. lo abbiamo misurato prima e dopo. è sceso del 40%.
#non è lo stesso di un bot di deflessione?
no, e la differenza è tutto il punto. una strategia di deflessione cerca di abbassare il volume di ticket rispondendo direttamente ai clienti. questo ha spostato un numero diverso. la metrica era il tempo di prima risposta, ottenuto mettendo il retrieval dietro l'agente. il cliente ha sempre parlato 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 gorgias suggestions funzionano dentro le proprie mura: le tue macro, i tuoi articoli di aiuto, le tue risposte salvate. noi abbiamo costruito il retrieval su tutto il resto. i ticket storici, i documenti di prodotto, i pdf della 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.
#funzionerebbe per il nostro team di supporto?
il test di idoneità è semplice. le tue risposte vivono già in posti lenti da cercare? quattro 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, è esattamente quel minuto che il retrieval restituisce.
questa realizzazione rientra nel nostro lavoro di consulenza, con la formazione del team di supporto integrata dal lato training. se vuoi vedere come si incastrano i pezzi, il journal ha altre prove come questa.
se i tuoi agenti cercano risposte prima di ogni risposta complessa, è esattamente il 40% che abbiamo inseguito qui. raccontaci cosa stai costruendo e ti diremo se il retrieval è la leva giusta, oppure no.