Richiesta ricevuta via ticket web (cliente Enterprise, 3 anni: Marco Conti). Oggetto 'Problema su ordine 22345 — urgente'. Tipo: supporto tecnico urgente. Priorità ALTA.
AGENTE · INBOUND TRIAGE
Le richieste in ingresso arrivano al ruolo giusto, in pochi secondi.
Inbound Triage riceve ticket, chat e messaggi in ingresso da qualunque canale del cliente. Legge il contenuto, riconosce il tipo di richiesta, identifica la priorità, smista al ruolo del team corretto secondo le regole dichiarative configurate. I canali nativi attivi dal primo giorno sono Slack, Telegram, WhatsApp e HTTP; l'integrazione email si realizza in fase di delivery.
Inbound Triage al lavoro.
Smistato a Elisa Ferrara (supporto tecnico senior, di turno). Contesto allegato: anagrafica, prodotto, ultimi 3 ticket, estratto messaggio.
Ricevuto. Rispondo entro 15 minuti.
Registrato. SLA avviato. Evento tracciato in audit.
Perché esiste.
Il flusso inbound di un'azienda mid-large è massivo e poco strutturato. Ticket dal sito, messaggi su canali di lavoro, chat in pagina di prodotto. Tutto arriva al primo team che lo intercetta, che spende il tempo a leggere, classificare, smistare al collega giusto. Il problema operativo è il tempo perso nel passaggio orizzontale tra team e il rischio di richieste perse fra le righe.
Come smista in pochi secondi.
Inbound Triage si attiva su ogni nuova richiesta. In pochi secondi classifica il tipo (richiesta commerciale, supporto tecnico, reclamo, rimborso, domanda generica), identifica la priorità, smista all'operatore con il contesto pronto. Per richieste standard, l'agente può rispondere autonomamente con un'azione configurata.
La decisione resta all'operatore.
Per casi standard configurati dal team, l'agente può rispondere autonomamente (materiale informativo, conferma appuntamenti, FAQ ricorrenti). Per richieste che richiedono giudizio umano, smista all'operatore con il contesto pronto.
Responsabile customer service, operatori, director operations.
Responsabile customer service
Vede ridursi il tempo di gestione del primo livello del flusso inbound. Lo smistamento è automatico; il primo livello del team si concentra sui casi che richiedono giudizio.
Tipo sinistro RC Auto
Gravità Media
Liquidatore Dott. Ferrari · Nord-Est
Riserva iniziale € 4.200
Instradato ✓
Operatore del team
Riceve solo le richieste pertinenti al proprio ruolo, già classificate e con il contesto pronto: anagrafica cliente, prodotto acquistato, ticket precedenti, parole-chiave estratte dal messaggio. Recupera il tempo del filtraggio manuale e risponde più rapidamente.
WhatsApp «ho avuto un incidente, sono Rossi»
Tipo RC Auto · media gravità
Contraente Rossi Marco
Polizza #IT-2024-04471
Pratica aperta · CRM aggiornato
Direttore operations
Vede in modo strutturato il flusso inbound (volumi, tipologie, priorità, SLA medi) per allocare correttamente le risorse. La capacità del customer service si dimensiona su dati reali, non su percezioni.
Cross-canale · 7gg 1.420 menzioni
Chat sito NPS 7.2
Recensioni top theme: spedizione
Social · IG sentiment +0.4
Brief al brand owner
Una richiesta urgente arriva lunedì mattina. L'operatore la riceve già classificata.
L'agente è integrato con i canali di ingresso via webhook.
Per un'azienda B2B mid-market con un volume inbound di quattrocento richieste al giorno (ticket web, chat, messaggi su canali di lavoro), l'agente è integrato con i canali di ingresso via webhook e con il sistema di ticketing.
Supporto tecnico urgente, priorità alta, contesto pronto.
Alle dieci di lunedì arriva un ticket da un cliente registrato da tre anni. Oggetto 'Problema su ordine 22345'. Il cliente segnala un mancato funzionamento del prodotto e dichiara urgenza per una riunione del pomeriggio. In pochi secondi l'agente classifica come 'supporto tecnico urgente', identifica la priorità alta per la combinazione di urgenza dichiarata, cliente Enterprise e parole-chiave del problema, smista all'operatore di turno con il contesto pronto.
L'operatore riceve la notifica con tutto già estratto.
L'operatore riceve la notifica sul canale di lavoro con tutto già estratto. Risponde entro mezz'ora. L'evento — richiesta classificata, smistamento, risposta dell'operatore — resta nel registro audit per analisi di performance del team.
Configurazione e risorse tecniche.
Le regole di Inbound Triage sono dichiarative. Il team customer service del cliente definisce la tassonomia delle richieste (tipi di richiesta possibili, mapping a ruolo del team), le regole di priorità (cosa è urgente, cosa è normale, cosa è basso, con criteri configurati), le regole di risposta automatica per casi standard. Le regole vivono nel repository del cliente, versionate.
I canali nativi attivi dal primo giorno sono Telegram, Slack, WhatsApp e HTTP OpenAI-compatible (per webhook di form, chat, ticket). L'integrazione con le caselle email aziendali si realizza tramite adapter IMAP/webhook in fase di delivery dal team Exelab. Lo stesso vale per l'integrazione con sistemi di ticketing proprietari (Zendesk, Freshdesk) e per canali di social listening.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, prompt-injection, topic-guardrail, message-length-limit
- Canali nativi di ricezione
- Telegram, Slack, WhatsApp, HTTP OpenAI-compatible (webhook form, ticket, chat)
- Email aziendale come canale di ricezione
- integrazione realizzata in fase di delivery (adapter IMAP/webhook); non disponibile dal primo giorno
- Integrazione sistema di ticketing
- adapter dedicato realizzato in fase di delivery (Zendesk, Freshdesk, sistemi proprietari)
- Integrazione CRM
- HubSpot nativo
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS sul contesto cliente
- Registro
- immutabile, interrogabile con client SQL standard
Domande frequenti sull'agente.
La tassonomia è dichiarativa, scritta dal team customer service del cliente. Il pattern tipico include: categorie di richiesta (supporto tecnico, commerciale, reclamo, informazioni, amministrativo), priorità (urgente / alta / normale / bassa con criteri configurati), mapping categoria–ruolo del team. La modifica della tassonomia non richiede intervento del team Exelab.
No. I canali nativi attivi dal primo giorno sono Telegram, Slack, WhatsApp e HTTP OpenAI-compatible. L'integrazione con le caselle email aziendali (mailbox generiche del customer service, PEC) si realizza tramite adapter IMAP/webhook in fase di delivery. La discovery qualifica quali canali attivare per il caso reale.
Per casi standard configurati dal team, sì: invio di materiale informativo per richieste base, conferma di appuntamenti, risposta a FAQ ricorrenti. Per richieste che richiedono giudizio umano, l'agente smista all'operatore con il contesto pronto. La regola di risposta automatica è dichiarativa.
Il pattern tipico è 4-6 settimane. Discovery una settimana, configurazione tassonomia e regole di priorità due settimane, integrazione canali e ticketing una o due settimane, hand-off al team customer service una settimana. La durata dipende dal numero di canali integrati e dalla profondità della tassonomia.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Inbound Triage si configurerebbe sul caso del cliente. Quali canali di ingresso, quale tassonomia delle richieste, quali regole di priorità.