Vai al contenuto
← Tutti gli articoli
Assistenza

Console ticket · la postazione dell'assistenza

La Console ticket è la postazione dove il tuo team lavora le richieste: la coda con le viste salvate, la conversazione con il cliente al centro e il contesto con gli orologi degli SLA e l'IA sulla destra. Qui trovi anche l'e-mail in entrata, le macro, l'instradamento, le automazioni, gli incidenti, la base di conoscenza e le metriche del team.

La Console ticket è la postazione di assistenza di SellioCRM: un unico posto per lavorare le richieste in coda, dalla prima e-mail del cliente fino al sondaggio di soddisfazione. Usa lo stesso oggetto Ticket del CRM, quindi tutto ciò che già registri (oggetto, azienda, contatto, categoria, canale) resta valido e compare nella vista a 360 gradi del cliente.

Aprila dal menu laterale, nel gruppo Assistenza, alla voce Console ticket. L'oggetto Ticket resta nello stesso gruppo per chi preferisce l'inserimento tramite modulo, la bacheca per stato e le viste elenco.

Layout a tre pannelli

La console si apre su tre pannelli, pensati per chi risponde tutto il giorno: a sinistra le viste e le code con i contatori, al centro la conversazione con il cliente, a destra il contesto della richiesta. Sul cellulare il pannello delle viste diventa un selettore in cima all'elenco, per non occupare spazio.

La coda e le viste salvate

  • La colonna di sinistra propone viste già pronte con il numero di ticket in ciascuna: Aperti, Non assegnati, I miei, In attesa (del cliente o di terzi) e Risolti oggi.
  • Viste salvate: crea un filtro con un nome per stato, priorità, assegnazione e gruppo, per esempio Urgenti del team di supporto. Compare nell'elenco con il proprio contatore.
  • Sopra la coda trovi la ricerca (per oggetto o richiedente), il filtro di priorità e l'ordinamento: più recenti, più vecchi, per priorità o per scadenza SLA.
  • Ogni riga mostra l'oggetto, il richiedente, lo stato, la priorità, l'assegnatario e lo stato dello SLA, con etichette colorate per una lettura immediata.
  • Azioni in blocco: spunta la casella in alto per selezionare più ticket e applicare stato o assegnatario in una volta sola.

La console dell'agente

Aprendo un ticket, la conversazione compare al centro in ordine cronologico e le proprietà restano a destra: richiedente, canale di ingresso, etichette, stato, priorità, categoria, assegnatario e gruppo. Modificando una proprietà il salvataggio è immediato.

  1. Nell'area di scrittura, scegli Risposta al cliente per scrivere qualcosa che il cliente vedrà, oppure Nota interna per annotare qualcosa visibile solo al team.
  2. La nota interna appare evidenziata con un colore diverso, per non confonderla con ciò che è stato detto al cliente.
  3. Clicca su Allega per inviare file insieme al messaggio (fino a 25 MB ciascuno). In una risposta pubblica, i link degli allegati finiscono anche nel corpo dell'e-mail inviata al cliente.
  4. Scrivi e clicca su Invia (oppure Aggiungi nota).
  • Numero di protocollo: ogni ticket riceve un numero progressivo per organizzazione, nel formato #000123. È immutabile, compare nella coda, in cima al ticket e nell'e-mail di risposta.
  • Cronologia: la scheda Cronologia unisce in ordine i messaggi pubblici e interni e gli eventi di modifica (creazione, stato, priorità, assegnatario e altre proprietà).
  • Menzioni e follower: in una nota interna, usa Menziona per chiamare un collega. Riceve una notifica e inizia a seguire il ticket. Chiunque può seguire o smettere di seguire dal pannello delle proprietà e viene avvisato a ogni aggiornamento.

Macro e variabili

  1. Clicca su Gestisci macro per creare risposte salvate con titolo e corpo.
  2. Se vuoi, la macro definisce lo stato e la priorità da applicare quando viene usata.
  3. Nell'area di scrittura, seleziona la macro in Applica macro: il corpo entra nel campo di risposta e, se configurati, stato e priorità vengono applicati.

Macro e risposte accettano variabili tra doppie parentesi graffe, compilate all'invio: {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} e {{org_name}}, tra le altre. In Canali e instradamento definisci una Firma dell'assistenza, allegata alle risposte pubbliche; la firma personale dell'agente, quando esiste, ha la precedenza.

SLA: scadenze, sospensione, orari e festività

Lo stato dello SLA compare nella coda e nel ticket: In linea o SLA violato mentre è aperto, e Risolto in tempo o Risolto in ritardo dopo la risoluzione. A destra, gli orologi di prima risposta, prossima risposta e risoluzione fanno il conto alla rovescia e cambiano colore: verde, giallo vicino alla scadenza e rosso quando scade. Portando lo stato a Risolto o Chiuso, la data di risoluzione viene registrata automaticamente.

  • Sospensione automatica: spostando il ticket su In attesa del cliente o In attesa di terzi, l'orologio della risoluzione si ferma e compare l'etichetta SLA sospeso. Tornando a uno stato attivo, l'orologio riprende. Il tempo di attesa non pesa sul tuo obiettivo né sulle metriche.
  • Prossima risposta: ogni politica può avere un obiettivo di prossima risposta. L'orologio parte quando il cliente risponde e riparte a ogni nuova risposta pubblica dell'agente.
  • Orari lavorativi: nella scheda SLA e orari definisci giorni, orari e fuso orario (indica un fuso come Europe/Rome per rispettare l'ora legale). Disattiva la restrizione per contare il tempo reale (assistenza 24 ore su 24, 7 giorni su 7).
  • Festività: registra le festività per data. In quei giorni il servizio è considerato chiuso e la scadenza slitta al primo giorno lavorativo successivo.
  • Politiche: ogni politica corrisponde per priorità, gruppo o categoria (vuoto significa qualunque) e definisce obiettivi in minuti lavorativi. Vengono valutate nell'ordine dell'elenco e vale la prima attiva che corrisponde. Se nessuna politica corrisponde, valgono le ore per priorità di Impostazioni, Assistenza.
  • Rischio di violazione: una barra stimata indica se il ticket ha un rischio basso, medio o alto di sforare la scadenza, con la relativa motivazione.
Esempio: Ticket critico aperto venerdì alle 17, con 4 ore di SLA e orario di servizio dalle 9 alle 18: 1 ora scorre il venerdì e le 3 restanti scorrono il lunedì, quindi la scadenza cade lunedì alle 11, e non nel fine settimana.

E-mail in entrata: l'e-mail diventa un ticket

  1. Apri la Console ticket e vai alla scheda Canali e instradamento.
  2. Clicca su Genera indirizzo di supporto. Il CRM mostra un indirizzo nel formato support+tuo-codice@dominio.
  3. Nel tuo provider di posta, inoltra la casella di supporto a questo indirizzo.
  4. Fatto: le nuove e-mail aprono ticket e le risposte del cliente entrano nella stessa conversazione.

Il mittente viene associato a un Contatto tramite l'e-mail; la prima volta il Contatto viene creato e il canale del ticket risulta E-mail. Ogni risposta inviata al cliente porta il codice del ticket nell'oggetto, nel formato [#XXXXXXXX]. Quando il cliente risponde mantenendo il codice, il messaggio entra nella stessa conversazione invece di aprire un ticket nuovo; se il ticket era risolto o chiuso, viene riaperto.

Conferma automatica di ricezione: in Canali e instradamento, attiva la Conferma di ricezione e scrivi il testo con le variabili. Quando un'e-mail apre un ticket nuovo, il richiedente riceve subito la conferma con il numero di protocollo. Nasce disattivata.

💡 La ricezione è autenticata e ogni e-mail viene attribuita soltanto all'organizzazione titolare dell'indirizzo di destinazione, senza mescolare aziende diverse. Risposte automatiche, avvisi di assenza e messaggi di mancato recapito vengono ignorati, per non creare ticket a catena, e il CRM non risponde mai in automatico a una risposta automatica.

Unire ticket e conversazioni parallele

Quando lo stesso argomento è diventato due ticket, apri quello che resterà come principale e clicca su Unisci. I messaggi dell'altro passano al principale e questo viene chiuso con un avviso che indica dove sono finiti.

Devi parlare con un fornitore o con un altro team senza che il cliente lo veda? Usa le Conversazioni parallele, subito sotto la conversazione principale: indica un oggetto e i partecipanti tramite e-mail, scrivi il messaggio e il CRM lo invia. Tutto resta registrato nel ticket, separato dalla conversazione con il cliente.

Assegnazione automatica e automazioni

In Canali e instradamento, definisci per ogni team come vengono distribuiti i ticket quando entrano nel gruppo: Round-robin (a rotazione tra gli agenti) o Per carico (prima l'agente con meno ticket aperti). Lascia su Disattivato per assegnare sempre a mano.

Nella scheda Automazioni crei regole del tipo quando qualcosa cambia, allora agisci. Ogni regola ha un evento (il ticket viene creato, oppure una proprietà cambia), condizioni facoltative su stato, priorità, categoria, gruppo e assegnatario, e una o più azioni.

  • Azioni: impostare stato, priorità o categoria; assegnare a un agente o a un gruppo; applicare una macro; notificare l'assegnatario; notificare l'intero gruppo; inviare il sondaggio di soddisfazione.
  • Le regole scattano nel momento esatto della creazione o della modifica, ovunque nel CRM: console, modifica del record o integrazione.
  • Trascina dalla maniglia a sinistra del nome per riordinarle; vengono valutate dall'alto verso il basso.
  • Automazioni basate sul tempo: girano da sole a intervalli regolari e agiscono in base alla scadenza, per esempio inoltrare a un livello superiore un ticket senza prima risposta da X ore lavorative, avvisare quando la scadenza sta per essere superata o chiudere quelli risolti da N giorni. Ciascuna agisce al massimo una volta per ticket.
  • Webhook in uscita: in Canali e instradamento, avvisa sistemi esterni a ogni evento del ticket (creato, aggiornato, risolto, nuovo messaggio), inviando a una URL firmata o ai canali di messaggistica già collegati nell'hub delle Integrazioni.

Intelligenza artificiale sul ticket

Con l'IA attiva, il pannello di destra analizza il ticket e suggerisce: categoria e urgenza, sentiment del cliente con un punteggio da 0 a 100, riepilogo dello storico, ticket simili e articoli della base di conoscenza. Nell'area di scrittura, il pulsante Suggerisci risposta (IA) redige una bozza a partire dalla conversazione, nella lingua della tua interfaccia. L'IA non invia mai nulla al cliente da sola: tu rivedi, modifichi e decidi.

💡 L'analisi resta in cache e viene rifatta solo quando il testo del ticket cambia, così il costo rimane basso. Senza IA configurata, il pannello mostra un chiaro avviso di indisponibilità invece di dare errore, e i ticket simili, il rischio SLA e gli articoli suggeriti continuano a funzionare.

Base di conoscenza e help center

La tua base di conoscenza alimenta un portale pubblico di self-service con ricerca per titolo, contenuto ed etichette. In fondo alla pagina, il modulo mi serve ancora aiuto suggerisce articoli correlati mentre la persona scrive (deflessione) e, se serve comunque, apre un ticket direttamente nel tuo CRM.

  • In Marketing, Base di conoscenza, la scheda Articoli consente di scrivere, modificare e inviare in revisione; la scheda Revisione è la coda di approvazione (Approva e pubblica oppure Rifiuta con motivazione); la scheda Importa crea una bozza a partire da una URL; la scheda Feedback mostra gli articoli più utili e quelli che richiedono attenzione, in base ai voti dei lettori.
  • Ogni salvataggio conserva uno storico e puoi ripristinare una versione precedente.
  • Ogni articolo ha una lingua e la ricerca pubblica può filtrare per lingua del lettore.
  • Nella scheda SLA e orari componi i moduli di apertura del portale: oltre a nome, e-mail, oggetto e messaggio, aggiungi campi tuoi di testo, elenco o e-mail, con visualizzazione condizionale. Contrassegnane uno come predefinito perché l'help center lo usi.

Incidenti e pagina di stato

  1. Apri la scheda Incidenti della console e crea un incidente con titolo e gravità.
  2. Collega i ticket coinvolti nello stesso evento.
  3. Pubblica aggiornamenti nella cronologia dell'incidente e comunica con tutti gli interessati in una volta sola, via e-mail ai richiedenti dei ticket collegati.
  4. Alla risoluzione, registra la causa radice e il post-mortem.
  5. Contrassegnalo come pubblico per esporre una pagina di stato aperta ai tuoi clienti.

Soddisfazione e metriche

Quando risolvi o chiudi un ticket, il CRM invia automaticamente un sondaggio di soddisfazione via e-mail al richiedente, con voto da 1 a 5 e un commento. Avviene una sola volta per ticket. Quando il cliente risponde, il voto compare nel blocco Soddisfazione della console e viene salvato nei campi del ticket stesso. Attivalo o disattivalo in Automazioni, Sondaggio di soddisfazione, e usa Reinvia sondaggio quando vuoi richiederlo di nuovo.

Nella scheda Metriche segui il periodo di 7, 30 o 90 giorni: ticket creati, risolti e aperti, tempo medio di prima risposta, tempo medio di risoluzione, percentuale entro SLA, soddisfazione media con il tasso di risposta, backlog, risoluzione al primo contatto, tasso di riapertura e carico per team, con segmentazione per canale e per categoria e una tabella per agente. Gli indicatori mostrano la variazione rispetto al periodo precedente e un mini grafico giornaliero, e i report si esportano in PDF o XLSX.

💡 Dove un numero più basso è meglio, come il tempo di prima risposta o il backlog, la freccia di variazione diventa verde quando il numero scende.

Domande frequenti

  • L'invio del sondaggio dipende dall'e-mail del richiedente, dal campo del ticket o dal Contatto collegato, e dal fatto che l'invio di e-mail sia configurato.
  • Quando esporti o rendi anonimi i dati di un interessato in Impostazioni, Privacy, anche il contenuto dei messaggi e delle valutazioni di quel richiedente viene incluso o reso anonimo.
  • Le integrazioni con help desk esterni creano ticket nel CRM in automatico; una volta creati, li lavori qui come qualunque altro.
  • Anche dall'applicazione mobile segui la coda, apri un ticket, rispondi e cambi lo stato.
  • Perché sia il cliente a seguire da solo i propri ticket, rispondere e riaprirli, consulta l'articolo sul portale del cliente.

Casi padre e figlio, regole di risposta automatica e mappatura del canale

Un caso ora può dipendere da un altro. Imposti il padre sul caso e i figli compaiono in elenco, con una guardia che rifiuta un ciclo o una catena troppo profonda, e un avviso quando provi a chiudere un padre che ha ancora figli aperti. La risposta automatica è diventata **regole** invece di un testo fisso: ogni regola ha le sue condizioni (canale, categoria, priorità, orario lavorativo, solo primo messaggio, parole chiave) e il suo messaggio, e vince la prima che corrisponde. La guardia anti-ciclo non è disattivabile, di proposito: rispondere a una casella automatica è come due segreterie telefoniche che si parlano all'infinito. E il canale del caso ora viene da una **tabella di mappatura** che controlli tu, così il caso arrivato per telefono nel tuo help desk smette di essere registrato come "portale" e i report per canale smettono di mentire.

Dove si trovano: il caso padre e i figli compaiono sul ticket stesso, nel pannello **Casi collegati**. Le regole sono in **Impostazioni → Risposte automatiche**, e la mappatura in **Impostazioni → Canali del ticket**; entrambe sono per chi amministra l'account.

Il ticket ha una terza scheda, **Contesto**, ed è lì che la console smette di mandarti su un'altra schermata. Raccoglie i campi del ticket stesso (compresi quelli che hai creato), i record collegati, le attività e le task, i file, i casi padre e figli, e gli altri ticket aperti dello stesso cliente. Se hai disegnato un Canvas per l'oggetto Ticket, quel layout vale anche qui, così non disegni due volte la stessa cosa.

Chiudere un ticket con un codice di esito

Risolvere un ticket voleva dire scrivere testo libero nel campo Risoluzione. Questo descrive che cosa è successo, ma non lo classifica: due agenti scrivono lo stesso esito in dieci modi diversi, e nessuno riesce a dire quanti ticket del mese scorso erano un difetto del prodotto e quanti un errore di configurazione. Nemmeno il campo Categoria aiuta, perché classifica l'argomento all'apertura del ticket, non l'esito alla chiusura.

Per questo l'esito ora è un elenco breve che controlli tu, in **Impostazioni → Codici di esito**. Ogni codice ha un'etichetta, un ambito e un'opzione che stabilisce se sceglierlo richiede una spiegazione (usala su "Altro", che da solo non spiega nulla). Lo stesso elenco vale per i ticket e per le telefonate, così mantieni un solo vocabolario invece di due che dicono la stessa cosa.

  1. Apri Impostazioni → Codici di esito e fai clic su Genera l'elenco predefinito, oppure scrivi il tuo elenco.
  2. Attiva "Richiedi un esito alla risoluzione" se vuoi che la regola valga.
  3. Nella console, scegli l'esito nel riquadro Chiusura, a destra, prima di risolvere il ticket.

Tre comportamenti da conoscere, perché sono voluti:

  • **Attivare l'obbligo prima di avere dei codici non blocca nulla.** Altrimenti congelerebbe tutti i ticket dell'azienda il giorno in cui qualcuno spunta la casella, senza niente da scegliere.
  • **A far valere l'obbligo è il server, non lo schermo.** Chiudere dall'elenco, da una macro, dalla API o dal terminale passa dallo stesso controllo.
  • **Un codice già usato non si può eliminare, solo disattivare.** Eliminarlo toglierebbe il significato a ogni ticket chiuso con quel codice, e i tuoi report vecchi comincerebbero a mentire in silenzio.
💡 Correggere un esito sostituisce il precedente. C'è un esito per ticket, non una pila di versioni.

Testo rapido: frasi pronte dietro una scorciatoia che digiti

Finora l'unico testo pronto della console era la macro, e la macro applica anche uno stato e una priorità: inserire una frase cambiava il ticket senza che nessuno lo avesse chiesto. Il testo rapido non scrive nulla oltre al testo. Proprio per questo può essere leggero, personale e raggiungibile con una scorciatoia che digiti.

  1. Nell'editor, digita :: seguito dall'inizio di una scorciatoia, per esempio ::hi.
  2. Continua a digitare per restringere l'elenco, oppure digita solo :: per vedere l'intera libreria.
  3. Scegli una frase dall'elenco, oppure completa la scorciatoia e conferma per inserire quella che corrisponde esattamente.
  4. Rileggi il testo prima di inviare: le variabili tra doppie parentesi graffe, come {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} e {{org_name}}, vengono compilate all’invio della risposta, come nelle macro.

Le librerie sono tre: **personale** (la vedi solo tu), **del team** (chi fa parte di quel team) e **dell'azienda** (tutte le persone che rispondono). La stessa scorciatoia può esistere in più di una, e vince quella più vicina a te: la tua frase personale batte quella del team, e quella del team batte quella dell'azienda. Così tieni la tua versione di ::hi senza chiedere a nessuno di cambiare lo standard della casa.

  • **Una scorciatoia non ha spazi né due punti**, e arriva a 40 caratteri. Una scorciatoia con uno spazio non sarebbe mai digitabile dopo ::, quindi viene rifiutata al salvataggio invece di diventare una frase che non compare mai.
  • **La scorciatoia è unica dentro la propria libreria.** Lo stesso ::hi può esistere come frase personale e come frase aziendale; due aziendali no.
  • **La ricerca ignora maiuscole e accenti** e guarda la scorciatoia, poi il titolo, poi la cartella. Il corpo non viene mai cercato: una parola comune corrisponderebbe a mezza libreria e la scorciatoia perderebbe senso.
  • **L'ordine è sempre lo stesso**: scorciatoia che inizia con quello che hai digitato, poi scorciatoia che lo contiene, poi titolo, poi cartella. Un elenco che cambiasse ordine tra due aperture ti farebbe scegliere la frase sbagliata per memoria del gesto.
  • **La cartella è testo libero** e serve solo a raggruppare la libreria sullo schermo. Non c'è un elenco di categorie separato da mantenere.

Le tue frasi personali sono tue: le crei, le modifichi e le elimini senza chiedere niente a nessuno. Le frasi del team e dell'azienda sono lo standard della casa, perché cambiano quello che domani tutti manderanno ai clienti, quindi appartengono a chi amministra le impostazioni. Nessuno modifica la frase personale di un'altra persona, nemmeno chi amministra.

💡 Chi amministra può generare una libreria aziendale iniziale: saluto, conferma di ricezione, richiesta di ulteriori informazioni, attesa del cliente, escalation, risolto e chiusura. Rieseguirla non duplica nulla e non sovrascrive mai ciò che hai riscritto.

E-mail del ticket: un testo tuo per evento, lingua, categoria e coda

Cinque momenti del ticket possono portare un testo tuo: **aperto**, **aggiornato**, **risolto**, **sondaggio** e **chiusura**. Ogni modello è scritto in una lingua e può, se vuoi, restare limitato a una categoria, a una coda, o a entrambe.

La scelta segue un ordine dichiarato, e si legge meglio in due metà: il sistema decide prima **che cosa dire** e solo dopo **in che lingua dirlo**. Le famiglie vengono visitate dalla più specifica alla più generica: coda e categoria, poi coda, poi categoria, poi quella generica. La coda pesa più della categoria perché la coda è il team che risponde e il testo è la sua voce; la categoria è solo l'argomento.

  • **Filtro vuoto è jolly, filtro compilato deve corrispondere.** Un modello senza categoria vale per qualunque categoria. Un modello con categoria vale solo per quella, e non fa mai da testo generico.
  • **La lingua, dentro la famiglia scelta**: prima quella esatta (pt-BR), poi la stessa lingua base (pt-PT vale per pt-BR), poi la lingua di riserva, che è l'inglese finché non ne indichi un'altra.
  • **Una famiglia che non ha nessuna di quelle tre lingue viene saltata**, e si tenta la successiva, meno specifica. Mandare il testo generico nella lingua di chi legge è meglio che mandare il testo giusto in una lingua che quella persona non legge.
  • **La specificità viene prima della lingua.** Se la famiglia Fatturazione esiste solo in inglese e quella generica esiste in portoghese, chi scrive in portoghese riceve il testo di Fatturazione in inglese. Il rimedio è aggiungere la riga in portoghese della stessa famiglia, che è esattamente ciò che la tabella ti chiede.

La lingua che conta è quella di **chi ha aperto il ticket**, la persona che legge l'e-mail, non quella dell'operatore. Oggetto e corpo accettano le stesse variabili delle macro e dei testi rapidi, e l'anteprima mostra quale modello ha vinto e in che lingua prima che esca qualsiasi cosa.

💡 Se non registri niente, non cambia niente. Senza modelli il ticket continua a comportarsi esattamente come oggi, ed è per questo che si può adottare una coda alla volta.

Swarm: chiamare persone su un caso difficile e mettere per iscritto che cosa ne è uscito

La sessione di swarm registra il rituale che finora viveva sparso nelle note interne: chi è stato chiamato, in che ruolo, per rispondere a quale domanda, entro quando, e che cosa si è concluso. **Registra la sessione; non apre un canale Slack e non avvia una videochiamata.** La conversazione continua dove già avviene (nota interna, menzione, follower, chat interna); quello che nasce è la sua memoria.

  1. Sul ticket, apri uno swarm e scrivi il motivo. La scadenza è facoltativa e non può stare nel passato.
  2. Chi apre la sessione è il **relatore**, e inizia a seguire il ticket.
  3. Chiama le persone che ti servono come **specialista** (senza limite) o come **verbalizzante** (posto unico). Chi viene chiamato riceve un avviso con il motivo e inizia a seguire il ticket.
  4. Chiudi la sessione con l'**esito**. Torna sul ticket come nota interna, così la persona successiva sul caso lo legge senza aprire altro.
  • **Una sola sessione aperta per ticket.** Due dividerebbero l'attenzione in due, e l'esito non avrebbe più una casa sola.
  • **Relatore e verbalizzante sono posti unici finché sono occupati**; lo specialista non ha tetto, perché chiamare persone è proprio lo scopo dello swarm.
  • **Il relatore non esce dalla sessione.** L'uscita è chiuderla dicendo che cosa si è concluso, anche quando è 'non si è concluso nulla'.
  • **Chiudere richiede l'esito**, e termina la partecipazione di tutti, così i minuti di persone smettono di crescere da soli.
  • **Chi è uscito resta nel registro.** Chi ha partecipato deve restare vero anche domani.
💡 Il riepilogo mostra quanto è durata la sessione, la somma dei minuti di tutte le persone che vi hanno preso parte e se la scadenza concordata è stata rispettata. Senza scadenza non c'è nulla da rispettare né da mancare, e quel dato resta vuoto.

Follow up programmato e promemoria personale

Due azioni che si somigliano e non sono la stessa cosa. Il **follow up** è un'attività sul ticket: può restare a un'altra persona e compare nell'elenco del giorno come qualsiasi attività. Il **promemoria** è sempre tuo, e suona all'ora che hai chiesto, non nel riepilogo di fine giornata.

  1. Sul ticket, scegli Programma follow up oppure Ricordamelo.
  2. Scrivi quando, con parole tue: domani 9, tra 2 ore, venerdì, la prossima settimana, o una data come 2026-09-10 14:30. Le dieci lingue del prodotto vengono capite.
  3. Nel follow up scegli il tipo (attività, chiamata, e-mail o riunione) e, se vuoi, la persona che lo prende. Il promemoria è sempre un'attività, e sempre tuo.
  • **Un giorno senza ora diventa le 09:00** nel fuso dell'organizzazione, lo stesso valore predefinito usato dal resto del prodotto.
  • **Una durata mantiene l'ora attuale**, perché la durata se la porta già dentro. Minuti e ore contano in tempo reale; giorni e settimane camminano sul calendario, così l'ora legale non li sposta.
  • **Un orario già passato va al giorno dopo**, come fa qualsiasi app di promemoria. Un giorno nel passato, invece, viene rifiutato e non indovinato: indovinare quale giorno intendevi sarebbe inventare.
  • **Oltre 365 giorni viene rifiutato.** È il filtro del dito sbagliato, il 2027 digitato nel 2026 che nessuno vedrebbe mai.

Lo schermo ripete l'orario davvero **salvato**, e non le parole che hai digitato, ogni volta che le 09:00 sono state assunte per te o l'orario è stato spostato al giorno dopo. Due risposte diverse alla domanda 'quando scade' sono esattamente la confusione che quell'eco esiste per evitare.

💡 Il follow up è un'attività normale collegata al ticket, quindi compare nella cronologia, nel tuo elenco di attività e nel calendario. Non c'è un secondo posto da guardare.

Schede di lavoro: più casi aperti allo stesso tempo

La console apriva un caso alla volta, e sceglierne un altro sostituiva il precedente. Chi lavora a volume tiene tre o quattro casi in corso (uno che aspetta il cliente, uno che aspetta l'ingegneria, uno che sta scrivendo), e ogni passaggio perdeva la bozza e il punto dello scorrimento. La barra delle schede di lavoro sta sopra la conversazione e compare appena c'è una seconda cosa aperta.

  • **Un clic singolo apre una scheda di anteprima**, mostrata in corsivo, e l'anteprima successiva ne prende il posto. Scriverci dentro, o fissarla, la rende definitiva. Senza questo, scorrere una coda di venti casi aprirebbe venti schede.
  • **Lo stesso caso non si apre mai due volte.** Cliccarlo di nuovo attiva solo la scheda, con la bozza e la sotto-scheda che vi avevi lasciato.
  • **Il punto blu segnala che c'è una risposta scritta e non inviata** in quella scheda. È quello che devi vedere prima di chiuderla, non dopo.
  • **Ogni scheda ricorda la propria sotto-scheda** (Conversazione, Cronologia o Contesto), così riprendi dove eri e non dall'inizio.
  • **Fino a otto schede.** Oltre, esce la scheda più vecchia senza bozza; se tutte hanno una bozza, il limite cede, perché perdere lavoro scritto è peggio di una barra lunga.
  • **Chiudere la scheda attiva attiva quella alla sua destra**, e quella a sinistra quando a destra non ce n'è, come fa un browser.

**Chiudi le salvate** chiude tutte le schede senza bozza e conserva quelle con la bozza: la pulizia non porta mai via lavoro scritto. Le schede vivono nel tuo browser, su questo dispositivo, quindi sono tue e non del team.

💡 Se l'oggetto di un caso cambia mentre la sua scheda è aperta, la scheda viene rinominata insieme a lui.

Contesto del cliente: salute, valore, piano e storico dell'assistenza

La scheda Contesto di un caso si apre con un blocco che risponde, prima che tu scriva una sola riga, se questo cliente sta bene, quanto vale, su quale piano si trova e quante volte è già stato servito male. Niente di tutto questo lo digita qualcuno: tutto è composto da ciò che il prodotto già conserva su quell'account.

  • **Salute** mostra il punteggio e, cosa più importante, **i fattori che lo formano**. Il numero da solo non ti dice nulla su cui agire; i fattori dicono se il problema è l'uso, l'assistenza, il denaro o la relazione.
  • **Valore** porta i ricavi vinti, i ricavi ricorrenti e l'ultimo movimento, perché un'espansione del mese scorso e una riduzione del mese scorso non sembrino la stessa cosa.
  • **Piano** dice quale piano, da quando e quando si rinnova, e segnala un rinnovo già marcato a rischio.
  • **Storico dell'assistenza** conta i casi precedenti, quanti hanno violato lo SLA, la soddisfazione di questo cliente e se c'è un caso critico aperto proprio adesso.

Sotto il blocco, tutta la conversazione con quel contatto compare su una riga sola, qualunque sia il canale: chat, SMS, WhatsApp, e-mail e casi insieme, in ordine. È lo stesso storico che mostra la scheda del contatto, portato dentro la console perché nessuno debba cambiare schermata solo per ricordare che cosa è già stato detto.

💡 Quando un blocco non può essere mostrato, dice perché invece di mostrare zero. **Zero e «non lo sappiamo» sono cose diverse.** Leggere «ricavi 0» porta a una conversazione con il cliente; leggere «non hai il permesso di vedere questo» ne porta a un'altra. Ricavi e piano seguono lo stesso permesso del resto dei dati finanziari, e quando l'account non è mai stato valutato, o non ha un abbonamento, o non ha casi precedenti, il pannello lo dice esattamente. Ogni blocco nomina anche la propria fonte, così sai di che cosa ti stai fidando prima di ripetere un numero al cliente.

Supervisione: la stessa operatività, vista da chi la coordina

La console risponde a «che cosa faccio adesso?» a chi sta rispondendo. La supervisione risponde a un'altra domanda, per un'altra persona: se l'operatività sta reggendo in questo momento. È una schermata a parte, fatta per restare aperta su un televisore, e si aggiorna da sola.

  • **L'operatività sta reggendo?** Elementi aperti per coda, quanti sono senza responsabile, quanti aspettano noi e quanti violeranno la scadenza nella prossima ora. Sapere che cosa sta per violare non è la stessa cosa che sapere che cosa ha già violato, e il pannello tiene le due cose separate.
  • **Chi è sovraccarico e chi è libero?** Elementi aperti per persona rispetto al limite di quella persona, chi è uscito dalla rotazione e chi guida la coda.
  • **Dov'è il collo di bottiglia?** La coda con l'attesa più lunga, il canale che porta più ingressi, e la coda da cui nessuno riesce a prendere nulla, perché richiede una competenza che nessuno nel team possiede.
  • **Che cosa è successo nell'ultima ora?** Il registro delle assegnazioni è già di sola aggiunta, quindi il pannello si limita a mostrarlo.
💡 Due avvertenze oneste che la schermata stessa dichiara. In un'operatività molto grande, il rischio di scadenza è misurato su un campione dei casi più vecchi, mentre i totali restano esatti: il pannello avvisa quando un numero viene dal campione, invece di presentare una stima come un conteggio. E una coda che richiede una competenza che nessuno possiede lascia elementi senza responsabile **di proposito**, ed è per questo che si accende in rosso: non è un guasto del sistema, è una configurazione che aspetta una persona.

La supervisione è di chi amministra, ed è deliberato: mostra il carico di ogni persona e chi è fuori dalla rotazione. Monitorare le persone è un atto di gestione dichiarato, non un effetto collaterale dell'aprire una schermata. Il pannello è di sola lettura, quindi al suo interno nulla riassegna né ridà priorità: indica, e il lavoro si fa dove già abita.

Catalogo dei servizi: una vetrina al posto del caso in bianco

Chi oggi ha bisogno di qualcosa di interno apre un caso vuoto e scrive quello che ricorda. Il catalogo sostituisce tutto questo con una vetrina: un elenco di ciò che si può chiedere, ogni voce con il proprio modulo, la propria coda e la propria priorità. La richiesta apre un caso vero, già compilato.

  1. In Impostazioni → Catalogo dei servizi, chi amministra costruisce il catalogo: categorie, voci e le domande che ogni voce pone.
  2. Chiunque apre la stessa schermata, sceglie un servizio e compila il suo modulo.
  3. Il sistema apre un caso nella coda della voce, con la sua priorità e le risposte dentro, nello stesso formato che il portale usa già.
  4. Se l’elemento richiede approvazione, la richiesta si apre subito e l’approvazione in sospeso ne blocca la risoluzione: nessuno la chiude prima che qualcuno decida.
  • **Disattivare una voce non annulla quello che è già stato chiesto.** Vuol dire «non chiedere più questo», mai «annulla quello che è in corso»: i casi già aperti restano aperti, con la stessa coda e la stessa scadenza.
  • **Una voce già richiesta non si può eliminare, solo disattivare.** Eliminarla farebbe mentire lo storico su ciò che è stato chiesto.
  • **La richiesta congela una fotografia del modulo.** Se cambi le domande più avanti, la richiesta vecchia continua a mostrare le domande a cui quella persona ha davvero risposto.
  • **Lo stato di una richiesta non è una copia.** Viene letto ogni volta dall'approvazione stessa, quindi non può mai discostarsi da ciò che il motore di approvazione ha deciso altrove.
💡 Una voce contrassegnata come «richiede approvazione», in un'organizzazione senza una policy di approvazione che le corrisponda, viene evasa subito, perché il motore risponde «approvato» quando nessuna policy si applica. La schermata lo dice nel punto stesso in cui attivi il requisito. Crea prima la policy, poi il requisito.

Catalogo dei servizi: evadere la richiesta

Una voce del catalogo può portare un piano di evasione: quello che deve succedere dopo che qualcuno ha chiesto il servizio, e in che ordine. Ogni passo diventa un'**attività vera**, con un responsabile, una scadenza, un promemoria e un posto nell'elenco di attività che la persona che deve farla apre tutti i giorni, e la dipendenza fra i passi è la stessa che le attività hanno già. Il piano viene congelato nella richiesta quando l'evasione **inizia**, non nel momento in cui il servizio viene chiesto: modificare la voce più avanti non riscrive mai una richiesta già in corso, e la versione nuova vale dall'avvio successivo in poi.

Chi coordina il lavoro ha la coda di evasione: che cosa è in sospeso, presso chi e da quanto tempo. Una richiesta approvata che nessuno ha ancora avviato compare **in cima**, con la sua età bene in vista, perché approvare non avvia niente: qualcuno deve ancora mettere in moto il piano. Una voce che non ha nessuna approvazione da aspettare parte appena viene richiesta.

  1. Disegna il piano sulla voce del catalogo: oggetto, tipo di attività, scadenza in giorni contati dall'avvio, chi la riceve e, quando conta, il passo precedente da cui dipende.
  2. Quando qualcuno chiede il servizio, il ticket si apre come si è sempre aperto. Se la voce richiede approvazione, l'evasione aspetta la decisione; se non c'è nessuna approvazione da aspettare, parte subito.
  3. All'avvio dell'evasione il piano viene congelato nella richiesta e le attività nascono nell'ordine delle dipendenze, ognuna con un titolare e una scadenza.
  4. Il pannello della richiesta, dentro il ticket, mostra ogni passo, presso chi si trova, la scadenza e che cosa è già fatto. I passi compaiono anche nella cronologia del ticket, perché sono normali attività legate al caso.
  5. Clicca su Consegnato quando il servizio è arrivato davvero alla persona. Un passo obbligatorio ancora aperto blocca, con il motivo bene in vista; un passo segnato come non obbligatorio non blocca mai.
  6. Segnato per sbaglio? Storna la consegna con una nota. È una scrittura nuova: la consegna precedente resta nello storico, non si cancella niente.
💡 Un passo la cui attività è stata eliminata compare come **abbandonato**, mai come completato. Non blocca la consegna (obbligarti a ricreare un'attività appena eliminata sarebbe una regola impossibile da rispettare) e non conta nemmeno come lavoro fatto. Il prodotto non sa che cosa sia successo a quel passo, e lo dice invece di tirare a indovinare.

Apparecchiature del cliente: il caso riguarda questa apparecchiatura

Un ticket adesso può puntare all'**apparecchiatura** del cliente, l'unità installata con il suo numero di serie, e non più solo al modello di prodotto che è stato venduto. Nel ticket la scegli dal parco installato del cliente, cercando per numero di serie, che è come il cliente la identifica al telefono. Si può collegare solo un'apparecchiatura del cliente di quel ticket, e da lì in poi è lo storico dell'apparecchiatura stessa a raccontare l'assistenza: i casi collegati, scollegati e risolti stanno sulla stessa cronologia dell'installazione, degli spostamenti e delle manutenzioni.

Il fermo lo registrano le **persone**, oppure parte dal ticket stesso. Qui non c'è telemetria né segnale della macchina, quindi disponibilità, MTTR e MTBF valgono esattamente quanto vale la disciplina di chi registra. La schermata lo dice ad alta voce invece di abbellire il numero.

  • Garanzia e copertura: il contrassegno di garanzia (in garanzia, in scadenza, scaduta) e il contratto di assistenza compaiono prima che tu apra bocca con il cliente.
  • Ubicazione: spostare l'apparecchiatura registra dov'è andata, quindi lo storico dei luoghi è la lettura di quei movimenti, non un campo unico che dimentica il passato.
  • Sostituzione con discendenza: sostituire manda in pensione l'unità vecchia e crea quella nuova, che eredita conto, contratto e ubicazione, con un evento da ciascun lato che punta all'altro.
  • Ciclo di vita: attiva, in manutenzione, in RMA, dismessa e stralciata. Quello che è stralciato non torna, perché lo stralcio è un fatto contabile; la strada per tornare indietro è registrare una nuova apparecchiatura con la discendenza della vecchia.
  • Fermo: aprire e chiudere un fermo, pianificato o no. La stessa apparecchiatura non è mai ferma due volte nello stesso momento, e i fermi sovrapposti vengono fusi prima di sommarli, così la disponibilità non diventa mai negativa.
  • Disponibilità: la percentuale sulla finestra, con la quota pianificata separata da quella non pianificata, perché una finestra di manutenzione concordata con il cliente non è una promessa rotta. MTTR e MTBF restano vuoti senza abbastanza campioni.
  • Rischio e prossima azione: criticità, età, guasti ripetuti, copertura e disponibilità misurata compongono un punteggio spiegabile, e il motore dichiara che cosa ha dovuto presumere per mancanza di dati.
💡 Un'apparecchiatura senza nessun fermo registrato **non** è un'apparecchiatura con il 100% di disponibilità: è un'apparecchiatura che nessuno ha misurato, e la lettura dice misura mancante invece di mostrare un numero tondo. Per lo stesso motivo la manutenzione viene suggerita solo quando dici al prodotto ogni quanti mesi si fa. Senza un piano registrato resta zitto, perché una data inventata è peggio del silenzio.

Base di conoscenza: responsabilità, revisione e utilizzo

La base di conoscenza ha guadagnato lo strato che risponde a chi risponde di ogni articolo e se ci si può ancora fidare: un responsabile, un revisore, un ciclo di revisione in giorni e, da questi, l'articolo **scaduto di revisione**. Il quadro di governance è dal vivo, viene calcolato nel momento in cui lo apri, quindi non dipende mai dal fatto che la passata notturna sia andata. Viene chiesto conto solo dell'articolo pubblicato: una bozza è ancora in scrittura e un articolo archiviato è fuori circolazione.

La visibilità non è più solo pubblicato o no. Ogni articolo adesso ha un pubblico: **esterno** è quello che l'help center e il portale mostrano a chiunque abbia il link, e **interno** non esce mai dal CRM. Ogni articolo nasce esterno, esattamente come si comportava prima, quindi non cambia niente finché non decidi diversamente.

  • Responsabile e revisore sono persone della tua squadra, impostate articolo per articolo. Senza responsabile l'articolo viene segnalato nel quadro, ed è lì che la mancanza si risolve.
  • Ciclo di revisione in giorni: la prossima revisione è l'ultima revisione più il ciclo. Un articolo senza ciclo non scade mai, e nessuno viene sollecitato per lui.
  • L'avviso di revisione scaduta va al **responsabile** dell'articolo, una volta per scadenza. Un articolo senza responsabile non avvisa nessuno, perché rovesciare ogni giorno la metà senza padrone nella campanella di chi amministra insegna alle persone a ignorare la campanella.
  • Archiviare toglie un articolo dalla circolazione con autore, data e traccia di controllo, invece che qualcuno modifichi di nascosto un campo di stato. Riportarlo fuori dall'archivio lo rimanda in bozza, mai direttamente online.
  • Bozza scritta dall'IA a partire dai ticket risolti: scegli fino a cinque casi chiusi, indica una lacuna se vuoi, e l'assistente scrive un articolo riutilizzabile. **Nasce sempre come bozza** ed entra nella stessa coda di revisione di qualsiasi articolo scritto a mano: l'IA propone, una persona approva. Vengono usati solo ticket risolti, perché un caso aperto non ha ancora una risposta.
  • Utilizzo per articolo: quante visite hanno aperto ciascun articolo, da quale porta, e quali articoli pubblicati nessuno ha letto nel periodo, cioè la fetta della base che non lavora.
💡 La lettura viene contata una volta per visita, per giorno e per porta, quindi ricaricare la pagina non gonfia niente e la stessa persona su due dispositivi conta come due visite. E una lettura **non** è un ticket evitato: il tasso di deflessione ha una definizione propria, più stretta, e sta nella scheda del self-service.

Self-service: l'assistente e il tasso di deflessione

La base di conoscenza pubblica adesso ha un assistente. Risponde ancorandosi **solo** ai tuoi articoli pubblicati e mostra le fonti che ha usato, così chi legge una risposta generata può controllare da dove è uscita. Quando non trova niente lo dice e porta al modulo di apertura, e la domanda rimasta senza risposta viene registrata come lacuna di copertura. Non riempie mai il silenzio con un passo inventato, e quando non c'è nessuna IA configurata mostra gli articoli trovati invece di fingersi fuori servizio.

È questo che rende la deflessione misurabile, e la definizione è stretta di proposito: un **ticket evitato è una dichiarazione esplicita** di chi stava per aprire un caso e ha rinunciato, dopo aver ricevuto una risposta o un articolo suggerito e aver cliccato che quello aveva risolto. Niente altro conta.

  • Leggere un articolo non conta. Chi legge può star confrontando, informandosi, o leggendo l'articolo sbagliato mentre va comunque ad aprire il ticket.
  • Cercare senza un esito non conta. Chiudere la scheda non è un successo.
  • Il ticket batte la dichiarazione: se la persona ha detto che era risolto e ha aperto un caso nella stessa visita, la visita conta come ticket. Preferiamo misurare di meno.
  • La visita che non ha deciso niente resta del tutto fuori dal tasso, né sopra né sotto, e viene riportata a parte come indecisa.
  • Il tasso è la fetta di visite che **hanno deciso qualcosa** e hanno deciso di non aprire un ticket. Senza nessuna decisione nel periodo il tasso resta vuoto e mai 0%, perché non sapere e zero per cento sono risposte diverse.
  • L'imbuto (ricerche, domande, domande con risposta) misura la portata, non il risultato, e niente di tutto questo entra nel tasso.
💡 Una domanda che non ha trovato risposta non gonfia mai i numeri dell'assistente: conta come risposta solo quando è tornato del testo davvero, e il resto diventa l'elenco delle lacune di copertura, che è la tua coda di quello che scrivere dopo. La visita in sé resta anonima da capo a fondo, una chiave opaca creata nel browser, senza e-mail e senza indirizzo, quindi la deflessione si misura senza sapere chi sia la persona.

Analisi dell'assistenza: report già pronti, rilievi e previsione

La scheda Analisi della console dei ticket risponde a quello a cui nessuna schermata rispondeva: da quanto tempo la coda è ferma, quanto di ogni traguardo promesso è stato rispettato, quanto è stato escalato, che cosa hanno fatto voce, bot e messaggistica, quanto sono costati gli incidenti in ticket, dove sta andando il volume e, alla fine, che cosa farci. Ogni numero arriva già calcolato dal server, quindi non ci sono due schermate che litigano in silenzio sullo stesso conto.

Due letture che sembrano uguali e non lo sono: **l'età corre sull'orologio** (il tempo di calendario da quando il ticket è stato creato) e **la scadenza corre sull'orario di lavoro** (la promessa di SLA, con le sospensioni scontate). Hanno nomi diversi di proposito. Mescolarle darebbe due numeri con la stessa etichetta e nessun modo di sapere quale dei due è stato rotto.

  • Report già pronti: un clic trasforma un modello in un report tuo, con il nome nella tua lingua. Da lì in poi è un report normale, modificabile, condivisibile, esportabile e pianificabile come qualsiasi altro, senza nessun motore separato dietro.
  • Rilievi: SLA sotto l'obiettivo, entra più di quanto esce, coda che invecchia, riaperture, escalation, lacuna di conoscenza. Ognuno arriva con i numeri che lo sostengono, una causa probabile e un'azione, in ordine di peso.
  • Rispetto per traguardo: prima risposta, risposta successiva e risoluzione, e non la sola risoluzione. La risposta successiva è ogni volta che il cliente torna a scrivere dopo essere già stato risposto una volta, e nel conto entra solo il caso che aveva davvero una scadenza.
  • Invecchiamento della coda per fasce (meno di un giorno, da uno a tre, da tre a sette, più di una settimana), in generale, per coda e per operatore, con il caso più vecchio bene in vista.
  • Il bot ha tre esiti, non due: risolto senza persone, passato a una persona, e **ha chiesto una persona e non è arrivato nessuno**, che è coda abbandonata e prima si nascondeva dentro il numero dei risolti.
  • Voce, messaggistica e incidenti hanno ciascuno la propria lettura, perché una conversazione WhatsApp non è un ticket e un incidente si misura da quanto è costato in casi e dalla causa radice che continua a tornare.
  • Previsione del volume: la tendenza più un indice per giorno della settimana, così il sabato non viene proiettato come se fosse un martedì.
💡 Dove non c'è base, la schermata mostra un trattino, non 0%: nessuno ha rispettato e non c'era niente da rispettare sono frasi diverse. La stessa onestà comanda sulla previsione, che ha bisogno di almeno due settimane piene di storico e, senza, si dichiara inaffidabile invece di tirare una linea sicura sopra il rumore.

IA che agisce sul ticket, sotto una policy

L'IA leggeva già ogni ticket (categoria, urgenza, sentiment, riepilogo) e nessuno ne faceva uso. Ora può **scrivere** categoria e priorità nel ticket, ma solo sotto una policy che lo spazio di lavoro definisce, ed è **spenta per impostazione predefinita**: nulla cambia finché chi amministra non la accende in **Impostazioni → IA dell'assistenza**. Campo per campo scegli tra **Non fare nulla**, **Suggerisci (una persona conferma)** e **Scrivi quando è sicura**. La scrittura avviene solo sopra una soglia di confidenza che decidi tu (dal 50% al 100%, 80% per impostazione predefinita); sotto, la stessa proposta diventa un suggerimento che si applica con un clic.

Nella console, il riquadro **Suggerimenti dell'IA** elenca ciò che è in attesa: il valore proposto con la sua confidenza e il motivo per cui non è stato scritto (la policy dice di suggerire soltanto, sotto la soglia, una persona aveva già scelto un valore, limite giornaliero raggiunto), con **Applica** e **Ignora**. Ciò che la policy ha scritto da sola resta visibile nella cronologia del riquadro come scritto dalla policy, così l'agente sa che la categoria non l'ha messa lui. **Classifica con l'IA adesso** esegue la stessa policy a mano. Il riquadro scompare per uno spazio di lavoro che non ha acceso la policy e non ha alcun suggerimento.

  • L'IA classifica in base alle **tue** liste di categorie e priorità. Un valore che non è una delle tue opzioni non viene mai scritto, e senza opzioni registrate per un campo resta in silenzio invece di inventarne una.
  • Un valore scelto da una persona non viene sovrascritto. Per impostazione predefinita la modalità automatica riempie solo ciò che è vuoto o ancora al valore predefinito del modulo; sostituire una scelta umana richiede l'opzione esplicita **Consenti all'IA di sostituire un valore scelto da una persona**.
  • Una bozza di risposta non viene **mai inviata**. Accettarla la mette nell'area di composizione con **Usa nell'area di composizione**; rileggere, modificare e inviare restano compiti tuoi. Anche risolvere e chiudere un ticket non sono mai automatici: non esiste una modalità per farlo, da nessuna parte.
  • Ogni scrittura automatica conta nel limite giornaliero di azioni condiviso con l'agente (**Impostazioni → IA**, autonomia dell'agente). Al limite, l'IA torna a suggerire soltanto e lo dice nel riquadro e nella pagina della policy, con i numeri di oggi: scritte, suggerite, trattenute dal limite, in attesa di una persona.
  • Tutto lascia traccia: ogni scrittura automatica nel registro delle azioni dell'agente, ogni chiamata all'IA nel registro di controllo dell'IA quando quel registro è acceso, e il cambio di policy stesso nella traccia di audit.
  • **Esegui quando viene creato un ticket** applica la policy senza alcuna automazione configurata. Con questa opzione accesa, creare un ticket dalla schermata attende l'IA per qualche secondo prima che il ticket compaia; se l'IA non è disponibile (nessuna chiave, tetto di spesa, provider fuori servizio) il ticket viene creato comunque, senza nulla di scritto.
  • Le automazioni del ticket e le regole a tempo hanno guadagnato due azioni: **Classifica con l'IA (secondo la policy IA dell'assistenza)** e **Redigi una risposta con l'IA (mai inviata)**. Una regola che prima imposta la categoria e poi interpella l'IA non vede l'IA disfarla.
  • La stessa analisi dello stesso testo non produce mai due suggerimenti e non conta mai due volte nel limite; ripetere un'esecuzione non costa nulla.
💡 Un suggerimento mostra il **primo** motivo che ha fermato la scrittura, in un ordine fisso: policy spenta, campo su non fare nulla, nessuna proposta valida, invariato, modalità suggerisci, valore umano mantenuto, confidenza bassa, limite giornaliero. Così "una persona aveva già scelto un valore" nasconde "sotto la soglia" quando sono veri entrambi, di proposito: è il motivo che continuerebbe a valere dopo che hai alzato la confidenza.

Lavoro sul campo a partire dal ticket

Un ticket che ha bisogno di una visita non si ridigita più in un'altra schermata. Con la verticale Servizi sul campo accesa, il riquadro **Lavoro sul campo** della console apre l'intervento direttamente dal ticket, programma la visita e mostra all'agente ciò che il cliente chiede al telefono: prossima visita, se è in ritardo, ultima visita, tecnico, apparecchiatura. Tutto viene letto dal vivo dall'intervento, dalle sue visite e dalla sua cronologia di stato, quindi una modifica fatta nella bacheca del dispacciamento è ciò che il ticket mostra alla prossima apertura. L'intervento porta con sé oggetto e descrizione del ticket come problema, e la priorità del ticket tradotta in quella dell'intervento (critica diventa urgente, alta resta alta, media normale, bassa bassa).

**Apri intervento** chiede l'**immobile**, che è obbligatorio perché il ticket non conosce l'indirizzo della visita: gli immobili del cliente vengono per primi e contrassegnati, un cliente con un solo immobile lo trova già preselezionato, e un ticket senza contatto né azienda cerca in tutta l'anagrafica per nome, indirizzo o CAP (i primi 50, con un avviso per affinare). Quando il ticket punta a un asset il cui numero di serie corrisponde esattamente a un'apparecchiatura di quell'immobile, l'apparecchiatura viene **suggerita** con una casella di spunta, mai scelta al posto tuo. Tipo di intervento (riparazione per impostazione predefinita), tecnico e finestra di arrivo sono facoltativi; con la finestra, la prima visita viene programmata subito e compare nella bacheca del dispacciamento; senza, l'intervento resta in bozza, ancora senza visita.

  • **Programma visita** aggiunge una visita allo stesso intervento dalla console: un ritorno è la visita 2, 3 e così via, mai un secondo intervento. Un ticket ha al massimo un intervento, e un secondo clic su apri risponde che esiste già.
  • La finestra di arrivo e il tecnico dell'intervento stesso vengono compilati solo quando erano vuoti: una seconda visita non riscrive ciò che era stato concordato per la prima.
  • **Visita in ritardo** compare quando la finestra è iniziata e la visita è ancora solo programmata, cioè nessuno è partito. Il selettore di cambio stato offre solo le transizioni che la macchina a stati della verticale accetta a partire dallo stato attuale.
  • Quando il lavoro sul campo è **completato**, **non è stato possibile completarlo** o è stato **annullato**, il responsabile del ticket riceve una notifica nella sua lingua con un link alla console, che il cambiamento arrivi dalla console, dalla schermata della verticale o dall'app. Dispacciato, in viaggio e in attesa di un ricambio restano visibili nel riquadro senza far suonare nessuno.
  • **Lo stato del ticket non cambia mai da solo** quando il campo finisce. Confermare con il cliente e risolvere il ticket è una decisione di chi lo segue.
  • **Scollega** rimuove il legame tra ticket e intervento e nient'altro: l'intervento continua a vivere nella verticale, con la sua traccia. Annullarlo è una transizione della verticale, che si fa lì.
  • Un'attività promemoria alla data della visita è facoltativa e riusa il modulo delle attività; compare nella cronologia del ticket e nell'elenco attività del tecnico, o in quello del responsabile del ticket quando non c'è un tecnico.
  • Con la verticale spenta, il riquadro lo dice e rimanda a **Impostazioni · Verticals**, invece di mostrare un pulsante che fallirebbe. Offre la strada leggera che ogni spazio di lavoro ha, **Apri invece un ordine di assistenza**, e mostra quell'ordine e i suoi appuntamenti quando ne esiste uno.
💡 La notifica va al **responsabile** del ticket, e solo quando il cambiamento l'ha fatto qualcun altro: chi ha completato l'intervento dalla console non viene avvisato del proprio clic, e un ticket senza responsabile non avvisa nessuno. Se chi si occupa delle visite non è il responsabile del ticket, assegna il ticket prima che il tecnico parta.

Dove configurare: **Impostazioni → Testi rapidi** per le frasi pronte, **Impostazioni → Modelli email del ticket** per i testi transazionali, e **Impostazioni → Competenze** per chi sa cosa e cosa richiede ogni coda. Swarm, follow-up e schede di lavoro non richiedono configurazione: sono già nella console.

Apri questo articolo dentro il sistema →

L'hai letto e vuoi vederlo all'opera?

L'account è gratuito e tutto il manuale è disponibile dentro il sistema, con un assistente che risponde proprio a partire da questi contenuti.

Crea un account gratuito
Console ticket · la postazione dell'assistenza · Sellio