OLA (Operational Level Agreement)

Ein Operational Level Agreement (OLA) ist das interne Gegenstück zum SLA. Während das SLA beschreibt, was Kund*innen zugesagt wird, regelt das OLA, was sich die beteiligten Teams untereinander zusagen. Der Begriff stammt aus dem IT-Service-Management nach ITIL, ist aber überall nützlich, wo mehrere Abteilungen an einem Kundenanliegen arbeiten.

Warum ein SLA ohne OLA wackelt

Der Support verspricht eine Lösung innerhalb eines Arbeitstags. Für die Hälfte der Fälle braucht er aber die Technik, die Buchhaltung oder das Lager. Wenn diese Teams keine eigene Zusage haben, wie schnell sie zuarbeiten, hängt die Einhaltung des SLA vom guten Willen ab. Das OLA schließt diese Lücke: Es verteilt die Zeit, die das SLA vorgibt, auf die Beteiligten.

Was in einem OLA steht

• Beteiligte: welche Teams einander was zuliefern.
• Art der Zuarbeit: zum Beispiel „technische Prüfung eines Fehlers“ oder „Freigabe einer Gutschrift“.
• Zielzeiten: wie schnell das zuarbeitende Team reagiert und liefert.
• Übergabepunkte: in welcher Form ein Fall übergeben wird und welche Angaben er enthalten muss.
• Erreichbarkeit und Vertretung: wer zuständig ist, wenn die eigentlich zuständige Person fehlt.

Beispiel: Zeitbudget aufteilen

Ein Onlinehändler sagt zu, Reklamationen innerhalb von zwei Arbeitstagen (16 Arbeitsstunden) zu entscheiden. Das OLA verteilt dieses Budget:

Die Summe der internen Zielzeiten liegt bewusst unter der Zusage an die Kund*innen. Ohne Puffer reißt das SLA, sobald ein Schritt nur leicht länger dauert.

OLA, SLA und Underpinning Contract

• SLA: Dienstleister gegenüber Kund*innen.
• OLA: internes Team gegenüber internem Team.
• Underpinning Contract (UC): Vertrag mit einem externen Lieferanten, etwa einem Hosting-Anbieter, der für das SLA mitliefert.

Ein OLA ist meist kein Vertrag im rechtlichen Sinn, sondern eine verbindliche Absprache. Es wirkt nur, wenn es gemessen wird – genau wie das SLA. Hilfreich ist eine klare Eskalationsmatrix für den Fall, dass eine interne Frist verstreicht.

Praxis-Tipps

• Beginne mit den zwei oder drei Übergaben, an denen die meisten Fristen reißen. Wo das ist, zeigt eine Auswertung nach Kategorien.
• Halte Übergaben im Ticket selbst fest und nicht in einer separaten Mail, damit die Zeit nachvollziehbar bleibt.
• Vereinbare Zielzeiten nur für Arbeit, die das Team selbst steuern kann.

Häufige Missverständnisse

• „Ein OLA ist nur etwas für Konzerne.“ Auch ein Betrieb mit zwölf Personen hat Übergaben zwischen Büro und Technik. Ein Satz wie „Rückfragen aus dem Support beantwortet die Technik am selben Tag“ ist bereits ein OLA.
• „Das OLA ersetzt das SLA.“ Nein. Kund*innen interessiert nur das Gesamtergebnis. Das OLA ist ein Werkzeug, um es zu erreichen.
• „Die Zielzeiten im OLA addieren sich genau zum SLA.“ Besser nicht. Ohne Puffer reicht eine einzige Verzögerung, und die Zusage an die Kund*innen ist verfehlt.

Für die Messung gilt dasselbe wie beim SLA: Übergaben brauchen einen Zeitstempel. Wird ein Fall per Zuruf weitergegeben, lässt sich später nicht mehr sagen, wo die Zeit verloren ging.

So hilft rapidFOX

rapidFOX kennt Bearbeitungsteams: Ein Vorgang wird einem Team zugewiesen, jedes Team sieht seine eigenen Tickets und kann ein eigenes Postfach haben. Über die Team-Frage im Ticket holst du Kolleg*innen gezielt dazu, ihre Antworten bleiben mit Zeitstempel am Vorgang. Eigene OLA-Fristen je Team bildet rapidFOX nicht ab; die Fristen hängen an der SLA-Klasse. Mehr zu Teams auf der Seite Ticketsystem mit Teams.