Richieste con attività e approvazione

«Arriva un nuovo collega» non è un singolo ticket. È un portatile, due account, un interno telefonico e forse un accesso dall'esterno. Ogni pezzo appartiene a un team diverso, e tu vuoi comunque un caso che ti dica a che punto sono le cose.

È a questo che serve una richiesta. È un ticket che crea le sue attività nel momento in cui viene inviata, e ogni attività diventa un ticket a sé nel team che se ne occupa.

Una richiesta non è una seconda cosa da mantenere. Vive su un modello di ticket: in «Settings → Request workflows» trovi tutti i modelli di ticket, e agganci le attività a uno di loro.

Per ogni attività compili alcuni campi. «Task» è il nome che legge chi fa la richiesta, «Handled by» è il team che la riceve, e «Ticket title» e «What the team has to do» riempiono il ticket che ne esce.

Più attività possono puntare allo stesso team. Quel team riceve allora più ticket, non un ticket con dentro un elenco.

Un'attività senza team non viene nemmeno offerta. Lo dice il campo stesso: «Not assigned yet — this task is not offered». Così puoi salvare un piano non ancora finito.

Sopra le attività c'è una frase che riassume tutto il piano: che cosa viene creato di serie, quanto può cambiare chi fa la richiesta e chi dà il via libera. Cambia un'impostazione e la frase si riscrive da sola.

Davanti a «Ticket title» c'è il testo fisso «Parent ticket title -». Il nuovo ticket inizia con il titolo della richiesta, seguito dal tuo titolo, per esempio «New colleague in accounting - Set up notebook and docking station». Così il team specializzato vede a quale richiesta appartiene un'attività. Se lasci vuoto il campo, al suo posto segue il nome dell'attività.

«Main category» e «Subcategory» precompilano la categoria del nuovo ticket. Ottieni solo le categorie del team in «Handled by», perché è lì che viene creato il ticket. Se cambi team, entrambi i campi vengono svuotati. Li imposti tutti e due o nessuno, e se restano vuoti il ticket viene creato senza categoria.

Il nome della richiesta sta sopra le attività. Usa la matita accanto per rinominarlo. Il nome appartiene al modello di ticket, quindi cambia anche in «Settings → Templates» e nel modulo del nuovo ticket.

Quando qualcuno sceglie il modello nel modulo di nuovo ticket, compare il riquadro «What is needed?» con una riga da spuntare per ogni attività.

Ci sono tre tipi, impostati per attività. «Selectable, off by default» parte vuota, «Selectable, on by default» parte spuntata e si può togliere, e «Always — cannot be deselected» parte sempre.

Un'attività che parte sempre viene comunque mostrata, con il contrassegno «(always included)». Chi fa la richiesta deve vedere che cosa succede in ogni caso.

Sotto il riquadro leggi che cosa ne verrà fuori: «Each selected item becomes its own ticket for the team that handles it.»

Anche un cliente può inviare una richiesta, purché il modello sia rilasciato ai clienti. L'interruttore per questo sta sul modello.

Il cliente vede allora soltanto la propria richiesta. I ticket nei team specializzati gli restano nascosti, anche se sono nati dalla sua richiesta: quei ticket contengono credenziali e note interne. Le loro note interne non compaiono nemmeno nella cronologia della richiesta. Quando un team specializzato chiude il suo ticket, i suoi allegati vengono copiati nella richiesta con l'etichetta «Internal», e il cliente non li vede né li scarica.

Se una richiesta arriva per e-mail, diventa un ticket normale. Il flusso di lavoro lo avvii allora in un secondo momento. Lo fa il pulsante «Start workflow» nell'intestazione del ticket.

Nella finestra scegli il modello adatto in «Template». Sotto compare lo stesso riquadro «What is needed?» del modulo di nuovo ticket. Spunta ciò che chiede la richiesta.

In «Title» adatti il titolo del ticket. I titoli delle attività iniziano con esso. Sotto trovi i campi aggiuntivi del modello. Lì inserisci i dati della richiesta. I campi obbligatori hanno un asterisco.

Con «Start» le attività nascono come per una richiesta dal modulo. Se il modello richiede un'approvazione, il ticket e le sue attività restano bloccati finché non arriva.

Per ogni ticket si può avviare un solo flusso di lavoro. Dopo, il pulsante sparisce. Manca anche sui ticket chiusi e sui ticket che sono essi stessi un'attività. Può avviarlo chiunque possa lavorare sul ticket.

Sulla richiesta stessa le attività sono elencate in «Workflow tasks», con il conteggio accanto, per esempio «1 of 4 done».

Ogni riga mostra il nome dell'attività, il numero del suo ticket, il team e il responsabile, e il nome è un collegamento a quel ticket.

«Done» viene dallo stato del ticket, non da una spunta a parte. Ciò che nell'elenco dei ticket conta come chiuso, qui conta come fatto: due modi di contare la stessa cosa prima o poi divergerebbero.

Il blocco compare solo su una richiesta. Un ticket normale non lo mostra.

Quando un team specializzato chiude il suo ticket, il suo «Closing comment» arriva nella richiesta. Lì compare come nota interna, e la sua prima riga indica il numero e il nome dell'attività. Il cliente non vede questa nota.

Le credenziali e tutto ciò che l'agente della richiesta deve inoltrare vanno nel commento di chiusura. Tutti gli altri commenti del team specializzato restano nel suo ticket. Se il team chiude senza commento, non viene creata nessuna nota.

Un'approvazione copre tutta la richiesta, non ogni singola attività. Otto applicazioni sono un messaggio al responsabile, non otto.

Questo si configura in «Approvals», nello stesso piano, e la frase sopra enuncia la regola: «One approval covers the whole request. Add a second stage only when single tasks need their own release.» Ogni fase ha cinque campi: «Name» è il nome della fase, «Covers» dice a che cosa si applica, «Decided by» dice da dove viene chi approva, «Approver» contiene la persona, e «Remind after (hours)» imposta il promemoria.

Chi approva non ha bisogno di un account nel sistema di ticket: inserisci un indirizzo e-mail e la decisione avviene tramite un collegamento. Un responsabile che approva due volte a trimestre non costa quindi nessuna postazione da agente.

Il messaggio contiene esattamente un collegamento a una pagina. Di proposito nel messaggio non ci sono pulsanti di approvazione o rifiuto: un antivirus che aprisse tutti i collegamenti finirebbe per approvare.

La pagina ha come titolo il nome della fase. Mostra il numero e il titolo della richiesta, chi l'ha fatta e, in «This decision covers», le attività a cui la decisione si riferisce, con un campo commento e i due pulsanti sotto.

Il collegamento non dura per sempre, e la pagina indica il termine: «Please decide by …». È valido 14 giorni. Dopo, la pagina dice soltanto che il collegamento non è valido o è scaduto, e un amministratore rimanda la richiesta con «Reassign».

Una decisione non si può ritirare, e dopo la pagina lo dice: «A decision cannot be changed.»

Alcune attività hanno bisogno di un via libera proprio. L'accesso dall'esterno non è la stessa cosa di un portatile.

Per questo aggiungi una seconda fase e la scegli sull'attività, in «Extra approval». Finché dice «None — the request approval is enough», basta il via libera della richiesta. Le due fasi vengono chieste nello stesso momento, non una dopo l'altra. Una fase viene chiesta solo se una delle attività scelte la riguarda. La fase per l'intera richiesta viene chiesta sempre.

Un'attività è libera quando tutte le fasi che la riguardano hanno detto di sì. Un'attività senza una fase propria parte subito, a meno che la fase per l'intera richiesta sia ancora in attesa. Allora parte appena la richiesta è approvata.

Fino ad allora l'attività è bloccata. Il suo ticket sta su «Waiting for approval» e non ha responsabile. Invece dei pulsanti di stato la scheda dice «This ticket is waiting for approval and cannot be worked on yet.» Prima di allora nessuna strada gli assegna un responsabile.

Il blocco vale anche per le azioni di massa sull'elenco dei ticket. Selezionane lì uno del genere e leggi il motivo: «This ticket is waiting for approval and cannot be worked on yet.»

Il ticket viene comunque creato subito, così il team specializzato vede che cosa sta arrivando e nessuno deve tenere d'occhio la richiesta.

Puoi impostare un sollecito per fase, indicato in ore.

Se non arriva risposta, dopo quel tempo lo stesso messaggio esce di nuovo, con lo stesso collegamento del primo. Chi ha conservato il primo messaggio può continuare a usarlo.

Senza sollecito la richiesta si limita ad aspettare, senza chiedere di nuovo.

Quello che non esiste è il via libera alla scadenza. Sotto il campo c'è scritto a parole: «A request is never approved automatically. If nobody reacts, it keeps waiting.» Un termine che dicesse di sì da solo non sarebbe un'approvazione, sarebbe una formalità.

Il rifiuto richiede una motivazione. Senza un testo la pagina non accetta il rifiuto.

Il campo dice dove finisce il testo: «Comment (required when you reject — the requester will see it)». Una nota interna qui non ci sta.

Chi ha fatto la richiesta riceve un'e-mail con la motivazione e non deve chiedere perché non si muove niente.

Approvare non ha bisogno di motivazione. È l'esito che ci si aspetta.

Se rifiuta solo una seconda fase, il rifiuto riguarda soltanto le attività di quella fase. Il resto della richiesta prosegue.

Un'attività rifiutata riceve lo stato «Rejected» e conta come conclusa, così la richiesta non resta appesa per sempre a qualcosa che non arriverà mai.

Appena la richiesta viene rifiutata, gli altri approvatori non ricevono più messaggi. Il loro collegamento dice allora «This request has already been rejected. Your decision is no longer needed.» Nell'elenco sul ticket la loro fase mostra «No longer needed: the request was rejected.»

Sulla richiesta, «Approvals» mostra una riga per fase con chi approva, lo stato e, se la richiesta è aperta, da quanto tempo sta aspettando.

Dopo la decisione la riga mostra quando è stata presa e con quale commento. È questa la tracciabilità, e resta con il caso.

Se chi approva è in ferie, un amministratore sposta la richiesta a un altro indirizzo. Il pulsante si chiama «Reassign» e compare solo mentre la richiesta è aperta.

Solo un amministratore può farlo. Un agente che potesse riassegnare potrebbe riassegnare a sé stesso e poi decidere.

La riassegnazione crea un collegamento nuovo, e quello vecchio muore all'istante, anche se qualcuno lo aveva inoltrato.

Lo spostamento stesso compare nello stesso elenco: chi lo ha fatto, quando, da chi a chi.

Nessuno può decidere a nome di un altro. Il collegamento è l'unica strada, e chi lo ha ricevuto resta registrato sul caso.