Service Desk Konzept: Ticketstruktur, Priorisierung, SLA-/OLA-System

Das SLA-System ist als extern wirksames Leistungsversprechen und das OLA-System als interne Leistungs- und Übergabevereinbarung zwischen Service Desk, Fachgewerken, Bereitschaften, OEMs und Drittdienstleistern festzulegen. Jede SLA-Definition muss Start-, Pause- und Stop-Bedingungen, Servicezeitkalender, Prioritäts- und Kategorielogik, Zielzeiten, Eskalationstrigger und Reportingzuordnung enthalten. Die Zeitmessung ist systemisch, nicht manuell, zu führen. Reaktions-, Wiederherstellungs- und Lösungszeiten sind als eigenständige Messgrößen aufzusetzen.

Es sind drei Servicezeitprofile zu verwenden: 24/7-Kritikalitätsprofil für P1 sowie definierte P2-Meldungen und automatisierte kritische Alarme, erweitertes Servicezeitprofil für priorisierte Tagesbetriebsleistungen und Regelservicezeitprofil für Standardstörungen, Service Requests und administrative Vorgänge. Portal, E-Mail, API und mobile Erfassung sind technisch jederzeit verfügbar zu halten; die SLA-Zeitmessung richtet sich je Vorgangsart nach dem zugeordneten Servicezeitprofil. Außerhalb der aktiven Besetzungszeiten sind kritische Tickets über Rufbereitschaft und definierte Alarmierungswege abzuwickeln. SLA-Kalender und Schedules sind im Tool konfigurierbar vorzuhalten.

Messbeginn der Reaktionszeit ist der qualifizierte Eingang im Ticketsystem beziehungsweise der erfolgreiche Import eines Systemalarms in das führende Ticket. Messende der Reaktionszeit ist die erste qualifizierte Bearbeitung, bestehend aus Annahme, Prioritätsprüfung, Zuordnung und aktiver Rückmeldung oder Alarmierung der zuständigen Bearbeitungseinheit. Messbeginn der Wiederherstellungszeit ist identisch; Messende ist die Herstellung des vereinbarten Zielzustands, bei P1 und P2 mindestens des sicheren Betriebszustands oder einer dokumentierten Ersatzlösung. Die Lösungszeit endet erst mit fachlich dokumentierter Fertigstellung, erforderlicher Abnahme und formalem Abschluss des Tickets. Pausenzeiten sind ausschließlich für definierte Wartezustände zulässig, insbesondere Warten auf Nutzerantwort, Warten auf Auftraggeberfreigabe, Warten auf Fremdleistung oder Warten auf Material. Jede Pause ist mit Grund und Verursacher zu codieren.

Die OLA-Ziele zwischen den internen Ebenen sind prioritätsbezogen festzulegen. Für P1 gilt eine Übergabe von 1st Level an 2nd Level innerhalb von 10 Minuten und an 3rd Level beziehungsweise OEM innerhalb von 30 Minuten nach Eskalationsentscheidung. Für P2 gilt 30 Minuten beziehungsweise 2 Stunden. Für P3 und P4 gelten Übergaben innerhalb derselben Servicezeitstufe. OLA-Verfehlungen sind wie SLA-Verfehlungen auswertbar zu machen, jedoch getrennt nach interner Verursachung. Das Tool muss hierfür Ownership- und Assignment-Dauern je Team und je SLA-Fall ausweisen können.

Die Rollen sind eindeutig und ohne Überschneidung festzulegen. Der Service-Desk-Manager verantwortet Prozessdesign, Queue-Struktur, Prioritätsregeln, SLA-/OLA-Konfiguration, personelle Einsatzplanung, Reporting, kontinuierliche Datenqualität und Eskalationsgovernance. Die Service-Desk-Agents verantworten Annahme, Qualifizierung, Erstanlage, Dublettenprüfung, Priorisierung, Standardkommunikation, Standardlösungen im Rahmen des 1st Level, Disposition sowie die lückenlose Protokollierung. Der 2nd Level übernimmt fachgewerkspezifische Diagnose, Vor-Ort-Einsatz, Wiederherstellung, technische Dokumentation und Rückmeldung an den Service Desk. Der 3rd Level umfasst OEMs, Systemintegratoren, Fachfirmen und sonstige Spezialisten. Fachverantwortliche und retained Funktionen des Auftraggebers entscheiden über Freigaben, Prioritätsübersteuerungen, Betriebs- und Sicherheitsabwägungen, Major-Incident-Führung sowie Ausnahmen vom Standardprozess.

Jede Übergabe zwischen den Ebenen ist als systemische Aufgabenübergabe abzubilden. Parent-/Child-Tickets, Incident Tasks oder technische Teilaufgaben sind so zu verwenden, dass Zuständigkeiten, Zeitverbräuche und offene Restpunkte je Bearbeitungseinheit auswertbar bleiben. Werden einem Incident weitere Bearbeitungsgruppen zugeordnet, ist dies im Aufgabenmodell des Ticketsystems mit eigener Zuständigkeit, Statuslogik und Synchronisierung zum Hauptticket abzubilden. Offene Teilaufgaben dürfen beim Schließen des Haupttickets nicht bestehen bleiben.

Stufe 1 ist die operative Eskalation innerhalb des Service Desk und der unmittelbar zuständigen technischen Einheit. Stufe 2 ist die eskalierte Fach- und Leitungsebene des Auftragnehmers einschließlich Bereitschaftskoordinator und Objektleitung. Stufe 3 ist die Management- und Auftraggebereskalation einschließlich Betreiberfunktion, Sicherheitsfunktion, Produktions- oder Nutzerschnittstelle und gegebenenfalls IT-/OT-Verantwortung. Trigger für eine Eskalation sind insbesondere P1-Priorisierung, drohende SLA-Verfehlung, ungeklärte Zuständigkeit, fehlende Freigabe, fehlende Ersatzteile, wiederholte Reopens, Serien- oder Massenstörungen, Ausfall der GLT-/API-Schnittstelle, Wartezustände oberhalb des OLA-Ziels sowie jedes Ereignis mit Sicherheits- oder Betreiberpflichtenbezug. Meldungen an Eskalationsinstanzen sind telefonisch oder über definierte Alarmkanäle zu bestätigen und zusätzlich im Ticket zu protokollieren.

Der Eskalationsprozess ist im Tool mit eindeutigen Status, Zeitstempeln, Verantwortungsübergängen und Kommunikationsereignissen abzubilden. Die Timer müssen bei jeder Eskalationsstufe sichtbar bleiben; Prioritätsänderungen, Pausegründe und Eskalationsgründe sind revisionssicher zu loggen. Die fachliche Systematik orientiert sich an konfigurierbaren Workflows, Statusmodellen, Incident Tasks und SLA-Timern, wie sie in marktüblichen ITSM-Lösungen dokumentiert sind.

Jeder Übergang im Eskalationsprozess ist mit Bearbeiter, Zeitpunkt, Kommunikationskanal und Verursacher zu protokollieren. Für P1 ist zusätzlich ein strukturierter Incident-Commander- oder Major-Incident-Modus vorzusehen, in dem Statusmeldungen an definierte Empfängerkreise in verkürzten Intervallen automatisiert oder halbautomatisiert ausgelöst werden.

Die Systemlandschaft ist so auszubilden, dass Ticketannahme, Bearbeitung, Objektbezug, Alarmverarbeitung, Kosten- und Beschaffungsbezug sowie Berichtswesen medienbruchfrei zusammenwirken. Verbindliche Schnittstellen bestehen zwischen Tickettool, CAFM, GLT, ERP, E-Mail, Telefonie, Mobile App und API-Layer. Das Tickettool führt die Vorgänge, das CAFM liefert den führenden Orts-, Flächen-, Anlagen- und Servicebezug, die GLT liefert Alarm- und Eventdaten, und das ERP führt kaufmännische Aufträge, Kosten-, Material- und Beschaffungsbezüge.

Als Eingangskanäle sind mindestens Self-Service-Portal, E-Mail, Telefon und mobile Erfassung vorzusehen; Chat oder Widget können ergänzend freigegeben werden. E-Mail-Eingänge müssen automatisiert in Queues überführt werden. Portale müssen an Servicekatalog, Knowledge Base und Request-Status angebunden sein. Mobile Nutzung muss die Anlage, Statusverfolgung, Kommentar- und Bild-/Anlagenübermittlung sowie den Abruf eigener Vorgänge unterstützen. REST-APIs sind für Create, Update, Read, Search, Attachment-Handling und Event-to-Ticket-Verarbeitung bereitzustellen. Die ITSM-Plattform muss Portale und Dashboards bereitstellen und für mobile Nutzung sowie API-basierte Service- und Request-Verarbeitung ausgelegt sein.

Die CAFM-Schnittstelle hat mindestens Standort, Gebäude, Ebene, Raum, Fläche, Asset-ID, Anlagengruppe, Kritikalität, Verantwortungszuordnung, Wartungs- oder Prüfpflichtstatus sowie Vertrags- oder Servicebezug bereitzustellen. Aus dem Tickettool zurückzugeben sind mindestens Ticket-ID, offener Status, Verweis auf Folgeauftrag, Störungshistorie, Mängelklassifikation, Betreiberpflichtbezug und Abschlussstatus. Die GLT-Schnittstelle hat Alarm-ID, Alarmklasse, Datenpunkt, Zeitstempel, Quittierungsstatus, zugehörige Anlage, Trendreferenz, Grenzwertverletzung, Meldekette und gegebenenfalls Wiederkehrmuster zu übergeben. Das Tickettool hat im Gegenzug Ticket-ID, Priorität, Bearbeitungsstatus, Eskalationsstatus und Abschlussstatus zurückzumelden.

Die ERP-Schnittstelle ist auftrags- und kostenwirksam auszulegen. Technische Vorgänge mit material-, fremdleistungs- oder investivem Bezug müssen in Arbeitsaufträge, Bestellanforderungen, Bestellungen, Kostenstellen- oder Innenauftragsbezüge überführbar sein. Herstellerdokumentation aus dem ERP-Umfeld weist Maintenance Orders mit Verantwortungsdaten wie Person Responsible und Work Center sowie mit Purchasing- und Accounting-Daten wie Cost Element und Purchase Requisition Number aus; Maintenance Orders werden zur Sammlung der Kosten eines Instandhaltungsvorgangs verwendet und dem verursachenden Cost Center zugeordnet. Für den Service Desk folgt daraus, dass Ticket und ERP-Auftrag technisch mindestens über Ticket-ID, Maintenance-Order-Referenz, Work Center, Cost Center, Beschaffungsstatus und Purchase-Requisition-Referenz zu koppeln sind. Ebenso ist eine API-basierte Verarbeitung von Maintenance-Order-Details und Purchase-Requisition-Daten vorzusehen.

Telefonie ist in den Ticketprozess so einzubinden, dass eingehende Anrufe als Ticket oder Call-Log mit Zeitstempel, Anruferkennung, Gesprächsnotiz und Rückrufstatus geführt werden. Für P1 und definierte P2-Vorgänge ist eine telefonische oder gleichwertige aktive Bestätigung der Übernahme verpflichtend. API- und E-Mail-Fehler, Dubletten, nicht zuordenbare Alarme und Schnittstellenabbrüche sind als eigene überwachte Eventklasse zu behandeln und in einem technischen Integrationsdashboard auszuweisen.

Das Reporting ist dreistufig aufzubauen. Operativ sind Live-Queues, offene P1/P2-Vorgänge, at-risk-Tickets, überfällige Tickets, offene Wartezustände, Schnittstellenfehler und aktuelle Last je Assignment Group in Echtzeit oder Near Real Time darzustellen. Taktisch sind wöchentliche und monatliche Reports je Servicekategorie, Gewerk, Standort, Kanal und Verantwortungsbereich zu erzeugen. Für die Managementebene sind Monatsreport und Dashboard mit SLA-Erfüllung, Volumina, Eskalationen, Wiederholstörungen, Backlog-Alterung, 1st-Level-Lösungsquote, Übergabezeiten, Reopen-Quote, Mass-Incident-Anteilen, Datenvollständigkeit und Nutzerfeedback bereitzustellen. Herstellerdokumentation aus marktüblichen Plattformen sieht hierfür Default Reports, Custom Reports, Dashboards, SLA-Übersichten sowie KPI-basierte Auswertungen aus aktiven, gefährdeten und gebrochenen SLAs vor.

Der KPI-Katalog umfasst mindestens Ticketeingang gesamt, Ticketeingang nach Kanal, Ticketeingang nach Kategorie und Subkategorie, Reaktionszeit-Compliance, Wiederherstellungszeit-Compliance, Lösungszeit-Compliance, Anteil gebrochener SLAs, Anteil at-risk-Fälle, durchschnittliche Queuezeit, durchschnittliche Bearbeitungszeit, durchschnittliche Wartezeit je Wartegrund, 1st-Level-Fix-Rate, Weiterleitungsquote 1st/2nd/3rd Level, Reopen-Rate, Dublettenquote, Mass-Incident-Anzahl, Integrationsfehlerquote, Vollständigkeit der Pflichtfelder, Knowledge-Link-Quote im Abschluss sowie Nutzerfeedbackquote. Für OLAs sind zusätzlich Übergabezeit je Bearbeitungsebene, Fremdleistungsannahmezeit, Freigabezeit retained Organisation und Abschlussdokumentationszeit zu messen.

Der Abschlussprozess ist formal zweistufig zu führen. Zunächst wird der technische Vorgang in den Status „Gelöst“ überführt. Voraussetzung sind vollständige Tätigkeitsdokumentation, Wiederherstellungs- oder Sicherungsnachweis, Abschlusscode, Ursachen- und Maßnahmenbeschreibung, Rückmeldung an den Meldenden, Abschluss der untergeordneten Tasks und Aktualisierung der relevanten Folgebezüge in CAFM und ERP. Anschließend erfolgt der Status „Geschlossen“, sobald Abnahme, definierte Rückmeldefrist oder automatischer Abschlussmechanismus greift. Zu jedem abgeschlossenen Ticket ist, sofern fachlich sinnvoll, ein Verweis auf einen Knowledge-Base-Artikel, eine Standard Operating Procedure oder eine interne Standardlösung zu hinterlegen. Knowledge Bases dienen nach Herstellerdokumentation sowohl der Self-Service-Vermeidung unnötiger Requests als auch der schnelleren Bearbeitung durch Agenten und der Standardisierung von Antworten.

Das Tool ist mit einem belastbaren Datenmodell zu betreiben. Zentrale Objekte sind Ticket, Task, Asset, Raum/Fläche, Service, Alarm/Event, Nutzer, Organisationseinheit, SLA, OLA, Knowledge-Artikel, Anhang, Beschaffungsreferenz und Aktivitätsprotokoll. Das Rechtekonzept trennt Portalnutzer, Agents, Teamleiter, Fachbearbeiter, Administratoren, Integrationsnutzer, Auditoren und Reportingnutzer. Änderungen an Konfiguration, Integrationen, Rechten, SLAs, Queues, Request Types und Workflows sind in Audit Logs zu protokollieren; Export, Filterung und revisionsfähige Bereitstellung der Logs sind vorzusehen. Öffentliche Dokumentation marktgängiger Plattformen weist Audit Logs ausdrücklich als Instrument zur Nachverfolgung von Konfigurations- und Integrationsänderungen aus, einschließlich Filterung und Export.

Das Personalkonzept ist am Servicezeitprofil auszurichten. Für jede aktive Servicezeit ist mindestens ein leitstand- und dispositionsfähiger Service-Desk-Agent verfügbar zu halten. Für Betriebsfenster mit parallelem Eingang über Portal, E-Mail und Telefon ist eine Doppelbesetzung der Annahme vorzusehen. Für P1- und definierte P2-Vorgänge ist zusätzlich eine technische Bereitschaftsfunktion mit verbindlicher Alarmannahme, Rückmeldepflicht und Übergabefähigkeit an 2nd Level vorzuhalten. Der Schichtplan ist so aufzubauen, dass Besetzungslücken, Übergaben, Pausen, Abwesenheiten und Peaks nicht zu SLA-Verletzungen aus struktureller Unterbesetzung führen.

Die personellen Mindestqualifikationen sind rollenspezifisch festzulegen. Der Service-Desk-Manager muss Prozessverantwortung für Ticketing, SLA-/OLA-Steuerung, Queue-Management, Eskalationsführung und Reporting tragen können. Service-Desk-Agents müssen technische Grundkenntnisse der betreuten Gewerke, sichere Beherrschung des Tickettools, belastbare Kommunikationsfähigkeit und sichere Klassifikation nach Servicekatalog, Assetstruktur und Kritikalitätslogik nachweisen. Im 2nd und 3rd Level sind gewerke- und systemspezifische Fachqualifikationen und Zugangsberechtigungen nachzuweisen. Die eingesetzten Personen müssen objektspezifisch zugriffs- und kommunikationsfähig sein.

Für Sicherheits- und Datenschutzanforderungen gilt ein rollenbasiertes Least-Privilege-Modell. Portalnutzer dürfen ausschließlich eigene oder freigegebene Vorgänge sehen und kommentieren; sie erhalten keinen Zugriff auf Administrations-, Queue- oder Konfigurationsfunktionen. Agenten erhalten Bearbeitungsrechte nur in den ihnen zugewiesenen Vorgangs- und Aufgabenkreisen. Administratorrechte sind auf einen eng begrenzten Personenkreis zu beschränken und technisch von operativen Agentenrechten zu trennen. Knowledge-Base-Zugriffe sind getrennt nach Lese- und Mitwirkungsrechten zu steuern. Öffentliche Dokumentation marktgängiger Plattformen ordnet Portalzugriff, Agentenrechte, Adminrechte und Knowledge-Base-Zugriffe ausdrücklich unterschiedlichen Rollen und Kriterien zu.

Für GLT-/GA-nahe Fernzugriffe, technische Portale, mobile Nutzung und Integrationskonten gelten die Umsetzungshinweise des BSI zu technischem Gebäudemanagement und Gebäudeautomation. Fernzugriffe sind ausschließlich über freigegebene, protokollierte und abgesicherte Verfahren zulässig. Änderungen an Alarmierungsregeln, Automationsbezügen, Schnittstellenparametern, Berechtigungen und mobilen Zugriffen sind revisionssicher zu protokollieren. Für mobile Nutzung sind Rollen, Berechtigungen, sichere Authentisierung sowie Upload- und Aufgabenfunktionen kontrolliert freizugeben. Die Dokumentation des Herstellers mobiler Serviceplattformen weist zudem auf rollen- und berechtigungsbezogene Absicherung, mobile Ticketbearbeitung, Bild-/Anlagenupload und konfigurierbare mobile Oberflächen hin.

Das Datenschutzmodell hat zwischen Standardtickets und Vorgängen mit erhöhtem Schutzbedarf zu unterscheiden. Tickets mit Personenbezug, Gesundheitsbezug, Sicherheitsvorfällen, Zutrittsbezug oder sonstigen sensiblen Inhalten sind gesondert zu kennzeichnen, in Berechtigungen einzuschränken und in Reports zu pseudonymisieren oder zu aggregieren. Für Anhänge, Exporte, API-Zugriffe und Audit-Logs ist eine dokumentierte Aufbewahrungs-, Archivierungs- und Löschlogik je Datenklasse zu hinterlegen. Löschungen dürfen nur entlang einer freigegebenen Aufbewahrungsmatrix erfolgen; sicherheits-, betreiber- oder nachweisrelevante Vorgänge dürfen aus dem Produktivsystem erst nach erfolgreicher revisionssicherer Archivierung entfernt werden.

• - die konkreten Servicezeiten je Servicezeitprofil, insbesondere die exakten Uhrzeiten für Regelservicezeit, erweiterte Servicezeit und 24/7-Betrieb

• die endgültigen SLA-Zielwerte je Priorität und je Servicekategorie sowie die verbindlichen OLA-Zielwerte je Übergabestufe

• die Zuordnung, welche P2-Kategorien außerhalb der Regelservicezeit in die 24/7-Bereitschaft fallen

• der verbindliche Ticketkatalog mit allen Kategorien, Subkategorien, Abschluss- und Ursachencodes

• die endgültige Pflichtfeldmatrix je Eingangskanal, insbesondere für Portal, E-Mail, Telefon, Mobile App und API

• die vorhandenen Systeme einschließlich Hersteller, Versionen und Verantwortlichkeiten für CAFM, GLT, Monitoring, ERP, Telefonie und E-Mail

• die tatsächlich verfügbaren Schnittstellen, Protokolle, APIs, Webhooks, Authentisierungsverfahren und Exportformate

• die konkrete ERP-Objektlogik für Arbeitsaufträge, Kostenstellen, Innenaufträge, Bestellanforderungen, Bestellungen und Materialreservierungen

• die endgültigen Assignment Groups, Bereitschaftsrollen, OEM- und Fremddienstleister-Schnittstellen sowie Eskalationsempfänger

• das definitive Schichtmodell, die Mindestbesetzung je Schicht und die sprachlichen oder fachlichen Zusatzanforderungen an das Service-Desk-Personal

• die Vorgaben für Call-Logging, gegebenenfalls Gesprächsaufzeichnung und die datenschutzrechtlichen Randbedingungen hierfür

• die finalen Reportformate, Dashboard-Empfängerkreise, KPI-Grenzwerte und die Gewichtung einzelner Kennzahlen

• die verbindliche Aufbewahrungsmatrix für Tickets, Audit-Logs, Kommunikationsdaten, Anhänge und Knowledge-Base-Bezüge

• die Regeln für besondere Schutzbedarfe, etwa sicherheitsrelevante Tickets, sensible Personendaten, Besucher- oder Zutrittsinformationen

• die Anforderungen an Mandantenfähigkeit, Datenspeicherort, Exportpflichten und Abgabepakete für Mobilisierungs- und Exit-Phasen