Punti chiave
- Distingui gli alert dagli incidenti, così i clienti capiscono che cosa innesca una risposta e perché.
- Suddividi il ciclo di vita dell’alert in rilevamento, creazione del ticket, triage, risposta, escalation e chiusura, spiegandolo in parole semplici.
- Traduci gli SLA in scenari concreti invece di citare i tempi di risposta senza contesto.
- Chiarisci i percorsi di escalation, così i clienti sanno chi si occupa della prima risposta e quando il caso passa al secondo livello o a un fornitore.
- Mostra ai clienti che cosa vedranno durante e dopo un incidente e spiega come soglie e filtri evitano l’alert fatigue.
Come provider di servizi gestiti (MSP), devi essere in grado di spiegare ai tuoi clienti il processo di gestione degli alert in modo chiaro ed efficace. Se non lo fai, i clienti potrebbero avere l’impressione di non essere seguiti adeguatamente o che i tuoi sforzi non siano all’altezza (anche se segui le best practice del settore, con un team competente e dotato di tutte le risorse necessarie, capace di risolvere i problemi in tempi rapidi).
Questa guida offre un framework per comunicare il tuo processo di gestione degli alert in modo comprensibile per i clienti. In questo modo si fissano aspettative realistiche e si mantiene la fiducia durante gli incidenti.
Cerchi una guida completa sull’argomento? Guarda il nostro video: Come spiegare con chiarezza ai clienti il processo di gestione degli alert.
Qual è la differenza tra alert e incidenti?
Un incidente è un’interruzione dei servizi IT che fornisci ai tuoi clienti o che gestisci per loro. Gli incidenti di solito non sono pianificati e possono andare da problemi come un servizio internet degradato per via di una connessione caduta fino al blocco totale di un file server causato da un crash di sistema. Gli incidenti di cybersecurity, come le violazioni dei dati, possono non interrompere il servizio in modo acuto o immediato, ma possono generare altri effetti negativi.
Un alert viene prodotto in conseguenza di un incidente e inviato al tuo team tecnico affinché ne sia informato. Può essere generato da sistemi di monitoraggio o da piattaforme di cybersecurity e può essere inviato al primo verificarsi di un incidente (ad esempio, un server smette di rispondere) oppure al raggiungimento di soglie specifiche (ad esempio, un certo numero di tentativi di accesso falliti per un utente). Gli alert possono anche nascere da una persona, sotto forma di ticket di assistenza, e rivelare attività insolite o malfunzionamenti della tua infrastruttura che i sistemi automatizzati potrebbero non cogliere.
Che cos’è il processo di gestione degli alert?
Il processo di gestione degli alert (o triage degli alert) è il modo in cui configuri gli alert e vi rispondi. Un processo di gestione degli alert efficace garantisce soglie sensate e fa sì che gli alert vengano classificati per priorità e sottoposti a escalation quando necessario, così nulla sfugge e gli incidenti critici hanno la precedenza sui fastidi minori.
Per il tuo team MSP, l’obiettivo del processo di gestione degli alert è avere visibilità evitando l’alert fatigue. Per i clienti, invece, tutto questo deve risultare comprensibile: devi saper spiegare in modo semplice le ragioni tecniche per cui il tuo processo di triage è impostato in un certo modo. Così, quando inevitabilmente si verificherà un incidente grave, saranno rassicurati nel sapere che ha la precedenza sulle altre attività in corso e che il tuo team se ne sta già occupando.
Spiegare con chiarezza il processo di gestione degli alert
La tecnologia può aiutarti a comunicare ai clienti quanto il tuo team sia preparato. Puoi fare una dimostrazione del software di monitoraggio, mostrando dashboard e notifiche in azione. Le policy di monitoraggio e sistema di alert (compresi i livelli di escalation) possono essere condivise tramite la piattaforma di documentazione del tuo MSP, mentre il software di helpdesk può supportare una comunicazione chiara con il cliente e aggiornamenti sullo stato di un incidente.
Le quarterly business review (QBR) sono l’occasione per mostrare report generati dalle metriche di monitoraggio e dell’helpdesk, dimostrando che il tuo processo di gestione degli alert è stato efficace.
Quando spieghi il tuo processo di gestione degli alert, ai clienti devono risultare chiare le risposte a queste domande:
- Che cosa succede quando qualcosa va storto?
- Con quale rapidità intervenite?
- Come faccio a sapere che nessun problema verrà trascurato?
Nessuna di queste risposte deve suonare astratta: devono essere risposte concrete, basate sulle tue policy, che verranno messe in pratica quando se ne presenterà davvero la necessità.
Requisito 1: spiega il ciclo di vita dell’alert in parole semplici
Evita il gergo tecnico quando illustri i tuoi sistemi di monitoraggio e i metodi di alert. Tratta le tecnologie e i concetti seguenti, spiegando come li usi per rispondere ai problemi dei clienti:
- Rilevamento: spiega quali strumenti di monitoraggio usi per individuare i problemi.
- Creazione del ticket: spiega come vengono creati i ticket, sia automaticamente dai sistemi di monitoraggio sia dagli utenti che segnalano un problema.
- Triage: descrivi nel dettaglio come il tuo tecnico verifica un alert e ne valuta la priorità.
- Risposta: se l’alert ha rilevato un incidente, illustra il processo con cui viene assegnato e risolto.
- Escalation: assicurati che il cliente capisca che, se un incidente non viene risolto in tempi rapidi, l’alert passa a personale di livello superiore o a un fornitore terzo. Ad esempio, può essere necessaria un’escalation al supporto Microsoft per un problema su Microsoft 365 che non può essere risolto esternamente.
- Chiusura e reporting: i dettagli e i tempi di risoluzione documentati vengono inclusi nei report e utilizzati per analisi e miglioramenti futuri
Diagrammi e diagrammi di flusso che mostrano il percorso dei diversi alert possono essere d’aiuto. Potresti mostrare, ad esempio, come un alert inizialmente a bassa priorità venga sottoposto a escalation al raggiungimento di determinate soglie.
Requisito 2: traduci gli SLA in scenari
Gli scenari pratici aiutano a rassicurare i clienti perché offrono un esempio che possono applicare ai propri processi aziendali per valutare l’impatto del tuo processo di gestione degli alert.
Ad esempio, invece di limitarti a citare un tempo di risposta, contestualizzalo: “Se il tuo server va offline alle 2 di notte, il nostro sistema genera immediatamente un alert e un tecnico reperibile interviene entro 15 minuti. In genere prevediamo di rimetterlo in funzione entro i 30 minuti successivi e, se non ci riusciamo, entro un’ora facciamo intervenire un tecnico on-site.”
Requisito 3: chiarisci i percorsi di escalation
Spiega come fai in modo che un incidente non resti bloccato in coda o fermo con un tecnico che non è riuscito a risolverlo. Tratta questi punti:
- Chi si occupa della prima risposta (primo livello)
- Chi gestisce l’escalation dei problemi complessi (secondo/terzo livello o fornitore terzo)
- Come vengono informati clienti e stakeholder durante l’escalation
Requisito 4: mostra ai clienti che cosa vedranno quando qualcosa va storto
Nell’ambito dell’onboarding del cliente, mostragli esempi di ciò che vedrà durante e dopo gli incidenti che hanno generato alert. Possono essere report con gli alert risolti e le metriche di uptime, oppure dashboard rivolte al cliente con dati in tempo reale.
Metti in evidenza i casi eccezionali durante le QBR per dimostrare l’efficacia del tuo processo di gestione degli alert.
Requisito 5: distingui tra alert e rumore di fondo
Spiega quali tecnologie stanno dietro al monitoraggio e agli alert e come permettono al tuo team di offrire servizi efficienti, orientati a garantire l’uptime. L’alert fatigue si verifica quando i tecnici vengono sommersi da alert relativi a problemi minori e finiscono per lasciarsi sfuggire incidenti importanti.
Mostra ai clienti come eviti tutto questo e come usi soglie, filtri e automazione per assegnare agli incidenti una priorità sensata in base alla loro gravità.
NinjaOne offre una soluzione unificata per monitoraggio, alert, gestione dei ticket e documentazione
NinjaOne mette a disposizione degli MSP una toolchain completa per monitoraggio, alert e risposta agli incidenti. Le soglie possono essere impostate per singolo cliente e, quando accade qualcosa, le notifiche possono arrivare via SMS, email e notifica push, così i tecnici non restano mai indietro e hanno subito una soluzione a portata di mano.
I ticket nell’helpdesk di NinjaOne possono essere generati automaticamente dagli alert provenienti da un’ampia gamma di server, strumenti e piattaforme, e si possono creare dashboard che mostrano le metriche di uptime e di risoluzione. NinjaOne Documentation può essere utilizzato per archiviare SLA, documentazione di processo, grafici, report, esempi e altri documenti destinati ai clienti, che aggiungono contesto prezioso e rassicurazione al tuo processo di gestione degli alert.
