Die wichtigsten Punkte
SLA- und Ticket-Lösungsberichte für MSP-Kund:innen automatisieren
- Die Automatisierung von SLA- und Ticket-Lösungsberichten senkt den manuellen IT-Aufwand und erhöht die Genauigkeit der Berichte.
- Zentralisierte IT-Berichterstattung hilft Teams dabei, Leistungstrends zu verfolgen, Ticketvolumen zu senken und die SLAs ihrer Kund:innen einzuhalten
- IT-Automatisierung sorgt zudem für bessere Transparenz über Endpunkte, schnellere Reaktionszeiten und mehr betriebliche Effizienz für MSPs und deren Kund:innen.
Der Nachweis der SLA-Compliance (Service Level Agreement) ist für MSPs (Managed Service Provider) von zentraler Bedeutung. Dabei geht es um weit mehr als reine Berichterstattung: Sie ist entscheidend, um das Vertrauen der Kund:innen zu erhalten und gute Leistungen zu belegen. Hinzu kommt, dass Kund:innen Transparenz erwarten, besonders bei der Erfüllung vertraglicher Verpflichtungen.
Eine ausgezeichnete Lösung dafür ist es, SLA- und Ticket-Lösungsberichte zu automatisieren. Automatisierte Berichte für Kund:innen ersetzen den manuellen Prozess und sorgen für einen einheitlichen, wiederholbaren Ablauf. So können MSPs Leistungstrends verfolgen, Probleme frühzeitig erkennen und Berichte ohne den sonst üblichen hohen Aufwand bereitstellen.
Dieser Leitfaden führt Sie durch die Tools, Skripte und Workflows, die Sie benötigen, um präzise SLA-Berichte auch in großem Umfang zu erstellen.
Einen kompakten visuellen Überblick erhalten Sie in unserem Video-Leitfaden So automatisieren Sie SLA- und Ticket-Lösungsberichte für MSP-Kund:innen.
So automatisieren Sie SLA- und Ticket-Lösungsberichte
📌 Voraussetzungen:
- Sie benötigen eine aktive PSA-Plattform wie NinjaOne, Autotask oder ConnectWise.
- Die SLA-Richtlinien müssen jedem Kunden bzw. jeder Kundin zugewiesen sein, damit die Systeme wissen, welche Zeitvorgaben gelten.
- Die Zeitstempel und Kategorien der Tickets sollten korrekt erfasst werden, damit die Berichte genau sind.
- Für PowerShell und skriptgesteuerte Datenabfragen sind Administratorrechte erforderlich.
- Sie benötigen Zugriff auf Ereignisprotokolle oder lokale Systemdaten, um Vorfallszeitlinien zu bestätigen.
SLA-Metriken und Lösungs-Benchmarks definieren
Bevor Sie automatisierte Berichte für Kund:innen einrichten, die die Einhaltung von SLA-Benchmarks belegen, müssen Sie zunächst festlegen, was Sie überhaupt messen.
📌 Anwendungsfälle:
- Das hilft dabei, die SLA-Nachverfolgung über alle Kund:innen hinweg zu standardisieren.
- Es bildet die Grundlage für automatisierte Berichte und Dashboards.
- Sie können damit die Metriken und Leistungsziele darstellen, die Sie vertraglich erfüllen müssen.
📌 Voraussetzungen:
- Dafür müssen SLA-Richtlinien pro Kund:in über die PSA zugewiesen sein.
- Zeitstempel für Ticket-Statusänderungen (erstellt, bestätigt, gelöst) müssen korrekt protokolliert werden.
- Sie sollten Tickettypen oder Kategorien definiert haben, um SLA-Daten zu gruppieren.
Diese SLA-Compliance-Metriken sollten Ihre Berichte enthalten:
- Zeit bis zur Bestätigung (Time to Acknowledge, TTA)
- Zeit bis zur Lösung (Time to Resolve, TTR)
- Prozentsatz der SLA-konformen Reaktionen
- Lösungsquote nach Kategorie (Hardware, Software, Netzwerk)
- Anzahl eskalierter im Vergleich zu gelösten Tickets
- Anzahl verpasster oder wiedereröffneter SLA-Tickets
SLA- und Ticketdaten mit PowerShell oder API auslesen
Nachdem Sie Ihre Metriken definiert haben, besteht der nächste Schritt darin, die Ticketdaten aus Ihrer PSA zu ziehen. Die meisten Plattformen unterstützen Abfragen über API (Application Programming Interface) oder Exporte, die sich per PowerShell filtern und zeitlich planen lassen.
📌 Anwendungsfälle:
- Mit dieser Methode automatisieren Sie die SLA-Nachverfolgung über mehrere Kund:innen hinweg.
- Sie reduziert den manuellen Aufwand bei monatlichen Ticket-Reviews.
- Sie unterstützt Dashboards und Berichte nach SLA-Kategorie oder Verletzungsstatus.
📌 Voraussetzungen:
- Sie benötigen ein API-Token mit Berechtigung zum Abfragen von Tickets.
- Ihre PowerShell-Version sollte 5.1 oder höher sein.
- RMM oder die Aufgabenplanung sollten Zugriff haben, um Skriptausführungen zu automatisieren.
Hier ein PowerShell-Beispiel, das gelöste Tickets aus einer PSA-API abruft und als CSV exportiert:
$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
Um den Bericht nach Kund:in, Zeitraum oder SLA-Status zu filtern, müssen Sie das Skript anpassen. Fügen Sie der API-URL Abfrageparameter hinzu oder verwenden Sie Bedingungen in PowerShell.
Lokale SLA- oder Agent-Ereignisse über die Registry nachverfolgen (optional)
📌 Anwendungsfälle:
- Ergänzt einen lokalen Audit-Trail skriptbasierter Reaktionen, verknüpft mit Ticket-IDs.
- Hilft Ihnen zu überprüfen, wann eine Alarmierung oder eine Behebungsmaßnahme ausgelöst wurde.
- Unterstützt RMM-Dashboards mit Ticket-Kontext pro Endpunkt.
📌 Voraussetzungen:
- Diese Methode erfordert Administratorrechte, um in die Registry zu schreiben.
- Sie benötigen ein RMM oder ein Skript, um die Registry-Werte zu aktualisieren.
- Ein einheitliches Namensschema, um Tickets systemübergreifend zuzuordnen.
Um SLA-relevante Ereignisse lokal zu kennzeichnen, legen Sie eigene Registry-Werte an. So gehen Sie vor:
- Öffnen Sie den Registrierungs-Editor.
- Navigieren Sie zu diesem Pfad: HKEY_LOCAL_MACHINE\SOFTWARE
- Klicken Sie anschließend mit der rechten Maustaste auf den Ordner SOFTWARE, wählen Sie Neu > Schlüssel und nennen Sie ihn Org.
- Klicken Sie mit der rechten Maustaste auf den Schlüssel Org und wählen Sie Neu > Schlüssel. Nennen Sie ihn: SLAEvents
- Klicken Sie innerhalb des Schlüssels SLAEvents mit der rechten Maustaste in den rechten Bereich und wählen Sie Neu > Zeichenfolge.
- Nennen Sie sie LastAcknowledgedTicket. Doppelklicken Sie darauf und tragen Sie als Wert eine Ticket-ID ein (z. B. TKT-10129).
- Erstellen Sie in SLAEvents eine weitere Zeichenfolge. Nennen Sie sie LastActionTime. Doppelklicken Sie darauf und setzen Sie als Wert den Zeitstempel des Ereignisses (z. B. 2025-08-15T14:23Z).
Sobald diese Werte angelegt sind, lassen sie sich später per Skript auslesen oder von Ihrem RMM erfassen.
💡 Tipp: Dieser Schritt ist eine manuelle Methode zur SLA-Nachverfolgung. Das Ticketing-System von NinjaOne kann die SLA-Compliance jedoch automatisiert überwachen.
Eingabeaufforderungs-Skripte für Endpunkt-Kontext oder Service-Überwachung ausführen
Mit Skripten für die Eingabeaufforderung können Sie grundlegende Systemdaten von Windows-Geräten sammeln. So lässt sich nachvollziehen, was auf einem Endpunkt zum Zeitpunkt der Ticketerstellung passiert ist. Sie können Betriebszeit, fehlgeschlagene Dienste oder Ereignisse prüfen, die mit Systemproblemen zusammenhängen, und so Ihre Ticket-Lösungsberichte reibungsloser gestalten.
📌 Anwendungsfälle:
- Hilft zu bestätigen, ob ein Problem mit einem Neustart, einem Absturz oder einer Ausfallzeit zusammenhing.
- Sie können damit Ihre Ursachenanalyse (RCA) unterstützen, indem Sie das Verhalten von Endpunkten mit Tickets korrelieren.
- Nützlich, wenn PowerShell nicht verfügbar ist.
📌 Voraussetzungen:
- Sie benötigen Administratorzugriff, um die Eingabeaufforderung mit erhöhten Rechten auszuführen.
- Auf den Endpunkten müssen Protokollierung und Ereignisverlauf aktiviert sein.
- Ihr Berichtsprozess sollte das Speichern oder Hochladen von Protokollen zulassen.
Hier einige Beispielbefehle für die Eingabeaufforderung:
Systembetriebszeit prüfen
systeminfo | findstr "System Boot Time"
Das gibt den Zeitpunkt des letzten Neustarts zurück und hilft Ihnen festzustellen, ob ein Gerät vor oder nach der Meldung eines Problems neu gestartet wurde.
Liste fehlgeschlagener oder gestoppter Dienste
sc query type= service state= all | findstr "STOPPED"
Diese Methode zeigt, welche Dienste nicht laufen. Anschließend können Sie dies mit dem gemeldeten Problem abgleichen und prüfen, ob zum Zeitpunkt der Ticketerstellung ein kritischer Dienst ausgefallen war.
Aktuelle Systemprotokolleinträge exportieren
wevtutil qe System /q:"*[System[(EventID=7034)]]" /f:text /c:20
Damit rufen Sie die letzten 20 Systemprotokoll-Ereignisse zu Diensten ab, die unerwartet beendet wurden. Das hilft Ihnen zu bestätigen, wann ein Gerät einen kritischen Fehler hatte.
💡Hinweis: Mit diesen Befehlen können Sie das Verhalten eines Endpunkts rund um den Zeitpunkt prüfen, an dem ein Ticket geöffnet oder gelöst wurde.
Bericht-Templates für die Übermittlung an Kund:innen erstellen
Sobald Sie SLA-Compliance- und Ticketdaten gesammelt haben, geht es im nächsten Schritt darum, die Tickets zu exportieren und Ihren Kund:innen so aufzubereiten, dass sie leicht verständlich sind. Ihre Berichte sollten die wichtigsten Metriken und verpassten SLAs zusammenfassen und aufzeigen, wo Verbesserungen möglich sind.
📌 Anwendungsfälle:
- Hilft Ihnen, einheitliche Berichte im eigenen Branding an Kund:innen zu liefern.
- Vereinfacht wiederkehrende Berichte und SLA-Reviews.
- Sie können damit Trends, Fortschritte und Risiken in verständlicher Sprache kommunizieren.
📌 Voraussetzungen:
- Sie benötigen die gesammelten SLA- und Ticketdaten.
- Ein Tool, mit dem Sie Diagramme oder Tabellen erstellen können (MS Excel, Google Sheets).
- Eine definierte, standardisierte Berichtsstruktur, die Sie bei allen Kund:innen wiederverwenden können.
Achten Sie darauf, diese Kernelemente in Ihren Bericht aufzunehmen:
- Management-Zusammenfassung – Sollte den Prozentsatz der SLA-Compliance sowie die wichtigsten Kennzahlen enthalten.
- Ticket-Trends – Enthält Ticketvolumen, Ticketarten und Lösungsmuster.
- Analyse verpasster SLAs – Ticket-IDs und die Gründe, warum sie angelegt wurden.
- Leistung der Techniker:innen (optional) – Sollte durchschnittliche Reaktions- und Lösungszeiten enthalten.
- Empfehlungen – Servicelücken, Ursachen und Verbesserungsfelder, insbesondere mit Blick auf die Analyse verpasster SLAs und die Leistung der Techniker:innen.
Das sind die empfohlenen Formatoptionen:
- Microsoft Excel, exportiert über PowerShell. Sie können zum Beispiel diesen Beispielbefehl für gefilterte Ticketdaten verwenden:
$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
Sie können auch eine PDF-Version nutzen, müssen die Datei dann allerdings manuell als PDF speichern.
- Power BI (Business Intelligence) für weitere Dashboards mit Live-Metriken.
- HTML-basierter Bericht mit Diagrammen und Tabellen.
- Geplanter Bericht direkt aus der PSA.
Stellen Sie sicher, dass diese Berichte pro Kund:in segmentiert sind und zu deren jeweiligen SLA-Schwellenwerten und Zielen passen.
Berichtserstellung und -versand automatisieren
Der letzte Schritt beim Aufbau automatisierter Berichte für Kund:innen ist deren Zustellung. Dafür können Sie Skripte planen, die Berichte exportieren und E-Mails versenden.
📌 Anwendungsfälle:
- Hilft Ihnen, SLA-Zusammenfassungen und Ticket-Lösungsberichte ohne manuellen Aufwand zu liefern.
- Sorgt für pünktliche Berichte „ohne Verzögerung“ bei allen Kund:innen.
📌 Voraussetzungen:
- Sie benötigen ein funktionierendes Berichtsskript, das CSV-, XLSX- oder PDF-Dateien erzeugt.
- Die Anmeldeinformationen für den Mailserver oder das Dateiziel Ihrer Kund:innen.
- Eine RMM- oder PSA-Plattform, die geplante Skripte oder Berichte unterstützt.
Sie können den Versand Ihrer Berichte auf mehrere Arten automatisieren:
- Skripte planen, die SLA-Daten exportieren und per E-Mail an die Kund:innen senden.
- API-Push an SharePoint, S3 oder einen sicheren FTP-Ordner.
- Planungstools direkt in der PSA nutzen. Ein gutes Beispiel sind die Berichtsexporte von NinjaOne.
- Sie können die Automatisierung auch über Ihr RMM auslösen.
Hier ein PowerShell-Beispiel für den E-Mail-Versand:
Send-MailMessage -From "[email protected]" -To "[email protected]" `
-Subject "Monthly SLA Performance - July" `
-Attachments "C:\Reports\SLAReport_July2025.pdf" `
-SmtpServer "smtp.msp.com"
⚠️ Darauf sollten Sie achten
| Risiken | Mögliche Folgen | Gegenmaßnahmen |
| Fehlende Zeitstempel in den Ticketdaten | SLA-Berechnungen sind falsch oder unvollständig. | Prüfen Sie die Automatisierungsregeln und Status-Workflows der PSA, damit Zeitstempel protokolliert werden. |
| Falsche SLA-Zuordnungen pro Kund:in | Berichte zeigen eine falsche Compliance oder verfehlte Ziele. | Überprüfen Sie unbedingt die SLA-Regeln jeder Kundin und jedes Kunden und stimmen Sie sie auf die Ticket-Queues ab. |
| PowerShell-Skripte werden nicht ausgeführt | Es werden keine Berichte erzeugt oder versendet. | Berechtigungen prüfen und aktualisieren sowie auf Syntax- oder Netzwerkprobleme kontrollieren. |
| E-Mail-Zustellung schlägt fehl | Kund:innen erhalten ihre Monatsberichte nicht rechtzeitig. | Testen Sie die SMTP-Einstellungen (Simple Mail Transfer Protocol) und bestätigen Sie den Postfachzugriff. |
| Uneinheitliches Berichtslayout | Kund:innen empfinden die Berichte als verwirrend oder schwer lesbar. | Standardisieren Sie das Layout und verwenden Sie ein Template. |
| Berichte enthalten Rohdaten. | Kund:innen ohne technischen Hintergrund verstehen den Bericht nicht und ignorieren ihn vollständig. | Richten Sie Berichte auf ein nicht-technisches Publikum aus und ergänzen Sie Zusammenfassungen und Erläuterungen. |
Weitere Überlegungen zur Automatisierung von SLA- und Ticket-Lösungsberichten
SLAs jedem Kunden und jeder Kundin zuordnen
Kund:innen haben unterschiedliche Anforderungen an Reaktions- und Lösungszeiten. Stellen Sie sicher, dass jedes Ticket in Ihrem PSA-System mit der passenden SLA-Richtlinie verknüpft ist.
Ticketdaten über alle Umgebungen hinweg standardisieren
Verwenden Sie bei allen Kund:innen dieselben Ticketkategorien, Statusbezeichnungen und Workflows. Dadurch lassen sich die Daten leichter filtern, grafisch darstellen und die SLA-Leistung über die Zeit vergleichen.
Rohdaten für Audits aufbewahren
Am besten bewahren Sie exportierte Ticketprotokolle und Lösungszeitstempel mindestens 12 bis 24 Monate auf. Das hilft Ihnen bei Vertragsprüfungen, Abrechnungsstreitigkeiten und externen Audits.
Daten nach Kund:in trennen
In Umgebungen mit Mehrmandantenfähigkeit ist das besonders wichtig. Filtern und exportieren Sie Tickets immer pro Kund:innen-ID. So verhindern Sie Datenabfluss und halten Berichte sauber und korrekt.
Fehlerbehebung bei SLA- und Ticket-Lösungsberichten
Fehlende Zeitstempel
Stellen Sie sicher, dass Ihr Ticketsystem alle erforderlichen Statusänderungen protokolliert, etwa:
- Erstellt
- Bestätigt
- Eskaliert
- Gelöst
Ohne diese Angaben bleiben die SLA-Metriken in Ihrem Bericht unvollständig.
Falsche SLA-Zuordnung
Stellen Sie sicher, dass Ihre PSA-Automatisierungsregeln und Ticket-Queues die richtigen SLA-Richtlinien pro Kund:in anwenden. Ein falsch zugeordnetes Ticket kann die Statistiken beeinflussen und Ihre Zahlen verzerren.
Fehlgeschlagene PowerShell-Skripte
Wenn Ihre Skripte keine Berichte exportieren oder versenden, prüfen Sie Probleme mit API-Berechtigungen, abgelaufene Tokens oder Fehler im Skript.
Uneinheitliche Zeitzonen-Anzeige
Wenn die Zeitstempel im Bericht nicht zum Ticketverlauf passen, normalisieren Sie alles auf UTC oder, noch besser, rechnen Sie in die Ortszeit der Kund:innen um.
NinjaOne-Services
Mit NinjaOne können MSPs die SLA-Berichterstattung automatisieren und die Nachverfolgung der Ticketlösung über alle Kund:innen hinweg vereinfachen. Die Funktionen sind in der folgenden Tabelle zusammengefasst:
| Was kann NinjaOne? | Worum es sich handelt | Wie es hilft, SLA- und Ticket-Lösungsberichte zu automatisieren |
| Geplante Berichtsexporte | Automatisiert die wiederkehrende Berichtserstellung | Liefert einheitliche SLA-Compliance-Zusammenfassungen ohne manuelles Eingreifen |
| Skriptbasierte Nachverfolgung und Kennzeichnung | Vergibt benutzerdefinierte Tags für Tickets oder Geräte auf Basis von Alarmierungs- oder SLA-Bedingungen | Markiert SLA-Verletzungen und Lösungsereignisse für besseres Filtern und bessere Berichte. |
| Zusammenführung von Alarmierungs- und Behebungshistorie | Verbindet Daten zu Alarmierungen, Reaktionen und Ticketlösungen in einer einzigen Zeitlinie | Das unterstützt eine präzise SLA-Zeiterfassung vom Vorfall bis zur Lösung. |
| Registry- und Endpunkt-Überwachung | Erfasst lokale Signale wie Dienstneustarts oder Gerätefehler | Das liefert zusätzlichen Kontext für SLA-Berichte und hilft, die Ursache zu bestätigen. |
| Bericht-Templates im eigenen Branding | Damit passen Sie exportierte Berichte pro Kund:in an. | Unterstützt MSPs |
Automatisierte SLA- und Ticketberichte halten MSPs und Kund:innen auf dem Laufenden
Wer SLA- und Ticket-Lösungsberichte automatisiert, bleibt als MSP nachweisbar verlässlich, transparent und effizient. Das reduziert den Zeitaufwand für manuelle Exporte, erhöht die Genauigkeit der Berichte und stellt sicher, dass Servicezusagen eingehalten und sichtbar werden.
Wir haben gezeigt, wie Sie die richtigen SLA-Metriken definieren, Ticketdaten per PowerShell oder API auslesen, Lösungsereignisse mit Registry- und Eingabeaufforderungs-Tools überprüfen und Berichte für die Übermittlung an Kund:innen aufbereiten. Mit diesen Methoden können MSPs verlässliche, richtlinienkonforme SLA-Berichte auch in großem Umfang liefern.
Verwandte Themen:
- Wichtige NinjaOne-Ticketing-Automatisierungen für den Einstieg
- Was ist ein MSP Service Level Agreement (SLA)?
- 6 Tipps für Helpdesk-Berichte im modernen IT-Management
- Mehr als nur Fehlerbehebung: Best Practices für IT-Berichte
Quick-Start-Guide
NinjaOne bietet leistungsstarke Funktionen für SLA- und Ticket-Lösungsberichte für MSP-Kund:innen. Insbesondere die Ticketing-Zusammenfassungsberichte liefern umfassende Einblicke in das Ticket-Management:
Wichtige Funktionen für SLA- und Ticket-Lösungsberichte:
- Mittlere Lösungszeit: Berechnet die durchschnittliche Zeit bis zur Lösung von Tickets
- Erste Reaktionszeit: Misst die durchschnittliche Zeit zwischen Ticketerstellung und erster Reaktion der Techniker:innen
- One-Touch-Lösung: Anteil der Tickets, die mit minimalen Kommentaren der Techniker:innen gelöst werden
- Nachverfolgung des Ticketvolumens: Schlüsselt Tickets nach Status, Erstellungszeitpunkt und Effizienz der Techniker:innen auf
Zu den Berichtsfunktionen gehören:
- Berichtsoptionen für die letzten 7 Tage und die letzten 30 Tage
- Aufschlüsselung nach:
- Offenen Tickets
- Ausstehenden Tickets
- Gelösten Tickets
- Pro Tag/Stunde erstellten Tickets
- Ticket-Effizienz der Techniker:innen
Die Berichte helfen MSPs dabei, ihre Service-Erbringung nachzuverfolgen und zu verbessern, indem sie detaillierte Einblicke in die Lösungsleistung, Reaktionszeiten und Produktivität der Techniker:innen geben.