So erklären Sie Ihren Kund:innen Ihren Prozess zur Alarmbearbeitung verständlich

Als Managed Service Provider (MSP) müssen Sie Ihren Kund:innen Ihren Prozess zur Alarmbearbeitung klar und nachvollziehbar erklären können. Gelingt das nicht, entsteht schnell der Eindruck, dass sie nicht ausreichend betreut werden oder dass Ihre Bemühungen nicht genügen, selbst wenn Sie den Best Practices der Branche folgen und ein kompetentes, vollständig ausgestattetes Team Probleme zeitnah löst.

Dieser Leitfaden liefert einen Rahmen dafür, wie Sie Ihren Prozess zur Alarmbearbeitung so vermitteln, dass Ihre Kundschaft ihn versteht. So entstehen realistische Erwartungen und das Vertrauen bleibt auch während eines Incidents erhalten.

Sie suchen einen umfassenden Leitfaden zum Thema? Sehen Sie sich unser Video an: So erklären Sie Ihren Kund:innen Ihren Prozess zur Alarmbearbeitung verständlich.

Der Unterschied zwischen Alarmierungen und Incidents

Ein Incident ist eine Unterbrechung der IT-Services, die Sie für Ihre Kund:innen bereitstellen oder verwalten. Incidents sind in der Regel ungeplant und reichen von einer beeinträchtigten Internetverbindung aufgrund eines Verbindungsausfalls bis zum kompletten Ausfall eines Dateiservers nach einem Systemabsturz. Sicherheitsvorfälle wie Datenschutzverletzungen unterbrechen den Service nicht zwingend akut oder unmittelbar, können aber andere negative Folgen nach sich ziehen.

Eine Alarmierung entsteht als Folge eines Incidents und geht an Ihr Technikteam, damit dieses davon erfährt. Sie kann von Überwachungssystemen oder Sicherheitsplattformen erzeugt werden und bereits beim ersten Auftreten eines Incidents ausgelöst werden (z. B. wenn ein Server nicht mehr antwortet) oder erst beim Erreichen bestimmter Schwellenwerte (z. B. bei einer bestimmten Anzahl fehlgeschlagener Anmeldeversuche für eine:n Benutzer:in). Alarmierungen können auch von Menschen ausgehen, etwa in Form eines Support-Tickets, und ungewöhnliche Aktivitäten oder Fehlfunktionen in Ihrer Infrastruktur aufdecken, die automatisierte Systeme möglicherweise nicht erfassen.

Was ist ein Prozess zur Alarmbearbeitung?

Der Prozess zur Alarmbearbeitung (oder zur Alarm-Triage) beschreibt, wie Sie Alarmierungen konfigurieren und darauf reagieren. Ein wirksamer Prozess sorgt für sinnvolle Schwellenwerte und dafür, dass Alarmierungen priorisiert und bei Bedarf eskaliert werden. So geht nichts verloren und kritische Incidents haben Vorrang vor kleineren Ärgernissen.

Für Ihr MSP-Team besteht das Ziel darin, Transparenz zu schaffen und gleichzeitig Alarmmüdigkeit zu vermeiden. Für Ihre Kund:innen muss das verständlich aufbereitet werden: Sie müssen die technischen Gründe dafür entschlüsseln können, warum Ihre Alarm-Triage genau so aufgebaut ist. Tritt dann unvermeidlich ein schwerwiegender Incident ein, wissen Ihre Kund:innen beruhigt, dass er Vorrang vor anderen laufenden Arbeiten hat und Ihr Team bereits daran arbeitet.

So erklären Sie den Prozess zur Alarmbearbeitung verständlich

Technologie hilft dabei, Kund:innen die Einsatzbereitschaft Ihres Teams zu vermitteln. Überwachungssoftware lässt sich live vorführen, inklusive Dashboards und Benachrichtigungen in Aktion. Richtlinien für Überwachung und Alarmierung (einschließlich Eskalationsstufen) können Sie über die Dokumentationsplattform Ihres MSP teilen, und Ihre Helpdesk-Software unterstützt eine klare Kommunikation mit Kund:innen sowie Statusmeldungen zu einem Incident.

Quarterly Business Reviews (QBRs) bieten die Gelegenheit, Berichte aus Überwachungs- und Helpdesk-Kennzahlen zu zeigen und damit zu belegen, dass Ihr Prozess zur Alarmbearbeitung funktioniert.

Wenn Sie Ihren Prozess zur Alarmbearbeitung erläutern, sollten Sie Ihren Kund:innen die folgenden Fragen eindeutig beantworten:

• Was passiert, wenn etwas schiefgeht?
• Wie schnell reagieren Sie?
• Woher weiß ich, dass keine Probleme untergehen?

Keine dieser Antworten darf abstrakt wirken. Sie sollten konkret und auf Ihren Richtlinien aufgebaut sein, damit sie im Ernstfall auch belegbar sind.

Anforderung 1: Den Lebenszyklus einer Alarmierung in verständlicher Sprache aufschlüsseln

Vermeiden Sie Fachjargon, wenn Sie Ihre Überwachungssysteme und Alarmierungsmethoden erklären. Gehen Sie auf die folgenden Technologien und Konzepte ein und erläutern Sie, wie Sie damit auf die Probleme Ihrer Kund:innen reagieren:

• Erkennung: Erklären Sie, mit welchen Überwachungstools Sie Probleme identifizieren.
• Ticketerstellung: Erklären Sie, wie Tickets entstehen, sowohl automatisiert aus Überwachungssystemen als auch durch Benutzer:innen, die Probleme melden.
• Triage: Beschreiben Sie, wie Ihre Techniker:innen eine Alarmierung prüfen und ihre Priorität bewerten.
• Reaktion: Hat die Alarmierung einen Incident erkannt, erläutern Sie Schritt für Schritt, wie er zugewiesen und behoben wird.
• Eskalation: Stellen Sie sicher, dass Ihre Kundschaft versteht: Lässt sich ein Incident nicht zügig lösen, geht die Alarmierung an erfahrenere Mitarbeiter:innen oder an einen externen Anbieter. So kann es etwa nötig sein, ein Microsoft-365-Problem, das sich nicht extern lösen lässt, an den Microsoft-Support zu eskalieren.
• Abschluss und Berichterstattung: Dokumentierte Angaben zur Lösung und die zugehörigen Zeiten fließen in Berichte ein und dienen späteren Auswertungen und Verbesserungen

Hilfreich sind dabei Diagramme und Flussdiagramme, die zeigen, wie unterschiedliche Alarmierungen durchlaufen werden. Sie können zum Beispiel darstellen, wie eine zunächst niedrig priorisierte Alarmierung beim Erreichen von Schwellenwerten eskaliert wird.

Anforderung 2: SLAs in Szenarien übersetzen

Praxisnahe Szenarien schaffen Vertrauen, weil Kund:innen sie auf die eigenen Geschäftsprozesse übertragen und so einschätzen können, welche Wirkung Ihr Alarmierungsprozess hat.

Nennen Sie also nicht einfach eine Reaktionszeit, sondern setzen Sie sie in einen Zusammenhang: „Geht Ihr Server um 2 Uhr nachts offline, erzeugt unser System sofort eine Alarmierung, und ein:e Techniker:in aus der Rufbereitschaft reagiert innerhalb von 15 Minuten. In der Regel rechnen wir damit, ihn innerhalb der folgenden 30 Minuten wieder online zu haben. Gelingt das nicht, eskalieren wir innerhalb einer Stunde an eine:n Techniker:in vor Ort.“

Anforderung 3: Eskalationswege transparent machen

Erklären Sie, warum ein Incident weder in einer Warteschlange hängen bleibt noch bei einer Person liegen bleibt, die ihn nicht lösen konnte. Gehen Sie auf diese Punkte ein:

• Wer übernimmt die Erstreaktion (Level 1)
• Wer eskaliert komplexe Probleme (Level 2/3 oder externer Anbieter)
• Wie Kund:innen und Stakeholder während einer Eskalation informiert werden

Anforderung 4: Zeigen Sie Ihren Kund:innen, was sie im Ernstfall sehen

Zeigen Sie Ihrer Kundschaft im Rahmen der Einarbeitung Beispiele dafür, was sie während und nach Incidents sieht, die Alarmierungen ausgelöst haben. Dazu können Berichte mit gelösten Alarmierungen und Verfügbarkeitskennzahlen oder Dashboards mit Live-Daten für Kund:innen gehören.

Heben Sie besondere Fälle in QBRs hervor, um die Wirksamkeit Ihres Prozesses zur Alarmbearbeitung zu belegen.

Anforderung 5: Zwischen echten Alarmierungen und Rauschen unterscheiden

Erläutern Sie die Technologien hinter Ihrer Überwachung und Alarmierung und wie Ihr Team damit effiziente Services mit Fokus auf Verfügbarkeit erbringt. Alarmmüdigkeit entsteht, wenn Techniker:innen mit Alarmierungen zu Kleinigkeiten überflutet werden und dadurch wichtige Incidents übersehen.

Zeigen Sie Ihren Kund:innen, wie Sie das verhindern und wie Schwellenwerte, Filterung und Automatisierung dafür sorgen, dass Incidents sinnvoll nach ihrem Schweregrad priorisiert werden.

NinjaOne vereint Überwachung, Alarmierung, Ticketing und Dokumentation in einer Lösung

NinjaOne bietet MSPs eine umfassende Toolchain für Überwachung, Alarmierung und Incident Response. Schwellenwerte lassen sich pro Kund:in festlegen, und wenn etwas passiert, gehen Benachrichtigungen per SMS, E-Mail und Push-Nachricht raus, damit Techniker:innen nie hinterherhinken, sondern die Lösung parat haben.

Tickets im NinjaOne Helpdesk lassen sich automatisiert aus Alarmierungen einer Vielzahl von Servern, Tools und Plattformen erzeugen, und Dashboards zeigen Verfügbarkeits- und Lösungskennzahlen. In NinjaOne Documentation speichern Sie SLAs, Prozessdokumentationen, Diagramme, Berichte, Beispiele und weitere Unterlagen für Kund:innen, die Ihrem Prozess zur Alarmbearbeitung wertvollen Kontext geben und zusätzlich Vertrauen schaffen.