AI · CX Operations
Come automatizzo il triage dei ticket di supporto con Make.com e Claude
Ogni operation che ho gestito ha la stessa settimana segnata in calendario: il rientro dall'estate o l'avvicinarsi del Q4, quando i ticket si accumulano più in fretta di quanto chiunque avesse previsto. Anche la risposta di default è quasi sempre la stessa, aggiungere personale o spingere sugli straordinari. Entrambe sono reattive, entrambe costano più di quanto dovrebbero, ed entrambe trattano un problema strutturale come se fosse un problema di organico.
Quello che tiene davvero durante un picco di volume non è più gente che risponde più veloce. È una struttura che ordina, filtra e prepara i ticket prima che un umano li apra. Ho costruito esattamente questo con Make.com e Claude API, e voglio ripercorrere l'architettura che uso davvero, non una versione teorica.
Il blueprint di base
Tre fasi, in sequenza: un ticket arriva, viene categorizzato, viene deviato o instradato con il contesto già allegato. Niente di tutto questo sostituisce il giudizio di un agente. Rimuove il lavoro di smistamento che non era mai stato un buon uso del loro tempo.
Fase uno: categorizzare prima di instradare
La maggior parte degli strumenti di ticketing di default segue il first-in-first-out. Una domanda minore sta davanti a un account ad alto rischio di churn semplicemente perché è arrivata prima. Quell'ordine non ha nulla a che vedere con quello che conta davvero per il business.
Un webhook Make.com resta in ascolto dei nuovi ticket che arrivano nell'helpdesk o nel CRM. Ognuno viene passato a Claude insieme al corpo del ticket, all'oggetto, e ai dati sul tier del cliente se disponibili, con istruzione di restituire un output strutturato:
{
"intent": "Billing_Issue | Technical_Blocker | Feature_Request | General_Info",
"urgency_score": "1 to 5",
"churn_risk": "High | Medium | Low",
"suggested_queue": "VIP_Tier2 | Standard_Queue | Auto_Deflection"
}
Make.com interpreta quella risposta e aggiorna automaticamente tag, priorità e assegnazione della coda. Un ticket ad alta urgenza e alto rischio di churn raggiunge uno specialista senior entro pochi secondi dall'arrivo, invece di aspettare dietro tutto quello che è arrivato prima.
Fase due: deviare quello che non ha bisogno di un umano
Una quota significativa di qualsiasi backlog post-picco è ripetitiva: reset password, domande standard sulle fatture, stato spedizione. Nulla di questo richiede giudizio, e tutto questo consuma capacità che dovrebbe andare ai ticket che invece lo richiedono.
Quando la fase uno etichetta un ticket come generale o a bassa complessità, Make.com interroga la knowledge base per l'articolo rilevante. Quell'articolo e la domanda originale del cliente vanno a Claude con un'istruzione precisa:
Sei uno specialista senior del supporto. Usando SOLO il contesto fornito, scrivi una risposta concisa e diretta al problema del cliente. Se il contesto non risolve completamente la domanda, segnala per escalation umana.
La parola "solo" in quell'istruzione non è decorazione. È l'intero meccanismo di sicurezza. Senza, ottieni un modello che improvvisa una risposta invece di citare la tua documentazione reale, e le risposte improvvisate sono esattamente ciò che erode la fiducia in una risposta automatizzata. Con quella parola, i casi a bassa confidenza vanno in escalation invece di tirare a indovinare.
Fase tre: riassumere prima che l'agente apra il ticket
Le escalation complesse e multi-thread creano un tipo diverso di rallentamento. Un agente che eredita un thread lungo passa tempo reale solo a leggere prima di poter agire, e quel tempo di lettura gonfia l'Average Handling Time proprio sui ticket dove l'AHT dovrebbe essere l'ultima cosa da ottimizzare.
Per i ticket instradati a un umano, Make.com aggrega l'intero thread e lo passa a Claude con un prompt di sintesi:
Riassumi la seguente conversazione di supporto in 3 punti distinti: - Problema Centrale del Cliente: - Passi Già Fatti: - Prossima Azione Richiesta:
Quel riassunto viene inserito come nota interna prima che l'agente apra il ticket. Parte già orientato, invece di ricostruire la storia da solo.
Zendesk o Freshdesk non lo fanno già?
In parte sì, e vale la pena dirlo chiaramente. Copilot di Zendesk genera riassunti dei ticket nativamente, incluse le note interne se abilitato, sui piani Professional in su, come add-on da circa 50 dollari per agente al mese. Freddy AI Auto Triage di Freshdesk prevede priorità, tipo e gruppo nativamente, come parte di un add-on Copilot da circa 29 dollari per agente al mese. Fin di Intercom ribalta del tutto la sequenza e prova a risolvere prima di smistare. Niente di tutto questo è un segreto, e niente di tutto questo rende inutile l'architettura sopra. Significa solo che la domanda onesta non è "esiste già", è "per chi è davvero utile".
Se non sei su una di quelle piattaforme
Molte scale-up gestiscono il supporto con strumenti più leggeri, Help Scout, Front, Gorgias, un inbox HubSpot su piano base, a volte una casella condivisa senza nessun helpdesk vero e proprio. La maggior parte di questi ha AI di triage nativa scarsa o assente, specialmente sui piani entry che un team early-stage può davvero permettersi. Per questo pubblico, Make.com più Claude non è un'alternativa più economica a qualcosa che già hai. È l'unico modo pratico di avere questa capacità senza migrare piattaforma o salire di piano dove non ti serve nient'altro. Il costo corrente a questa scala è quasi nullo: il piano gratuito di Make.com copre un numero reale di operazioni al mese, e il prezzo a consumo di Claude su payload delle dimensioni di un ticket costa pochi dollari al mese per un volume early-stage, non un abbonamento per persona.
Se hai già il budget per l'add-on nativo
Qui la logica cambia, ed è dove un livello custom può produrre un risparmio vero invece di essere solo un'alternativa. Copilot e Freddy Auto Triage hanno un prezzo per agente al mese. Quel costo scala linearmente con il numero di persone anche se il lavoro AI sottostante avviene una volta per ticket, non una volta per agente. Una pipeline Make.com e Claude ha un prezzo a consumo, ticket processati, non posti occupati. Su un team piccolo la differenza conta poco. Su un team di quindici o venti agenti, pagare una fee ricorrente per persona per qualcosa che gira centralmente comincia a essere un'inefficienza strutturale, non solo una preferenza.
L'avvertenza onesta vale anche al contrario. Se stai già pagando Copilot o Freddy e il tuo team è piccolo, il conto probabilmente non favorisce costruire un sistema parallelo. Attiva quello che già paghi. Costruisci il livello custom quando sei tagliato fuori dall'opzione nativa del tutto, o quando il prezzo per posto è cresciuto oltre il punto in cui ha senso per quello che l'AI sta effettivamente facendo.
Perché funziona solo con le fondamenta giuste
Niente di tutto questo regge se viene innestato su una knowledge base che nessuno ha mantenuto, o su percorsi di escalation che esistono solo in modo informale. Ho scritto di questo pattern di fallimento in L'AI deflection fallisce quando viene implementata sotto pressione, e questa architettura è il lato accurato di quell'articolo: è come appare la stessa automazione quando le fondamenta sono davvero già a posto.
La fase di categorizzazione dipende dal fatto che le definizioni delle code siano reali e aggiornate. La fase di deflection dipende interamente dal fatto che la knowledge base sia accurata, perché il modello può essere buono solo quanto quello che gli consegni. La fase di sintesi dipende dal fatto che i percorsi di escalation siano abbastanza chiari da rendere davvero rispondibile la "prossima azione richiesta". Salta una qualsiasi delle tre, e hai solo automatizzato più in fretta la cosa sbagliata.
Automatizzare il triage non sostituisce il giudizio. Toglie di mezzo il lavoro di smistamento cosi il giudizio si spende dove conta davvero.
Cosa ti direi di controllare prima di costruirlo
Fai un audit della knowledge base per primo, non per ultimo. Conferma che i tuoi percorsi di escalation siano documentati da qualche parte oltre alla memoria di qualcuno. Decidi quale soglia di confidenza attiva l'escalation umana prima di lanciare, non dopo che la prima risposta automatizzata sbagliata ha insegnato ai tuoi clienti a non fidarsi del sistema. Niente di tutto questo è lavoro affascinante, ed è tutto il vero progetto. Il setup Make.com e Claude sono le due ore facili. Le fondamenta sotto sono quello che determina se quelle due ore sono valse la pena.