Chi siamo AI
Settori
Piattaforme
Servizi
Progetti Blog Contatti
Richieda un preventivo
WooCommerce

Un agente AI di supporto sul suo store: cosa può gestire e cosa non deve mai toccare

La differenza tra un agente AI che riduce il volume dei ticket e uno che le fa perdere clienti non sta nel modello. Sta nel documento di ambito: quali domande può gestire, quali azioni può eseguire e cosa deve sempre passare a un operatore.

Limiti di ambito per un agente AI di supporto clienti su uno store e-commerce

L'automazione del supporto è cambiata. I vecchi chatbot si limitavano ad abbinare parole chiave e offrire un menu; la generazione attuale legge i dati dell'ordine, comprende la domanda e può agire per conto del cliente. Questo è davvero più utile, ma anche più rischioso, e il rischio non è l'hallucination — è l'ambito.

Un agente che può leggere un ordine è utile. Un agente che può annullarlo diventa un rischio nel momento in cui la sua sicurezza supera le prove disponibili. Questo è il criterio che usiamo per definire quel limite.

Tre livelli, non due

La maggior parte dei team pensa in termini di lo gestisce il bot o lo gestisce una persona. Tre livelli funzionano molto meglio, perché il valore maggiore e tutti i rischi si concentrano proprio nel livello intermedio.

Tier 1: Legge e risponde — può essere attivato con fiducia

Domande a cui si può rispondere con dati che l'agente può consultare, dove sbagliare è imbarazzante ma non costoso.

  • Stato dell'ordine e tracking. La categoria di ticket più numerosa nella maggior parte degli store, e quasi sempre gestibile in autonomia.
  • Stime di consegna per un determinato prodotto e destinazione
  • Disponibilità dello stock e date previste di riassortimento
  • Domande sulle policy — tempi per i resi, condizioni di garanzia, soglie per la spedizione — risposte basate sulla policy pubblicata, non sulla conoscenza generale del modello
  • Domande sulle specifiche dei prodotti risposte esclusivamente in base agli attributi del catalogo
  • Domande sull’account — dove trovare una fattura, come modificare un indirizzo

Si noti il qualificatore che compare due volte: dai suoi dati. Un agente che risponde a una domanda sui resi usando i dati di addestramento invece della sua policy sui resi può risultare plausibile, sicuro e talvolta errato in modo per lei vincolante. Ogni risposta su una policy deve basarsi su testo recuperato dai suoi contenuti.

Tier 2: Agisce, con limiti di sicurezza

Azioni che modificano qualcosa, consentite solo entro limiti espliciti e meccanici — applicati dal suo codice, non dal prompt.

  • Modifica di un indirizzo di consegna — solo prima della spedizione, solo per il titolare autenticato dell’account
  • Avvio di un reso — solo entro il periodo previsto per i resi, solo per prodotti idonei, solo generando un’etichetta già prevista dal suo processo attuale
  • Annullamento di un ordine — solo prima dell’inizio dell’evasione, solo sotto una soglia di valore da lei definita
  • Applicazione di un credito di cortesia — solo entro un limite fisso per interazione e un limite cumulativo per cliente
  • Aggiornamento delle preferenze di marketing — effettivamente a basso rischio e spesso fonte di disagio per i clienti

Ogni vincolo qui deve essere applicato dallo strumento che l’agente utilizza, non da istruzioni nel prompt. Un prompt che dice non rimborsare mai più di £50 è solo un suggerimento. Un’API che rifiuta importi superiori a £50 è un controllo. Consideri che il prompt verrà prima o poi aggirato: la progettazione deve renderlo irrilevante.

Tier 3: Mai — passaggio immediato a un operatore

Categorie in cui l’unica azione corretta dell’agente è raccogliere il contesto ed effettuare l’escalation.

  • Qualsiasi aspetto che coinvolga dati di pagamento o di carte. Nessuna eccezione, nessun tentativo di aggiramento.
  • Frodi, chargeback e contestazioni — un interlocutore avversariale non è una conversazione di supporto
  • Segnalazioni di sicurezza, infortuni, allergie, reazioni avverse o richiami di prodotto. Sono casi regolamentati, urgenti e spesso soggetti a obblighi di segnalazione.
  • Consulenza medica, sul dosaggio, legale o finanziaria, indipendentemente da come viene posta la domanda
  • Reclami sull’azienda, in particolare se menzionano azioni legali, autorità di vigilanza o la stampa
  • Situazioni di disagio di qualsiasi tipo. Un cliente turbato ha bisogno di una persona; ogni minuto in più con un sistema automatico peggiora la situazione.
  • Qualsiasi questione relativa all’account o ai dati di un minorenne
  • Trattative su prezzi all’ingrosso, per grandi volumi o B2B — si tratta di una trattativa commerciale, non di supporto

Rediga questo elenco prima di scrivere il prompt. È il documento che i responsabili legale, compliance e supporto dovrebbero approvare, e resta valido anche quando il modello sottostante sarà cambiato due volte.

L’escalation è la funzione chiave

La maggior parte delle implementazioni fallisce nella fase di handover, non nella risposta. Ecco cosa va gestito:

  1. Escalation in caso di ripetizione. Se il cliente ripete la domanda, l’agente ha già fallito. Effettui l’escalation al secondo tentativo, non al quinto.
  2. Escalation in base al sentiment, non solo alle parole chiave. La frustrazione è rilevabile ed è il segnale più precoce e affidabile.
  3. Offra sempre una via d’uscita visibile. Un cliente che non trova il contatto umano scriverà una recensione a riguardo.
  4. Trasferisca il contesto. L’agente deve fornire all’operatore umano un riepilogo, l’ordine interessato e quanto già tentato. Costringere il cliente a ripetersi è peggio che non automatizzare affatto.
  5. Escalation in caso di bassa fiducia. Un agente che dice non sono sicuro, le passo un collega è più affidabile di uno che indovina correttamente la maggior parte delle volte.

Le metriche che si possono manipolare

I fornitori riportano il containment rate — la quota di conversazioni che non raggiungono mai un operatore umano. È la metrica più facile da far apparire positiva, perché anche una conversazione abbandonata dal cliente per frustrazione viene conteggiata come contenuta.

Misuri invece questi indicatori:

  • Resolution rate — il problema del cliente è stato effettivamente risolto, verificato dall’assenza di ulteriori contatti entro 72 ore?
  • Qualità dell’escalation — tra le conversazioni trasferite, quante sono state risolte dall’operatore umano con una sola risposta? Un trasferimento di contesto inefficace si nota qui per primo.
  • Costo per contatto risolto, confrontato con il dato di riferimento umano — il numero che giustifica il progetto
  • Tasso di conversione e di riacquisto post-interazione per i clienti che hanno utilizzato l’agente rispetto a chi non l’ha fatto. Se questo valore è negativo, il containment è irrilevante.
  • Tasso di reclami che menzionano l’agente. Lo monitori in modo esplicito; non emergerà spontaneamente.

Esegua un test di controllo. Instradi una quota di conversazioni idonee agli operatori umani normalmente per il primo trimestre. Senza questo non potrà distinguere l’effetto dell’agente dalla stagionalità, né difendere i dati davanti a un consiglio di amministrazione scettico.

Prima di attivarlo

Un breve elenco pre-lancio che intercetta la maggior parte dei problemi:

  1. Costruisca un set di valutazione con 100 ticket storici reali e l’esito corretto annotato, e testi ogni modifica di prompt o modello su questo set. Senza questo, i cambiamenti sono fatti a sensazione.
  2. Faccia un red teaming. Provi a ottenere un rimborso oltre il limite, a far rivelare un ordine di un altro cliente o a ricevere consigli medici. Qualcuno ci riuscirà; meglio sia lei.
  3. Verifichi cosa dice su concorrenti, prezzi e promesse. Un agente che promette una consegna in 24 ore che lei non offre ha creato un obbligo.
  4. Verifichi la posizione in materia di protezione dei dati. Quali dati dei clienti escono dai Suoi sistemi, verso quale fornitore, con quali termini di conservazione, e tutto ciò è documentato?
  5. Indichi chiaramente che è automatizzato. Al di là di ogni obbligo normativo, non dichiarare l'automazione comporta un costo di fiducia che può evitare.
  6. Preveda un interruttore di emergenza che un responsabile del supporto possa attivare alle 2 di notte senza coinvolgere un tecnico.

Il valore di questa soluzione

Se gestita correttamente, la sola Tier 1 elimina di solito una quota rilevante dei ticket, perché dov'è il mio ordine domina la casella di posta della maggior parte degli store ed è una domanda a cui può rispondere con i dati già disponibili. È un risparmio concreto, ottenuto senza toccare nulla di rischioso.

Tier 2 aggiunge funzionalità, ma anche la possibilità di errori. Tier 3 è dove si concentra il rischio reputazionale, e si può evitare del tutto — basta non implementarla.

I negozi che si pentono di questo progetto sono quelli che sono partiti dalla Tier 2 perché la demo era più d'effetto. Chi invece è soddisfatto ha implementato la Tier 1, l'ha valutata con onestà per un trimestre e ha ampliato sulla base dei risultati.

Realizziamo queste soluzioni su store attivi tramite la nostra pratica di AI e machine learning; la questione più ampia di dove inserire l'automazione in azienda è l'obiettivo del nostro lavoro di integrazione AI. In contesti regolamentati — tra cui i nostri clienti healthcare — la Tier 3 richiede più tempo e la disciplina è ancora più importante.

Domande frequenti

Quale percentuale di ticket di supporto può gestire realisticamente un agente AI?

Domande su stato ordine, tracking e policy rappresentano la maggior parte delle richieste e sono quasi sempre risolvibili con i dati già disponibili; una gestione Tier 1 ben definita riduce quindi una quota significativa. Oltre questo livello, la riduzione incrementale cala mentre il rischio aumenta.

L’agente deve poter emettere rimborsi?

Solo entro limiti rigidi applicati tramite API e non tramite prompt: un tetto per singola interazione, un limite cumulativo per cliente e regole di idoneità verificate lato server. Qualsiasi caso di contestazione, chargeback o gestione di dati carta va sempre a un operatore umano.

Come si evita che inventi la policy sui resi?

Ogni risposta sulle policy deve basarsi su testo recuperato dai contenuti pubblicati dall’azienda; se non trova nulla, l’agente deve rifiutarsi di rispondere invece di dedurre. Una risposta generata dal modello su base generale può sembrare plausibile e vincolante, ma non è affidabile.

La containment rate è un buon indicatore?

No. Conta come successo anche le conversazioni abbandonate. Misuri invece la risoluzione: il problema è stato risolto, verificato dall’assenza di follow-up entro 72 ore, insieme al costo per contatto risolto e al conversion rate dei clienti che hanno usato l’agente.

È obbligatorio informare i clienti che stanno parlando con un’AI?

Gli obblighi di disclosure variano secondo la giurisdizione e stanno diventando più stringenti; verifichi la posizione attuale con il legale. Oltre alla compliance, conviene comunque etichettare: l’automazione non dichiarata, se scoperta dal cliente, costa più fiducia di quanta ne farebbe perdere la disclosure.

Parta dal documento di scope

Prima di qualsiasi scelta tecnologica, definisca le tre tier per la Sua azienda e le faccia approvare da supporto, legale e commerciale. Le aiutiamo a redigere il documento e sviluppiamo la soluzione in base a quello. Contatti il nostro team; rispondiamo entro un giorno lavorativo.


Ha un progetto simile?

Descriva cosa sta realizzando e dove si è bloccato. Riceverà una risposta entro un giorno lavorativo con una valutazione trasparente su ambito, sequenza e costi.

  • Una valutazione trasparente su ambito, sequenza e costi
  • Risposta entro un giorno lavorativo
  • Nessun impegno, nessuna sequenza commerciale

Protetto da Cloudflare Turnstile. I dati non vengono mai condivisi.