L'assistenza clienti è l'unico lavoro in cui la coda non chiude mai. Ogni ticket è urgente per chi l'ha scritto, ogni risposta rappresenta l'intera azienda, e l'orologio delle metriche (tempo di prima risposta, tempo di risoluzione, CSAT) non si ferma. Ed è anche il lavoro in cui l'aiuto dell'AI è più a doppio taglio: un modello sa scrivere in pochi secondi una risposta calda e ben strutturata, e lo stesso modello sa inventarsi con totale sicurezza una politica di rimborso che non hai. Un'indagine Intercom del 2026 su oltre 2.400 professionisti del customer service ha rilevato che l'82% dei senior leader ha investito in AI per il supporto nel 2025 e che il 62% dei team ha visto migliorare le proprie metriche con l'AI in funzione, ma solo il 10% definisce maturo il proprio deployment [1]. Lo State of Service di Salesforce, su un campione di 6.500 professionisti, stima che il 30% dei casi sia già gestito dall'AI, con una proiezione al 50% entro il 2027 [2]. I team di supporto dalla parte giusta di quei numeri non sono quelli con più strumenti AI: sono quelli con una libreria di prompt riutilizzabile e testata, puntata sul triage, sulle bozze e sul lavoro di documentazione che divora la giornata, con le protezioni sull'accuratezza scritte dentro i prompt stessi.
Questo articolo raccoglie 50 prompt pronti all'uso per chi lavora nell'assistenza clienti, organizzati per flusso di lavoro: triage e prioritizzazione dei ticket, prime risposte e tono, reclami, rimborsi ed escalation, accuratezza e controllo delle allucinazioni, knowledge base e contenuti self-service, feedback dei clienti e segnali di churn, SLA e comunicazione interna, qualità e processi del team. Se cercavi prompt AI per l'assistenza clienti, prompt ChatGPT per il customer service o pattern di prompt per ridurre le allucinazioni nelle risposte di supporto, la raccolta è qui sotto. Ogni prompt usa [segnaposto tra parentesi] così puoi adattarlo al tuo prodotto e alle tue policy. Funzionano con ChatGPT, Claude e Gemini, con una nota dove un modello è chiaramente più adatto di un altro.
Mappa dei flussi di lavoro dell'assistenza clienti: otto aree in cui i prompt restituiscono tempo senza rischiare l'accuratezza
Prima di incollare: due regole non negoziabili
1. I dati dei clienti non entrano mai grezzi. Un ticket di supporto è un fascio di dati personali: nomi, email, numeri d'ordine, indirizzi, a volte dettagli di pagamento o di salute. Incollarlo in un chatbot AI consumer può conservarlo e, a seconda del piano, usarlo per l'addestramento: un problema GDPR e un problema di fiducia prima ancora che di altro. Anonimizza prima: sostituisci i nomi con [cliente], togli gli identificativi, tieni solo la forma del problema. Se la tua azienda ha un'installazione AI enterprise con un accordo sui dati, usa quella; se sei su un piano gratuito, dai per scontato che tutto ciò che incolli venga conservato.
2. Il modello scrive la bozza; i fatti e il pulsante di invio restano umani. Una risposta di supporto è una promessa fatta su carta intestata. L'AI inventerà con scioltezza un dettaglio di policy, una dichiarazione di compatibilità o uno sconto mai offerto, e il cliente ti ci terrà legittimamente ancorato. Ogni affermazione fattuale in una risposta in uscita (policy, prezzo, tempistica, comportamento tecnico) va verificata sulla documentazione reale prima dell'invio, e tutto ciò che vincola (rimborsi oltre policy, temi legali, incidenti di sicurezza) richiede giudizio umano, non solo una rilettura umana. I prompt della sezione 4 servono a rendere tutto questo meno costoso: obbligano il modello ad ancorarsi ai tuoi documenti e a dire "non lo so" invece di improvvisare.
Guida rapida all'uso sicuro per i team di supporto: cosa puoi incollare, cosa verificare, cosa deve approvare un umano
Fissate queste due regole, ecco i 50 prompt.
1. Triage e prioritizzazione dei ticket
La coda è il lavoro. L'AI legge più veloce di qualunque umano, e il triage è reversibile: è il posto più sicuro da cui cominciare.
1. Classifica e prioritizza un blocco di ticket
Ecco [N] ticket di supporto, anonimizzati: [incolla]. Per ciascuno indica: categoria ([le tue categorie, es. fatturazione / bug / come-si-fa / richiesta funzionalità]), urgenza (P1-P3 con una riga di motivazione), sentiment (calmo / frustrato / arrabbiato), e se serve uno specialista umano o basta una risposta standard. Output in tabella, da scorrere in un solo passaggio.
2. Trova la vera domanda
Questo ticket è lungo e disordinato: [incolla il ticket anonimizzato]. Dimmi: la domanda o il problema reale (spesso non è il primo dichiarato), le richieste secondarie sepolte dentro, cosa il cliente ha già provato, e il registro emotivo a cui la risposta dovrebbe allinearsi. Cita la frase che contiene il problema vero.
3. Individua duplicati e pattern nella coda
Ecco oggetti e prime righe dei ticket di oggi: [incolla l'elenco]. Raggruppali nei cluster che probabilmente condividono la stessa causa, segnala i cluster che sembrano un incidente in corso (picco improvviso su una funzionalità), e suggerisci quale cluster gestire per primo in base a volume e gravità. Verificherò sul nostro monitoraggio prima di dichiarare un incidente.
4. Scrivi la rubrica di triage per il team
Aiutami a scrivere una rubrica di triage per un team di supporto di [dimensione] che gestisce [tipo di prodotto]. Categorie: [elenca o chiedimele]. Per ogni livello di priorità definisci: obiettivo di tempo di risposta, cosa vi rientra, un esempio concreto, e il percorso di escalation. Tienila in una pagina, così i nuovi agenti la usano davvero.
5. Instrada un ticket che non capisci
Ho ricevuto questo ticket e non so a quale team appartenga: [incolla anonimizzato]. In base alla descrizione, elenca i due o tre team più probabili ([i tuoi team]), quali indizi nel ticket puntano verso ciascuno, e l'unica domanda di chiarimento da fare al cliente che risolverebbe l'instradamento.
6. Riassumi un thread lungo prima del passaggio di consegne
Riassumi questo thread di supporto per il prossimo agente: [incolla il thread anonimizzato]. Includi: il problema originale, tutto ciò che è già stato tentato (con l'esito), lo stato attuale, lo stato d'animo del cliente, e l'unica cosa da NON riproporre. Sotto le 150 parole, così viene letto e non scorso.
2. Prime risposte e tono
La prima risposta decide la temperatura dell'intera conversazione. L'AI la abbozza in fretta; la tua conoscenza del prodotto e la tua policy la rendono vera.
7. Scrivi una prima risposta nella tua voce di supporto
Scrivi una prima risposta a questo ticket: [incolla il ticket anonimizzato]. La nostra voce di supporto è [descrivi: es. calda, diretta, senza riempitivi aziendali]. Struttura: riconosci il problema specifico nella prima riga (non scuse generiche), dichiara cosa sappiamo o verificheremo, dai il prossimo passo con la sua tempistica, chiudi con una riga sincera, non con "ci scusiamo per il disagio". Non affermare policy o fatti tecnici che non ti ho fornito; lascia segnaposto [VERIFICA] dove devo inserire i dettagli reali.
Claude tende a mantenere un tono di supporto coerente e mai zuccheroso anche su risposte lunghe; dagli prima due o tre delle tue risposte migliori come esempi.
8. Regola la temperatura di una bozza
Ecco la mia bozza di risposta: [incolla]. Il cliente è [calmo ma confuso / frustrato / arrabbiato / un cliente storico che abbiamo deluso]. Riscrivila per allinearla: stessi fatti, stessa struttura, ma calibra calore, livello di scuse e formalità. Dammi due versioni: una leggermente più calda, una più asciutta, così scelgo.
9. Spiega una causa tecnica con parole semplici
Un cliente ha incontrato questo problema: [descrivi]. La causa tecnica è: [spiega in breve]. Scrivi la parte esplicativa della risposta per un cliente non tecnico: cosa è successo, perché, e cosa stiamo facendo, in parole semplici, massimo tre frasi, senza gergo, senza dare colpe al cliente e senza promettere tempi che non ho indicato.
10. Di' di no senza bruciare la relazione
Il cliente chiede [richiesta] e la risposta è no perché [motivo reale]. Scrivi una risposta che: dà il no con chiarezza nelle prime due righe (senza seppellirlo), spiega il motivo onestamente senza nascondersi dietro "la policy", offre la cosa più vicina che POSSIAMO fare ([alternativa]), e lascia la porta aperta. Niente empatia finta; rispettoso e diretto.
Vuoi sapere quanto sono efficaci i tuoi prompt? Prompt Score li analizza su 6 criteri.
11. Gestisci il "ci sono novità?" su un ticket lento
Il cliente aspetta su [problema] e chiede un aggiornamento; lo stato onesto è [stato, es. "è in mano all'engineering, ancora nessuna stima"]. Scrivi un aggiornamento che dica qualcosa di reale invece di "ci stiamo lavorando": cosa è successo concretamente, cosa succede adesso, quando riceverà nostre notizie anche se non ci saranno novità. Mai inventare progressi.
12. Rispondi bene a un cliente contento
Questo cliente ha scritto qualcosa di positivo: [incolla]. Scrivi una risposta breve che suoni come una persona, non come un bot: ringrazialo in modo specifico per ciò che ha apprezzato, una riga, nessun tentativo di vendita, e se è appropriato invitalo a [recensione / community / beta]. Allineati alla sua energia; non superarla.
13. Estrai una guida di tono dalle risposte migliori del team
Ecco [N] risposte scritte dal nostro agente migliore: [incolla esempi anonimizzati]. Estrai la nostra voce di supporto implicita in una guida breve: tre o quattro tratti con una definizione ciascuno, un elenco diciamo-così / non-diciamo-mai ricavato da questi esempi, e le due abitudini che rendono umane queste risposte. La userò per allineare il team e i prompt futuri.
3. Reclami, rimborsi ed escalation
Le conversazioni che nessuno vorrebbe, dove una buona struttura conta di più e una parola sbagliata costa di più. La bozza all'AI, la decisione alla policy, l'invio al giudizio.
14. Rispondi a un reclamo formale
Un cliente ha inviato questo reclamo: [incolla anonimizzato]. Scrivi una risposta che: riformula il reclamo con precisione in una frase (così si sente letto), si assume la responsabilità di ciò che è stato davvero colpa nostra e solo di quello, spiega cosa è successo senza accampare scuse, indica il rimedio concreto ([rimedio]) e il passo che facciamo perché non si ripeta. Formale ma umana. Lascia segnaposto [VERIFICA] su ogni affermazione fattuale.
15. Gestisci una richiesta di rimborso dentro la policy
Richiesta di rimborso: [incolla anonimizzata]. La nostra policy per questo caso: [incolla il testo reale della policy]. Scrivi la risposta applicando la policy così com'è scritta: se il rimborso spetta, confermalo con i passi esatti e la tempistica; se non spetta, spiega esattamente quale condizione non è soddisfatta citando la riga della policy, e offri [eventuale alternativa]. Non ammorbidire la policy fino all'ambiguità e non inventare eccezioni.
16. Fai un'escalation senza alzare la temperatura
Questa conversazione deve passare a [responsabile / engineering / legale]: [incolla il thread anonimizzato]. Scrivi due cose: (a) la nota interna di escalation: solo fatti, cronologia, cosa è stato promesso, livello di rischio, quale decisione serve ed entro quando; (b) la risposta ponte al cliente: chi prende in carico e quando avrà notizie, senza ammettere colpe né fare promesse che chi gestisce l'escalation non ha approvato.
17. Disinnesca un thread arrabbiato
Il cliente è arrabbiato e il thread si sta scaldando: [incolla anonimizzato]. Scrivi una risposta che disinnesca senza capitolare: nomina la sua frustrazione in modo specifico, separa i due o tre problemi aggrovigliati e affrontali uno per uno, dichiara cosa faremo e quando, e poni un limite rispettoso se il tono ha superato la soglia. Niente sarcasmo, niente rincorsa alla sua energia, niente muro di testo.
18. Rispondi a una recensione negativa pubblica
Questa recensione pubblica riguarda un'esperienza di supporto: [incolla la recensione]. Scrivi la risposta pubblica: ringrazia, riconosci lo specifico fallimento senza legalese, indica cosa è cambiato o cambierà, e sposta la risoluzione su un canale privato con un modo concreto per raggiungerci. Massimo due paragrafi brevi; il pubblico sono i futuri clienti che leggono, non solo chi ha recensito.
19. Comunica un errore che abbiamo fatto noi
Abbiamo commesso un errore che tocca questo cliente: [descrivi l'errore]. Scrivi il messaggio proattivo: cosa è andato storto e il suo impatto reale su di lui, cosa abbiamo già sistemato, cosa facciamo per lui in particolare ([rimedio]), e come preveniamo il ripetersi. Nessun linguaggio minimizzante ("piccolo problema", "lieve disagio"): la misura del disagio non la decidiamo noi.
20. Decidi i risarcimenti con coerenza
Aiutami a ragionare sul risarcimento per questo caso: [descrivi situazione e impatto]. Le nostre soglie abituali: [incolla le linee guida se esistono]. Metti in fila: gravità dell'impatto, rischio di precedente (cosa succede se ogni caso simile ottiene lo stesso), le opzioni dalla più economica alla più generosa con il messaggio che ciascuna manda, e la tua raccomandazione motivata. La decisione è mia; tu struttura i compromessi.
4. Accuratezza, ancoraggio e controllo delle allucinazioni
La sezione che tiene svegli i team di supporto, e il motivo per cui molti vietano l'AI del tutto. Ed è anche ciò che i tuoi clienti già sospettano: in uno studio SurveyMonkey di dicembre 2025, l'84% dei consumatori statunitensi considera gli agenti umani più accurati dell'AI [3]. La soluzione non è vietare il modello: è scrivere prompt in cui inventare diventa più difficile che ammettere di non sapere. Per il metodo completo dietro questi pattern, vedi la nostra guida per ridurre le allucinazioni dell'AI con prompt migliori.
21. Ancora ogni risposta ai tuoi documenti reali
Rispondi a questa domanda del cliente usando SOLO la documentazione che incollo sotto. Domanda: [domanda]. Documentazione: [incolla gli articoli della knowledge base / la policy pertinente]. Regole: se la documentazione non contiene la risposta, scrivi esattamente "NON NEI DOCUMENTI" ed elenca cosa manca; non colmare mai i vuoti con la conoscenza generale, perché la tua conoscenza generale può non corrispondere al nostro prodotto; cita nella bozza la riga del documento che sostiene ogni affermazione.
22. Dai al modello il permesso di rifiutare
Stai scrivendo bozze di risposta per il supporto di [prodotto]. Regola fissa per tutta la sessione: quando non sei certo che un'affermazione sul nostro prodotto, sui prezzi o sulla policy sia vera in base a ciò che ti ho fornito, non tirare a indovinare. Scrivi [NON-VERIFICATO] al posto dell'affermazione e prosegui. Una bozza con tre segnaposto [NON-VERIFICATO] è utile; una bozza fluente con un fatto inventato è pericolosa.
23. Verifica una bozza a caccia di fatti inventati
Ecco una bozza di risposta: [incolla]. Ecco il materiale di partenza su cui si basa: [incolla documenti/policy]. Elenca ogni affermazione fattuale della bozza (dichiarazioni di policy, numeri, comportamento delle funzionalità, tempistiche) e marca ciascuna: SUPPORTATA (cita la riga della fonte), NON SUPPORTATA (assente dalle fonti) o CONTRADDETTA (in conflitto con le fonti). Non giudicare il tono; solo i fatti.
24. Rispondi su una policy senza deviare
Domanda del cliente: [domanda]. Testo esatto della policy: [incolla]. Scrivi la risposta in modo che ogni frase sulla policy sia una riformulazione del testo incollato in linguaggio da cliente, senza aggiunte e senza ammorbidimenti. Se il caso del cliente cade in un vuoto che la policy non copre, di' che dobbiamo verificare e NON improvvisare una regola. Segnalami il vuoto a parte.
25. Comprimi un articolo della knowledge base in una risposta verificata
Ecco il nostro articolo della knowledge base: [incolla]. Il cliente ha chiesto: [domanda]. Estrai solo la parte che risponde al suo caso specifico, riscrivila in tre o quattro passi per la sua esatta situazione ([contesto]), e segnala tutto ciò che nell'articolo potrebbe essere invecchiato ([numeri di versione, date, nomi di interfaccia]) e che dovrei verificare prima di inviare.
26. Costruisci l'elenco delle lacune note per una nuova area di prodotto
Stiamo per dare supporto a [funzionalità/prodotto] nuovo: [descrivi]. In base a questa documentazione: [incolla], elenca le domande dei clienti a cui questa documentazione NON risponde ancora, raggruppate per frequenza probabile. Diventa l'elenco delle risposte da scrivere prima del lancio, così gli agenti non improvvisano dal primo giorno.
Le tecniche che stai leggendo funzionano. Testa subito i tuoi prompt con Prompt Score e vedi il punteggio in tempo reale.
Ogni ticket a cui rispondi due volte è un articolo che manca. L'AI trasforma i thread risolti in documentazione più in fretta di quanto chiunque trovi il tempo di farlo.
27. Trasforma un ticket risolto in un articolo
Questo thread è arrivato a una soluzione: [incolla il thread anonimizzato]. Scrivine un articolo per la knowledge base: un titolo formulato come lo cercherebbe il cliente, il sintomo, la causa in parole semplici, la soluzione in passi numerati, e un rimando "se non ha funzionato". Togli tutto ciò che è specifico del caso; tienilo generale sul prodotto. Verificherò ogni passo sull'interfaccia attuale prima di pubblicare.
28. Genera una FAQ dalla documentazione di prodotto
Da questa documentazione di prodotto: [incolla], genera le [N] domande che i clienti faranno davvero, formulate nel loro linguaggio (non con i nostri nomi interni), ciascuna con una risposta di due-quattro frasi tratta rigorosamente dai documenti. Marca ogni risposta in cui la documentazione è ambigua, così sistemiamo la documentazione, non solo la FAQ.
29. Riscrivi un articolo che i clienti non capiscono
Questo articolo della knowledge base continua comunque a generare ticket: [incolla l'articolo]. Dai ticket risulta che i clienti inciampano su: [cosa li confonde]. Riscrivilo: parole più semplici, passi nell'ordine esatto in cui l'interfaccia li presenta, un segnaposto [SCREENSHOT: cosa mostrare] dove le parole non bastano, e i prerequisiti dichiarati all'inizio invece che scoperti a metà.
30. Localizza una macro di supporto
Traduci e adatta questa macro di supporto per [lingua/mercato]: [incolla]. Non tradurre parola per parola: mantieni il significato, adatta la formalità a ciò che i clienti di [mercato] si aspettano da un team di supporto, lascia intatti i segnaposto, e segnala ogni disallineamento culturale (consuetudini sui risarcimenti, tono delle scuse) invece di correggere la policy in silenzio.
31. Progetta il percorso self-service per un problema frequente
Il problema [problema] genera [quota approssimativa] dei nostri ticket. Disegna il percorso self-service che lo intercetterebbe: dove il cliente incontra il problema per la prima volta, dove dovrebbe comparire un suggerimento o un link ([in-app / email / knowledge base]), cosa deve contenere l'articolo, e quale quota di casi ha comunque bisogno di un umano (casi limite, dati specifici dell'account). Su quest'ultima parte sii onesto.
32. Tieni onesta la knowledge base dopo una release
Abbiamo appena rilasciato queste modifiche: [incolla il changelog]. Ecco i titoli degli articoli attuali della nostra knowledge base: [incolla l'elenco]. Segnala quali articoli ora sono invecchiati o sbagliati, cosa è cambiato di preciso in ciascuno, e ordina le correzioni per volume di ticket che l'articolo stantio rischia di causare. Titoli certi dove sei sicuro; punti interrogativi dove stai ipotizzando.
6. Feedback dei clienti e segnali di churn
Il supporto vede la verità sul prodotto prima di qualunque dashboard. Questi prompt trasformano la coda in intelligence di prodotto.
33. Estrai i temi da una settimana di ticket
Ecco i ticket di questa settimana, anonimizzati, oggetti e sintesi brevi: [incolla]. Raggruppali per tema, e per ogni tema indica: volume, tendenza rispetto a ciò che ti dico della settimana scorsa ([contesto]), le parole dei clienti che ricorrono (testuali), e se si legge come un bug, una lacuna di UX, una lacuna di documentazione o un'obiezione sul prezzo. Chiudi con i tre temi che il team di prodotto dovrebbe sentire per primi.
34. Scrivi il report voce-del-cliente
Trasforma questi temi di supporto in un report mensile voce-del-cliente per il team di prodotto: [incolla temi/dati]. Per ciascuno: cosa vivono i clienti (parole loro, non nostre), impatto sul business (ticket, rimborsi, menzioni di abbandono), e una formulazione neutra della decisione che il prodotto ha davanti. Niente soluzioni preconfezionate; noi portiamo il segnale, la correzione è loro.
35. Riconosci il rischio di churn in una conversazione
Leggi questo thread: [incolla anonimizzato]. Valuta il rischio di abbandono: quali frasi segnalano intenzione di uscita (paragoni con concorrenti, "stiamo valutando alternative", lamentele sui costi già sostenuti), quanto il danno sembra grave e reversibile, e come sarebbe un tentativo di recupero genuino, in contrapposizione a ciò che suonerebbe da copione di retention e peggiorerebbe le cose. Se un recupero reale non esiste, dillo.
36. Scrivi il messaggio di recupero per un cliente a rischio
Questo cliente probabilmente ci lascerà perché [motivo emerso dal thread]: [incolla il contesto anonimizzato]. Scrivi un contatto che: nomina il problema reale che ha avuto (niente "il suo parere è importante per noi"), dichiara cosa abbiamo cambiato o cosa possiamo offrire di VERO ([incolla cosa posso offrire]), e fa una domanda onesta su cosa lo farebbe restare. Niente disperazione, niente sconti che non ho autorizzato.
37. Analizza un blocco di commenti dai sondaggi
Ecco [N] commenti CSAT/NPS: [incolla]. Separa il segnale dal rumore: le specificità ricorrenti (citale testualmente), i casi isolati, e i commenti sull'agente distinti da quelli sul prodotto. Dammi le due modifiche che muoverebbero il punteggio in base a questi soli commenti, e ciò che questi commenti NON possono dirci (bias di selezione, la maggioranza silenziosa che manca).
38. Chiudi il cerchio quando la correzione arriva
Abbiamo risolto il problema dietro questi ticket: [descrivi la correzione]. Ecco l'elenco dei clienti coinvolti con il reclamo originale: [incolla anonimizzato]. Scrivi il modello di messaggio per chiudere il cerchio: richiama la loro specifica segnalazione, comunica cosa è stato rilasciato, ringrazia in modo concreto per la segnalazione. Personale abbastanza da non sembrare una campagna massiva; breve abbastanza da essere letto.
7. SLA, incidenti e comunicazione interna
Quando qualcosa si rompe, il carico di scrittura triplica esattamente quando il tempo per scrivere sparisce. Questi conviene prepararli prima che servano.
39. Scrivi un aggiornamento di stato durante un incidente
Abbiamo un incidente in corso: [ciò che si sa: impatto, perimetro, ora di inizio, cosa si sta facendo]. Scrivi l'aggiornamento di stato per i clienti: cosa è coinvolto in parole semplici, cosa sappiamo e cosa non sappiamo ancora, cosa possono fare i clienti nel frattempo ([workaround se esiste]), e quando arriva il prossimo aggiornamento. Riporta solo ciò che ti ho dato: niente ipotesi sulle cause, nessuna stima che non ti ho fornito.
40. Spiega una violazione di SLA
Abbiamo mancato lo SLA con questo cliente: [contesto: cosa era promesso, cosa è successo]. Scrivi la comunicazione proattiva: riconosci l'impegno specifico mancato, il motivo onesto (senza scaricare la colpa su un team), il rimedio concreto previsto dai nostri termini ([rimedio]), e cosa cambia. Questo messaggio sarà letto dai loro dirigenti; professionale e con rispetto di sé.
41. Scrivi il riepilogo post-incidente per i clienti
L'incidente è risolto: [cronologia, causa in termini tecnici, correzione]. Scrivi il post-mortem per i clienti: cosa è successo e quando, l'impatto dichiarato onestamente, la causa tradotta in linguaggio semplice, cosa abbiamo cambiato perché non si ripeta. Niente melodramma, niente minimizzazioni. La precisione tecnica la rivede l'engineering; lascia un segnaposto [VERIFICA-ENG] su ogni affermazione tecnica.
42. Prepara il team prima di una release rischiosa
Rilasciamo [modifica] il [data]; il supporto deve aspettarsi [problemi probabili]. Scrivi il briefing interno: cosa cambia dal punto di vista del cliente, le domande che probabilmente riceveremo con le risposte approvate, cosa dire se compare [caso limite noto], e quando fare escalation invece di improvvisare. Una pagina, leggibile a colpo d'occhio durante un turno pieno.
43. Standardizza il passaggio di turno
Progetta un modello di passaggio di turno per un team di supporto di [dimensione] su [fusi orari/copertura]. Deve trasferire in meno di cinque minuti di lettura: i P1/P2 aperti con lo stato, gli incidenti in corso, le promesse fatte a clienti specifici con le scadenze, le anomalie nella coda, e un campo per la "sensazione a pelle" che i dati non catturano. Poi compilalo da queste note come esempio: [incolla].
44. Trasforma il caos in un piano di macro
Ecco le nostre 20 risposte libere più usate del mese scorso: [incolla anonimizzate]. Quali dovrebbero diventare macro ufficiali? Raggruppale, dai un nome a ogni macro, indica cosa deve restare segnaposto ([nome], [ordine], [data]) e cosa testo fisso, e segnala le risposte che NON dovrebbero diventare macro perché funzionavano solo nel loro contesto e riusate suonerebbero robotiche.
8. Qualità e processi del team
I prompt che fanno attecchire i 44 precedenti: revisione della qualità, inserimento dei nuovi, metriche oneste.
45. Rivedi una risposta prima che parta
Rivedi questa bozza rispetto a questa checklist: [incolla la bozza]. Checklist: risponde alla domanda davvero posta; ogni affermazione fattuale verificata o marcata; tono allineato allo stato del cliente; nessuna promessa che non possiamo mantenere; prossimo passo e tempistica espliciti; suona come una persona. Restituisci la checklist con esito per voce e la correzione minima per ogni mancanza, non una riscrittura completa.
46. Fai il campione di qualità settimanale
Ecco [N] risposte campionate a caso da questa settimana, anonimizzate: [incolla]. Valuta ciascuna sulla nostra rubrica: [incolla la rubrica, oppure usa: accuratezza, completezza, tono, efficienza]. Per la retrospettiva del team dammi: i risultati a livello di pattern (senza colpe individuali), la mancanza più ricorrente, e una risposta che vale la pena condividere come esempio di come si fa.
47. Inserisci un nuovo agente sulla conoscenza del prodotto
Costruisci un piano di inserimento di due settimane per un nuovo agente di supporto su [prodotto], con background [background]. Settimana per settimana: cosa leggere ([le sezioni della nostra knowledge base]), quali tipi di ticket osservare e poi gestire, le dieci domande a cui deve saper rispondere a freddo entro il decimo giorno, e come verifichiamo che sia pronto senza un quiz umiliante. Presupponi che sia una persona in gamba e nuova, non junior e lenta.
48. Prepara la storia dietro le metriche, non solo le metriche
Ecco le metriche di supporto del mese: [incolla: volume, tempo di prima risposta, risoluzione, CSAT, deflection]. Scrivi la narrazione per l'aggiornamento alla direzione: cosa si è mosso e il perché onesto (compreso "non lo sappiamo ancora" dove è vero), cosa i numeri nascondono (una risposta sbagliata ma rapida batte una giusta ma lenta nel tempo di prima risposta), e l'investimento singolo che migliorerebbe di più il mese prossimo. Solo i numeri che ti do; nessun benchmark inventato.
49. Metti in discussione il tuo stesso processo
Ecco come un ticket attraversa il nostro team oggi: [descrivi il processo]. Fai il consulente scettico: dove questo flusso costringe il cliente a ripetersi, dove ottimizza le nostre metriche a spese del cliente, quale passaggio esiste per un motivo che nessuno ricorda più, e cosa un team grande la metà sarebbe costretto a semplificare? Ordina i risultati per dolore del cliente, non per comodità interna.
50. Trasforma le lezioni di questo mese nei prompt del prossimo
Ecco le situazioni di supporto andate male o durate troppo questo mese: [incolla descrizioni brevi]. Per ciascuna dimmi se un prompt riutilizzabile avrebbe aiutato (e abbozzane lo scheletro), oppure se il fallimento era di processo o di conoscenza, dove un prompt è la soluzione sbagliata. Sii onesto sulla seconda categoria; non tutto deve diventare un prompt.
Trasformali in template
Non devi ricostruire ogni prompt da zero. La libreria di template di Keep My Prompts ha una categoria dedicata all'assistenza clienti, con prompt strutturati e pronti da eseguire:
Un prompt incollato una volta e perso vale poco. Un prompt che entra nel modo in cui il team risponde è un sistema. Tre mosse separano i team che dall'AI ricavano valore marginale da quelli che si riprendono ore vere:
Salvali, come team. Ogni prompt che produce una bozza utilizzabile entra in una libreria di prompt condivisa, taggata per flusso di lavoro (triage, risposte, escalation, knowledge base), così tutto il team attinge dallo stesso insieme testato invece di cinque agenti che mantengono cinque file di note privati. Se oggi macro e prompt vivono in un foglio di calcolo, ecco cosa si rompe e come migrare.
Dagli un punteggio prima di fidarti. Un prompt di supporto che lascia spazio all'invenzione è un rischio con il tuo logo sopra. Usa i sei criteri che fanno un buon prompt per controllare quelli che adatti da questa pagina: le regole di ancoraggio della sezione 4 funzionano solo se il prompt le dichiara davvero ogni volta, che è esattamente ciò che un template salvato e valutato garantisce e un prompt digitato a memoria no.
Versionali quando cambia la policy. La policy sui rimborsi cambia, il prodotto cambia, la voce evolve. Un prompt scritto sulla policy del trimestre scorso è un generatore di allucinazioni con buone intenzioni. Tieni ogni prompt versionato insieme al testo di policy che incorpora e, quando la policy si muove, aggiorna il prompt conservando la storia: così "quale versione ha risposto a questo ticket" non è mai un mistero.
I team di supporto che si riprendono le ore non sono quelli che spediscono bozze AI senza leggerle. Usano meno prompt, migliori e ancorati ai documenti per triage, bozze e documentazione, verificano ogni fatto prima che parta, e tengono il pulsante di invio, con il giudizio che ci sta dietro, saldamente umano.
Fonti
[1] Intercom, 2026 Customer Service Transformation Report (indagine su oltre 2.400 professionisti del customer service, gennaio 2026): l'82% dei senior leader ha investito in AI per il customer service nel 2025 e l'87% prevede di farlo nel 2026, ma solo il 10% descrive un deployment maturo; il 62% dei team riporta metriche di servizio migliorate con l'AI. https://www.intercom.com/blog/customer-service-transformation-report-2026/
[3] SurveyMonkey, studio sulle statistiche del customer service (2.017 adulti statunitensi, dicembre 2025): l'84% dei consumatori considera gli agenti umani più accurati dell'AI; l'89% vuole avere sempre l'opzione di parlare con un umano. https://www.surveymonkey.com/curiosity/customer-service-statistics/
