Nessuna pratica resta ferma senza che qualcuno lo sappia.
SLA, timeout ed escalation a step con notifiche che arrivano alla persona giusta, all'ora giusta, senza sommergere nessuno.
- Per
- Management
- Operatore
- Process owner
Il problema
Le pratiche ferme si scoprono quando il cliente chiama. Gli alert esistenti sono tutto o niente: o non arrivano, o arrivano a tutti, a qualsiasi ora, finché diventano rumore e vengono ignorati. E non si sa se qualcuno ha davvero preso in carico il problema. Un avviso che nessuno conferma di aver letto è un avviso che potrebbe non essere mai esistito, e un avviso che arriva alle tre di notte a tutto il reparto insegna soltanto a silenziare le notifiche. Per funzionare, l'escalation deve avere gradini ragionati, canali adatti, orari rispettosi e una prova chiara che qualcuno si sia fatto carico. FlowSharp dà a ciascuna di queste cose una forma configurabile e tracciata.
Politica a 3 step
- T+0 · in-app all'assegnatario
- T+4h · email al responsabile
- T+1g · webhook al canale operations
Stato
- Fuori fascia: invio alle 08:00
- Presa in carico da Marco · 12 min
Come funziona
- 1
Definisci tempi e SLA
Timeout per fase con durate leggibili (2h, 1d, 1w), SLA del flusso e fasi di eccezione (Escalation, Scaduto, Fuori capacità) raggiungibili solo dal sistema. Le durate si scrivono come le diresti a voce.
- 2
Scegli la reazione
Solo avviso all'assegnatario (o agli Admin), oppure spostamento automatico verso la fase di escalation. Il processo può quindi limitarsi a segnalare, o cambiare strada da solo quando il tempo è scaduto.
- 3
Costruisci la politica di alert
Step temporali via email, webhook o evento, come regola predefinita dell'organizzazione o dedicata al flusso. Ogni step ha il suo canale e il suo destinatario, in modo che la gravità cresca con il tempo.
- 4
Qualcuno prende in carico
Il destinatario clicca un link monouso di presa in carico. Gli Admin vedono i tempi di presa in carico e di risoluzione. L'avviso smette di essere un messaggio lanciato nel vuoto e diventa un impegno misurabile.
Specifiche
| Canali | email, webhook firmato HMAC-SHA256, evento, in-app |
|---|---|
| Anti-rumore | digest per destinatario, fasce orarie con fuso e ora legale |
| Fuori fascia | email e webhook slittano; l'in-app resta immediata |
| Presa in carico | link monouso a scadenza, con clic esplicito |
| Durate | fino a 366 giorni; anche da espressione o variabile |
| Alert speciali | "Automazione ferma" agli Admin: un solo avviso persistente per pratica e fase |
Un esempio operativo: una politica a tre step
Una politica di escalation può avere tre step. Al tempo zero parte una notifica in-app all'assegnatario. Dopo quattro ore, se nessuno ha agito, parte un'email al responsabile. Dopo un giorno, un webhook avvisa il canale operations. Ogni step è quindi più visibile del precedente, e la pratica non resta ferma senza che qualcuno se ne accorga. Se un avviso cade fuori fascia oraria, non viene inviato di notte: attende e parte alle 08:00. Quando un collega prende in carico la segnalazione, nell'esempio Marco dopo dodici minuti, lo stato lo registra e gli step successivi non vengono più necessari. Lo schema accanto è illustrativo, con tempi e nomi a titolo di esempio, e non una schermata ufficiale. Le notifiche viaggiano sui canali previsti: in-app, email e webhook.
Come verificare che gli avvisi arrivino
Un'escalation è affidabile se si può verificare cosa è successo a ogni step. Controlla nello storico della pratica quando è partito ciascun avviso, a chi e su quale canale, e se è stato rimandato per la fascia oraria. Verifica poi che la presa in carico sia registrata con chi l'ha fatta e dopo quanto tempo: il tempo di presa in carico è un buon indicatore di quanto l'organizzazione risponde. Per i canali esterni come il webhook, guarda lo stato di consegna, che dichiara onestamente se è riuscita, fallita o non verificata. Dal punto di vista della governance, questo evita il classico scenario in cui un avviso si dava per inviato e nessuno l'ha mai ricevuto. Se un avviso resta senza presa in carico fino all'ultimo step, la politica ha comunque lasciato la prova che l'organizzazione è stata informata e quando.
Funzionalità collegate
- Timeout, SLA e rotte di eccezioneDurate leggibili, destinazione allo scadere e fasi di eccezione raggiungibili solo dal sistema.
- Alert "Automazione ferma"Un solo avviso persistente agli Admin quando una fase non ha uscite valide o un'AI fallisce.
- Limiti WIP e code di capacitàLimiti di lavoro in corso per flusso e per fase, con quattro reazioni possibili.
- Webhook in uscita verificabiliQuando accade un evento, FlowSharp avvisa i sistemi collegati, con storico per tentativo.
- Dashboard e tempo realeKPI, distribuzione per stato, tempi per fase e pratiche a rischio, aggiornati in tempo reale.
Casi d'uso
Domande frequenti
Che differenza c'è tra timeout e SLA?
Il timeout agisce sulla singola fase ("allo scadere vai a…"); lo SLA misura il flusso e può limitarsi ad avvisare oppure spostare la pratica in escalation.
Posso evitare notifiche di notte?
Sì: con le fasce orarie, email e webhook slittano all'apertura della fascia.
Gli alert possono avviare un altro processo?
Sì: lo step "evento" può avviare un flusso di gestione dell'escalation.
Chi vede i tempi di presa in carico?
Gli Admin.