Gestione dei ticket

Un ticket nuovo lo crei con «New Ticket» nella barra di sinistra. Il modulo si chiama «Create new ticket». Da agente registri con lo stesso modulo anche le richieste di altre persone: è a questo che serve il campo «User», che dice per chi è il caso, non chi lo sta scrivendo.

Tutto ciò che ha un asterisco è obbligatorio: «Title», «User», «Main category» e «Description». Ce n'è un altro che sfugge facilmente: il modulo non salva senza una sottocategoria, anche se «Subcategory» non ha l'asterisco – una categoria principale e una sottocategoria vanno insieme e si impostano sempre in coppia.

Quali campi sono obbligatori si imposta in «Settings → Ticket Settings». La scheda «Admin / Agent Field Settings» ha per questo solo l'interruttore «Field is mandatory». La scheda «Customer Field Settings» ha in più «Is hidden for Customer» e «Is not editable». È per questo che un cliente può vedere un modulo più corto del tuo, senza che nessuno debba mantenere due moduli. «Title» e «Description» sono sempre obbligatori. Non si può disattivare.

Dopo puoi cambiare quasi tutto: a destra del ticket c'è la scheda «Details» con chi ha fatto la richiesta, telefono, e-mail, sede, categoria e numero di riferimento; modifichi il campo e confermi con il «Save» sotto. Lo stato, l'assegnazione, la priorità, il canale e gli osservatori stanno una scheda più su, in «Actions». Lo stato e l'assegnazione hanno effetto subito. La priorità, il canale e gli osservatori vengono salvati solo con il «Save» della scheda «Details».

Solo gli agenti e gli amministratori possono cambiare queste cose. Chi ha fatto la richiesta può leggere il caso, commentarlo e allegare file, ma non cambiare la classificazione su cui si reggono i tuoi report.

C'è un effetto collaterale che vale la pena sapere una volta: se modifichi un ticket che non appartiene ancora a nessuno, dopo appartiene a te. Il sistema ti iscrive come agente e sposta lo stato da «Open» ad «Assigned» – finiscono entrambi nella cronologia. Se non era questo che volevi, assegnalo poi a un'altra persona.

Ognuna di queste modifiche finisce nella cronologia del ticket, con nome, ora, valore vecchio e valore nuovo. Per questo non devi accendere niente.

Resta la domanda di come liberarsi di nuovo dei ticket. In «Settings → Archive» scegli un periodo, vedi con «Preview» quanti ticket chiusi contiene e crei un file ZIP con «Create archive»: ticket, commenti, cronologia, campi personalizzati e allegati, tutto in un file. Crearlo non rimuove niente. I ticket escono dalla banca dati in funzione solo con il passaggio a sé «Delete from live DB» nell'elenco «Existing archives», e da quello stesso file si possono ripristinare.

La descrizione e i commenti non sono semplici caselle di testo. Ognuna ha sopra una barra degli strumenti, e i pulsanti dicono che cosa fanno quando ci passi sopra: «Bold», «Italic», «Underline», «Strikethrough», «Text color», «Highlight color», «Bullet list», «Numbered list», «Quote», «Link» e «Clear formatting».

Un collegamento si fa così: seleziona il testo, premi «Link», scrivi l'indirizzo nella piccola finestra. Un inserimento vuoto toglie di nuovo il collegamento. Sono ammessi indirizzi web e di posta (http, https, mailto): tutto il resto viene buttato via al salvataggio, così un commento non può far passare niente a nessuno.

Le immagini entrano dagli appunti: fai un'immagine dello schermo e incollala direttamente nell'editor con Ctrl+V. All'inizio il testo mostra solo un segno come «[inline-image:1]». Al salvataggio il sistema carica l'immagine e la mostra esattamente in quel punto, e l'immagine finisce anche nella scheda «Attachments», dove stanno tutti i file del caso. Incollare immagini funziona nella descrizione di un ticket esistente e in un commento nuovo. Non funziona nel modulo «Create new ticket» né mentre modifichi un commento.

Quello che vedi è quello che vedono gli altri: la formattazione, gli elenchi e i collegamenti restano nel ticket e anche nel messaggio a chi ha fatto la richiesta. La marcatura che arriva da fuori — da una pagina web copiata o da un'e-mail in arrivo, per esempio — viene ridotta a questo insieme consentito. Nel processo non si perde niente del tuo testo, solo l'involucro.

Un commento si può segnare come interno con «Internal note (not visible to the customer)». Prende allora l'etichetta «Internal» ed è invisibile a chi ha fatto la richiesta: nemmeno la ricerca lo tira fuori.

Ognuno può modificare e cancellare i propri commenti. Quello che ha scritto un cliente può modificarlo o cancellarlo solo quel cliente o un amministratore. Questo vale anche per le sue e-mail. I commenti dei colleghi può modificarli e cancellarli ogni agente che può lavorare sul ticket. Questo vale anche per un team che ha avuto il ticket prima.

I file appartengono al caso, non a un singolo commento. Sul ticket la scheda «Attachments» porta all'elenco: «Upload file» ne aggiunge uno, e ogni riga indica il file, la sua dimensione e la sua data. Chiunque sia coinvolto nel ticket può allegare qualcosa, anche chi ha fatto la richiesta; così nessuno deve mandarti l'immagine dello schermo per e-mail. Un cliente può cancellare solo gli allegati che ha caricato lui stesso. Quando un sotto-ticket viene chiuso, i suoi allegati vengono copiati nel ticket principale, dove portano l'etichetta «Internal». Gli agenti li vedono; i clienti non li vedono né li scaricano.

Un clic sul nome apre l'anteprima, senza che tu debba scaricare il file. Nelle immagini puoi ingrandire, ridurre e ruotare: utile per uno schermo fotografato di sbieco. Un PDF viene mostrato nella stessa finestra, con panoramica delle pagine, ingrandimento e stampa. I file di testo vengono mostrati come testo. Con «Open in new tab» apri il file in una finestra a parte.

Un allegato appartiene al caso e viaggia con lui: compare nella cronologia («File uploaded: …»), sopravvive al passaggio a un altro team e finisce dentro al file di archivio quando il ticket viene archiviato.

La scheda «History» del ticket risponde alla domanda che sta dietro a ogni ripresa: chi ha cambiato che cosa, e quando? Ogni riga indica la persona, il campo, il valore vecchio barrato, quello nuovo di seguito e l'ora al secondo. La voce più recente è in cima.

Le voci vengono scritte senza che tu faccia niente: ai cambi di stato, di priorità, di assegnazione, di categoria, di sede, di osservatori, di titolo e di descrizione, e così alla creazione («Ticket opened»), a ogni commento e a ogni file caricato. Il numero sulla scheda ti dice in anticipo quanto movimento c'è stato nel caso.

La cronologia non si può modificare e non si può spegnere. È proprio questo a renderla utile: è il motivo per cui un ticket non si può cancellare uno a uno, e viaggia nel file di archivio quando il ticket viene archiviato.

Per un commento, la cronologia registra solo che è stato aggiunto, modificato o eliminato. Il testo sta nella scheda «Comments». Anche un commento interno compare nella cronologia, ma solo per gli agenti e gli amministratori.

Lo stato dice a che punto è un ticket in questo momento. Il sistema porta con sé dodici stati — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed e altri. Li trovi in «Settings → General Settings», nella sezione «Drop-down lists», dietro alla scheda «Status»; «+ Add status» ne crea uno tuo, «Edit status» apre uno esistente.

Quello che conta è la differenza tra il nome e il significato. Nell'editor di uno stato, in «Meaning of this status», ci sono tre interruttori: «Counts as resolved», «Counts as closed» e «Waiting for the requester». Sono solo questi interruttori a dire al sistema come trattare uno stato.

Puoi rinominare ogni stato, anche quelli che arrivano con il sistema: in fondo all'editor, in «Translations», c'è un campo «Name» per lingua – scrivi lì quello che le tue persone devono leggere. Il nome tecnico dietro resta intatto, ed è esattamente per questo che non si rompe niente: l'automazione, i report e gli interruttori qui sopra dipendono da quel nome e non dalla tua etichetta. Così «Resolved» può diventare «Done».

Cancellare, invece, non funziona con tutti. Otto stati portano nell'elenco l'etichetta «Mandatory» — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval e Rejected. Si possono rinominare e riordinare, ma non rimuovere; provarci finisce con un messaggio chiaro. Non è lì per darti fastidio: da loro dipendono processi che altrimenti si fermerebbero senza dire niente, per esempio la chiusura automatica, che ha bisogno di uno stato «risolto» come punto di partenza.

Due stati appartengono al sistema stesso: «Waiting for approval» e «Rejected» portano l'etichetta «System only». Nascono da un processo di approvazione, e nessuno deve poter sostenere a mano che è stato rifiutato qualcosa che non è mai andato in decisione.

Che cosa fanno i tre: uno stato che conta come risolto chiude il ticket da solo dopo 24 ore. Uno stato che conta come chiuso è lo stato finale in cui il ticket viene spostato. E «Waiting for the requester» significa esattamente questo: stiamo aspettando chi ha fatto la richiesta, non un altro team e non un fornitore di servizi. È questo il contrassegno su cui l'orologio dello SLA si ferma, se lo imposti così.

Sotto c'è «Allowed transitions to new status». Qui spunti quali stati si possono raggiungere da questo. Lascia tutto vuoto e non viene limitato niente; spunta qualcosa e tutte le altre strade si chiudono. È così che si costruisce un flusso che non si può saltare — per esempio: da «Open» si può andare solo a «In Progress» o ad «Assigned», ma non direttamente a «Closed».

Gli altri interruttori dell'editor sono dettagli con grande effetto: il colore per l'elenco, «Sort order» per l'ordine, «Show status in new ticket form» (questo stato deve poter essere scelto quando si crea un ticket?), «Requires comment in dialog» (obbligare a una motivazione) e «System only» per gli stati che solo il sistema può impostare.

Fino a quattro stati compaiono sul ticket come pulsanti sotto «Change Status to:». Li scegli nell'editor con l'interruttore «Set as primary status (max. 4)». Con l'impostazione di serie sono In Progress, Waiting for User Response, Waiting for Service Provider Response e Resolved. Tutti gli altri stati si trovano in «More statuses».

Tutto ciò che in un ticket compare come menu a tendina è tuo. In «Settings → General Settings» c'è la scheda «Drop-down lists» con sei linguette: «Department», «Position», «Location», «Role», «Status» e «Priority». Il funzionamento cambia da elenco a elenco.

Una alla volta: scrivi il nome inglese nel campo vuoto e premi il pulsante accanto – porta il nome dell'elenco, quindi «+ Add location», «+ Add department» e così via. Le righe sotto sono le voci esistenti. In «Department», «Position» e «Location» è lì che cambi un nome e confermi con il «Save» accanto.

Per molte voci in una volta «Department», «Position» e «Location» offrono anche «Export JSON» e «Import JSON». Su un sistema appena installato scarichi la struttura vuota con «Export JSON», la compili e la reimporti. Non è un modo per rinominare: lo dice la scheda stessa.

Alcune voci portano l'etichetta «Mandatory». Tra queste ci sono i tre ruoli «Admin», «Agent» e «Customer», otto degli stati che arrivano con il sistema, e un segnaposto in ognuno degli elenchi Location, Position e Department («None selected or available»). Nessuna di queste si può cancellare: da loro dipendono permessi e processi che altrimenti si fermerebbero senza dire niente. Gli stati si possono comunque rinominare nel loro editor. I ruoli e i segnaposto non si possono rinominare. Che cosa è permesso dipende dall'elenco. «Role» è bloccato: un ruolo non si può né aggiungere né rinominare. In «Priority» aggiungi e cancelli voci, ma non c'è un file né si può rinominare. «Status» ha un suo editor e nemmeno lì c'è un file.

Qui non si traduce nelle altre lingue: lo si fa in una volta sola nella pagina delle traduzioni. Qui basta il nome inglese, che è l'ancora a cui le traduzioni si agganciano dopo.

Lo stato è l'unica voce con un editor proprio, perché da lui dipende più di un nome; ha la sua scheda più in basso.

Le categorie sono ciò che chi fa la richiesta o l'agente sceglie quando crea un ticket, e ciò per cui più tardi raggruppi i tuoi report. Ogni team ha le sue: un helpdesk ordina per cose diverse rispetto a un reparto di rete, e nessuno dei due vede gli elenchi dell'altro.

Le trovi in «Settings», alla voce «<team name> Categories». Nell'esempio il team si chiama «Helpdesk», quindi la voce dice «Helpdesk Categories».

La pagina ha tre schede: «Main categories», «Subcategories» e «Links». La partenza più rapida: scrivi il nome inglese nel campo «EN (required)» e premi «+ New main category» o «+ New subcategory». La traduzione si fa dopo, in una volta sola, nella pagina delle traduzioni: qui non c'è niente da preparare.

Se hai davanti molte categorie, prendi la strada del file: «Export JSON» scarica la struttura — su un sistema appena installato il file è vuoto e ti mostra solo la disposizione. Lo compili (a mano o con l'aiuto di un'intelligenza artificiale), lo salvi e lo ricarichi con «Import JSON». Non è un modo per rinominare: un nome lo cambi nel campo di quella categoria e confermi con il «Save» accanto — lo dice anche la pagina.

La terza scheda, «Links», è dove sta il lavoro vero. Scegli in alto una categoria principale, spunta sotto le sottocategorie che le appartengono e salva con «Save links». Il trucco: una sottocategoria può essere agganciata a più categorie principali. Così ti serve «Malfunction» una volta sola e la riusi per Printer, Network, Meeting-Room e Notebook.

Da quel momento le categorie sono disponibili nel ticket. La cancellazione può fallire finché ci sono ticket che usano una categoria: è voluto, altrimenti i vecchi ticket perderebbero la loro classificazione. Se togli un collegamento, i ticket che usano quella coppia si possono ancora salvare. Solo una categoria scelta di nuovo viene confrontata con i collegamenti.

Se passi un ticket a un altro team, la sua classificazione resta, anche quando il nuovo team quelle categorie non le ha proprio. Compare allora nel campo insieme alla sua origine, per esempio «Meeting-Room · from Helpdesk», ed è in grigio: il nuovo team vede come è andato il caso finora, ma non può assegnare quella voce. Per riclassificarlo scegli dal tuo elenco, e il sistema vuole allora una categoria principale e una sottocategoria insieme.

Ogni ticket ha un canale. Sta nel modulo e poi sulla scheda «Actions», in «How the request came in», e risponde a una domanda che nei report diventa presto importante: il lavoro arriva dal portale o per telefono?

Puoi scegliere solo ciò che una persona sa e il sistema no: «Phone» ed «Entered by an agent». Gli altri due valori li imposta il sistema stesso — «Self-service» quando è stato chi ha fatto la richiesta a creare il ticket nel portale, ed «E-mail» quando è nato da un messaggio in arrivo. Quando un agente crea un ticket, il modulo parte da «Entered by an agent».

Un canale impostato dal sistema non lo può più cambiare nessuno. Il campo dice allora «Recorded by the system. It cannot be changed.» Altrimenti il campo perderebbe esattamente l'affermazione per cui esiste. Al contrario, su un ticket registrato al telefono puoi continuare a cambiare tutto il resto.

Solo un agente o un amministratore può impostare il canale. Per chi ha fatto la richiesta sarebbe un'affermazione sul proprio caso, e i report dipenderebbero dall'onestà di tutti.

«E-mail» richiede una casella di posta collegata, che fa parte dell'edizione Professional. Gli altri tre canali esistono in entrambe le edizioni.

Sopra ogni elenco di ticket c'è il campo «Search tickets…». Non cerca solo nei titoli, ma nell'intero caso: titolo, descrizione, nome di chi ha fatto la richiesta, indirizzo e-mail e numero di telefono, sede, numero di ticket di riferimento, tutti i commenti e i valori di testo dei tuoi campi personalizzati.

L'esempio lo mostra: «coffee» non compare in nessun titolo, solo nella descrizione di un ticket — e viene trovato lo stesso. Non devi quindi ricordarti come era intitolato un ticket; basta una parola del caso.

Maiuscole e minuscole non contano. La ricerca vale sempre per l'elenco in cui ti trovi e si può combinare con il «Filter» accanto; «Reset» azzera di nuovo ricerca e filtri. L'elenco ricorda i tuoi filtri, separatamente per ogni elenco del team. Restano impostati quando torni da un ticket, ricarichi la pagina o accedi da un altro computer. Il testo di ricerca non viene ricordato. Per i clienti c'è un limite che non si vede ma è bene conoscere: non cercano nei commenti interni, altrimenti dall'elenco dei risultati potrebbero dedurre che cosa si è discusso internamente. Né cercano nei campi personalizzati nascosti ai clienti.

Ognuno compone il proprio elenco dei ticket. Per questo il pulsante «Columns» sta accanto a «Filter». Apre la finestra «Choose columns».

Nella finestra spunti ogni colonna che vuoi vedere. Le frecce accanto stabiliscono l'ordine. «#» e «Title» sono sempre incluse. La larghezza di una colonna la cambi nell'elenco stesso, trascinando il bordo della sua intestazione.

«Save» salva la tua scelta con il tuo account utente. Vale quindi su ogni computer e resta anche dopo che esci. «Default columns» riporta l'elenco all'impostazione di serie.

Quando non c'è spazio per tutte le colonne, quelle più a destra spariscono per prime. «#», «Title» e «Status» restano sempre. Quindi sposti in avanti ciò che per te conta di più.

Con Professional ti vengono offerti anche i tuoi campi personalizzati. Compaiono nella finestra con il loro nome, qui per esempio «Asset tag».

I clienti possono impostare il loro elenco allo stesso modo, ma vengono offerte loro meno colonne. «Team», «Created by», «Last activity», «Status changed at», «Deadline», «Follow-up» e «Time» per loro non sono disponibili. Nemmeno i campi che hai nascosto ai clienti compaiono come colonna.

Sul telefono il pulsante non viene mostrato. Lì l'elenco mostra le colonne che ci stanno.

Per questo il ticket offre due pulsanti affiancati, e la differenza è scritta sotto in piccolo. «Involve another team»: resti responsabile e l'altro team lavora accanto a te in un ticket collegato. «Escalate to another team»: l'altro team prende in carico.

Quando passi il caso, la responsabilità si sposta senza che nasca un secondo ticket. Il tuo team mantiene l'accesso in lettura e può ancora commentare, ma non può più cambiare niente — ed è esattamente quello che la finestra ti dice prima che tu confermi. Lì scegli il team di destinazione e puoi aggiungere una motivazione.

Quando coinvolgi un team, il tuo ticket resta nelle tue mani e riceve un sotto-ticket nell'altro team. Il tuo passa allo stato «Waiting for other team»; appena l'altro team chiude il suo, il tuo torna come «Back from other team». Così non devi chiedere se dall'altra parte è successo qualcosa. Gli allegati del sotto-ticket vengono copiati nel tuo ticket con l'etichetta «Internal», e il cliente non li vede.

Quanto alla classificazione: le categorie del team che passa il caso restano sul ticket, anche quando il nuovo team non le ha proprio — vi compaiono con la loro origine, in grigio. Così il nuovo team vede come è andato il caso finora e, se serve, lo riclassifica nel proprio elenco.

Solo chi è responsabile in questo momento può passare un ticket. Una stazione precedente continua a vedere il caso, ma non lo può passare una seconda volta. Può commentare, ma non può riprendersi il ticket.

Nell'elenco del tuo team il ticket mostra poi «Waiting for other team» finché l'altro team ci lavora. La spunta «Also show tickets this team handed over» è attiva di serie, e la scelta di ogni utente viene conservata. Per l'altro team il ticket parte come «Open».

Chi passa il ticket ne diventa osservatore. La finestra lo dice prima che tu confermi. Come osservatore ricevi un'e-mail quando cambia lo stato, il ticket viene chiuso o qualcuno commenta. Come ogni osservatore, ti togli con «Stop observing».

Quando nei tuoi ticket manca un'informazione — il numero di inventario, la fine della garanzia, il centro di costo — la aggiungi tu. In «Settings → Ticket Settings», in fondo, c'è la scheda «Custom fields»; il pulsante si chiama «Add custom field».

Nella finestra dai un nome e un tipo di campo: «Text», «Multiline text», «Integer», «Decimal», «Date» o «Yes / No». Il tipo decide che cosa si può inserire: un campo data non accetta «la settimana prossima», ed è esattamente per questo che poi ci puoi fare un report.

In «Scope» decidi dove vale il campo: «All teams (including new ones)» oppure «Selected teams only». La prima scelta comprende anche i team che ancora non esistono: il tipo di differenza di cui ci si accorge solo mezzo anno dopo.

I tre interruttori in «Defaults» sono «Mandatory by default», «Hidden for customer by default» e «Not editable by customer by default». Valgono per un campo solo finché per quel campo non è stato salvato niente nelle impostazioni del campo della stessa pagina. Appena lo imposti lì, decidono le impostazioni del campo.

Sul ticket i campi personalizzati stanno in una scheda a parte, «Additional information», tra la descrizione e i commenti. Senza un modello il modulo mostra tutti i campi personalizzati del team. Se scegli un modello mentre crei un ticket, mostra esattamente i campi che quel modello elenca, nel suo ordine — «solo i campi di cui questo caso ha bisogno».

Un modello può inoltre rendere obbligatorio un campo. Ciò che l'amministratore ha nascosto ai clienti resta nascosto, anche se un modello lo elenca. Un campo obbligatorio che un modello non elenca non viene chiesto, quindi quell'obbligo non vale per i ticket creati con questo modello.

Quanti campi personalizzati può avere un team si imposta in «Settings → General Settings», nella scheda «Custom fields limit». Ti liberi di un campo con «Deactivate»: sparisce dal modulo, ma i suoi valori restano sui vecchi ticket — l'interruttore «Show deactivated» lo riporta nell'elenco.

A volte qualcuno deve seguire un caso senza lavorarci: il responsabile del team su una questione delicata, il collega che subentra la settimana prossima. È a questo che servono gli osservatori. Sul ticket il campo «Observers» sta sulla scheda «Actions» e il pulsante si chiama «Add observer»; il modulo «Create new ticket» ha lo stesso campo. Sul ticket una modifica lì viene salvata con il «Save» della scheda «Details».

Si possono scegliere solo agenti e amministratori del team a cui appartiene il ticket. Un cliente non può essere osservatore: riceverebbe messaggi sul lavoro interno.

Un osservatore riceve un'e-mail quando sul ticket succede qualcosa: un commento nuovo, un cambio di stato, una nuova assegnazione, campi modificati. Non viene mandata subito ma raggruppata: dopo l'ultima modifica il sistema aspetta un minuto e poi manda UN messaggio con tutto ciò che è successo in quel tempo. Così lavorare un ticket in una volta sola non genera sette messaggi. Se in quel tempo arrivano più commenti, ci sono tutti nel messaggio.

Chi osserva fa parte della cronologia: una modifica viene registrata come qualsiasi altra, con lo stato vecchio e quello nuovo.

Inserire osservatori fa parte di Basic. Il messaggio agli osservatori fa parte di Professional, perché ha bisogno dell'invio di posta. Senza, puoi inserire osservatori ma non esce niente. Un osservatore può togliersi da solo con il pulsante «Stop observing». Non gli serve il diritto di modificare il ticket.

Un osservatore si aggiunge anche da solo: chi passa un ticket con «Escalate to another team» ne diventa osservatore. Così viene a sapere che cosa fa l'altro team con il ticket.

Quando due persone lavorano sullo stesso ticket nello stesso momento, il salvataggio successivo potrebbe sovrascrivere quello precedente, e nessuno se ne accorgerebbe. Per questo il ticket mostra chi altro lo ha aperto. Inoltre rifiuta un salvataggio basato su una versione non aggiornata.

L’avviso si trova nell’intestazione del ticket. «Marco Rossi is viewing this ticket» significa che Marco ha il ticket aperto. «Marco Rossi is actively editing this ticket» significa che Marco ha modifiche non salvate. Può essere una risposta iniziata, un commento in corso di modifica, il titolo o la descrizione in modalità di modifica, un promemoria, un campo personalizzato o una registrazione dei tempi. Contano anche i campi modificati nelle schede «Actions» e «Details», finché non sono stati salvati con «Save». Conta anche una finestra aperta sul ticket. Sono le finestre «Involve another team?», «Escalate to another team?», «Close ticket», «Resolve incident» e «Start a workflow», più la finestra per il commento a un cambio di stato. Dopo due minuti senza digitare nulla, l’avviso mostra di nuovo «viewing», anche se la bozza è ancora lì.

Se più colleghi hanno il ticket aperto, l’avviso li riassume, per esempio «Marco Rossi and 2 more are viewing this ticket». Punta sull’avviso per vedere tutti i nomi. Appena qualcuno sta modificando attivamente, la riga conta solo le persone che stanno modificando. Te stesso non ti vedi mai. Se hai il ticket aperto in due schede del browser, conti una volta sola. Se il ticket è aperto solo in una scheda nascosta, dopo circa un minuto sparisci dall’avviso degli altri.

Quando un collega salva una modifica, l’avviso dice «Marco Rossi changed this ticket», con il pulsante «Refresh» accanto. Un nuovo commento di un’altra persona mostra «Marco Rossi added a comment». Se la modifica non viene da una persona, per esempio da una regola di automazione o da un’e-mail in arrivo, l’avviso dice «This ticket was changed». L’avviso resta finché non ricarichi.

«Refresh» carica la versione attuale del ticket, per esempio stato, assegnazione, campi e cronologia. Non ricarica l’intera pagina. Le tue modifiche non salvate restano. Una risposta iniziata resta nel campo di risposta, e un titolo o una descrizione aperti conservano il tuo testo. Se nel frattempo il testo salvato è cambiato, sotto il campo compare «The saved text has changed in the meantime.». Se salvi a quel punto, il tuo testo sostituisce quello salvato. Il pulsante «Refresh» nell’intestazione del ticket fa la stessa cosa.

Se salvi comunque su una versione non aggiornata, il salvataggio viene rifiutato. Si apre la finestra «Ticket changed in the meantime». Se la modifica l’ha fatta una persona, la finestra la nomina. La tua modifica non è stata salvata. Fai clic su «Refresh», confronta la tua modifica con la versione attuale e salva di nuovo. Questo vale per ogni modifica al ticket stesso, per esempio stato, assegnazione, priorità, la scheda «Details» e i campi personalizzati.

I commenti non vengono mai rifiutati. Due risposte non si sovrascrivono a vicenda. Finiscono entrambe sul ticket. Lo stesso vale per allegati e registrazioni dei tempi. Anche le azioni di massa sull’elenco dei ticket e le regole di automazione non vengono confrontate con la versione. Modificano il ticket direttamente. Chi lo ha aperto vede l’avviso dopo.

I clienti non vedono niente di tutto questo. Non compaiono nell’avviso. Non vedono nemmeno chi sta lavorando al loro ticket.

Chi ha un ticket aperto viene tenuto solo nella memoria del server. Circa un minuto dopo che la persona ha lasciato il ticket, la voce sparisce. Niente di tutto questo viene scritto in un log. Il ticket memorizza chi l’ha modificato per ultimo. Questa voce fa parte dell’esportazione dei dati di quella persona. Quando la persona viene anonimizzata, la voce viene rimossa.

Il canale di posta è una strada a due sensi, e i due sensi vanno insieme: un messaggio in arrivo diventa un ticket, la tua risposta esce come messaggio, e la risposta di chi ha fatto la richiesta finisce come commento sullo stesso ticket, non su un secondo.

L'abbinamento non si fa a occhio: una risposta finisce sul ticket esistente solo quando il messaggio porta nell'oggetto il riferimento del caso o porta con sé le intestazioni di risposta del programma di posta. Un messaggio senza nessuna delle due cose comincia un caso nuovo: meglio un ticket in più che due casi senza legame uniti solo perché l'oggetto per caso coincideva.

Tutto quello che serve sta in «Settings → E-Mail Settings». La scheda in alto, «SMTP settings», è la via d'uscita: server, porta, «Use SSL», utente e password, più l'indirizzo e il nome del mittente. Con «Send test e-mail» mandi un messaggio di prova a te stesso — prima salva, poi prova, come dice la scheda stessa.

La scheda «IMAP settings» è la via d'ingresso: server, porta, l'intervallo di controllo e le due cartelle. Il nome della cartella non lo devi indovinare: «Read from server» recupera le cartelle che esistono davvero nella tua casella, «Create on server» ne crea una nuova. Il campo accetta poi il percorso che il tuo server di posta usa per essa: un server scrive «INBOX/Processed», un altro «INBOX.Processed», e i due significano la stessa cosa.

La «Processed folder» raccoglie i messaggi che il sistema mette da parte: messaggi di mittenti bloccati, messaggi generati automaticamente e messaggi che un flusso di lavoro sposta con «Move to folder» senza una cartella propria. Lasciala vuota e restano nella casella in arrivo. Sotto imposti quando gira la pulizia («Hour», «Minute») e che età può raggiungere un messaggio («Retention (days)»): altrimenti la casella cresce in silenzio.

Le caselle di posta appartengono al team, non al sistema: in «Team mailboxes» ogni team inserisce il proprio indirizzo con una password. Quell'indirizzo è allo stesso tempo il mittente dei messaggi di quel team, così chi ha fatto la richiesta risponde nello stesso posto da cui la posta viene raccolta.

E ora la parte senza la quale niente di tutto questo succede: il flusso di lavoro. Una casella configurata, da sola, non fa niente. Se un team non ha un flusso di lavoro attivo, la casella non viene nemmeno consultata: nessun ticket, nessuna conferma, i messaggi restano semplicemente lì. La risposta automatica ai tuoi clienti esiste solo qui, e la configuri tu. È voluto: un sistema che scrivesse a ogni indirizzo mittente senza che nessuno lo chieda sarebbe peggio di uno che sta zitto.

In «E-Mail workflows» scegli in alto il team e crei un flusso di lavoro con «+ Add workflow». Riceve un nome (solo per te), un interruttore «Enabled» e due affermazioni su quando vale: «Match» decide se tutte le condizioni devono essere vere («All conditions») o se ne basta una, e «Stop after match» chiude l'esecuzione appena questo flusso ha corrisposto — un flusso più in basso non arriva più al suo turno. L'ordine lo cambi con le frecce accanto.

In «When?» sta la condizione vera e propria. «Every e-mail in this mailbox» prende tutti i messaggi; «Only when subject or text contains» richiede una parola nell'oggetto o nel corpo. «Advanced» rende tutto preciso: lì scegli che cosa viene guardato — «Subject or body», «Subject», «Body», «Sender (From)» o «Recipient (To/Cc)» — e come viene confrontato: «Contains», «Equals» o «Regex». È così che separi, per esempio, le segnalazioni mandate a un indirizzo comune da tutto il resto.

Sotto ci sono cinque azioni come interruttori. Sono il vero contenuto del flusso di lavoro: ciò che non è acceso non succede:

«Create or append ticket» trasforma il messaggio in un ticket, oppure lo aggiunge come commento a uno già esistente quando il riferimento è nell'oggetto. Senza questa azione un messaggio non diventa mai un caso.

«Set fields» imposta la priorità, lo stato, la categoria principale e la sottocategoria, il team responsabile e chi prende il ticket già al momento della creazione. Tutto ciò che resta su «— Keep default —» rimane come sarebbe senza un flusso di lavoro.

«Auto-reply» è la conferma a chi ha scritto. Con questo interruttore spento il tuo cliente non riceve nessuna conferma, per quanto bene sia configurato tutto il resto. Anche «Send mail» può scrivere a chi ha scritto, come mostra l'azione successiva.

«Send mail» manda un messaggio in più: o a chi ha mandato il messaggio in arrivo, oppure a membri scelti del team e a indirizzi fissi. Ha le sue «Send conditions»: lasciale vuote ed esce a ogni esecuzione di questo flusso di lavoro.

«Move to folder» archivia il messaggio trattato in una cartella. Lascia il campo vuoto e vale la «Processed folder» generale delle impostazioni IMAP qui sopra.

L'azione «Auto-reply» nel dettaglio: l'oggetto lo costruisci con dei blocchi. «Original subject {originalSubject}» riprende l'oggetto del messaggio in arrivo, «Ticket reference {ticketTag}» inserisce il riferimento del caso — insieme danno qualcosa come «Printer problem [TICKET-99-a1b2c3]».

Il riferimento non si aggiunge da solo. Compare solo dove metti {ticketTag}. {ticketId} inserisce solo il numero nudo, e il sistema non riconosce una risposta da quello. Senza il riferimento nell'oggetto, una risposta viene comunque abbinata se porta le intestazioni di risposta della conferma. Solo un messaggio senza nessuno dei due diventa un ticket nuovo.

Il testo sotto è il tuo messaggio di conferma. Scrivilo in inglese: passa dalla stessa esportazione e importazione di tutti gli altri testi, e solo così può essere tradotto nelle altre lingue. Lascialo vuoto e il sistema manda il proprio messaggio predefinito. Qui sono ammessi gli stessi segnaposto.

«Reply language» decide in quale lingua escono l'oggetto e il testo: «Standard English» usa l'inglese, «Fixed language» una lingua che scegli, «Assigned agent's language» la lingua dell'agente assegnato e «Team default language» la lingua predefinita del team. Le traduzioni si mantengono nella pagina delle lingue.

Un consiglio che il sistema stampa anche sopra la scheda: tutto ciò che appartiene a un caso appartiene a UN flusso di lavoro. Solo le azioni dentro allo stesso flusso conoscono il ticket appena creato: è per questo che la conferma può indicarne il numero e un'azione di un secondo flusso no.

Tutto il canale di posta, in entrata e in uscita, fa parte dell'edizione Professional. In Basic il sistema non manda né riceve e-mail; lì i ticket nascono dal portale, dal telefono e dall'agente.