Modelli di risposta e di ticket

I modelli stanno in «Settings → Templates». La riga sotto il titolo dice che cosa fanno e che cosa non fanno: «Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.» Un modello è un gesto preparato, non una macchina: sei sempre tu a inviare.

Ci sono due tipi e ne scegli uno alla creazione: «Add reply template» per la risposta su un ticket aperto, «Add ticket template» per il modulo di nuovo ticket. Il tipo non si può cambiare dopo, perché decide quali campi mostra il modulo. L'etichetta sopra ogni modello ti dice quale stai guardando: «Reply template» in blu, «Ticket template» in verde.

Un modello di risposta è fatto dal testo della risposta («Reply text»), dalla casella «Internal note» e da un numero qualsiasi di azioni. Le azioni sono sei: «Set the status», «Set the priority», «Assign to a user», «Remove the assignee», «Hand over to another team» e «Set a follow-up».

L'elenco «Assign to a user» comincia con la voce «The agent who applies it». Scegli quella quando più persone condividono il modello: il ticket appartiene allora a chi lo ha applicato, non a una persona fissa dell'elenco. «Set a follow-up» chiede una quantità e un'unità (minuti, ore, giorni, minuti lavorativi, ore lavorative, giorni lavorativi) e poi la nota che più tardi ti dirà perché il ticket è tornato.

Il riquadro azzurro alla fine di ogni modello scrive in una frase che cosa farà — per esempio «Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.» La frase si ricostruisce mentre modifichi. È la tua controprova: se dice qualcosa di diverso da quello che volevi, c'è un'impostazione sbagliata.

Il testo non è obbligatorio. «Passare questo al team di rete senza scrivere una parola» è un modello valido: la frase dice allora «Suggests actions without a reply text». L'azione «Set the status» segue le stesse regole di un cambio di stato a mano. Applicato a più ticket in una volta, il modello salta i ticket bloccati e ne indica il motivo.

Anche la finestra «Close ticket» offre i modelli di risposta, nel campo «Template». Elenca solo i modelli la cui azione attiva «Set the status» imposta uno stato che conta come risolto o chiuso. I modelli interni lì non vengono offerti. Se ne scegli uno, la finestra ne riprende il testo come commento. Se il modello invia un messaggio e la finestra offre l'invio per posta, riprende il destinatario solo se è «Requester» o un indirizzo fisso. Le altre azioni del modello lì non vengono eseguite, e i suoi allegati non vengono aggiunti. Il ticket si chiude come al solito.

Su un ticket aperto il pulsante «Template» sta sopra l'editor dei commenti. Un clic apre la ricerca con suggerimenti («Search templates…») e sceglierne uno riempie l'editor dei commenti. Non succede nient'altro, e la riga sotto lo dice: «Nothing happens until you add the comment.»

Ogni azione del modello diventa un'etichetta accanto al pulsante, in parole semplici e non in gergo: «sets status to Waiting for Service Provider Response», «assigns to the applying agent», «sets a follow-up in 3 days». Cliccare un'etichetta la barra: è deselezionata e non verrà eseguita. Un altro clic la riporta indietro.

Le azioni deselezionate restano barrate, non vengono rimosse. Così resta visibile che cosa avrebbe suggerito il modello, e la decisione resta reversibile finché non hai inviato.

Quali etichette partono attive lo decide il modello: nelle impostazioni ogni azione ha un interruttore «Suggested». Quell'interruttore è la proposta per tutti i casi; l'etichetta sul ticket è la decisione per questo.

La «×» dopo le etichette toglie di nuovo il modello. Il testo resta nell'editor — potresti benissimo averlo già riscritto; sparisce solo l'effetto, cioè le azioni, il messaggio e gli allegati.

Invii con il solito pulsante dei commenti. Solo allora il commento viene creato, e solo dopo vengono eseguite le azioni ancora attive.

Il testo della risposta può usare cinque segnaposto; l'elenco sta sotto il campo: «{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}». Scrivili con le parentesi graffe, esattamente come compaiono lì.

«{ticketRef}» è il riferimento del ticket nella forma «[TICKET-8-…]». È da lì che il sistema riconosce la risposta di un cliente quando torna per e-mail. «{ticketId}», invece, è solo il numero nudo.

Vengono risolti quando il modello viene APPLICATO, non quando viene salvato: la pagina delle impostazioni continua a mostrare «{requesterName}», l'editor dei commenti sul ticket mostra il nome vero. Il motivo è pratico: risolvere al salvataggio inciderebbe per sempre nel modello i valori di UN ticket.

Così leggi il testo finito prima che qualcosa esca dall'azienda. Se il saluto non va bene, lo cambi nell'editor come qualsiasi altro testo.

Chi conta come «chi ha fatto la richiesta» lo decide il ticket, non l'account: chi è registrato sul ticket viene prima dell'account che lo ha inviato. Se un agente apre un ticket per un collega dopo una telefonata, la risposta saluta comunque il collega e non l'agente.

Un segnaposto scritto male viene rifiutato al salvataggio, e viene nominato: «Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.» Così te ne accorgi mentre scrivi il modello, non su un cliente.

L'oggetto dell'e-mail ha il SUO elenco, più corto («{originalSubject}, {ticketTag}, {ticketId}»): è per questo che lì viene stampato una seconda volta. Lì funziona anche «{ticketRef}», che significa lo stesso di «{ticketTag}». «{requesterName}», «{ticketTitle}» e «{agentName}» non funzionano nell'oggetto e vengono rifiutati allo stesso modo.

L'interruttore «Send the comment as e-mail» trasforma il commento anche nel messaggio. Di proposito non c'è un secondo campo di testo: quello che sta nel ticket è quello che legge il cliente — due testi prima o poi divergerebbero.

In «Recipient» scegli tra «Requester», «Assignee», «Observers» e «Fixed address». Chi sia chi ha fatto la richiesta lo risolve il server quando il modello viene applicato: un modello non conosce ancora il ticket. All'account della casella in arrivo non viene mai scritto; sarebbe un messaggio a noi stessi. Se il campo «User» contiene un nome senza indirizzo, a chi ha fatto la richiesta non parte nessun messaggio. Né viene mandato al suo posto a chi ha registrato il ticket.

L'oggetto può contenere «{originalSubject}», «{ticketTag}» e «{ticketId}». Tieni dentro «{ticketTag}»: è da quel riferimento che il sistema riconosce la risposta del cliente e la aggiunge allo stesso ticket. Senza, ogni risposta diventa un ticket nuovo.

Il messaggio esce come testo semplice. Il grassetto, gli elenchi e i collegamenti vengono tolti prima dell'invio, altrimenti il cliente leggerebbe la marcatura grezza. Dentro al ticket il commento mantiene la sua formattazione.

Sul ticket il messaggio è un'etichetta in più accanto alle azioni («E-mail to Requester») e si può deselezionare come loro. Così un modello non manda mai niente senza che tu l'abbia visto. L'etichetta compare solo quando la casella del team manda messaggi sulle azioni del ticket.

Gli allegati di un modello («Attachments») sono copie proprie dei file. Applicare il modello li aggiunge al TICKET, con una riga propria nella cronologia: non fanno parte del messaggio. Avere allegati su un modello non richiede una licenza Professional; solo l'invio la richiede. Un modello con la spunta «Internal note» non aggiunge file.

La maggior parte dei modelli non nasce a tavolino, ma nel momento in cui scrivi la stessa risposta per la seconda volta. Per questo ogni commento su un ticket ha a destra una piccola icona a foglio, con la scritta «Make template». Prende esattamente quel commento come testo di partenza, anche il commento di un collega. L'icona la vede solo chi può gestire i modelli.

Se il ticket ha allegati, una finestra chiede prima quali devono venire con te: «Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default.» Non c'è niente di già spuntato, ed è voluto.

Dopo arrivi nella pagina dei modelli con una bozza che NON è ancora salvata. In cima c'è la banda ambra «Draft from ticket #… — name it and review the text (it may contain customer details), then save.» Il nome è vuoto: devi darne uno, altrimenti non si salva.

Che cosa viene ripreso: il testo, la casella «Internal note», il team del ticket e lo stato del ticket come proposta — il suo stato e la sua priorità sono già lì come due azioni. Che cosa non viene ripreso: chi ha fatto la richiesta, l'indirizzo e il titolo. Quelli appartengono a questo caso.

Leggi il testo prima di salvare. Viene da un caso vero e può contenere il nome di una persona, un numero d'ordine o una stanza. Niente viene reso anonimo al posto tuo: la banda lo dice, ma farlo è compito tuo.

Solo «Save» crea il modello; gli allegati spuntati vengono poi copiati e confermati con un messaggio.

«Applies to» decide a chi viene offerto il modello: a un team preciso oppure a «All teams». Un modello nuovo parte con un team preciso: «All teams» è una scelta che qualcuno deve fare, non un'impostazione silenziosa.

Su un ticket ti vengono offerti i modelli del team responsabile e quelli globali. Se dopo un passaggio il ticket va a un altro team, l'elenco lo segue: puoi scegliere tra i modelli del nuovo team.

L'interruttore «Draft» trasforma il modello nella tua officina: «Only you can see this template until you publish it.» La bozza di un altro non compare in nessun elenco e non si raggiunge nemmeno dall'indirizzo, nemmeno da amministratore. Un modello nuovo parte come bozza; solo quando spegni quell'interruttore e salvi lo vedono gli altri.

Due modelli non possono avere lo stesso nome se si possono incontrare: uno globale entra in conflitto con qualsiasi modello dello stesso nome, in qualsiasi team. Un modello di risposta e un modello di ticket, invece, possono condividere un nome: non compaiono mai affiancati nello stesso elenco.

«Duplicate» fa una copia, e la copia è sempre una bozza: «Duplicated. The copy is a draft only you can see.» È la strada comoda per una variante senza che a nessun altro venga offerta la versione a metà.

Un modello di ticket riempie il modulo «Create new ticket». Non ha testo di risposta, non ha azioni e non ha messaggio: in questo momento non esiste nessun ticket su cui agire. Il modulo mostra quindi campi diversi da quelli di un modello di risposta, e la cornice verde ti dice che stai guardando un modello di ticket.

Puoi precompilare «Ticket title», «Owning team of the new ticket», «Main category», «Subcategory», «Priority» e la «Ticket description». Ogni campo può restare su «Not prefilled»: quello che resta vuoto lo riempie poi chi usa il modulo.

Fai attenzione alla differenza tra i due campi di team: «Applies to», in alto, dice CHI vede il modello. «Owning team of the new ticket» dice DOVE va il nuovo ticket. Sono due domande diverse e possono avere risposte diverse.

Le categorie sono raggruppate per team, perché una categoria appartiene a un team. Se ne scegli una di un altro team, il modulo te lo dice e il salvataggio viene rifiutato: nel modulo di nuovo ticket del team di destinazione quella categoria non verrebbe nemmeno offerta, quindi la precompilazione non porterebbe a niente.

Qui non ci sono segnaposto, e l'indicazione sotto il testo lo dice: «No placeholders here: the template only prefills the form, nothing is resolved or sent.» Un «{requesterName}» finirebbe alla lettera nel ticket nuovo: è per questo che viene rifiutato al salvataggio.

Anche qui il riquadro azzurro riassume che cosa fa il modello: «Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description.»

Nel modulo stesso scegli il modello con il pulsante «Template»; accanto c'è «Prefills the form - nothing is created until you submit.» Tutto ciò che è precompilato si può ancora cambiare, e niente viene creato finché non invii.

Il sistema porta con sé un modello di esempio: «Example: create accounts for a new colleague». Mostra la forma della cosa e da solo non fa niente: ricostruiscilo o cancellalo.

L'interruttore «Offer this template to customers» è spento di serie. L'indicazione accanto dice le due cose che devi sapere: «Customers can pick this template when they create a ticket. A draft stays hidden either way.»

Perché è spento di serie: spesso un modello ha un nome in vocabolario interno ed è scritto per i colleghi. Renderlo visibile ai clienti è un'affermazione verso l'esterno: qualcuno deve farlo di proposito, non per sbaglio.

Il cliente vede lo stesso pulsante «Template» sopra il modulo di nuovo ticket, ma solo i modelli rilasciati. Una bozza resta nascosta anche con l'interruttore acceso: le due regole stanno una dietro l'altra, non affiancate.

L'obiettivo non è la comodità, è il primo contatto: una richiesta che arriva completa fa risparmiare il giro di domande che altrimenti costerebbe due giorni. Metti quelle domande nella descrizione del modello: il cliente ci risponde mentre crea il ticket.

Puoi andare oltre con «Fields to ask for». Il modello decide allora quali campi personalizzati chiede il modulo, in che ordine e quali di essi sono obbligatori. Quella selezione SOSTITUISCE i campi abituali del team, non li aggiunge. È esattamente la sua funzione. I campi personalizzati in sé fanno parte di Professional; la loro scheda si chiama «Campi personalizzati». Rilasciare un modello ai clienti funziona in tutte le edizioni.

Un campo nascosto ai clienti resta nascosto, anche se un modello lo elenca. La selezione dei campi è uno strumento di ordine e di taglio, non un modo per aggirare le impostazioni dei campi.

Ogni utilizzo che fa più che inserire testo scrive UNA voce nella cronologia, sotto il nome di campo «Template». Nomina il modello. Le azioni eseguite scrivono righe proprie. Senza, non ci sarebbe modo di spiegare più tardi perché un ticket sia saltato all'improvviso su «In Progress»: le singole azioni scrivono le proprie righe, ma nessuna di loro nomina il modello.

L'immagine dice: «Template 'First reply: we have your ticket' applied». Quello che il modello ha fatto sta nelle righe delle sue azioni, per esempio il cambio di stato.

Le azioni deselezionate non ci sono: non sono avvenute. Un fallimento c'è, ed è nominato come tale, dopo la parola «failed». Un modello di solo testo, senza azioni, messaggio né allegati, non lascia nessuna voce «Template» su un singolo ticket. Ha solo inserito del testo. Applicato a più ticket in una volta, la voce viene sempre scritta, insieme alla riga interna «Bulk».

La voce è INTERNA: chi ha fatto la richiesta non la vede. Il nome di un modello è vocabolario interno («rifiuto standard»), e la cronologia è aperta anche a chi ha creato il ticket. Le modifiche ai campi restano visibili a quella persona; solo la loro origine in un modello no.

L'autore è l'agente, non «system» e non il modello. È voluto: applicarlo è stata una sua decisione. A differenza di una regola di automazione, qui sul ticket resta una persona.