La SLA di approvazione e cosa succede quando viene superata

Due timer, e quale dei due vince

La maggior parte delle approvazioni non ha una data inserita. Un producer invia un cut e nessuno scrive una scadenza, quindi il problema non è una data mancata, bensì un'approvazione rimasta aperta per quattro giorni senza che nessuno se ne accorgesse. Ecco perché la SLA di approvazione viene misurata a partire dal momento in cui l'approvazione è stata aperta, rispetto a un obiettivo. L'obiettivo predefinito è di 72 ore e la finestra di avviso predefinita è di 12 ore prima.

Quando invece viene inserita una scadenza, quella data ha la priorità. Un'approvazione risulta violata quando l'obiettivo è scaduto o la scadenza è passata (a seconda di quale evento si verifichi per primo), ed è a rischio quando uno dei due rientra nella finestra di avviso. Un processo di sollecito separato viene eseguito ogni cinque minuti e invia un promemoria per le approvazioni la cui scadenza è giunta o scadrà entro i successivi 60 minuti, in modo da rispettare all'ora esatta la scadenza inserita.

Le fasi hanno il loro timer. Una fase può avere una SLA espressa in ore; l'ingresso di un task avvia il timer, lo stato è regolare fino al passaggio dell'80 percento della finestra temporale, a rischio da quel momento fino alla scadenza, e violato successivamente. Lo stato viene calcolato a partire dai timestamp ogni volta che viene letto, quindi non c'è alcun contatore che possa rimanere indietro.

Cosa fa il controllo ogni 15 minuti

Un processo pianificato esamina le approvazioni in sospeso di ogni organizzazione, a partire dalle più vecchie, fino a un massimo di 500 per organizzazione a ogni esecuzione, e classifica ciascuna come regolare, a rischio o violata. Per ogni violazione il cui periodo di cooldown del sollecito è trascorso, invia lo stesso sollecito che un producer invierebbe manualmente, ed elenca nel proprio report le approvazioni in attesa da più tempo, in modo che un operatore possa vedere quali sono.

Il sollecito è limitato a 50 approvazioni per organizzazione a ogni esecuzione. Uno studio che rientra da una chiusura di due settimane non deve ricevere solleciti per l'intero backlog in un colpo solo; l'esecuzione successiva si occuperà del resto.

Il processo non inventa uno stato di escalation e non invia un'email al proprietario. Ciò che fa è reale e registrato: un contrassegno di sollecito sull'approvazione, una riga di controllo che indica che il sollecito è stato inviato dal sistema e un messaggio alla persona che può agire.

Chi riceve il sollecito

Ha senso inviare un sollecito solo a chi deve ancora approvare. Per un'approvazione rivolta al cliente, si tratta del cliente stesso, il quale non ha un account, nessun posto e nessuna notifica in-app; ciò che ha è un accesso al portale. Quindi il processo cerca gli accessi attivi che possono decidere su questa approvazione: accessi con autorizzazione di approvazione, non revocati, non scaduti, limitati a questo progetto o all'intero cliente, e associati a un'email o a un numero di telefono.

Ciascuno di questi accessi riceve il sollecito sui canali disponibili: un'email che indica il nome dell'approvazione, specifica da quanti giorni è in attesa e rimanda alla pagina principale del portale, e un SMS con il nome dello studio e il link al portale. Non viene reinviata alcuna credenziale; il cliente accede nuovamente nello stesso modo in cui è entrato la prima volta. L'email viene inviata una volta al giorno per accesso, e l'approvazione stessa riceve un sollecito al massimo una volta ogni 12 ore.

Quando non ci sono accessi del cliente raggiungibili - come nel caso di un'approvazione interna o di un cliente il cui unico accesso è un codice consegnato a mano senza email né telefono - il sollecito passa agli assegnatari del task tramite la notifica in-app, ovvero l'elenco interno dello studio. Questo è l'unico caso in cui lo studio deve sollecitare direttamente il cliente, e la notifica lo segnala chiaramente.

Il sollecito manuale e la traccia che lascia

Un producer può sollecitare un'approvazione manualmente dall'approvazione stessa. Il percorso seguito è lo stesso del processo automatico: viene registrato il contrassegno di sollecito, una riga di controllo memorizza chi lo ha premuto e il messaggio viene inviato ai medesimi accessi. La differenza nel registro sta nell'autore: una persona per il sollecito manuale, il sistema per quello pianificato.

Il cooldown di 12 ore si applica a entrambi i casi. Un secondo sollecito manuale all'interno della finestra temporale viene rifiutato con un messaggio che indica che l'approvazione è già stata sollecitata di recente, evitando così di inviare un duplicato al cliente. Anche il sollecito per un'approvazione non più in sospeso viene rifiutato.

Il contrassegno viene registrato prima dell'invio del messaggio, quindi un'eventuale interruzione del provider di posta non annulla mai il sollecito; il registro indicherà che è stato tentato un sollecito e l'esecuzione successiva potrà riprovare una volta terminato il cooldown.

Leggere la SLA nei report di analytics

Il timer della SLA alimenta i dati di analytics che lo studio consulta per monitorare le proprie prestazioni. La vista dei colli di bottiglia riporta il tempo mediano che un task trascorre in ciascuna fase: è qui che una fase di review del cliente particolarmente lenta emerge come un dato numerico concreto anziché come una semplice sensazione. Il report settimanale per i proprietari mostra lo stesso quadro e il punteggio di rischio di un progetto ne elenca i motivi, spiegando chiaramente perché un progetto è in attesa di un cliente da tre giorni oltre l'obiettivo.

Il conteggio degli elementi in attesa del cliente viene calcolato a partire dalle approvazioni effettivamente sottoposte a un cliente tramite un link decisionale, in modo che un'approvazione interna non vada mai a gonfiare artificialmente il numero di elementi in attesa del cliente.

Impostare l'obiettivo

L'obiettivo di 72 ore e l'avviso di 12 ore sono i valori predefiniti con cui viene eseguito il controllo. Le SLA di fase vengono impostate per ciascuna fase del workflow, in ore, e un workflow proposto dall'onboarding dell'AI include una tabella delle SLA per fase che viene applicata solo dopo che lo studio l'ha esaminata e approvata; una fase non menzionata nella tabella non avrà alcun timer, poiché un timer non scelto è peggio di nessun timer.

Una scadenza inserita su una singola approvazione rappresenta l'istruzione più specifica e prevale su tutto il resto. Se un cliente ha promesso una risposta entro giovedì, inserisci giovedì.

• Predefinito: 72 ore dall'apertura, avviso 12 ore prima.
• Controllato ogni 15 minuti; solleciti per le scadenze ogni 5 minuti con un anticipo di 60 minuti.
• Un sollecito per approvazione ogni 12 ore; un'email per accesso al giorno.