Leistungsphase 5 der HOAI

Die Annahme von Störungen (technische Defekte, Instandsetzungsbedarf) und Servicefällen (Serviceanfragen wie z.B. Raumbuchungen, Umzüge, Benutzerwünsche) ist die erste und vielleicht wichtigste Funktion eines Servicedesks. Hier entscheidet sich, wie effektiv und schnell ein Anliegen weiterbehandelt werden kann. In der Ausführungsplanung sollte daher besonderer Wert auf die Gestaltung dieses ersten Prozessschritts gelegt werden.

• Meldewege und Erreichbarkeit: Es ist festzulegen, auf welchen Kanälen der Servicedesk erreichbar ist – z.B. telefonisch (ggf. mit spezieller Servicedesk-Nummer), per E-Mail, über ein Web-Portal oder eine mobile App. Ebenso sind die Servicezeiten zu definieren: z.B. 24/7-Bereitschaft bei kritischen Infrastrukturen oder Mo–Fr zu Geschäftszeiten in weniger kritischen Umgebungen. In LPH 5 muss geprüft werden, ob die geplante Erreichbarkeit den vertraglichen Anforderungen entspricht (z.B. Vorgaben des Auftraggebers in der Leistungsbeschreibung). Zudem sollte bereits hier eingeplant werden, wie Anrufe oder Meldungen außerhalb der Kernzeiten behandelt werden (Anrufbeantworter mit Notfallnummer, Rufbereitschaft oder automatisierte Annahme).

• Standardisierte Erfassung: Bei jedem eingehenden Stör- oder Servicefall sind alle relevanten Informationen aufzunehmen. Gemäß ITIL ist die erste Aufgabe des Service Desks, alle relevanten Details zu loggen sowie Kategorisierungs- und Priorisierungscodes zu vergeben. In der Praxis bedeutet das: Der Mitarbeiter am Servicedesk fragt systematisch alle benötigten Angaben ab. Dazu zählen typischerweise: Wer meldet (Name, Kontakt), Was ist passiert bzw. gewünscht (Beschreibung des Problems oder der Anfrage), Wo tritt es auf (Gebäude, Raum, Standort – oft via Standortkennung aus CAFM), Wann wurde es bemerkt und Wie kritisch ist es (Einschätzung der Dringlichkeit durch den Meldenden). Für Serviceanfragen kommt evtl. Bis wann (Wunschtermin) hinzu. Es empfiehlt sich, in der Planung ein Meldeformular oder einen digitalen Eingabemasken-Standard zu entwickeln, damit kein wichtiges Feld vergessen wird. Soll der Melder z.B. direkt eine Kategorie auswählen können (etwa "Heizung", "Reinigung", "IT-Problem" etc.)? Gerade bei Webportalen kann man Nutzer durch vorgegebene Formulare lenken, sodass strukturierte Tickets entstehen. In LPH 5 sollte beschrieben werden, wie dieser Erfassungsprozess gestaltet ist.

• Erstreaktion und erste Bearbeitung: Oft kann schon während der Annahme eine erste Einordnung erfolgen. Idealerweise erhält der Meldende umgehend eine Bestätigung, dass sein Anliegen registriert wurde – sei es ein automatierter E-Mail-Reply mit Ticketnummer oder ein direkter mündlicher Hinweis am Telefon ("Ich habe Ihren Fall aufgenommen, Ticket Nr. 123"). So eine Rückmeldung erhöht die Transparenz und schafft Vertrauen. Außerdem ist zu klären, welche Sofortmaßnahmen der Servicedesk gegebenenfalls ergreifen soll. Zum Beispiel: Bei einer kritischen Störung (etwa Wasserrohrbruch, kompletter Stromausfall, Gefahr für Personen) gibt es meist Notfallprotokolle – hier könnte der Servicedesk angewiesen sein, direkt die Haustechnik oder einen Bereitschaftsdienst zu alarmieren, noch bevor ein Ticket formal angelegt wird. Solche Abläufe müssen geplant und dokumentiert sein (Notfallkontakte, Eskalationsmatrix für dringende Fälle). Bei weniger zeitkritischen Fällen kann der Servicedesk dem Nutzer ggf. erste Tipps geben (z.B. "Bitte versuchen Sie inzwischen XYZ" oder Verweis auf FAQ/Wissensdatenbank, falls vorhanden).

• Unterscheidung Störmeldung vs. Service Request: Im FM-Umfeld vermischen sich diese Begriffe oft, doch es ist sinnvoll, in den Prozessen zu unterscheiden: Störungen beziehen sich auf ungeplante Vorfälle, die einen vorhandenen Zustand beeinträchtigen (etwas ist kaputt, funktioniert nicht, entspricht nicht der Soll-Beschaffenheit). Service Requests sind planbare Leistungen auf Nutzerwunsch (etwas Zusätzliches wird gewünscht, z.B. Möbel rücken, Zusatzreinigung, Schlüssel nachmachen). Warum ist die Unterscheidung wichtig? Weil sie oft unterschiedlich priorisiert und bearbeitet werden: Störungen können Dringlichkeit haben, Service Requests laufen evtl. als Aufträge mit Vorlaufzeit. Nach ITIL gehören Incidents und Service Requests zwar zu unterschiedlichen Kategorien, aber der Service Desk behandelt beide Arten von Meldungen zunächst ähnlich: Aufnahme, Dokumentation, Weiterleitung. In LPH 5 sollte festgelegt sein, ob und wie diese Differenzierung im System erfolgt (z.B. getrennte Tickettypen oder ein Feld "Vorfall vs. Anfrage").

• Kategorisierung und erste Priorisierung: Schon bei der Annahme sollte der Servicedesk nach einem vorgegebenen Schema eine Kategorisierung und Priorisierung durchführen – zumindest vorläufig. ITIL schreibt, dass jedes Ticket eine Kategorie (oder Kategorie-Schlüssel) und eine Priorität erhalten soll. Die Kategorie könnte z.B. den betroffenen Service oder Gewerk betreffen (Elektro, HKLS, Reinigung, Sicherheitstechnik, IT etc.), während die Priorität die Dringlichkeit widerspiegelt. Oft wird die Priorität aus Auswirkung (Impact) und Dringlichkeit (Urgency) hergeleitet. Ein gängiges Modell nutzt eine Impact-Urgency-Matrix, um eine Prioritätsstufe von z.B. 1 (hoch) bis 4 oder 5 (niedrig) zu bestimmen. In der Planung sollten diese Kriterien festgehalten werden: Was gilt als hoher Impact (z.B. Beeinträchtigung vieler Nutzer oder kritischer Bereich) und was als hohe Dringlichkeit (z.B. Gefahr im Verzug oder Betriebsunterbrechung)? Daraus ergibt sich z.B., dass Priorität 1 = hoher Impact + hohe Dringlichkeit (z.B. Brandmeldeanlage ausgefallen), Priorität 2 = hoher Impact + mittlere Dringlichkeit etc. – bis zu Priorität 4 = niedrig/Standard. Wichtig: Der Meldende selbst sollte die Priorität nicht allein bestimmen, außer durch die gelieferten Fakten. Laut ITIL sollte ein gut definiertes SLA und Regelwerk es ermöglichen, dass der Service Desk die Priorität sachlich festlegt. Nutzer neigen sonst dazu, jedes eigene Problem als "dringend" einzustufen. Hier kommt es auch auf die Kommunikation an (siehe unten): Nutzer*innen sollten darauf vertrauen können, dass ihre Meldung angemessen behandelt wird, ohne dass sie künstlich die Wichtigkeit erhöhen müssen. Der Service Desk-Mitarbeiter kann z.B. sagen: "Ihr Anliegen ist erfasst und wird entsprechend der vereinbarten Prioritäten bearbeitet. Wir kümmern uns schnellstmöglich darum."

• Erfassung im Ticketsystem: Die gesammelten Informationen werden im Ticketsystem (Software) erfasst. In LPH 5 sollte die Auswahl oder Spezifikation dieses Systems erfolgen: Ob ein dediziertes CAFM-Modul, ein Helpdesk-Tool oder eine Eigenentwicklung – entscheidend ist, dass es die erforderlichen Felder und Funktionen bereitstellt. Die Planer müssen definieren, welche Datenfelder ein Ticket hat (siehe oben) und ob Pflichtfelder vorgesehen sind (z.B. keine Ticketanlage ohne Angabe des Standorts). Auch sollten gleich in der Ausführungsplanung Überlegungen zur Benennung/Kodierung von Tickets einfließen (Ticketnummern, Kategorienamen etc.), da diese später für Auswertungen relevant sind.

Nach der initialen Annahme und Aufnahme aller Informationen wird das Ticket in den weiteren Workflow übergeben.

Unter Ticketmanagement versteht man die organisierte Verwaltung eines Vorgangs vom Moment der Erfassung (durch den Servicedesk) bis zum Abschluss (Lösung und Schließen des Tickets). Während im vorherigen Kapitel der Fokus auf der initialen Annahme lag, geht es nun um den Prozess, der folgt: Die Weiterbearbeitung des Tickets, die Koordination von Maßnahmen und das Monitoring des Fortschritts. In LPH 5 der Planung sind diese Abläufe detailliert zu beschreiben, um sicherzustellen, dass kein Ticket "verloren geht" und jeder Fall transparent nachverfolgt werden kann.

• Zuweisung (Dispatching): Sobald ein Ticket im System erfasst und kategorisiert ist, muss entschieden werden, wer die Bearbeitung übernimmt. In vielen Fällen fungiert der Servicedesk nur als Erstannahme (First Level) und leitet das Ticket dann an einen zuständigen Fachbereich oder Dienstleister weiter (Second Level oder Third Level). Die Planung sollte festhalten, welche Eskalationspfade es gibt: z.B. interne technische Abteilung, externes Wartungsunternehmen, Spezialist für bestimmte Anlagen, Hausmeisterdienst, etc. Hierbei sind Schnittstellen intern/extern zu beachten: Ist im CAFM-System oder Ticketing-Tool hinterlegt, welcher Ansprechpartner für eine bestimmte Kategorie zuständig ist (z.B. Kategorie "Aufzug" -> Servicefirma XY)? Im Optimalfall erfolgt die Zuweisung automatisch anhand vordefinierter Regeln (z.B. basierend auf der Kategorie oder Örtlichkeit). Falls die Zuweisung manuell durch den Service Desk Agent erfolgt, braucht dieser klare Richtlinien: etwa eine hinterlegte Matrizen oder Kontaktlisten, wer bei welcher Art von Problem informiert wird. In LPH 5 sollte eine RACI-Matrix (Responsible, Accountable, Consulted, Informed) oder ähnliche Darstellung entwickelt werden, um Verantwortlichkeiten je Ticketart aufzuzeigen. In einer Leistungsbeschreibung wird oft gefordert, dass "der Auftragnehmer sicherstellt, dass Meldungen unverzüglich an die zuständige Einheit weitergeleitet werden". Hier muss der Plan die organisatorische Struktur mitdenken.

• Bearbeitungsprozess & Statusverfolgung: Jedes Ticket durchläuft Status wie Offen, In Bearbeitung, Wartet auf Rückmeldung, Erledigt etc. In der Planung muss definiert sein, welche Statuswerte es gibt und wie der Workflow aussieht. Z.B.: Nach Zuweisung auf "In Bearbeitung" setzen; wenn Techniker vor Ort war und Rückmeldung gegeben hat, auf "Warten auf Bestätigung" (ggf. durch den Nutzer) setzen; anschließend Abschluss = "Geschlossen". Wichtig ist, dass der Ticketstatus jederzeit transparent ist, sowohl für die Servicedesk-Mitarbeiter als auch – wo sinnvoll – für die Endnutzer (z.B. über ein Web-Portal können Nutzer ihren Ticketstatus einsehen). In der Ausführungsplanung sollte auch festgelegt werden, ob es SLAs gibt, die an Ticketstatus geknüpft sind (z.B. Reaktionszeit = Zeit bis Status "In Bearbeitung"; Lösungszeit = Zeit bis Status "Erledigt"). Das System sollte idealerweise automatisch anzeigen, wenn ein Ticket eine Frist überschreitet oder eskaliert werden muss (dazu mehr im Kapitel Klassifikation und Eskalation).

• Kommunikation während der Bearbeitung: Teil des Ticketmanagements ist die laufende Kommunikation zwischen allen Beteiligten – Servicedesk, Bearbeiter (z.B. Techniker), ggf. externer Dienstleister und natürlich der meldenden Person. Das Servicedesk-System sollte ermöglichen, dass Notizen, Fortschrittsupdates und Rückfragen im Ticket dokumentiert werden. In der Planung sollte vorgesehen sein, wie diese Kommunikation abläuft: Wird der Nutzer proaktiv informiert, wenn sich der Status ändert (z.B. E-Mail: "Ihr Ticket #123 wurde einem Techniker zugewiesen")? Wer kommuniziert mit dem Nutzer – weiterhin der Service Desk (als Single Point of Contact) oder direkt der Techniker? Best Practice ist meist, dass der Service Desk zentraler Ansprechpartner bleibt, um Konsistenz zu wahren. D.h., Techniker geben ihre Updates ins System und der Service Desk leitet sie an den Nutzer weiter bzw. das System sendet automatisierte Updates. Diese Abläufe sollten im Prozessehandbuch klar definiert werden.

• Nachverfolgung und Erinnerung: Ein gutes Ticketmanagement sorgt dafür, dass kein Vorgang liegen bleibt. Geplante Kontrollpunkte (intern "Tickler" oder Reminder) sind hilfreich. Zum Beispiel kann ein Workflow vorsehen, dass der Servicedesk jeden Morgen die offenen Tickets prüft und z.B. bei Tickets, die seit X Tagen ohne Update sind, nachhakt. Moderne Systeme erlauben automatische Reminder oder Eskalationen, wenn ein Ticket zu lange in einem Status verweilt. In LPH 5 sollte man definieren, nach welchen Regeln das geschieht (z.B. nach 3 Tagen ohne Bearbeiter-Zuweisung Alarm an Teamleiter).

• Teilschritte / Aufgabenmanagement: Bei komplexeren Tickets (z.B. ein Umzugsprojekt mit mehreren Teilaufgaben) sollte überlegt werden, ob das Ticketsystem Teilaufgaben abbilden kann. Ein Beispiel: Ein Nutzer meldet "Büroumzug von Raum A nach B". Daraus entstehen Aufgaben für IT (PC umziehen), für Möbelpacker, für Zugangskarten-Team etc. Entweder man erstellt verknüpfte Tickets pro Aufgabe oder man nutzt ein System, das Unteraufgaben im Ticket managen kann. In der Planung sollte festgelegt sein, wie solche Fälle gehandhabt werden, damit nichts vergessen wird. Falls das Ticketsystem diese Tiefe nicht abbildet, muss der Servicedesk in solchen Fällen vielleicht manuell koordinieren.

• Dokumentation der Lösung und Abschluss: Ist das Problem behoben oder der Service erbracht, muss der Bearbeiter dem Servicedesk eine Rückmeldung geben (Details dazu im Kapitel Rückmeldung von Maßnahmen). Der Servicedesk oder das System setzt das Ticket dann auf Erledigt/Gelöst. Bevor endgültig geschlossen wird, kann – je nach Prozess – noch eine Qualitätskontrolle erfolgen: Etwa ruft der Service Desk beim Meldenden an oder schickt eine E-Mail, um zu bestätigen, dass das Problem tatsächlich behoben und der Kunde zufrieden ist. Erst dann wird das Ticket geschlossen. In der Planung sollte festgelegt sein, ob solche Abschluss-Bestätigungen vorgesehen sind. Häufig wird auch definiert, dass ein Ticket nach einer bestimmten Zeit automatisch geschlossen wird, wenn der Nutzer nicht reagiert (z.B. "wird automatisch nach 5 Werktagen geschlossen, sofern keine weitere Beschwerde eingeht").

• Wiedereröffnung und Verknüpfungen: Es sollte geregelt sein, was passiert, wenn eine angeblich behobene Störung wieder auftritt oder doch nicht gelöst ist. Darf der Nutzer das Ticket wieder öffnen (Reopen) oder wird ein neues Ticket erstellt? Oft erlauben Helpdesk-Systeme ein Reopen innerhalb eines bestimmten Zeitraums. Ebenso sollte das System Verknüpfungen erlauben – z.B. wenn mehrere Meldungen die gleiche Ursache haben (Netzwerkausfall führt zu 10 Tickets), können diese verlinkt werden oder als Duplikate markiert werden. In der Planung sollte die Strategie für solche Situationen beschrieben sein, damit konsistent verfahren wird.

Rollen im Ticketmanagement: Meist gibt es einen Service Desk Agent (First Level, erfasst und löst einfache Dinge sofort), einen Sachbearbeiter/Techniker (Second Level, bekommt Tickets zugewiesen) und eventuell Spezialisten oder Dienstleister (Third Level). Darüber hinaus kann ein Service Manager oder FM-Leiter im Prozess involviert sein, der z.B. Eskalationen entgegen nimmt oder Berichte erhält. Diese Rollen und ihre Befugnisse (z.B. wer darf ein Ticket schließen? Wer darf Prioritäten ändern?) sollten in der Ausführungsplanung klar dokumentiert sein.

Die Implementierung all dieser Ticketmanagement-Aspekte muss natürlich vom eingesetzten System unterstützt werden. Daher ist die Auswahl der Software bzw. deren Konfiguration ein wesentlicher Bestandteil der Planung. Ein System, das z.B. keine unterschiedlichen Ticketstatus zulässt oder keine automatischen Eskalationen, würde den geplanten Prozess einschränken – hier muss das Planungsteam Softwareanforderungen definieren, die den beschriebenen Prozess ermöglichen.

Die Klassifikation von Tickets (Einordnung nach bestimmten Kriterien) und die Eskalation (kontrolliertes Weiterleiten an höhere Ebenen bei Bedarf) sind eng mit dem Ticketmanagement verknüpft, verdienen aber besondere Betrachtung. In LPH 5 sollten klare Richtlinien geschaffen werden, wie jedes Ticket eingeordnet wird und wann welche Eskalationsmaßnahmen greifen. Das Ziel ist, jedem Vorgang die richtige Priorität und Aufmerksamkeit zukommen zu lassen und vereinbarte Service Levels einzuhalten.

Wie bereits bei der Annahme erwähnt, wird jedem Ticket eine Kategorie und eine Priorität zugeordnet.

• Kategorienbaum: Eine hierarchische Liste von Kategorien kann helfen, Tickets statistisch auszuwerten und an die richtigen Experten zu routen. Beispielsweise könnte der Kategorienbaum im FM so aussehen: Technik > Elektro > Beleuchtung oder Infrastruktur > Reinigung > Sonderreinigung, etc. Es ist sinnvoll, sich an bestehenden Normen zu orientieren, z.B. an einem standardisierten Leistungskatalog (viele FM-Ausschreibungen nutzen Kataloge wie GEFMA 200 oder eigene Code-Systeme). In LPH 5 sollten diese Kategorien abgestimmt werden – am besten in Abstimmung mit den zukünftigen Servicedesk-Betreibern und technischen Leitern, damit die Kategorien praxisnah sind. ITIL selbst schreibt keine spezielle Kategorisierung vor und überlässt das der Organisation, aber empfiehlt es für Auswertungen und Problemmanagement. Wichtig ist: Nicht zu grob (sonst wenig Aussagekraft) und nicht zu fein (sonst unübersichtlich und aufwändig). Ein Ansatz: maximal 3 Ebenen und insgesamt vielleicht 20–30 Hauptkategorien. ISO 20000 fordert zumindest, dass Kategorien festgelegt und konsistent genutzt werden, um später Analysen (z.B. welche Art von Störung tritt am häufigsten auf) zu ermöglichen.

• Prioritäten und Dringlichkeit: Die Priorität steuert maßgeblich die Reaktions- und Lösungszeiten. Daher muss für jede Prioritätsstufe definiert werden, welche zeitlichen Vorgaben gelten (z.B. Priorität 1: Reaktion in 1h, Lösung in 4h; Priorität 2: Reaktion 4h, Lösung 24h; etc.). Diese Vorgaben sollten im Service Level Agreement (SLA) oder im Leistungsverzeichnis festgeschrieben sein. In LPH 5 ist dafür zu sorgen, dass diese SLA-Zeiten mit den Prioritäten im System verknüpft werden können. ITIL empfiehlt, Priorität als Ergebnis aus Impact/Urgency zu bestimmen, wie zuvor beschrieben. Es ist außerdem gängig, eine begrenzte Anzahl von Prioritätsstufen (4 bis 5) zu verwenden, um Klarheit zu behalten. Die Planer sollten Beispiel-Szenarien definieren, was typisch Priorität 1 ist (z.B. akute Gefährdung, Betriebsstillstand), Priorität 2 (wichtige Einschränkung, aber kein Sicherheitsrisiko), usw. – das hilft den Service-Mitarbeitern später bei der Einstufung. Auch sollte mit dem Auftraggeber abgestimmt sein, wie viele höchste Priorität Fälle realistisch angenommen werden (damit nicht alles Priorität 1 bekommt).

• Auswirkungen falscher Klassifikation: In Schulungen und im Qualitätsmanagement muss darauf geachtet werden, dass Tickets weder über- noch unterbewertet werden. Ein zu niedrig priorisiertes Ticket könnte zu Verzug und Unzufriedenheit führen, ein zu hoch priorisiertes blockiert evtl. Ressourcen unnötig. Deshalb sollten im Plan Qualitätssicherungsmaßnahmen beschrieben sein (z.B. stichprobenartige Überprüfung der Klassifikationen durch den Servicemanager).

• Funktionale Eskalation: Damit ist das Weitergeben eines Tickets an die nächste fachliche Ebene gemeint, wenn die aktuelle Ebene nicht weiterkommt. Beispiel: Der First-Level (Servicedesk-Agent) kann das Problem nicht selbst lösen -> Weiterleitung an Second-Level-Techniker; dieser evtl. weiter an eine externe Fachfirma oder Hersteller (Third Level). Diese Eskalationskette sollte in LPH 5 für alle relevanten Tickettypen festgelegt sein. Wer sind die Second Level Einheiten pro Kategorie? Wann wird extern eingeschaltet? Gibt es z.B. fest beauftragte Nachunternehmer für bestimmte Gewerke (die über das Ticketsystem informiert werden)? Die Planung sollte vorsehen, dass das Ticketsystem solche Eskalationen unterstützt, z.B. durch Zuweisung an andere Teams oder durch Schnittstellen (etwa automatische E-Mail an externen Dienstleister mit Ticketdetails).

• Hierarchische Eskalation: Das meint das Einschalten höherer Management-Ebenen, wenn bestimmte Kriterien erfüllt sind – häufig wenn SLAs verletzt zu werden drohen oder besondere Aufmerksamkeit nötig ist. Beispielsweise: Wenn ein Priorität-1-Ticket nach 2 Stunden noch nicht gelöst ist, bekommt der Serviceleiter eine Benachrichtigung (Management Attention). Oder wenn ein VIP-Nutzer betroffen ist (z.B. Geschäftsführung), kann man eine Eskalation an den Key Account Manager vorsehen. In der Planung sollte definiert werden, welche Eskalationsstufen es gibt und wer die jeweiligen Eskalationsempfänger sind (z.B. Teamleiter, Abteilungsleiter, GF). Diese hierarchischen Eskalationen sind wichtig, um Problemen, die aus dem Ruder laufen, entgegenzuwirken. ITIL sieht vor, dass man SLA-Eskalationen einrichtet – d.h. bei drohendem SLA-Bruch gibt es Alerts. In LPH 5 muss man daher sicherstellen, dass das gewählte System entsprechende SLA-Monitoring-Funktionen hat und Eskalationsprozesse (Benachrichtigungen) implementiert werden können.

• Eskalationsmatrix: Es bietet sich an, eine Tabelle oder Grafik zu erstellen, die für verschiedene Kombinationen von Priorität + verstrichene Zeit bzw. Ticketkategorie + Kritikalität die Eskalationsschritte zeigt. Beispiel: Priorität 1: sofort Techniker alarmieren (functional); nach 1h ungelöst -> hierarchische Eskalation an FM-Leiter; nach 2h -> an Bereichsleiter etc. Priorität 2: nach 4h ohne Reaktion -> funktional an Backup-Techniker oder anderes Team; nach 8h -> hierarchisch an Teamleiter, etc. Diese Matrix sollte Bestandteil der Ausführungsplanung sein, damit später alle Beteiligten nach dem gleichen Schema handeln.

• VIP-Handling: Oft gibt es besondere Eskalationsregeln für bestimmte Personengruppen (Geschäftsführung, wichtige Kunden/Mieter). In der Planung sollte erörtert werden, ob solche VIP-Regeln gelten sollen. Laut einer ITIL-Empfehlung kann man VIP-Tickets zwar bevorzugt behandeln, aber man muss aufpassen, dass es nicht die generelle Priorisierungslogik aushebelt. Ein pragmatischer Ansatz: Ressourcen flexibel einsetzen, um VIP-Wünsche zu erfüllen, aber solche Fälle im nächsten SLA-Meeting offen ansprechen, um keinen Dauerzustand daraus zu machen. In der Checkliste/Leistungsbeschreibung kann das z.B. als "besondere Kundenanfragen sind in Absprache prioritär zu behandeln, ohne jedoch den übrigen Betrieb zu gefährden" formuliert sein.

Werkzeuge der Eskalation: In vielen Ticketsystemen kann man Eskalationen als Regeln hinterlegen, die z.B. automatisch E-Mails versenden oder Tickets an eine Eskalationswarteschlange übergeben. Die Planer sollten definieren, welche automatischen Eskalationsfunktionen genutzt werden und welche manuell angestoßen werden. Zum Beispiel: "Beim Überschreiten von 80% der SLA-Zeit -> automatischer Reminder an Bearbeiter; bei 100% SLA-Zeit überschritten -> Ticket wird an Service Manager weitergeleitet."

Auch Kommunikation bei Eskalation ist ein Thema: Wenn ein Fall eskaliert wird, sollte der Nutzer informiert werden ("Ihr Anliegen wurde an den leitenden Techniker/Service Manager weitergegeben und hat höchste Priorität"), damit er weiß, dass man dran ist.

Schließlich muss der Eskalationsprozess auch mit dem Vertrag übereinstimmen – oft gibt es Vertragsstrafen bei SLA-Verletzungen, daher ist es im Interesse des FM-Dienstleisters, früh zu eskalieren, um das Problem noch zu lösen. In der Leistungsbeschreibung können Eskalationswege sogar eingefordert sein.

Ein entscheidender Erfolgsfaktor des Servicedesks ist die Kommunikation – sowohl mit den meldenden Nutzer*innen, als auch intern zwischen Servicepersonal, Technikern und ggf. externen Dienstleistern. Offene, transparente und serviceorientierte Kommunikation erhöht die Zufriedenheit der Kunden erheblich. In LPH 5 gilt es, Kommunikationswege und -regeln festzulegen, die in den Prozessen verankert werden.

• Erreichbarkeit und Freundlichkeit: Der Servicedesk ist die "Visitenkarte" des Facility Managements gegenüber den Nutzern. Daher sollte schon in der Planung betont werden, dass Servicedesk-Mitarbeiter nicht nur fachlich, sondern auch kommunikativ geschult sein müssen. Aspekte wie Freundlichkeit, Verbindlichkeit, klare Ausdrucksweise sollten in Schulungskonzepten vorgesehen sein. Man kann z.B. Standard-Begrüßungsformeln (Telefon) und E-Mail-Vorlagen (für Bestätigungen, Zwischenmitteilungen, Abschlussmeldungen) definieren, um Konsistenz zu gewährleisten.

• Transparenz über den Status: Nutzer*innen wollen wissen, was mit ihrer Meldung passiert. Ohne ein gutes Incident Management fühlen sich Endanwender schnell im Unklaren gelassen – fehlende Transparenz über den Ticketstatus und die voraussichtliche Bearbeitungszeit ist eine häufige Beschwerde. Daher sollte der Prozess vorsehen, dass wichtige Statusänderungen proaktiv mitgeteilt werden. Zum Beispiel: Eingang bestätigen (sofort), Techniker zugewiesen (Information: "Ihr Anliegen wird bis [Datum] bearbeitet."), Verzögerungen kommunizieren ("Es dauert länger, weil..."), Abschluss mitteilen ("Ihr Problem wurde gelöst. Bitte prüfen Sie..."). Diese Kommunikation kann teils automatisiert erfolgen (durch das Ticketsystem), sollte aber inhaltlich in der Planung vorbereitet sein (Vorlagentexte etc.). Gerade im Deutschen kommt es gut an, wenn Mitteilungen höflich und präzise sind und keine Fachchinesisch enthalten. In LPH 5 kann man einen Kommunikationsplan entwerfen, der festlegt: wer informiert wann wen über was.

• Feedbackkultur und Rückfragen: Der Servicedesk sollte als Lotse für den Nutzer agieren. Das heißt, wenn der Nutzer nach einer Meldung rückfragen hat ("Wann kommt denn der Techniker?" – solche Fragen werden erfahrungsgemäß kommen), sollte klar sein, wer antwortet. In der Regel bleibt das der Servicedesk. Die Servicedesk-Mitarbeiter benötigen hierfür Einblick in den aktuellen Stand der Bearbeitung und ggf. Prognosen. In der Planung muss also auch sichergestellt sein, dass sie Zugriff auf die Informationen haben, die sie den Nutzern mitteilen sollen (z.B. wenn ein externer Dienstleister beauftragt wurde, muss dieser Rückmeldung geben, wann er kommt). Ein Prozesspunkt könnte sein: "Servicedesk holt 1 Tag vor Ablauf der SLA ein Update vom Bearbeiter ein, um den Kunden ggf. vorab zu informieren."

• Umgang mit schwierigen Situationen: Nicht jede Kommunikation verläuft reibungslos. Nutzer könnten verärgert anrufen, weil eine Störung zu lange dauert. Hierauf sollten Servicedesk-Mitarbeiter vorbereitet sein. In LPH 5 können solche Szenarien in den Schulungsplan aufgenommen werden (z.B. Training für Deeskalation am Telefon). Auch sollte der Prozess vorsehen, ab wann ein verärgerter Kunde an eine Führungskraft weitergereicht wird. (Beispiel: Nutzer verlangt, mit dem Vorgesetzten zu sprechen -> der Servicedesk sollte wissen, an wen er verweisen darf). Für die schriftliche Kommunikation gilt: Bei Beschwerden oder Eskalations-E-Mails sollte es Vorlagen geben, wie man sich entschuldigt und Lösungen in Aussicht stellt.

• Mehrsprachigkeit: In internationalen Unternehmen oder Objekten mit internationalen Mietern kann es erforderlich sein, den Servicedesk mehrsprachig auszulegen (mindestens Deutsch/Englisch). Falls dies relevant ist, muss in LPH 5 geklärt werden, wie das sichergestellt wird (mehrsprachige Mitarbeiter oder Übersetzungsdienst, zumindest Übersetzung von Standardkommunikationen). Auch das Ticketsystem sollte Unicode unterstützen und evtl. zweisprachige Benachrichtigungen ermöglichen.

• Nutzerportal/Self-Service: Immer häufiger werden Portallösungen eingesetzt, wo Nutzer selbst den Status einsehen oder kleine Anliegen eigenständig lösen können (z.B. FAQs, Wissensartikel). Sollte ein Self-Service-Portal geplant sein, gehört dessen Ausgestaltung auch zur Kommunikation. In LPH 5 müsste man definieren: Welche Informationen sieht der Nutzer im Portal? Kann er Kommentare hinzufügen? Sieht er alle eigenen Tickets und deren Status? Ein Portal entlastet den Servicedesk, aber nur, wenn es aktuell gehalten wird und benutzerfreundlich ist.

• Rückmeldung nach Lösung (Kundenzufriedenheit): Ein wichtiger letzter Schritt in der Kommunikation ist das Einholen von Feedback. Viele Servicedesks versenden nach Ticketabschluss eine kurze Zufriedenheitsabfrage ("Wie zufrieden waren Sie mit der Bearbeitung? [Sternchen-Bewertung oder Freitext]"). In der Ausführungsplanung sollte geprüft werden, ob und wie so ein Feedbackprozess implementiert werden soll. ISO 9001 würde ein solches Kundenfeedback begrüßen, da es direkt Input für Verbesserungen liefert. Allerdings muss man auch die Akzeptanz bedenken (zu häufige Surveys könnten ignoriert werden). Dennoch: Im Konzept sollte festgehalten sein, ob z.B. quartalsweise eine Umfrage an alle Nutzer geht oder stichprobenartig Tickets nachverfolgt werden.

• Kommunikation innerhalb des Serviceteams: Nicht zu vergessen ist die interne Kommunikation. Wenn z.B. eine Schichtübergabe im Servicedesk stattfindet (Agent A übergibt an Agent B), muss klar sein, wie laufende Tickets übergeben werden – idealerweise natürlich über das System (alle Infos im Ticket), aber ggf. auch mündlich für kritische Fälle. In der Planung kann es hierzu Hinweise geben ("Tägliches kurzes Team-Meeting zur Durchsprache aller offenen High-Priority Fälle" o.ä.).

Eine transparente Kommunikation zahlt sich aus: Die Nutzer fühlen sich ernst genommen, auch wenn etwas mal länger dauert, solange sie informiert bleiben. Umgekehrt gilt: Keine Nachricht ist die schlechteste Nachricht – dann laufen Nutzer eher zur Leitung und beschweren sich. Das Warten auf Rückmeldung ohne Info führt zu Frustration. Deswegen sollte der Plan diese weichen Faktoren nicht vernachlässigen.

Eine lückenlose und strukturierte Dokumentation ist das Rückgrat eines jeden Servicedesks. Sie ermöglicht erst die Nachvollziehbarkeit von Vorgängen, die Auswertung von Häufigkeiten und die Grundlage für Qualitätsmanagement und Audits. In der Ausführungsplanung müssen deshalb konkrete Festlegungen zur Dokumentation getroffen werden: Was wird wo und wie lange dokumentiert, und wie wird die Qualität der Dokumentation sichergestellt?

• Ticketinhalte und Verlaufsdokumentation: Jedes Ticket sollte eine vollständige Historie enthalten – von der Erstanfrage über alle Bearbeitungsschritte bis zum Abschluss. In LPH 5 ist sicherzustellen, dass das gewählte Ticketsystem jede Aktion am Ticket protokolliert (Änderungen des Status, Zuweisungen, Kommentare, E-Mails, Zeitstempel). Es sollte klar definiert sein, welche Informationen mindestens erfasst werden müssen. Z.B.: Problembeschreibung, Kategorie/Priorität, Verantwortlicher Bearbeiter, Lösungsschritte/Maßnahmen, Ursache (falls ermittelt), Zeitaufwand, Kosten (falls relevant) und Abschlusskommentar. Eine gute Praxis ist, am Ende eines Tickets einen Lösungs-Eintrag zu verfassen, der zusammenfasst: Ursache und was wurde getan, um das Problem zu lösen. Diese strukturierten Abschlussnotizen können später für Wissensmanagement genutzt werden.

• Wissensdatenbank und Wiederverwendbarkeit: Dokumentation dient nicht nur dem einzelnen Vorgang, sondern auch dem Aufbau von Wissensbasis. Wiederkehrende Störungen können schneller behoben werden, wenn aus früheren Fällen gelernt wurde. Daher sollte in der Planung berücksichtigt werden, ein Knowledge Base-Modul zu nutzen, oder zumindest eine Kategorisierung von Lösungen (z.B. Markierung "Known Error"/"Workaround vorhanden"). Gemäß ITIL unterstützt eine gute Ticket-Dokumentation auch das Problem Management und Management-Entscheidungen. Beispielsweise: Wenn in Tickets dokumentiert wird, dass eine temporäre Lösung gefunden wurde, kann das Problemmanagement daraus einen Dauerlösungsauftrag ableiten. In LPH 5 sollten Mechanismen vorgesehen werden, wie aus Ticketinformationen Wissenseinträge werden können. Evtl. definiert man, dass nach X gelösten Tickets zu einer neuen Art, ein FAQ-Artikel erstellt wird.

• Dokumentation von Maßnahmen und Ergebnissen: Im Ticket sollte nicht nur das Problem, sondern auch die Maßnahmen dokumentiert sein: Was hat der Techniker vor Ort gemacht? Welches Ersatzteil wurde getauscht? War der Versuch erfolgreich? Hierbei muss mit den Bearbeitern (Technikern) abgestimmt werden, dass sie ausreichend Rückmeldung geben. Evtl. gehört in die Leistungsbeschreibung des Technik-Dienstleisters die Verpflichtung, nach Einsatz eine Einsatzdokumentation an den Servicedesk zu liefern (ggf. mittels mobiler App direkt ins Ticket). Diese Berichte sollten in Klarschrift für den Kunden verständlich sein (also nicht nur "Anl. geprüft, i.O.").

• Anlagen und Fotos: Oft ist es hilfreich, Bilder oder Dateien an Tickets zu hängen (z.B. Foto des Schadens, Scan eines Formulars, Messwerte). Das System sollte das ermöglichen. In der Ausführungsplanung sollte geregelt sein, wie mit solchen Anlagen verfahren wird, insbesondere im Hinblick auf Speicher und Datenschutz (z.B. keine sensiblen Dokumente unverschlüsselt anhängen). Man sollte definieren, ob gewisse Dokumente Pflicht sind: z.B. Wartungsprotokoll anhängen bei bestimmten Tickets (insofern der Service Desk solche administrativen Aufgaben mit abwickelt).

• Protokollierung von Entscheidungen: Wenn im Verlauf eines Tickets Entscheidungen getroffen werden (z.B. Abbruch, weil unwirtschaftlich; oder Kulanzentscheidung dem Nutzer gegenüber), sollte das vermerkt werden, inkl. wer autorisiert hat. In Audits (z.B. ISO 9001 oder interne Revisionsprüfungen) wird oft geschaut, ob die Prozesse eingehalten wurden. Gut dokumentierte Tickets mit klaren Freigabevermerken können hier enorm hilfreich sein.

• Aufbewahrungsfristen und Archivierung: Dokumentation erzeugt Daten, und diese müssen auch unter DSGVO-Aspekten irgendwann gelöscht werden. In LPH 5 ist ein Konzept vorzusehen, wie lange Tickets aufbewahrt werden (z.B. X Jahre digital, dann Archiv, dann Löschung). Manche Branchen erfordern längere Aufbewahrung (z.B. im Gesundheitswesen). Hier sollte man rechtliche Anforderungen (Verjährungsfristen etc.) prüfen. DSGVO fordert, Daten nicht länger als nötig zu speichern. Ein Vorgehen kann sein: Tickets werden 2 Jahre nach Schließen anonymisiert, sodass sie für Statistik erhalten bleiben, aber keine Personenbezüge mehr haben. Die Planung sollte solche Punkte ansprechen und eine Archivierungsstrategie definieren, möglichst auch technisch (unterstützt das System eine Lösch/anonymisierungs-Funktion?).

• Qualität der Dokumentation sicherstellen: Oft hängt die Qualität an den Menschen, die Tickets bearbeiten. Um sicherzustellen, dass Dokumentation konsistent ist, helfen Richtlinien und Schulungen. In LPH 5 sollte man Dokumentationsrichtlinien erstellen (z.B. "Beschreibung so, dass ein Dritter es versteht", "keine Schuldzuweisungen ins Ticket schreiben, da Kunden das evtl. lesen", "einheitliche Begriffe verwenden" etc.). Möglicherweise macht es Sinn, ein paar Datenfelder mit Auswahllisten zu erzwingen – z.B. "Störungsursache" aus einer Dropdown-Liste (Menschliches Versagen, Verschleiß, Softwarefehler etc.), um später Auswertungen zu erleichtern. Weiterhin kann man interne Audits planen, bei denen stichprobenartig Tickets geprüft werden, ob sie vollständig dokumentiert sind.

• Verknüpfung mit anderen Dokumenten: Der Servicedesk ist oft die Drehscheibe, aber es gibt Randprozesse. Beispiel: Aus einem Ticket "Licht defekt" wird eine interne Bestellung einer neuen Lampe ausgelöst, welche im ERP läuft. Idealerweise notiert man im Ticket die Bestellnummer aus dem ERP zur Nachverfolgung. Oder umgekehrt, wenn im ERP eine Wartung durchgeführt wurde, erzeugt man ein Ticket zur Info. Diese Schnittstellen zu anderen Dokumentationssystemen (ERP, CAFM Wartungsplan, Prüfprotokolle) sollten mitbedacht werden. In LPH 5 wäre zu definieren, welche Systeme Daten mit dem Ticketsystem austauschen (Thema Schnittstellen, nächstes Kapitel) und welche Daten redundant erfasst oder verlinkt werden. Vielleicht wird man definieren: Das Ticket verweist auf das Prüfprotokoll im DMS und umgekehrt.

• Reporting und Kennzahlen (Überleitung zu Auswertung): Die Dokumentation aller Tickets schafft die Basis für Reports. Daher ist sicherzustellen, dass alle Felder, die man später auswerten will, auch konsequent gepflegt werden. Das Planungsdokument sollte aufzählen, welche Kennzahlen erhoben werden sollen (z.B. Anzahl Tickets pro Monat, Durchschnittliche Lösungszeit pro Priorität, häufigste Störungsursachen etc.) – und überprüfen, ob diese Kennzahlen aus der vorhandenen Datenstruktur überhaupt generierbar sind. Das führt direkt zum nächsten Kapitel Qualitätssicherung und Auswertbarkeit, wo wir auf KPIs und Reporting eingehen.

Heutige Servicedesk-Prozesse sind selten isoliert – sie stehen in Verbindung mit anderen IT-Systemen, insbesondere im Facility Management. In LPH 5 ist zu planen, wie der Servicedesk in die Systemlandschaft integriert wird, um Medienbrüche zu vermeiden und Daten effizient zu nutzen.

• CAFM (Computer Aided Facility Management): Ein CAFM-System verwaltet Gebäudedaten, Anlagen, Wartungspläne, Raumbücher usw. Oft bringen CAFM-Lösungen ein integriertes Störmeldemodul mit. Es gibt zwei Herangehensweisen: Entweder dient das CAFM-System selbst als Ticketsystem (dann ist Integration "intern" und gegeben) oder der Servicedesk nutzt ein separates Helpdesk-Tool, welches mit dem CAFM kommunizieren muss. Die Entscheidung sollte in LPH 5 fallen. Ein Vorteil der Integration ins CAFM: Die Störungsmeldung kann direkt mit Objektdaten verknüpft werden – z.B. der Melder wählt den betroffenen Raum oder die Anlage aus einer Liste der CAFM-Datenbank aus. Dadurch weiß der Techniker sofort, um welches Gerät es geht, welche Historie es hat, wo es genau ist. Die GEFMA 444 zertifizierten CAFM-Systeme haben meist Module für Helpdesk/Störmanagement, die solche Verknüpfungen erlauben. Ist ein separates System im Einsatz, sollte eine Schnittstelle geplant werden, z.B. um Anlage-Stammdaten aus dem CAFM ins Ticketsystem zu synchronisieren oder umgekehrt Ticket-IDs im CAFM zu referenzieren. Auch Rauminformationen und Nutzerstammdaten (z.B. welches Büro gehört zu welchem Nutzer) können aus dem CAFM/HR-System gezogen werden, um dem Servicedesk die Erfassung zu erleichtern.

• ERP-System: Ein ERP (Enterprise Resource Planning), z.B. SAP oder Microsoft Dynamics, wird oft für Beschaffung, Budgetierung und Auftragsverwaltung genutzt. In FM-Dienstleistungsunternehmen werden Leistungen abgerechnet, Material bestellt, usw. Eine Integration zwischen Servicedesk und ERP kann z.B. bedeuten: Aus einem Ticket heraus wird ein Wartungsauftrag oder Bestellung im ERP angestoßen. Beispielsweise meldet der Servicedesk ein defektes Bauteil und erstellt direkt eine Beschaffungsanforderung im ERP, wobei Ticketnummer und Kostenstelle übergeben werden. Planon (ein CAFM-Anbieter) beschreibt, dass in integrierten Plattformen Materialbestellungen per Knopfdruck aus dem Work Order heraus im ERP ausgelöst werden und alle Kosten zurückverlinkt werden. So fließen die Kosten der Maßnahme automatisch ins Ticket und können dem Kunden weiterberechnet werden. In LPH 5 sollte definiert sein, ob solche integrativen Prozesse vorgesehen sind. Minimales Beispiel: Der Servicedesk dokumentiert im Ticket die ERP-Bestellnummer manuell. Maximales Beispiel: eine automatische Webservice-Schnittstelle, die bei Ticketanlage das ERP anstößt. Man muss hier Aufwand/Nutzen abwägen. Aber gerade bei größeren FM-Outsourcing Verträgen, wo Kosten erfasst und fakturiert werden müssen, ist eine enge Kopplung ratsam, um Doppelerfassung zu vermeiden.

• Helpdesk/ITSM-System: Manchmal existiert bereits ein Helpdesk-System in der Organisation (z.B. für IT-Abteilung). Die Frage ist dann, ob der FM-Servicedesk integriert oder getrennt davon sein soll. Es gibt Fälle, wo ein zentrales System sowohl IT-Tickets als auch FM-Tickets verwaltet, oft aber getrennt mit jeweils spezialisiertem Personal. Wenn getrennt, sollte zumindest ein Austauschmechanismus bedacht werden: Was, wenn ein Ticket falsch landet (IT-Problem beim FM-Desk gemeldet oder umgekehrt)? Es sollte definierte Übergabeprozeduren geben: Der FM-Servicedesk leitet IT-Fälle an den IT-Helpdesk weiter, idealerweise sogar im System per Transfer. Oder beide Systeme sind verbunden. Wenn kein direkter Link, dann zumindest definierte Kommunikationskanäle intern. In LPH 5 sollte die Abgrenzung der Zuständigkeiten zwischen IT-Helpdesk und FM-Helpdesk festgehalten werden, damit Nutzer nicht im Kreis geschickt werden. Ggf. richtet man ein gemeinsames Portal ein, wo der Nutzer erst den Kategorie-Bereich wählt (IT vs. FM).

• Gebäudeleittechnik (GLT/BMS): Moderne Gebäude haben GLT-Systeme, die Alarme erzeugen können (z.B. Klimaanlage Störung, Brandschlag, etc.). Diese Alarmmeldungen könnten direkt in den Servicedesk einfließen. Idealerweise wird automatisiert ein Ticket erzeugt, wenn z.B. ein Aufzug-Notruf eingeht oder eine Störungsmeldung von der GLT. Das setzt eine Schnittstelle voraus: Entweder via E-Mail (die GLT schickt E-Mails an das Ticket-System) oder über APIs. Planerisch sollte man prüfen, ob wichtige Anlagengruppen (Aufzüge, Brandmeldeanlage, Heizungssteuerung) bereits digitale Meldungen liefern und wie der Servicedesk diese erhalten soll. Manche CAFM-Systeme bieten GLT-Integration out-of-the-box. Falls ja, kann man in LPH 5 definieren: "Meldungen aus GLT XYZ werden direkt als Ticket mit Kategorie Anlage XY angelegt".

• DMS (Dokumenten-Management-System): Falls Wartungsdokumente, Bedienungsanleitungen oder Verträge relevant sind, könnte eine Schnittstelle zum DMS sinnvoll sein. Beispiel: Ein Techniker will im Ticket gleich das Schaltbild einsehen – das Ticket-System könnte über eine Verknüpfung ins DMS den passenden Plan anzeigen, sofern die Anlage ID bekannt ist. In der Planungsphase sollten solche Anforderungen gesammelt und priorisiert werden. Nicht jede tolle Idee ist direkt machbar; oft muss man pragmatisch entscheiden, welche Integrationen wirklich Mehrwert bieten.

• CRM/Kundenportal: Wenn der Servicedesk ein Service für externe Kunden ist (z.B. in gewerblich vermieteten Gebäuden), dann kommt evtl. ein CRM-System ins Spiel, in dem Kundenstammdaten geführt werden. Die Schnittstelle hier wäre: Ticket -> Kunde/Mietpartei. So kann man Berichte je Kunde erzeugen oder Kunden via Portal Einsicht geben. In LPH 5 sollte überlegt werden, ob die Auftraggeber solche Anforderungen haben (manchmal in Verträgen gefordert, dass der Mieter Zugang zu seinen Tickets bekommt).

Die Technologie der Schnittstellen kann vielfältig sein: von Dateiexport/Import (CSV/XML) über Webservices/API bis zu gemeinsamen Datenbanken. Wichtig ist, dass in der Ausführungsplanung zumindest die Anforderungen beschrieben werden, damit die IT-Umsetzung vorbereitet werden kann. Beispielsweise könnte im Plan stehen: "Eine Schnittstelle zwischen CAFM und ERP ist einzurichten, welche die Stammdaten der technischen Anlagen (inkl. IDs) synchron hält." Oder: "Das Ticketsystem muss eine REST-API bieten, um von externen Systemen (z.B. GLT) Tickets erstellen zu können." Solche Formulierungen sollten auch in die Leistungsbeschreibung für Softwarelieferanten aufgenommen werden.

Man sollte auch an Zukunftssicherheit denken: Offene Schnittstellen sind vorzuziehen. Ein CAFM wie pitFM wirbt z.B. mit offener Architektur zur Anbindung von Drittsystemen wie DMS, ERP, CAD/BIM, GLT. Das zeigt den Trend: kein System ist eine Insel. Daher in der Planung immer fragen: welche Daten müssen wir mit wem teilen?

Auch intern muss geklärt sein, wer Schnittstellen betreut. Wenn der Servicedesk outgesourct ist, aber an die internen Systeme andockt, braucht es Abstimmung zwischen den IT-Abteilungen.

Die Rückmeldung von Maßnahmen schließt gewissermaßen den Kreis im Ticketprozess. Sobald ein Problem behoben oder eine Serviceanfrage erfüllt wurde, müssen die durchgeführten Maßnahmen erfasst und an die relevanten Parteien zurückgemeldet werden – in erster Linie an den meldenden Nutzer (damit dieser weiß, dass sein Anliegen erledigt ist und wie es gelöst wurde), aber auch intern zur Dokumentation und ggf. an Vorgesetzte oder Auftraggeber zur Leistungskontrolle. In LPH 5 ist zu planen, wie diese Rückmeldeprozesse aussehen.

• Techniker-Feedback an Servicedesk: Nachdem der Techniker oder Dienstleister die Arbeit ausgeführt hat, sollte er dem Servicedesk mitteilen, was genau gemacht wurde und ob das Problem gelöst ist. Diese Information ist essenziell für die Dokumentation und spätere Kommunikation mit dem Nutzer. In der Praxis geschieht dies entweder direkt via Ticketsystem (Techniker schreibt Abschlussbericht ins Ticket per Mobile Device) oder mündlich/per Mail, wonach der Servicedesk-Mitarbeiter es ins System einträgt. Die Planung sollte den bevorzugten Weg festhalten. Optimal ist eine digitale Lösung: Techniker nutzen z.B. eine Mobile App, um direkt vor Ort den Einsatz abzuschließen, inkl. Zeitaufwand und Material. Ist das nicht möglich, muss der Servicedesk einen Prozess haben, diese Infos nachträglich einzupflegen. Wichtig: Der Plan sollte vorsehen, dass solche Rückmeldungen zeitnah erfolgen – z.B. noch am selben Tag des Einsatzes, damit keine Tickets "schweben", obwohl die Arbeit längst erledigt ist.

• Rückmeldung an den Nutzer: Sobald die Maßnahme erfolgt ist, sollte der Nutzer informiert werden. Hier gilt es, die richtige Balance zu finden in der Kommunikation: Der Nutzer möchte wissen, dass es erledigt ist und eventuell welche Maßnahmen ergriffen wurden (zum Verständnis, besonders wenn es länger dauerte). Er erwartet jedoch keine technischen Romane. Eine knappe, verständliche Info genügt: "Die Beleuchtung in Raum X wurde repariert. Ursache war ein Defekt im Vorschaltgerät, welches ausgetauscht wurde. Der Raum ist wieder voll beleuchtet." Solche Texte können als Vorlage im System hinterlegt sein oder vom Servicedesk formuliert werden. Wichtig ist, dass sie frei von internem Jargon sind. In LPH 5 kann man beispielhafte Abschlussmitteilungen entwerfen, um den Ton festzulegen. Ebenfalls zu entscheiden: Soll der Techniker vor Ort dem Nutzer Bescheid geben (z.B. "Es funktioniert jetzt wieder") und zusätzlich der Servicedesk schriftlich? Meist ist der offizielle Weg über den Servicedesk (um sicherzugehen, dass es dokumentiert ist), aber in persönlicher Umgebung sagt der Techniker oft direkt dem Büronutzer, dass es erledigt ist – was okay ist, aber der Servicedesk sollte trotzdem abschließend kommunizieren, zumindest per Ticket-Status "geschlossen".

• Abnahme durch Nutzer (optional): In manchen Fällen will man, dass der Nutzer die erfolgreiche Umsetzung bestätigt. Das kann formlos sein (der Nutzer meldet sich nicht mehr – implizit okay) oder formal (der Nutzer klickt im Portal "Einverstanden" oder unterschreibt auf einem Arbeitsauftrag). In der Planung sollte stehen, ob eine Abnahme erforderlich ist. Beispielsweise bei Umbaumaßnahmen oder größeren Services könnte das relevant sein, bei kleinen Reparaturen eher nicht. Falls ein Kunde vertraglich die Leistung abnehmen muss, dann muss der Servicedesk-Prozess das berücksichtigen (Ticket bleibt offen bis Abnahme da, o.ä.).

• Zeit- und Kostenerfassung: Die Rückmeldung beinhaltet oft auch, wie viel Zeit aufgewendet wurde und welches Material (Kosten) gebraucht wurde. Dies ist wichtig für interne KPIs, aber auch für die Abrechnung an Kunden. LPH 5 sollte definieren, ob der Servicedesk/das System als Zeiterfassung für Techniker dient oder ob das separat läuft. Viele Ticketsysteme erlauben es, Arbeitszeit und Material direkt am Ticket zu buchen. Ist das gewünscht, muss es eingeplant werden. Andernfalls muss eine Schnittstelle zum Zeiterfassungssystem bestehen, oder man ignoriert es auf Ticket-Level. Für die Kostentransparenz ist es aber vorteilhaft, im Ticket zumindest grobe Angaben zu haben ("Ersatzteil €50, 2h Arbeit"), gerade in FM-Verträgen mit Weiterberechnung an den Kunden.

• Qualitätskontrolle der Maßnahme: Nach der Rückmeldung kann der Servicedesk (oder ein Supervisor) bewerten, ob alles ordnungsgemäß erledigt wurde. Bei kritischen Fällen könnte z.B. ein technisches Controlling passieren – Stichprobe: wurde wirklich die richtige Ursache behoben? In LPH 5 muss man das nicht im Detail ausarbeiten, aber erwähnen, ob es so eine Kontrolle geben soll. Ein Indikator ist die Nutzerzufriedenheit: Wenn der Nutzer kurz nach Abschluss erneut anruft, weil das Problem wieder auftritt, war die Maßnahme nicht erfolgreich. Daher gehört zur Rückmeldephase auch die Beobachtung, ob Folgeprobleme auftreten. Manchmal belässt man ein Ticket noch ein paar Tage auf "Monitoring", bevor man endgültig abschließt (ITIL schlägt das z.B. bei Major Incidents vor – aber im FM evtl. weniger formal).

• Feedback-Schleife ins Vorbeugende: Die gesammelten Rückmeldungen sind Gold wert für präventive Maßnahmen. Z.B. wenn öfter Leuchtmittel ausfallen und immer nur getauscht werden, könnte die Dokumentation zeigen, dass vielleicht eine Spannungsprüfung nötig wäre. Dies ist mehr im Problemmanagement verankert, aber eben auf Basis der Rückmeldungen. In der Checkliste kann ein Punkt sein: "Werden Erkenntnisse aus der Bearbeitung an das Team weitergegeben oder ins Wartungsprogramm aufgenommen?" Diese Lessons Learned fließen oft informell, aber man kann es formal begleiten (regelmäßige Meetings etc.).

Von Seiten der gesetzlichen Betreiberverantwortung ist die Rückmeldung ebenfalls wichtig: Nachweisführung, dass bei einer Gefahrmeldung Maßnahmen ergriffen wurden. Wenn es z.B. um Arbeitssicherheit geht, sollte die Fachkraft für Arbeitssicherheit eine Kopie der Rückmeldung erhalten (oder zumindest Zugriff auf das Ticket), um zu prüfen, ob die Gefahr beseitigt wurde. Solche internen Informationsflüsse kann man vorsehen.

Ein Servicedesk im Facility Management sollte nicht nur reaktiv Störungen abarbeiten, sondern auch proaktiv die Qualität seiner Leistungen überwachen und Verbesserungspotenziale erkennen. Dazu bedarf es einer strukturierten Qualitätssicherung und der Auswertbarkeit der erfassten Daten. In LPH 5 sollten die Grundlagen für ein solches Qualitätsmanagement gelegt werden, indem Kennzahlen, Berichtswege und Feedbackschleifen definiert werden.

• Service Level Monitoring: Wie bereits bei SLAs und Eskalationen angesprochen, müssen definierte Service Levels ständig überwacht werden. Qualitätssicherung fängt damit an, dass man misst, ob die vereinbarten Leistungen erbracht wurden (z.B. X% aller Tickets Priorität 2 innerhalb 24h gelöst). In der Planung sollte festgehalten sein, welche KPIs (Key Performance Indicators) regelmäßig erhoben werden. Typische KPIs im FM-Servicedesk: Anzahl der Tickets pro Zeitraum, Anzahl Störungen vs. Serviceanfragen, Durchschnittliche Reaktionszeit, Durchschnittliche Lösungszeit nach Priorität, Prozentsatz der Tickets innerhalb SLA gelöst, Wiederholungsrate (wie viele Tickets werden erneut geöffnet oder treten als Folge erneut auf), Kundenzufriedenheitswert. Der GEFMA-Leitfaden 967 "Performance Measurement" betont, dass klar definierte Service Levels und KPIs die Basis bilden, um die Dienstleistungsqualität sicherzustellen und zu optimieren. Diese Kennzahlen sollten im Konzept und später im Vertrag festgelegt sein. Auch Verantwortlichkeiten: Wer überwacht die KPIs? Oft der Service Manager im Monatsbericht.

• Regelmäßige Reports: Es empfiehlt sich, einen Berichtsrhythmus festzulegen: z.B. monatliche Servicedesk-Reports an das Management und an den Auftraggeber. In LPH 5 kann man Musterreportings definieren, die später umgesetzt werden. Ein Monatsreport könnte z.B. enthalten: Ticketstatistik (nach Kategorie, Priorität), SLA-Compliance-Quote, besondere Vorkommnisse (Major Incidents), Trends (z.B. steigende Meldungen in einem Bereich), Maßnahmenvorschläge. Wenn der FM-Servicedienstleister extern ist, werden solche Reports oft vertraglich verlangt. Die Planung sollte sicherstellen, dass das System die dafür nötigen Daten liefern kann (Stichwort Auswertbarkeit: Können Berichte leicht aus dem System gezogen werden? Braucht es Zusatztools?). Gegebenenfalls ist zu planen, wie automatisierte Reports erstellt werden (manche Tools können geplante E-Mail-Reports versenden).

• Qualitätssicherungsmeetings: Neben zahlenbasierten Reports sind Meetings sinnvoll, um qualitatives Feedback zu besprechen. In der Planung kann man vorsehen: Quarterly Review zwischen Auftraggeber und Service-Team, um die Performance durchzugehen. Oder interne Team-Meetings monatlich, um Probleme im Prozess zu diskutieren. Hier können auch die erhobenen KPIs präsentiert werden. Wichtig ist, dass die Daten nicht einfach gesammelt, sondern auch interpretiert und genutzt werden (Plan-Do-Check-Act-Zyklus). ISO 9001 fordert ja gerade dieses "Check" und "Act": an Hand von Daten Verbesserungen initiieren.

• Kundenfeedback auswerten: Falls Kundenzufriedenheitsbefragungen gemacht werden (siehe Kommunikation), müssen diese ebenfalls ausgewertet und in Verbesserungen überführt werden. Man kann z.B. als KPI definieren: Durchschnittliche Zufriedenheit auf einer Skala, und Ziel > 90%. Kritikpunkte aus Feedback sollten protokolliert und nachverfolgt werden. In LPH 5 kann man vorschlagen, dass z.B. in den Reports auch Kundenfeedback ein Kapitel hat.

• Kontinuierliche Verbesserung (KVP): Man sollte einen Mechanismus definieren, wie Verbesserungsmaßnahmen umgesetzt werden. Beispielsweise: "Wenn SLA-Ziele 2 Monate in Folge verfehlt werden, ist ein Verbesserungsplan zu erstellen." Oder: "Jedes Jahr werden gemeinsam mit dem Auftraggeber neue Ziele vereinbart." Dieser KVP kann Teil der vertraglichen Regelungen sein (in Ausschreibungen manchmal gefordert). Die Planer könnten hier Bezug nehmen auf ITILs Continual Service Improvement (CSI) oder ISO 20000 Continual Improvement, was in FM nicht minder wichtig ist. Gerade über mehrere Jahre Laufzeit will man effizienter werden und aus Fehlern lernen.

• Benchmarking: Falls Daten über längere Zeit gesammelt werden, kann man Benchmarking betreiben – entweder intern (Monat vs. Vormonat, Jahr vs. Jahr) oder extern (Vergleich mit branchenüblichen Werten). In LPH 5 kann man überlegen, ob man bekannte Benchmark-Zahlen hat (z.B. "Tickets pro Nutzer und Jahr" oder "Kosten pro Ticket") – eventuell nicht so verbreitet im FM wie in IT, aber größere FM-Dienstleister haben interne Benchmarks.

• Audits und Zertifizierungen: Wenn angestrebt, sollte die Ausführungsplanung auch berücksichtigen, ob man z.B. eine ISO 9001 Zertifizierung des Servicedesks plant, oder ISO 20000 (für ITSM, selten für FM angewandt, aber möglich). Dann müssten die entsprechenden Dokumentationen und Prozesse auditfähig sein. Gegebenenfalls kann man im Plan vorsehen, interne Audits zu machen (z.B. der Qualitätsbeauftragte prüft quartalsweise den Servicedesk-Prozess auf Compliance mit Vorgaben). Diese Kontrollpunkte könnte man in der Checkliste notieren.

• Auswertbarkeit der Daten: Das zweite Wort im Titel des Kapitels. Es ist nicht genug, Daten zu haben – man muss sie auch auswerten können. Daher in LPH 5 drauf achten: Das Tool sollte ein gutes Reportingmodul haben oder einen Datenexport ermöglichen. Datenfelder sollten so gestaltet sein, dass man darauf filtern und gruppieren kann (daher lieber vordefinierte Kategorien als freie Texte, wo möglich). Eventuell braucht es zusätzliche Business-Intelligence-Werkzeuge, wenn komplexe Auswertungen gewünscht sind (z.B. Power BI, Crystal Reports etc.). Ein oft unterschätzter Punkt: Auswertbarkeit von Freitext – viele wichtige Infos stecken in Beschreibungen. KI-gestützte Analysen wären denkbar, aber das ist meist außerhalb des Scopes. Besser man gestaltet die Ticketerfassung so strukturiert wie nötig, um manuell auswerten zu können.

• Performance-Indikatoren und Verträge: Gemäß GEFMA 967 sollen definierte Service Levels und KPIs helfen, die Leistungserbringung transparent zu machen. Oft werden in FM-Verträgen bestimmte KPIs mit Bonus/Malus verknüpft. Z.B. "Erreichbarkeit des Servicedesks 98% im Monat, sonst Abzug". Die Planung sollte sicherstellen, dass diese Indikatoren messbar sind. Erreichbarkeit könnte man durch ein Telefonsystem mit Logging messen (wie viele Anrufe entgegengenommen vs. verpasst). Wenn solche Anforderungen bestehen, muss das entsprechend eingerichtet sein.

• Qualitätsziele: Es bietet sich an, ein paar konkrete Qualitätsziele zu formulieren (z.B. "Tickets richtig klassifiziert: >95%", "Kundenzufriedenheit >= 4 von 5", "Erste-Lösungsquote 70%"). Diese sollten SMART (spezifisch, messbar, akzeptiert, realistisch, terminiert) sein. In LPH 5 kann man diese Ziele vorschlagen und später in Absprache finalisieren.

Abschließend ist ein Blick darauf zu werfen, wie all die genannten Anforderungen in Ausschreibungsunterlagen und Leistungsbeschreibungen verankert werden können. Wenn ein Servicedesk im Rahmen eines FM-Dienstleistungsvertrags ausgeschrieben oder beauftragt wird, müssen die Erwartungen und Schnittstellen klar formuliert sein. Typische planerische Anforderungen und Kontrollpunkte in LPH 5 zielen darauf ab, dass die Leistungsbeschreibung für den Servicedesk vollständig und eindeutig ist, sodass Anbieter ein realistisches Angebot abgeben und der Auftraggeber die gewünschte Qualität erhält.

• Leistungsumfang genau definieren: Die Beschreibung sollte klar umfassen, welche Leistungen der Servicedesk erbringt. Dazu gehört: Erreichbarkeitszeiten (z.B. "24/7 Hotline"), Art der entgegenzunehmenden Meldungen (alle technischen Störungen, Benutzeranfragen, ggf. Notrufe?), Anzahl der Objekte/Nutzer die betreut werden (Dimensionierung), und welche Services explizit nicht enthalten sind (z.B. IT-Support falls getrennt). Ein detaillierter Servicekatalog ist hilfreich. GEFMA 968 "Specifications" empfiehlt, den Produkt- bzw. Leistungskatalog von Facility Services detailliert darzustellen als Ausschreibungsgrundlage. Dazu gehören auch alle Schnittstellen und Kooperationsformen (z.B. Zusammenarbeit mit vorhandener IT-Abteilung).

• Qualitätsanforderungen und KPIs nennen: Alle zuvor definierten KPIs, SLA-Zeiten und Qualitätsziele sollten Bestandteil der Leistungsbeschreibung sein. Nur was vertraglich festgehalten ist, kann später eingefordert werden. Beispiele: "Reaktionszeit max. 30 min für Notrufe, 4h für hohe Priorität" oder "Kundenzufriedenheit > 90% in quartalsweiser Umfrage". GEFMA 967 über Performance Measurement betont die Bedeutung klarer Beschreibung der Erwartungen und messbarer Fakten. Diese Messgrößen sollten in der Ausschreibung stehen, ebenso wie die Reportingpflicht (z.B. "Monatsbericht mit folgenden Inhalten ist zu liefern...").

• Dokumentations- und Nachweispflichten: In der Leistungsbeschreibung kann gefordert werden, dass ein Ticketsystem zu verwenden ist und alle Vorgänge zu dokumentieren sind. Auch Datenschutz kann hier adressiert werden (z.B. "Der Auftragnehmer stellt DSGVO-konforme Verarbeitung sicher, Datenlöschung nach X Jahren..."). Falls der Auftragnehmer das System stellt, kann man Anforderungen an dieses System definieren (etwa Schnittstellen, Funktionsumfang). Oft sind im Angebotsfragenkatalog Punkte wie "Beschreiben Sie Ihr eingesetztes Ticketsystem und dessen Auswertungsmöglichkeiten."

• Personalqualifikation und Schulung: Es sollte festgelegt werden, welches Personalprofil erwartet wird (z.B. "Die Service-Desk-Mitarbeiter müssen deutsch und englisch fließend sprechen, sowie in Ersthelfer-Maßnahmen geschult sein."). Auch Anzahl Personal evtl. als Anhalt (Service Desk Teamstärke, Schichten). Man kann verlangen, dass der Auftragnehmer ein Schulungskonzept vorlegt, insbesondere zu Kundendienst-Training und Prozess-Know-how (ITIL-Kenntnisse etc.).

• Schnittstellen und Zusammenarbeit: Die Schnittstellen zu anderen Beteiligten (andere Dienstleister, interne Abteilungen) sollten in der Leistungsbeschreibung benannt werden. Beispielsweise: "Der Service-Desk-Dienstleister hat mit dem vom Auftraggeber gestellten CAFM-System zu arbeiten und Meldungen an die vom Auftraggeber beauftragten Fachfirmen zu koordinieren." Oder "Zusammenarbeit mit der IT-Hotline muss gewährleistet sein, Details werden mit dem Auftraggeber abgestimmt." Wichtig ist, keine Lücken zu lassen, wer was macht. Input- vs. Output-Orientierung: GEFMA 968 erläutert sowohl inputorientierte (Aufwand wird beschrieben) als auch outputorientierte (Ergebnis wird definiert) Ausschreibungsformen. Für Servicedesk könnte man Output-orientiert ausschreiben ("Störungen werden innerhalb Frist X behoben"), aber man sollte trotzdem Prozesse einfordern.

• Übergabe und Implementierung: Wenn ein neuer Servicedesk aufgebaut wird, gehört zur Leistung evtl. auch Implementierungsaufwand. In LPH 5 kann festgelegt werden, dass der Auftragnehmer in einer Mobilisierungsphase ein Betriebshandbuch erstellt, das Personal rekrutiert, Systeme einrichtet. Diese Punkte sollten in der Ausschreibung stehen: z.B. "Implementierungsphase 2 Monate, inklusive Einrichtung des Ticketing-Systems, Übernahme bestehender Tickets, Schulung." So ist klar, dass Anbieter diesen Aufwand kalkulieren.

• Kontroll- und Abnahmepunkte: Planerisch sollten Meilensteine eingebaut werden, an denen die Ausführungsplanung des Servicedesks geprüft wird. Beispielsweise: Abnahme des Systemsetups durch Auftraggeber vor Live-Gang, Testläufe, Probealarm etc. In LPH 5 kann man Checklisten (wie die hier erstellten) auch für die Abnahme der Dienstleistung nutzen.

• Vertragsstrafen / Bonusregelungen: Falls gewünscht, sollten in der Leistungsbeschreibung Mechanismen bei Nichteinhaltung der SLAs benannt werden (z.B. Abzug pro % unterschrittener Erfüllung). Oder umgekehrt Bonus für übererfüllung. Diese müssen aber mit realen Daten belegbar sein (daher die Messung in Reporting). Die Planer könnten beispielhaft formulieren, was angemessen ist, oder sich an gängigen Verträgen orientieren.

• Technische Standards fordern: Es kann sinnvoll sein, in der Ausschreibung zu erwähnen, dass der Servicedesk nach ITIL/ISO20000 ausgerichtet sein soll oder dass der Auftragnehmer ein QM-System nach ISO 9001 haben muss. Das hängt vom Markt ab; große FM-Dienstleister sind oft zertifiziert, was ein Qualitätsversprechen ist. Wenn das wichtig ist, als Anforderung aufnehmen: "Zertifizierung nach ISO 9001:2015 und ISO/IEC 27001 (für Datensicherheit) sind wünschenswert." Oder "Die eingesetzten Prozesse sollen im Wesentlichen ITIL v4 entsprechen."

• Leistungsprogramm vs. Leistungsbeschreibung: HOAI spricht von "Leistungsbeschreibung mit Leistungsprogramm" bei funktionaler Ausschreibung. Im FM-Bereich wird oft outputorientiert (funktional) ausgeschrieben – sprich: gewünschtes Ergebnis, nicht jeder Handgriff. Dennoch muss der Servicedesk-Prozess planerisch so aufgesetzt sein, dass ein Bieter ihn mit einem Konzept füllen kann. In der Praxis empfiehlt es sich, dem Bieter gewisse Freiheiten zu lassen (z.B. eigenes Ticketsystem vs. vom AG gestellt), aber die Schnittstellenbedingungen klar vorzugeben.

• Checklisten als Vertragsanhang: Die in dieser Arbeit erstellten Checklisten können nahezu als Bestandteil der Leistungsbeschreibung dienen – zum Beispiel als Prüfliste bei Serviceübergaben. Der Auftragnehmer könnte verpflichtet werden, diese Punkte zu erfüllen und regelmäßig nachzuweisen (etwa durch Audit, siehe Quality).