suche
ESC

Service-Desk-Grundlagen

Ticket-Lebenszyklus, Klassifizierung und Priorisierung, SLA/OLA verstehen und anwenden.

First-Level Grundlagen 25 Min +120 XP

Worum geht’s

Im Service Desk landet jede Störung und jede Anfrage zuerst als Ticket. Wer ein Ticket sauber aufnimmt, richtig klassifiziert und korrekt priorisiert, entscheidet darüber, wie schnell und wie verlässlich Probleme gelöst werden. Das ist das Fundament jeder First-Level-Arbeit — und die Basis dafür, dass SLA-Zusagen eingehalten werden.

Konzept

Ein Ticket durchläuft einen Lebenszyklus: Neu → Zugewiesen → In Bearbeitung → Gelöst → Geschlossen. Kommt der Nutzer mit einem ungelösten Problem zurück, geht es in Wiedervorlage und der Zyklus läuft erneut.

Klassifizierung trennt zwei Grundtypen:

  • Incident — etwas funktioniert nicht (mehr): „Mein Drucker druckt nicht.”
  • Service Request — ein Wunsch im Rahmen des Service-Katalogs: „Bitte neue Software installieren.”

Priorität ergibt sich aus Impact × Urgency (Auswirkung mal Dringlichkeit):

  • P1 — kritisch: alle/viele Nutzer betroffen, Kerngeschäft steht (z. B. Mailserver down).
  • P2 — hoch: Abteilung oder wichtiger Dienst betroffen.
  • P3 — mittel: einzelner Nutzer eingeschränkt, Workaround existiert.
  • P4 — niedrig: kosmetisch oder Wunsch ohne Zeitdruck.

An jeder Priorität hängt ein SLA-Timer (Service Level Agreement): vereinbarte Reaktionszeit (wann meldet sich jemand) und Lösungszeit (wann ist es gelöst). Eine OLA (Operational Level Agreement) regelt dasselbe intern zwischen Teams. Aus der zugesagten Verfügbarkeitsklasse (z. B. 99,9 %) folgt direkt ein Ausfallzeit-Budget — probiere das im Visualizer aus.

PeriodeErlaubte Ausfallzeit
pro Jahr—
pro Monat—
pro Woche—
pro Tag—

Beispiel-Fall

Eingehende Meldung: „In der gesamten Buchhaltung kann seit 10 Minuten niemand mehr auf das ERP-System zugreifen. Monatsabschluss ist morgen.”

  1. Typ? Etwas funktioniert nicht → Incident (kein Request).
  2. Impact? Eine ganze Abteilung ist betroffen → hoch.
  3. Urgency? Deadline morgen, Kerngeschäft betroffen → hoch.
  4. Priorität: hoher Impact × hohe Urgency → P1 (mind. P2).
  5. SLA: P1-Reaktionszeit greift sofort — annehmen, dokumentieren, bei Lösungszeit-Überschreitung eskalieren.

So wird aus einem Anruf ein steuerbarer, messbarer Vorgang.

Anwenden

▶ Am Tool ausprobieren

Verfügbarkeitszusagen klingen abstrakt — der Rechner macht das Downtime-Budget greifbar.

  1. Wähle die Verfügbarkeitsklasse 99,9 %.
  2. Lies das erlaubte Ausfall-Budget pro Monat ab.
  3. Vergleiche mit 99,99 % — wie stark schrumpft das Budget?
Tool öffnen: /sla-rechner ↗

Selbsttest

Praxis-Challenge

⚑ Praxis-Challenge

Dein Unternehmen sagt Kunden eine Verfügbarkeit von 99,9 % zu. Bestimme im SLA-Rechner das erlaubte Ausfall-Budget pro Monat und pro Jahr. Überlege dann: Reicht dieses Budget für ein geplantes Wartungsfenster von 90 Minuten pro Monat? Begründe deine Antwort. (Tipp: 99,9 % erlaubt rund 43 Minuten pro Monat.)

Tool öffnen: /sla-rechner ↗

Modul im Speedrun testen →