Manuale

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 compaiono e quali di essi sono obbligatori si imposta in «Settings → Ticket Settings», separatamente per gli agenti e per i clienti. È per questo che un cliente vede un modulo più corto del tuo, senza che nessuno debba mantenere due moduli.

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, la priorità, l'assegnazione, il canale e gli osservatori stanno una scheda più su, in «Actions», e hanno effetto subito, senza un salvataggio a parte.

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. Solo allora quei ticket spariscono dalla banca dati in funzione, 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.

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 «Only for Admin/Agents». Prende allora l'etichetta «Internal» ed è invisibile a chi ha fatto la richiesta: nemmeno la ricerca lo tira fuori.

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 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.

Un commento vi compare abbreviato: il testo completo 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. Sei stati portano nell'elenco l'etichetta «Mandatory» — Open, Assigned, In Progress, Resolved, Closed e Reopened. 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 a «Rejected», 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.

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», «Site», «Role», «Status» e «Priority». Dietro a ciascuna c'è lo stesso funzionamento, quindi lo devi imparare una volta sola.

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

Per molte voci in una volta ci sono «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», sei degli stati che arrivano con il sistema, e un segnaposto in ognuno degli elenchi Site, Position e Department («None selected or available»). Si possono rinominare ma non cancellare: da loro dipendono permessi e processi che altrimenti si fermerebbero senza dire niente.

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 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 «Email» quando è nato da un messaggio in arrivo.

È anche per questo che non puoi poi cambiare in «Phone» un canale impostato dal sistema: 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.

«Email» 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. 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.

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.

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.

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» valgono per i ticket nuovi: «Mandatory by default», «Hidden for customer by default» e «Not editable by customer by default». Sono impostazioni predefinite: le impostazioni del campo nella stessa pagina restano il posto dove definisci tutto nel dettaglio per ruolo.

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, ma non può togliere una regola: ciò che l'amministratore ha nascosto ai clienti o dichiarato obbligatorio resta così, anche se un modello dice il contrario. Altrimenti un modello sarebbe un modo per sfuggire a una regola della casa.

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.

Si possono scegliere solo agenti e amministratori di un team coinvolto. 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.

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

La notifica è un'e-mail, quindi l'invio di posta deve essere configurato (Professional). Senza, puoi inserire osservatori ma non esce niente.

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.

I messaggi trattati passano nella «Processed folder»; 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: l'unico posto in cui il sistema risponde di propria iniziativa. Con questo interruttore spento il tuo cliente non riceve mai una risposta automatica, per quanto bene sia configurato tutto il resto.

«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]».

Il riferimento non si aggiunge da solo. Compare solo dove metti {ticketTag} o {ticketId}, ed è esattamente da quello che il sistema riconosce poi la risposta del tuo cliente. Senza di esso nell'oggetto, ogni seguito comincia un ticket nuovo invece di diventare un commento di quello vecchio.

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.

La registrazione dei tempi è spenta di serie. Finché è spenta non c'è nessun campo, nessuna colonna e nessun riquadro nel report.

Un campo morto sarebbe peggio di nessun campo, quindi la funzionalità sparisce del tutto invece di restare lì in grigio.

L'interruttore sta in «Settings → General», nella scheda «Time tracking per ticket», e si chiama «Enable time tracking».

Da lì in poi partecipano tutti i team. Per lasciarne fuori uno lo spegni sul team stesso, in «Settings → Teams», nel riquadro «Team details».

Un'azienda con un team IT interno e un team rivolto ai clienti spesso ne ha bisogno solo per il secondo.

Se più avanti rispegni la registrazione dei tempi, le voci esistenti restano leggibili ed esportabili: sono una base per la fatturazione, non una comodità. Non si può più registrare niente di nuovo.

Il ticket ha una scheda chiamata «Time spent». «Log time» apre l'inserimento.

Accanto al campo ci sono dei pulsanti rapidi: un clic su «30m» registra trenta minuti. Quali pulsanti compaiono si decide nelle impostazioni.

Il campo «Duration» accetta anche l'inserimento libero: «90» sono novanta minuti, «1.5h» è un'ora e mezza, e «1h 30m» pure. Un numero senza unità sono sempre minuti.

Un inserimento che il sistema non capisce del tutto viene rifiutato. «1h in the evening» non diventa una voce di un'ora: diventa un messaggio di errore.

In «What for (optional)» scrivi a che cosa è servito il tempo. Il testo va nell'esportazione e non compare nella cronologia del ticket.

Più agenti registrano tempo sullo stesso ticket. Ogni voce porta il suo giorno, la sua nota e il nome di chi ha fatto il lavoro.

Il tempo si registra su un giorno, non su un'ora precisa. Compilare il giorno prima è il caso normale, e un'ora precisa sosterrebbe una precisione che l'inserimento non ha.

Per le sessioni lunghe sul ticket c'è un cronometro: «Start timer» lo avvia, «Pause» lo ferma.

Il cronometro non crea mai una voce da solo. Propone il tempo trascorso, e niente viene salvato finché non premi «Log».

Sostituisce i calcoli a mente, non la conoscenza. Senza di lui la funzionalità è completa, perché scrivere il valore è la strada principale.

Aprire un altro ticket mette in pausa il cronometro in corsa, e il ticket nuovo ti dice a quale ticket è agganciato.

Una finestra nascosta non è una pausa. Il cronometro continua a correre se ti limiti a cliccare altrove.

Contro un cronometro lasciato correre tutta la notte c'è un tempo massimo. Il valore viene limitato, mai buttato via, e l'agente viene avvisato.

Il cronometro è spento di serie. Lo trovi nelle impostazioni, in «Stopwatch on the ticket».

Ogni voce ha una spunta «Billable». Il tempo viene registrato una volta, e la spunta decide se va sulla fattura.

Per questo il ticket mostra due totali: a sinistra tutto ciò che è stato registrato, a destra la somma fatturabile.

Non c'è un tipo a parte per l'omaggio commerciale. L'omaggio, il lavoro in garanzia e la rilavorazione interna si chiamano in modo diverso in ogni azienda, e il sistema conosce solo l'unica distinzione da cui dipendono i soldi.

Ecco come si registra un omaggio: inserisci il tempo come sempre, togli la spunta e scrivi il motivo nella nota.

La voce mostra allora «not billable». I minuti restano nel totale registrato, perché il lavoro c'è stato davvero.

Chi non registra affatto il tempo perde proprio il numero che poi spiega perché a un cliente è stato chiesto così poco.

Se la maggior parte del tuo lavoro non è fatturabile, ribalta l'impostazione di serie con l'interruttore «New entries are billable by default».

Di serie tutto viene fatturato al minuto. Chi fattura a quarti d'ora imposta due valori.

«Rounding increment (minutes)» è lo scatto. Ogni voce viene arrotondata per eccesso al multiplo successivo.

«Minimum per entry (minutes)» è il minimo. Ogni voce viene fatturata con almeno questo valore.

I due funzionano uno dopo l'altro: prima il minimo, poi lo scatto. Con un minimo di 20 e uno scatto di 15, cinque minuti diventano trenta, perché il risultato deve soddisfare entrambi.

Sotto i due campi c'è una frase di esempio con i tuoi valori. È calcolata, non affermata.

Viene arrotondato solo il valore fatturato, e solo per singola voce, mai il totale. Due voci piccole vengono quindi arrotondate per eccesso due volte.

Il tempo registrato resta intatto. Cambiare l'arrotondamento più avanti non falsifica nessun dato vecchio, perché il valore viene calcolato nel momento in cui viene mostrato.

Sulla voce li vedi entrambi: dove l'arrotondamento cambia il valore, il risultato compare accanto tra parentesi.

Un fornitore di servizi spesso non vuole nessun ticket chiuso senza tempo registrato. C'è un interruttore per questo.

Si chiama «Require a time entry before resolving or closing» ed è spento di serie.

Vale solo quando è una persona a cambiare lo stato. Un agente senza voce riceve un messaggio e il ticket resta aperto.

La chiusura automatica, l'unione e le azioni di massa non vengono mai bloccate. Altrimenti esisterebbero ticket che nessuno riesce più a chiudere.

È l'interruttore più pericoloso di tutta la funzionalità. Accendilo solo quando il tuo team registra davvero il tempo tutte le volte.

L'elenco dei ticket riceve una colonna «Time» che mostra quanto è già stato registrato su un caso.

Non la accendi tu. Compare appena un ticket dell'elenco ha del tempo.

Nelle finestre strette è una delle prime a sparire di nuovo. L'elenco tiene allora le colonne senza le quali un ticket non si trova.

Il tempo che sta solo su un singolo ticket non è una base per una fattura. Per questo la pagina dei report ha una scheda «Time spent».

In alto ci sono quattro numeri: registrato, fatturato, il numero di voci e il numero di ticket che hanno del tempo.

Quest'ultimo numero è il più importante dopo il totale. Quaranta ore su tre ticket su cinquecento non è una valutazione: sono tre agenti che sono gli unici a registrare.

Sotto vengono le ripartizioni: per chi ha fatto la richiesta, per team, per categoria e per giorno.

A questo si aggiunge una tabella per ogni campo personalizzato. È questa la strada per fatturare per azienda o per centro di costo: crei un campo personalizzato, lo compili sul ticket, e il report raggruppa per esso.

Il periodo in cima alla pagina si riferisce al giorno in cui il lavoro è stato fatto. Un lavoro di luglio su un ticket di giugno compare quindi nel report di luglio.

Una nota sopra i numeri merita di essere presa sul serio: vengono da voci inserite da persone e dalle tue regole di arrotondamento. Sono una base di lavoro, non una fattura verificata.

Sotto la scheda ci sono tre pulsanti. Consegnano le singole voci, non i totali della pagina.

Sono due destinatari, non tre formati di file. «Export entries (CSV)» ed «Export entries (Excel)» vanno alla contabilità: sono entrambi completi e non vengono mai tagliati.

«Export entries (PDF)» è il documento per una persona. Va al cliente come allegato della fattura.

Il PDF è limitato a 20.000 voci, e il documento stesso lo dice. Del resto nessuno legge una fattura con più righe di così.

Tutti e tre i file sono costruiti dalla stessa fonte: i filtri, l'arrotondamento, le colonne e i numeri esistono una volta sola, quindi i tre non possono divergere.

Una voce non fatturabile ha una cella vuota nella colonna del fatturabile, non uno zero. Uno zero verrebbe sommato in una tabella pivot.

Un cliente non vede mai le voci di tempo, nemmeno sul proprio ticket.

Non è un'impostazione, è un blocco nel server. Non c'è nessun interruttore che lo apra.

Il motivo sta nelle voci stesse: le note sono scritte per il team. Dicono che cosa è andato storto e quanto è durata la ricerca della causa.

Altri sistemi di questo tipo fanno lo stesso. Dove il tempo arriva al cliente, gli arriva come documento.

È a questo che serve l'esportazione in PDF: va con la fattura e non sul ticket nel portale del cliente.

Il report può mostrare anche chi ha registrato quanto. Di serie non lo fa.

Il tempo per persona è un dato di prestazione, e in molte aziende la rappresentanza dei lavoratori ha voce in capitolo.

L'interruttore si chiama «Per-agent evaluation» e sta nelle impostazioni.

Finché è spento, il server non consegna nemmeno i numeri. La tabella non è nascosta: non esiste.

Quella differenza conta. Un blocco che conosce solo lo schermo non è un blocco.