Service Level Agreement (SLA): Was drinstehen muss

Service Level Agreements (SLAs) regeln, welche Leistungen ein Provider für einen Kunden erbringt und was passiert, wenn etwas schiefläuft. Insbesondere im Bereich Managed-IT-Services sorgen SLAs so für Verbindlichkeit. Erfahren Sie, wie ein SLA aufgebaut sein sollte und welche Feinheiten es zu beachten gilt.

Definition: Was ist ein Service Level Agreement (SLA)?

Ein Service Level Agreement (SLA) ist eine vertragliche Vereinbarung zwischen einem Dienstleister und einem Kunden. Es benennt die Services, die vom Dienstleister erbracht werden müssen und die damit verbundenen Leistungsanforderungen. Ziel eines SLAs ist es, die Qualität eines Dienstes überprüfbar festzulegen. Man spricht in diesem Zusammenhang von Service Level Requirements (SLRs), welche die Anforderungen des Kunden abbilden.

Grundsätzlich kommen SLAs in einer Vielzahl von Branchen zum Einsatz, beispielsweise in der Logistik, beim Facilitymanagement oder bei Personaldienstleistungen. Besonders wichtig sind sie jedoch im IT-Bereich. Weil Unternehmen mittlerweile einen großen Teil ihrer IT-Dienste aus der Cloud beziehen, muss hier genau geregelt werden, was die Leistung umfasst und wie sie erbracht wird. Typische Kennzahlen im IT-Bereich sind etwa:

• Verfügbarkeit: wie oft der Service nutzbar sein muss
• Reaktionszeit bei Störungen: wie schnell der Anbieter Gegenmaßnahmen einleiten muss
• Wiederherstellungszeit (Recovery Time Objective, RTO): wie schnell ein Service nach einer Störung wieder online sein muss
• Performancewerte, beispielsweise welche Durchsatzrate oder Latenz ein Service aufweist

Insbesondere Managed-Services-Provider (MSPs) setzen stark auf SLAs. Hier können Unternehmen IT-Services modular beziehen, also genau das einkaufen, was im Unternehmen fehlt. Aber auch die großen Cloud-Provider sowie Telekommunikationsanbieter nutzen SLAs.

SLAs benennen auch Sanktionsregelungen: Was passiert, wenn ein bestimmter Service nicht wie vereinbart erbracht wird? Das trägt zur Absicherung des Kunden bei. Beispielsweise könnte der Anbieter auf Service-Gutschriften verpflichtet werden, falls er gewährleistete Verfügbarkeiten nicht einhält.

SLAs sind ein wichtiger Bestandteil des Service-Level-Management (SLM), wie es im Best-Practice-Leitfaden ITIL (Information Technology Infrastructure Library) definiert wird.

Interessant zu wissen: Service Level Agreements werden typischerweise zwischen einem IT-Provider und einem Unternehmen geschlossen. Unternehmen verwenden SLAs aber auch intern, um die Erbringung von Leistungen zwischen Abteilungen zu formalisieren. Das kann zum Beispiel die Lieferfrequenz eines internen Entwicklungsteams betreffen: Wie oft wird neue Software bereitgestellt?

Abgrenzungen

Wie unterscheiden sich SLAs von anderen vertraglichen Vereinbarungen? Hier die wichtigsten Abgrenzungen:

SLA vs. OLA (Operational Level Agreement)

Ein SLA regelt die Leistungserbringung gegenüber dem Kunden. Dagegen regelt ein OLA, wie die Leistung intern, aufseiten des Dienstleisters, organisiert und erbracht wird. Das betrifft insbesondere die Zusammenarbeit zwischen Teams, etwa zwischen dem Netzwerk- und dem Anwendungsteam. Beide müssen an einem Strang ziehen, um die SLA-Ziele zu gewährleisten. Der Kunde bekommt ein OLA also in der Regel nicht zu Gesicht. Es handelt sich um ein internes Abstimmungsinstrument des Providers.

SLA vs. UC (Underpinning Contract)

Ein Underpinning Contract ist ein Vertrag zwischen dem Service-Provider und einem externen Lieferanten. Zum Beispiel könnte ein Managed-Services-Provider mit einem Cloud-Anbieter wie AWS kooperieren, um bestimmte IT-Dienste für den Kunden zu erbringen. Das UC gewährleistet, dass die Kooperation mit AWS reibungslos verläuft und der MSP seinen Verpflichtungen gegenüber dem Kunden nachkommen kann. Auch hier gilt: Der Kunde bekommt den UC meistens nicht zu Gesicht, außer er fragt explizit danach, weil er zum Beispiel aufgrund regulatorischer Anforderungen die Sicherheit der Lieferkette nachweisen muss, Stichwort NIS-2.

3 Arten von SLAs

Je nach Unternehmen und Komplexität kommen unterschiedliche SLA-Typen zum Einsatz. Die drei wichtigsten sind:

SLA auf Kundenebene (Customer-Based SLA)

Ein kundenbasiertes SLA beschreibt alle Dienste, die ein Provider für einen bestimmten Kunden erbringt. Die Vereinbarung wird für jeden Kunden neu formuliert. Diese Art von SLA eignet sich am besten für maßgeschneiderte Lösungen. Ein Beispiel wäre ein Fertigungsbetrieb, der Infrastruktur-Leistungen, IT-Security und Support über einen Managed-Services-Provider bezieht. Der MSP setzt dafür ein SLA auf, der genau diese Kombination von Services abbildet.

SLA auf Serviceebene (Service-Based SLA)

Ein servicebasiertes SLA definiert unabhängig vom Kunden einen bestimmten Service universell. Es gilt für alle Kunden des Providers, die diesen Service nutzen. Beispielsweise könnte ein Provider für seinen Hosted-Mail-Service eine Verfügbarkeit von 99,9 Prozent gewährleisten. Dieser SLA gilt dann für alle Kunden.

Ein SLA auf Serviceebene bietet sich für Leistungen an, die standardisiert erbracht werden, insbesondere für viele Kunden gleichzeitig. Deshalb nutzen vor allem Cloud-Provider, Web-Hoster und Kommunikationsanbieter dieses Modell.

Mehrstufiges SLA (Multi-Level SLA)

Ein mehrstufiges Service Level Agreement kombiniert die beiden erstgenannten Ansätze. Dabei wird zwischen drei Ebenen unterschieden:

• Unternehmensweite Ebene: In diesem Teil des SLAs werden übergeordnete Standards für alle Kunden bzw. für alle Geschäftsbereiche eines Kunden definiert

• Kundenspezifische Ebene: Hier werden individuelle Anpassungen für einen bestimmten Kunden bzw. einzelne Abteilungen festgehalten

• Serviceebene: Dieser Teil enthält detaillierte Leistungsbeschreibungen für die einzelnen Services

Ein Beispiel: Ein IT-Provider bietet Cloud- und Supportleistungen für mittelständische Unternehmen an. Dafür definiert er zunächst allgemeine Rahmenbedingungen, zum Beispiel Verfügbarkeiten, Supportzeiten und Wartungsfenster (= unternehmensweite Ebene). Premium-Kunden erhalten zusätzlich Sonderregelungen, zum Beispiel 24/7-Support, verkürzte Reaktionszeiten oder eigene Ansprechpartner (= kundenspezifische Ebene). Zusätzlich enthält das SLA noch einen Teil, in dem die einzelnen Services detailliert beschrieben werden (= Serviceebene).

Solche mehrstufigen SLAs bieten sich an, wenn ein Provider verschiedene Service-Levels für verschiedene Kunden realisieren möchte. Das ist insbesondere im SaaS-Bereich weit verbreitet. Mehrstufige SLAs eignen sich aber auch für große, internationale Kunden mit Zweigstellen in verschiedenen Ländern. Hier werden zuerst unternehmensweite Bedingungen definiert, die für alle Standorte gelten (zum Beispiel ganz Europa), und dann spezifische Regeln, die nur für bestimmte Standorte gelten (zum Beispiel in Deutschland).

Es gibt auch Szenarien, in denen ein Unternehmen ein mehrstufiges SLA mit mehreren externen Anbietern abschließt. Das klassische Beispiel sind Multi-Cloud-Modelle (die parallele Nutzung mehrerer Public-Cloud-Anbieter).

Typische Inhalte eines SLAs

Ein Service Level Agreement besteht typischerweise aus den folgenden Bestandteilen:

1. Einleitung und Überblick

Zu Beginn eines SLAs werden die Eckdaten der Vereinbarung skizziert. Das betrifft die involvierten Vertragspartner und die relevanten Services. Außerdem wird der Geltungsbereich umrissen, für welche Systeme, Standorte und Nutzergruppen die Vereinbarung gilt. Zudem wird der Vertragszeitraum kurz benannt.

2. Beschreibung der Services

In diesem Abschnitt werden die IT-Services genau beschrieben. Punkte, die hier besprochen werden:

• Der Funktionsumfang des Dienstes: Was genau leistet der Service? Welche Features sind enthalten? Zum Beispiel könnte der Service die Bereitstellung eines Microsoft-365-Tenants beinhalten, einschließlich Exchange, SharePoint und Teams.

• Die technologische Basis: Auf welcher Plattform läuft der Service? Zum Beispiel könnte der Dienst auf einer VMware-basierten Private Cloud gehostet werden, bereitgestellt aus zwei redundanten Rechenzentren in Frankfurt und Nürnberg.

• Schnittstellen zu anderen Systemen: Welche Systeme sind angebunden und wie erfolgt die Integration? Zum Beispiel könnte ein Backup-Service über eine API mit dem zentralen Monitoring-System verbunden sein und bei Fehlern automatisch ein Ticket im ITSM-System auslösen.

• Betriebsszenarien: Wie wird der Service betrieben: On-prem, in der Cloud oder hybrid? Zum Beispiel könnte ein Machine-Learning-Service komplett aus der Cloud bereitgestellt werden, ohne dass lokale Infrastruktur notwendig wäre.

• Abwicklungszeiten: Wie schnell werden standardisierte Leistungen oder Service Requests erbracht? Zum Beispiel könnte die Erstellung eines neuen Benutzerkontos innerhalb von 8 Stunden zu erfolgen haben.

• Wartungspläne: Welche regelmäßigen Wartungsfenster gibt es und welche Auswirkungen haben diese? Zum Beispiel könnten Wartungsarbeiten immer am dritten Samstag im Monat erfolgen, mit kurzzeitigen Einschränkungen bei der Verfügbarkeit.

3. Serviceziele (Service Level Objectives, SLOs)

Die Serviceziele, im Englischen Service Level Objectives (SLOs), bilden das Kernstück des Service Level Agreements. Sie legen fest, wie gut ein Service funktionieren muss, damit die Geschäftsbedürfnisse des Kunden erfüllt werden. Wichtig ist, dass die SLOs überprüfbar und realistisch sind. Zu den wichtigsten Leistungskennzahlen zählen:

• Verfügbarkeit
• Reaktionszeit
• Wiederherstellungszeit
• Latenzzeiten
• Durchsatzraten
• Fehlerraten
• First Response Time
• Resolution Time

Wir gehen weiter unten ausführlich auf die Bedeutung dieser Kennzahlen ein.

4. Monitoring und Reporting

Dieser Teil des SLAs regelt, wie die Servicequalität überwacht wird. Das umfasst unter anderem:

• Verwendete Tools: Welche Monitoring-Tools kommen zum Einsatz? Ein Beispiel: „Die Verfügbarkeit des Webservers wird über ein externes Monitoring-Tool wie UptimeRobot oder PRTG im 1-Minuten-Intervall überprüft.“

• Kennzahlen: Welche Werte werden erfasst? Ein Beispiel: „Es werden verschiedene Leistungskennzahlen erfasst, darunter die First-Time Fix Rate, die durchschnittliche Antwortzeit und die Anzahl kritischer Incidents.“

• Zugriff: Wer kann die Monitoring-Daten einsehen? Ein Beispiel: „Der Kunde erhält Lesezugriff auf das Monitoring-Dashboard und kann die Historie der letzten 90 Tage einsehen.“

• Reports: Wie oft werden Reports erstellt? Ein Beispiel: „Der Kunde erhält einen monatlichen SLA-Report im PDF-Format mit Angaben zur Verfügbarkeit, Incident-Zahlen und Reaktionszeiten.“

• Abweichungen: Wie werden Soll-Abweichungen dokumentiert? Ein Beispiel: „Bei Nichterreichen vereinbarter Servicelevel wird automatisch ein Ticket im Ticketsystem erzeugt. Außerdem folgt eine Erklärung im nächsten Monatsreport.“

Solche Monitoring-Konzepte nützen dem Kunden in zweierlei Hinsicht: Erstens kann die Servicequalität fortlaufend und objektiv beurteilt werden, nicht nur auf Zuruf. Zweitens kann sich der Kunde bei SLA-Verstößen auf belastbare Daten stützen.

5. Support- und Reaktionszeiten

In diesem Abschnitt wird geregelt:

• Zu welchen Zeiten der Support zur Verfügung steht, zum Beispiel Montag bis Freitag, 8 bis 18 Uhr
• Auf welchen Wegen der Support erreichbar ist, zum Beispiel via Ticketsystem, Telefon oder E-Mail
• Wie schnell der Provider auf Anfragen reagieren muss

6. Sicherheitsstandards

Ein Service Level Agreement sollte die verwendeten Sicherheitsstandards und -protokolle benennen, um die Vertraulichkeit der Kundendaten zu gewährleisten. Typische Elemente sind:

• Einhaltung von Standards, zum Beispiel ISO/IEC 27001 (Informationssicherheits-Managementsystem) oder ISO/IEC 27018 (Schutz personenbezogener Daten in der Cloud)
• Verwendung von Sicherheitsprotokollen zur Datenübertragung und Speicherung, wie TLS/SSL, S/MIME oder IPsec
• Regelmäßige Audits und Penetrationstests
• Geheimhaltungsvereinbarungen (Non-Disclosure Agreements, NDAs)
• Regelungen zum Schutz geistigen Eigentums
• Meldepflichten bei Sicherheitsvorfällen

7. Ausnahmen

In diesem Teil des SLAs wird definiert, in welchen Fällen der Dienstleister nicht haftbar gemacht werden kann. Zu diesen Ausschlussgründen zählen:

• Höhere Gewalt (Force Majeure), zum Beispiel Naturkatastrophen oder politische Unruhen
• Geplante Wartungsarbeiten, zum Beispiel Infrastruktur-Umbauten oder Software-Updates, sofern sie vorab angekündigt wurden
• Kundenseitige Ursachen, zum Beispiel Nichtbereitstellung von Informationen oder kundenseitige Fehlkonfigurationen

8. Kundenpflichten

Ein SLA regelt nicht nur die Pflichten des Anbieters, sondern auch die des Kunden. Dazu gehören unter anderem:

• Benennung von Ansprechpartnern
• Einhaltung von Mitwirkungspflichten
• Freigabe-Fristen für Änderungen

9. Eskalationsverfahren

Falls kritische Störungen oder SLA-Verstöße auftreten, greift das vereinbarte Eskalationsverfahren. Es regelt, wie in solchen Fällen reagiert werden muss. Eskalationsverfahren sind oft mehrstufig aufgebaut, zum Beispiel:

Stufe	Reaktion	Ansprechpartner	Zeitrahmen
1	Der Bearbeiter informiert die Teamleitung	Teamleitung IT-Support	< 1 Stunde
2	Der Vorgang wird an den Service-Manager eskaliert	Kundenverantwortlicher	< 4 Stunden
3	Die Geschäftsführungsebene wird einbezogen	Account Manager / Geschäftsleitung	< 1 Werktag

Außerdem sollte definiert sein, wie Eskalationen eingeleitet werden, zum Beispiel per Anruf oder über eine spezielle Eskalations-Mailadresse. Zudem sollten sämtliche Eskalationen dokumentiert werden.

Insbesondere Unternehmen, die keine eigene IT-Abteilung besitzen, sollten diesem Abschnitt viel Aufmerksamkeit widmen. Denn ein klar definiertes Eskalationsverfahren schützt davor, dass Vorgänge verschleppt werden.

10. Sanktionen

Wenn Service-Levels unterschritten werden, kann das SLA Sanktionen vorsehen, zum Beispiel Ausgleichszahlungen oder Gutschriften. Diese Mechanismen tragen zur Verbindlichkeit bei. Wir gehen weiter unten noch genauer auf die Ausgestaltung solcher Sanktionen ein.

11. Change Management

Ein Service Level Agreement ist kein statisches Dokument: Sowohl die technischen Gegebenheiten im Unternehmen als auch die Geschäftsanforderungen ändern sich ständig. Gleichzeitig entwickeln sich die Fähigkeiten des Dienstleisters weiter. Deshalb sollte das SLA auch Regeln zur Anpassung enthalten. Das betrifft vor allem diese Fragen:

Wer darf Änderungen initiieren?

Ein Beispiel: „Sowohl der Kunde als auch der Provider können SLA-Änderungen vorschlagen. Solche Änderungen müssen schriftlich und mit mindestens 14 Tagen Vorlauf angekündigt werden.“

Wie läuft der Change Prozess ab?

Ein typisches Vorgehen ist:

1. Änderungsvorschlag schriftlich einreichen
2. Gemeinsame Bewertung
3. Schriftliche Zustimmung beider Parteien
4. Dokumentation in einem Change-Appendix

Was passiert bei einseitigen Änderungen?

Dabei geht es hauptsächlich um Änderungen, die der Dienstleister ohne vorherige Abstimmung vornimmt.

Ein Beispiel: „Der Anbieter informiert den Kunden mindestens 30 Tage vor wesentlichen Änderungen am Service-Umfang. Bei entstehenden Nachteilen kann der Kunde binnen 14 Tagen Einspruch einlegen.“

Was gilt bei Notfällen und Updates?

Hier entfällt in der Regel die Vorankündigungspflicht, es besteht aber eine Dokumentationspflicht.

Ein Beispiel: „Kritische Sicherheitspatches dürfen ohne Vorankündigung eingespielt werden. Der Kunde wird nachträglich, spätestens innerhalb von zwei Stunden, informiert.“

12. Kündigungsmanagement

Ein Service Level Agreement sollte klare Regeln zur Beendigung enthalten. Üblich sind:

• Ordentliche Kündigung. Beispiel: „Beide Parteien können das SLA mit einer Frist von 30 Tagen zum Monatsende kündigen.“

• Außerordentliche Kündigung. Beispiel: „Bei wiederholten SLA-Verstößen, z.B. bei dreimaliger Unterschreitung der Verfügbarkeit, kann der Kunde das SLA fristlos kündigen.“

• Form der Kündigung. Beispiel: „Die Kündigung muss schriftlich erfolgen, entweder per E-Mail oder Post.“

Die wichtigsten Serviceziele

Um zu gewährleisten, dass ein Provider seine Zusagen einhält, werden im SLA eine Reihe von verbindlichen Servicezielen (Service Level Objectives, SLOs) definiert. Die wichtigsten sind:

Verfügbarkeit (Availability)

Sie gibt an, wie zuverlässig ein Service zur Verfügung stehen muss, normalerweise als Prozentsatz über einen bestimmten Zeitraum.

Ein Beispiel: „Der Mailserver muss eine monatliche Verfügbarkeit von 99,9 Prozent aufweisen.“ Das entspricht einer maximalen Ausfallzeit von etwa 43 Minuten pro Monat.

In diesem Zusammenhang sollte auch definiert werden, wann und wie Ausfallzeiten gemessen werden. Beispielsweise könnte sich die Messung nur auf Werktage beziehen vs. eine 24/7-Verfügbarkeit. Außerdem sollte geregelt sein, ob geplante Wartungsfenster in die Verfügbarkeitsmessung einfließen oder nicht.

Reaktionszeit (Response Time)

Die Reaktionszeit gibt an, wie schnell der Provider nach Eingang einer Störungsmeldung reagieren muss. Dabei wird normalerweise nach der Priorität der Störung unterschieden.

Ein Beispiel: „Der Provider muss bei einem Vorfall mit Priorität 1 (kritisch) innerhalb von 30 Minuten reagieren.“

Dafür sollte definiert werden, ab wann genau gemessen wird, beispielsweise ab Eingang des Tickets oder ab telefonischer Meldung. Ebenso sollte spezifiziert werden, was genau als Reaktion gilt. Reicht es, wenn sich der Provider nur zurückmeldet? Oder zählt erst die Einleitung von Gegenmaßnahmen als Reaktion?

Wiederherstellungszeit (Resolution Time)

Die Wiederherstellungszeit bezeichnet die maximale Dauer, bis ein ausgefallener Service wieder betriebsbereit sein muss.

Ein Beispiel: „Kommt es zu einem Totalausfall der Firewall, muss die Wiederherstellung innerhalb von vier Stunden erfolgen.“

Wichtig: Die Wiederherstellungszeit unterscheidet sich von der Reaktionszeit. Letztere misst nur die Dauer bis zur ersten Bearbeitung des Vorfalls durch den Provider.

Leistung (Performance-Kennzahlen)

Performance-Kennzahlen messen die technische Leistung von Services, wie zum Beispiel Antwortzeiten, Durchsatzraten oder Ladezeiten.

Ein Beispiel: „Die API muss innerhalb von 500 Millisekunden auf 95 Prozent aller Anfragen antworten.“

Die Performance-Werte sollten auch unter Lastbedingungen realistisch sein, beispielsweise zu Stoßzeiten. Gegebenenfalls kann es sinnvoll sein, im Service Level Agreement nach Tageszeiten oder Regionen zu staffeln.

Fehlerrate (Error Rate)

Die Fehlerrate bezieht sich typischerweise auf die Anzahl fehlerhafter Datenverarbeitungen. Das ist insbesondere relevant für Softwaredienste, wie zum Beispiel E-Mail-Zustellungen, Datensynchronisationen oder Bestellübertragungen.

Ein Beispiel: „Das ERP darf maximal 0,1 Prozent aller Bestellungen fehlerhaft verarbeiten.“ Bei 10.000 Bestellungen pro Monat wären also bis zu 10 fehlerhafte Übertragungen zulässig.

Die Fehlerrate kann aber auch weiter gefasst werden, etwa im Hinblick auf:

• Verpasste Fristen, z.B. bei Compliance-Anforderungen
• Verzögerungen bei der Veröffentlichung neuer Software-Funktionen
• Codierungsfehler

Das SLA sollte außerdem regeln, wie Fehler erkannt und klassifiziert werden und ob Korrekturversuche automatisiert erfolgen oder der Provider manuell eingreifen muss.

Support-Kennzahlen

In vielen SLAs wird auch die Qualität der Support-Leistungen definiert, insbesondere bei Managed-Services-Modellen. Eine wichtige Kennzahl ist hier die First-Time Fix Rate (FTFR). Sie misst den Anteil der Anfragen, die beim ersten Kontakt mit dem Support vollständig gelöst werden konnten.

Ein Beispiel: „Mindestens 85 Prozent aller Support-Anfragen werden beim Erstkontakt abschließend gelöst.“

Solche Vorgaben steigern die Produktivität auf Kundenseite und entlasten das interne IT-Team.

Weitere wichtige Kennzahlen für die Support-Qualität sind:

• Kundenzufriedenheit nach Ticket-Abschluss, zum Beispiel CSAT-Werte (Customer Satisfaction Score)
• Ticket-Rücklaufquote: Wie oft kommt es zu Rückfragen, weil die vorhergehende Antwort unklar war?
• Gesamt-Lösungszeit, insbesondere bei Rückläufen
• Abbrecherquote: Der Anteil der Support-Anfragen, die vom Kunden vorzeitig abgebrochen werden
• Ergebnisse interner Support-Audits

Geschäftsergebnisse (Business Outcomes)

In manchen SLAs, vor allem bei strategischen Partnerschaften, werden nicht nur technische, sondern auch geschäftsbezogene Ziele definiert. Sie orientieren sich am konkreten geschäftlichen Mehrwert.
Ein Beispiel: „Durch das neue Cloud-CRM sollen durchschnittlich 95 Prozent aller Kundenanfragen innerhalb von 12 Stunden abgewickelt werden.“

Welche Strafen gibt es?

Service Level Agreements definieren Sanktionen, falls der Anbieter seinen Verpflichtungen nicht nachkommt. Dabei ist es unerheblich, ob dem Kunden ein Schaden entstanden ist. Es geht vielmehr darum, Anreize zur Vertragstreue zu setzen.

Typische Strafen sind:

• Servicegutschriften: Hier erhält der Kunde finanzielle Gutschriften oder Rückerstattungen. Die Höhe orientiert sich meist prozentual an der monatlichen Vergütung des Providers.

• Vertragsstrafen: Pauschale Vertragsstrafen sind ebenfalls üblich, zum Beispiel 1.000 € bei wiederholter Nichtverfügbarkeit des Mail-Servers.

• Kündigungsrechte: Kommt es zu wiederholten, schwerwiegenden SLA-Verletzungen durch den Provider, kann der Kunde den Vertrag vorzeitig außerordentlich kündigen.

• Andere Sanktionen: Dazu zählen etwa Lizenzverlängerungen, kostenfreier Support oder nachträgliche Ausgleichsleistungen, etwa in Form verlängerter Wartungszeiträume.

Vorteile von SLAs

Service Level Agreements bieten Unternehmen eine Reihe von Vorteilen:

Klarheit

SLAs schaffen eine gemeinsame Erwartungsbasis: Es ist klar, welche Leistungen in welcher Qualität erbracht werden müssen. Das minimiert Missverständnisse und Reibungspunkte.

Servicequalität

Durch definierte Kennzahlen wie Verfügbarkeit oder Reaktionszeit wird die Servicequalität objektiv messbar und damit auch optimierbar.

Outsourcing

In vielen KMU sind die IT-Ressourcen begrenzt. Dank SLAs können IT-Services problemlos von außen bezogen werden.

Verlässlichkeit im Ernstfall

Ein SLA bietet klar geregelte Reaktions- und Eskalationsmechanismen. So wissen alle Beteiligten, was zu tun ist, wenn der Ernstfall eintritt.

Rechtliche Absicherung

Kommt es zu Problemen bei der Zusammenarbeit mit dem Provider, bieten SLAs eine vertragliche Grundlage für Entschädigungen.

User Experience

Indem SLAs die Servicequalität erhöhen, verbessert sich auch die User Experience. Die Endanwender können besser und produktiver arbeiten.

Verlassen Sie sich auf Ihren Provider – mit Proact!

Ob Cloud-Speicher, On-Prem-Lösungen oder IT-Security – unsere Services sind immer an klar definierte Service Levels geknüpft. So können Sie sich auf das Wesentliche konzentrieren.

Unsere Zusammenarbeit beginnt mit einer strukturierten Bedarfsanalyse. Auf dieser Basis entwerfen wir Ihr maßgeschneidertes Managed Services Konzept. Dieses Konzept dokumentieren wir in einem umfassenden SLA, der auch Sicherheitsprotokolle und Vertragsstrafen präzise definiert. So gehen Sie kein Risiko ein. Sie wissen schon im Vorfeld genau, welche Leistungen wie erbracht werden.

Im Anschluss übernehmen wir die vollständige Implementierung und den Betrieb der Lösung. Auch das Monitoring erfolgt durch uns. Natürlich können Sie sich jederzeit mit Support-Anfragen an uns wenden – mit hoher Erstlösungsquote. Sie sind noch unsicher, welche IT-Services sich perfekt dazu eignen, ausgelagert zu werden? In unserem Whitepaper „Managed Services: Welche IT-Dienste Sie am besten auslagern können“ erfahren Sie, welche 9 IT-Services bei einem Service Provider in besten Händen sind.

Das klingt interessant? Dann kontaktieren Sie uns jetzt für ein kostenloses Beratungsgespräch. Wir freuen uns schon, von Ihnen zu hören!