/
/

Come automatizzare la reportistica su SLA e risoluzione dei ticket per i clienti MSP

di Mikhail Blacer, IT Technical Writer   |  
translated by Chiara Cavalletti
How to Automate SLA and Ticket Resolution Reporting for MSP Clients blog banner image

Instant Summary

This NinjaOne blog post offers a comprehensive basic CMD commands list and deep dive into Windows commands with over 70 essential cmd commands for both beginners and advanced users. It explains practical command prompt commands for file management, directory navigation, network troubleshooting, disk operations, and automation with real examples to improve productivity. Whether you’re learning foundational cmd commands or mastering advanced Windows CLI tools, this guide helps you use the Command Prompt more effectively.

Per gli MSP (Managed Service Provider – Fornitori di servizi gestiti) è fondamentale dimostrare la conformità agli SLA (Service Level Agreement). Si tratta di qualcosa di più di un semplice esercizio di reporting: è essenziale per mantenere la fiducia dei clienti e convalidare le buone prestazioni. Inoltre, i clienti si aspettano trasparenza, soprattutto nel rispetto degli obblighi contrattuali.

A tal fine, sarebbe un’ottima idea automatizzare la risoluzione di SLA e ticket. Il reporting automatizzato per i clienti eliminerà il processo manuale e fornirà un processo coerente e ripetibile. Ciò consentirà agli MSP di monitorare le tendenze delle prestazioni, di individuare tempestivamente i problemi e di presentare rapporti senza il consueto carico di lavoro.

Questa guida ti aiuterà a conoscere gli strumenti, gli script e i flussi di lavoro necessari per creare rapporti SLA accurati su scala.

Come automatizzare la reportistica su SLA e risoluzione dei ticket

📌 Prerequisiti:

  • Devi disporre di una piattaforma PSA attiva, come NinjaOne, Autotask o ConnectWise.
  • I criteri SLA devono essere assegnati a ciascun cliente, in modo che i sistemi sappiano quali sono i tempi di applicazione.
  • Le date e le categorie dei ticket devono essere registrate correttamente per garantire l’accuratezza dei rapporti.
  • Le autorizzazioni di amministratore sono necessarie per PowerShell e per le query di dati scriptate.
  • Devi avere l’accesso ai registri degli eventi o ai dati del sistema locale per confermare le tempistiche degli incidenti.

Definizione di metriche SLA e parametri di risoluzione

Prima di impostare report automatici per i clienti che mostrino la conformità ai benchmark SLA, è necessario definire cosa si sta misurando.

📌 Casi d’uso:

  • Questo aiuterà a standardizzare il monitoraggio degli SLA tra tutti i clienti.
  • Costituisce la base per la creazione di report e dashboard automatizzate.
  • Ti permette di mostrare le metriche e gli obiettivi di prestazione che devi raggiungere nel contratto.

📌 Prerequisiti:

  • Questi richiedono criteri SLA assegnati per cliente tramite PSA.
  • Registrazione corretta dei timestamp per i cambiamenti di stato dei ticket (creati, confermati, risolti).
  • Dovresti definire i tipi di ticket o delle categorie per raggruppare i dati SLA.

Ecco le metriche di conformità agli SLA che devi includere nei tuoi report:

  • Tempo di riconoscimento (TTA)
  • Tempo di risoluzione (TTR)
  • Percentuale di conformità agli SLA
  • Tasso di successo della risoluzione per categoria (hardware, software, rete)
  • Numero di escalation dei ticket vs. ticket risolti
  • Numero di ticket SLA persi o riaperti

Estrazione di dati SLA e ticket tramite PowerShell o API

Dopo aver definito le metriche, il passo successivo è l’estrazione dei dati dei ticket dal PSA. La maggior parte delle piattaforme supporta query o esportazioni API (Application Programming Interface) che possono essere filtrate e programmate tramite PowerShell.

📌 Casi d’uso:

  • Questo metodo ti aiuterà ad automatizzare il monitoraggio degli SLA su più clienti.
  • Contribuirà a ridurre l’impegno manuale nelle revisioni mensili dei ticket.
  • Supporta l’utilizzo delle dashbaord e la reportistica per categoria di SLA o stato di violazione.

📌 Prerequisiti:

  • È necessario un token API con il permesso di interrogare i ticket.
  • La versione di PowerShell deve essere 5.1 o successiva.
  • RMM o Utilità di pianificazione devono avere accesso all’esecuzione automatica degli script.

Ecco un esempio di snippet PowerShell che estrae i ticket risolti da un’API PSA e li esporta in CSV:

$headers = @{ "Authorization" = "Bearer $token" }
$response = Invoke-RestMethod -Uri "https://api.ninjaone.com/v2/tickets" -Headers $headers
$response | Where-Object { $_.resolved -eq $true } | Export-Csv "C:\Reports\SLAReport.csv" -NoTypeInformation

Per filtrare il rapporto in base al cliente, all’intervallo di date o allo stato SLA, è necessario modificare lo script. Aggiungi parametri di query all’URL dell’API o utilizza condizioni in PowerShell.

Utilizzare il Registro per tenere traccia degli SLA locali o degli eventi dell’agente (opzionale)

📌 Casi d’uso:

  • Aggiunge un audit trail locale delle risposte basate su script e legate agli ID dei ticket.
  • Aiuta a convalidare il momento in cui è stato attivato un avviso o un’azione di rimedio.
  • Supporta le dashboard RMM su informazioni dei ticket per endpoint.

📌 Prerequisiti:

  • Questo metodo richiede le autorizzazioni di amministratore per scrivere nel Registro.
  • È necessario un RMM o uno script per aggiornare i valori del registro.
  • Un formato di denominazione standard per la mappatura dei ticket tra i vari sistemi.

Per contrassegnare localmente gli eventi relativi agli SLA, crea valori di registro personalizzati. Ecco come procedere:

  1. Apri l’Editor del registro di sistema.
  2. Naviga in questo percorso: HKEY_LOCAL_MACHINE\SOFTWARE
  3. Quindi, fai clic con il pulsante destro del mouse sulla cartella SOFTWARE, scegli Nuova > Chiave e rinominalaOrg.
  4. Fai clic con il pulsante destro del mouse sulla chiave Org e seleziona Nuova > chiave . Nomina il valore così: SLAEvents
  5. All’interno della chiave SLAEvents , fai clic con il tasto destro del mouse sul riquadro di destra e scegli Nuovo > Valore Stringa.
  6. Rinominalo LastAcknowledgedTicket. Fai doppio clic su di esso e inserire un ID del ticket (ad esempio, TKT-10129) come dati del valore.
  7. Crea un altro valore di stringa in SLAEvents. RinominaloLastActionTime. Fai doppio clic e imposta i dati del valore sul timestamp dell’evento (ad esempio, 2025-08-15T14:23Z)

Una volta creati, questi valori possono essere letti in seguito tramite script o raccolti dall’RMM.

💡 Suggerimento: Questo passaggio è un modo manuale per tracciare gli SLA. Tuttavia, il sistema di ticketing di NinjaOne può tracciare automaticamente la conformità agli SLA.

Esecuzione di script CMD per il monitoraggio del contesto o del servizio dell’endpoint

Puoi utilizzare script del prompt dei comandi per raccogliere dati di sistema di base dai dispositivi Windows. Questo aiuta a verificare cosa stava accadendo su un endpoint al momento della creazione del ticket. In questo modo puoi verificare i tempi di attività, i servizi non funzionanti o gli eventi legati a problemi di sistema, rendendo più fluido il processo di segnalazione della risoluzione dei ticket.

📌 Casi d’uso:

  • Questo può aiutare a confermare se un problema è legato a un riavvio, a un arresto anomalo o a un tempo di inattività.
  • Puoi utilizzare per supportare l’attività di analisi delle cause principali, correlando il comportamento dell’endpoint con i ticket.
  • Utile quando PowerShell non è disponibile.

📌 Prerequisiti:

  • Per eseguire una versione elevata del Prompt dei comandi è necessario l’accesso come amministratore.
  • Gli endpoint devono essere abilitati alla registrazione e alla cronologia degli eventi.
  • Il processo di reporting dovrebbe consentire di salvare o caricare i registri.

Ecco alcuni esempi di codici del prompt dei comandi:

Controllare il tempo di attività del sistema

systeminfo | findstr "System Boot Time"

Questo restituirà l’ultima volta che il sistema è stato riavviato, aiutandoti a confermare se un dispositivo è stato riavviato prima o dopo la segnalazione di un problema.

Elenco dei servizi non riusciti o interrotti

sc query type= service state= all | findstr "STOPPED"

Questo metodo identifica quali servizi non sono in esecuzione. Puoi confrontare questo dato con quello del problema segnalato per verificare se un servizio critico era inattivo al momento della creazione del ticket.

Esportare voci recenti del registro di sistema

wevtutil qe System /q:"*[System[(EventID=7034)]]" /f:text /c:20

Questo recupera gli ultimi 20 eventi del registro di sistema per i servizi che si sono arrestati inaspettatamente. Può aiutare a confermare quando un dispositivo ha subito un errore critico.

💡Nota: Puoi utilizzare questi comandi per verificare il comportamento dell’endpoint nel momento in cui un ticket è stato aperto o risolto.

Come creare modelli di report per consegnarli ai clienti

Una volta raccolti i dati relativi alla conformità agli SLA e ai ticket, il passo successivo consiste nell’esportare i ticket e presentarli ai clienti in modo facilmente comprensibile. I rapporti devono riassumere le metriche chiave e gli SLA mancati e indicare i punti in cui è possibile apportare miglioramenti.

📌 Casi d’uso:

  • Ti consente di fornire ai clienti rapporti coerenti con il marchio.
  • In questo modo puoi semplificare i rapporti ricorrenti e le revisioni degli SLA.
  • Puoi utilizzarli per comunicare tendenze, progressi e rischi in un linguaggio semplice.

📌 Prerequisiti:

  • Hai bisogno dei dati SLA e dei ticket raccolti.
  • Uno strumento che consente di creare grafici o tabelle (MS Excel, Google Sheets).
  • Una struttura di report definita e standardizzata che può essere riutilizzata da tutti i clienti.

Assicurati di inserire questi elementi fondamentali nella tua relazione:

  • Riepilogo esecutivo – Deve contenere la percentuale di conformità agli SLA e le statistiche principali.
  • Tendenze dei ticket: contiene il volume dei ticket, i tipi e i modelli di risoluzione.
  • Analisi degli SLA mancati – ID dei ticket e motivi per cui sono stati sollevati.
  • Prestazioni del tecnico (opzionale) – Dovrebbe contenere i tempi medi di risposta e di risoluzione.
  • Raccomandazioni – Lacune del servizio, cause principali e aree di miglioramento, in particolare per quanto riguarda l’analisi degli SLA mancati e le prestazioni dei tecnici.

Ecco le opzioni di formato consigliate:

  • Microsoft Excel, esportato tramite PowerShell. Ad esempio, puoi utilizzare questo comando di esempio per i dati dei ticket filtrati:

$response = Invoke-RestMethod -Uri "https://api.psa.com/v2/tickets" -Headers @{ "Authorization" = "Bearer $token" }
$filtered = $response | Where-Object { $_.resolved -eq $true }
$filtered | Export-Excel -Path "C:\Reports\SLA_Report_July.xlsx" -WorksheetName "ResolvedTickets" -AutoSize

Puoi utilizzare anche una versione PDF, ma dovrai salvare manualmente il file come PDF.

  • Power BI (Business Intelligence) per altre dashboard per le metriche in tempo reale.
  • Rapporto basato su HTML con grafici e tabelle.
  • Rapporto programmato PSA-nativo.

Assicurati che questi report siano segmentati per cliente e allineati alle soglie e agli obiettivi SLA specifici.

Automatizza la generazione e la consegna dei report

L’ultima fase della creazione di report automatizzati per i clienti consiste nel consegnarli ai clienti stessi. A tal fine, puoi programmare gli script per l’esportazione dei rapporti e l’invio di e-mail.

📌 Casi d’uso:

  • Consente di fornire riepiloghi SLA e rapporti sulla risoluzione dei ticket senza alcuno sforzo manuale.
  • Garantisce un reporting tempestivo e “mai in ritardo” tra i clienti.

📌 Prerequisiti:

  • Hai bisogno di uno script di report funzionante che generi output CSV, XLSX o PDF.
  • Le credenziali del server di posta o della destinazione dei file dei tuoi clienti.
  • Una piattaforma RMM o PSA che supporta script o report programmati.

Puoi automatizzare la consegna dei report in diversi modi:

  • Programmare gli script per esportare i dati SLA e inviarli via e-mail al cliente.
  • API push su SharePoint, S3 o una cartella FTP sicura.
  • Utilizzare gli strumenti di programmazione nativi di PSA. Un buon esempio sono i report di esportazione di NinjaOne.
  • Puoi attivare l’automazione anche attraverso l’RMM.

Ecco un esempio di e-mail inviata tramite PowerShell:

Send-MailMessage -From "[email protected]" -To "[email protected]" `
-Subject "Monthly SLA Performance - July" `
-Attachments "C:\Reports\SLAReport_July2025.pdf" `
-SmtpServer "smtp.msp.com"

⚠️ Cose da tenere d’occhio

Rischi Potenziali conseguenze Possibilità di tornare alla configurazione precedente
Timestamp mancanti nei dati dei ticket I calcoli degli SLA saranno errati o incompleti. Controlla le regole di automazione PSA e i flussi di lavoro di stato per verificare che i timestamp siano registrati.
Mappature SLA errate per cliente I rapporti mostreranno una falsa conformità o obiettivi mancati. Assicurati di rivedere le regole SLA per ogni cliente e di allinearle alle code dei ticket.
Gli script PowerShell non vengono eseguiti Non sono stati generati o inviati rapporti. Convalida e aggiorna le autorizzazioni e verifica la presenza di problemi di sintassi o di rete.
Le consegne delle e-mail non vanno a buon fine I clienti non potranno ricevere i rapporti mensili in tempo. Verifica le impostazioni SMTP (Simple Mail Transfer Protocol) e conferma l’accesso alla mailbox.
Layout del report incoerente I clienti possono trovare i rapporti confusi o difficili da leggere. Standardizza e utilizza un modello.
I rapporti contengono dati grezzi. I clienti che non hanno un background tecnico non capiranno il rapporto e lo ignoreranno completamente. Mantieni i report adatti a un pubblico non tecnico e includi riassunti e spiegazioni.

Ulteriori considerazioni quando automatizzi la reportistica su SLA e risoluzione dei ticket

Mappare gli SLA per ogni cliente

I clienti hanno esigenze diverse in termini di tempi di risposta e risoluzione. Assicurati che ogni ticket sia collegato ai criteri SLA appropriati nel tuo sistema PSA.

Standardizzare i dati dei ticket in tutti gli ambienti

Utilizza le stesse categorie di ticket, gli stessi nomi di stato e gli stessi flussi di lavoro per tutti i clienti. In questo modo sarà più facile filtrare, tracciare grafici e confrontare le prestazioni SLA nel tempo.

Conservare i dati grezzi per gli audit

Sarebbe meglio conservare i log dei ticket esportati e i timestamp delle risoluzioni per almeno 12-24 mesi. Questo ti supporterà nelle revisioni dei contratti, nelle controversie sulla fatturazione e negli audit esterni.

Dati separati per cliente

Questo aspetto è estremamente importante negli ambienti multi-tenant. Filtra ed esporta sempre i ticket per ID cliente, per evitare la perdita di dati e mantenere i rapporti puliti e accurati.

Risoluzione dei problemi di SLA e di segnalazione della risoluzione dei ticket

Timestamp mancanti

Assicurati che il tuo sistema di ticketing registri tutti i cambiamenti di stato richiesti, ad esempio:

  • Creato
  • Confermato
  • Escalation
  • Risolto

Senza di essi, le metriche SLA nel tuo report saranno incomplete.

Mappatura SLA errata

Assicurati che le regole di automazione PSA e le code di ticket applichino i giusti criteri SLA per cliente. Un ticket mal distribuito può influenzare le statistiche e falsare i numeri.

Errori negli script PowerShell

Se gli script non esportano o non inviano i report, verifica i problemi di autorizzazione API, i token scaduti o gli errori nello script.

Visualizzazione incoerente del fuso orario

Se i timestamp del report non corrispondono alla cronologia dei ticket, normalizza tutto a UTC o, meglio ancora, converti all’ora locale del cliente.

Servizi NinjaOne

Con NinjaOne, gli MSP possono automatizzare la reportistica SLA e semplificare il monitoraggio della risoluzione dei ticket per tutti i clienti. Le sue caratteristiche sono evidenziate nella tabella seguente:

Cosa può fare NinjaOne?  Di cosa si tratta Come può aiutare ad automatizzare la reportistica sugli SLA e sulla risoluzione dei ticket
Esportazione programmata dei rapporti Automatizza la generazione di rapporti ricorrenti Fornisce riepiloghi coerenti sulla conformità agli SLA senza interventi manuali
Tracciamento e tag basati su script Applica tag personalizzati ai ticket o ai dispositivi in base a condizioni di allarme o SLA Segnala le violazioni degli SLA e gli eventi di risoluzione per un migliore filtraggio e reporting.
Consolidamento della cronologia degli avvisi e dei ripristini Combina i dati relativi agli avvisi, alle risposte e alla risoluzione dei ticket in un’unica timeline Questo supporta un accurato tracciamento dei tempi SLA dall’incidente alla risoluzione.
Registro e monitoraggio degli endpoint Cattura i segnali locali come i riavvii del servizio o gli errori del dispositivo Questo aggiunge un ulteriore contesto ai rapporti SLA e aiuta a convalidare la causa principale.
Modelli di report con marchio Consente di personalizzare i rapporti per cliente per i rapporti esportati. Abilita gli MSP

L’automatizzazione dei rapporti sugli SLA e sui ticket tiene informati gli MSP e i clienti

L’automatizzazione dei rapporti sugli SLA e sulla risoluzione dei ticket aiuta gli MSP a essere responsabili, trasparenti ed efficienti. Riduce il tempo dedicato alle esportazioni manuali, migliora l’accuratezza dei report e garantisce che gli impegni di servizio siano rispettati e visibili.

Abbiamo spiegato come definire le giuste metriche SLA, estrarre i dati dei ticket utilizzando PowerShell o API, convalidare gli eventi di risoluzione con strumenti di registro e CMD e formattare i report per la consegna ai clienti. Grazie a questi metodi, gli MSP possono fornire una reportistica SLA affidabile e allineata ai criteri su scala.

Argomenti correlati:

Quick-Start Guide

NinjaOne offre solide funzionalità di reportistica su SLA e sulla risoluzione dei ticket per i clienti MSP. In particolare, la funzionalità di riepilogo dei ticket fornisce informazioni complete sulla gestione dei ticket:

Principali funzionalità di reporting su SLA e risoluzione dei ticket:

  • Tempo medio di risoluzione: Calcola il tempo medio di risoluzione dei ticket
  • Primo tempo di risposta: Misura il tempo medio tra la creazione del ticket e la prima risposta del tecnico
  • Risoluzione al primo contatto: Percentuale di ticket risolti con commenti minimi da parte del tecnico
  • Monitoraggio del volume dei ticket: Suddivisione dei ticket in base allo stato, al tempo di creazione e all’efficienza del tecnico

Le funzionalità di reporting includono:

  • Opzioni di reportistica per gli ultimi 7 giorni e gli ultimi 30 giorni
  • Ripartizione di:
    • Ticket aperti
    • Ticket in sospeso
    • Ticket risolti
    • Ticket creati al giorno/ora
    • Efficienza del ticket tecnico

I report aiutano gli MSP a monitorare e migliorare l’erogazione dei servizi, fornendo informazioni dettagliate sulle prestazioni di risoluzione dei ticket, sui tempi di risposta e sulla produttività dei tecnici.

Ti potrebbe interessare anche

Pronto a semplificare le parti più complesse dell'IT?

Termini e condizioni NinjaOne

Cliccando sul pulsante “Accetto” qui sotto, dichiari di accettare i seguenti termini legali e le nostre condizioni d’uso:

  • Diritti di proprietà: NinjaOne possiede e continuerà a possedere tutti i diritti, i titoli e gli interessi relativi allo script (compreso il copyright). NinjaOne ti concede una licenza limitata per l’utilizzo dello script in conformità con i presenti termini legali.
  • Limitazione d’uso: Puoi utilizzare lo script solo per legittimi scopi personali o aziendali interni e non puoi condividere lo script con altri soggetti.
  • Divieto di ripubblicazione: In nessun caso ti è consentito ripubblicare lo script in una libreria di script appartenente o sotto il controllo di un altro fornitore di software.
  • Esclusione di garanzia: Lo script viene fornito “così com’è” e “come disponibile”, senza garanzie di alcun tipo. NinjaOne non promette né garantisce che lo script sia privo di difetti o che soddisfi le tue esigenze o aspettative specifiche.
  • Assunzione del rischio: L’uso che farai dello script è da intendersi a tuo rischio. Riconosci che l’utilizzo dello script comporta alcuni rischi intrinseci, che comprendi e sei pronto ad assumerti.
  • Rinuncia e liberatoria: Non riterrai NinjaOne responsabile di eventuali conseguenze negative o indesiderate derivanti dall’uso dello script e rinuncerai a qualsiasi diritto legale o di equità e a qualsiasi rivalsa nei confronti di NinjaOne in relazione all’uso dello script.
  • EULA: Se sei un cliente NinjaOne, l’uso dello script è soggetto al Contratto di licenza con l’utente finale (EULA) applicabile.