# 3.3 Benutzerkommunikation und professioneller Umgang

> **Kurz erklärt**
>
> Benutzerkommunikation ist ein wesentlicher Bestandteil der Serviceerfahrung.
>
> Ein technisches Problem wird aus Sicht eines Benutzers nicht nur danach bewertet:
>
> - ob es gelöst wurde,
> - sondern auch wie der Kontakt verlief,
> - ob das Anliegen verstanden wurde,
> - ob Informationen verständlich waren,
> - ob Zusagen eingehalten wurden,
> - und ob der Benutzer wusste, was als Nächstes geschieht.
>
> Professionelle Kommunikation bedeutet:
>
> - aufmerksam zuhören,
> - Auswirkungen verstehen,
> - verständlich sprechen und schreiben,
> - Erwartungen realistisch steuern,
> - Unsicherheiten offen benennen,
> - regelmäßig informieren,
> - respektvoll bleiben,
> - Sicherheits- und Datenschutzregeln einhalten,
> - und das erreichte Ergebnis aus Benutzersicht bestätigen.
>
> Empathie ist dabei kein Ersatz für technische Kompetenz.
>
> Sie hilft, technische Kompetenz so einzusetzen und zu vermitteln, dass Benutzer Vertrauen gewinnen und handlungsfähig bleiben.

---

**Warum Kommunikation Teil der Serviceleistung ist**

Benutzer erleben einen Service nicht ausschließlich über:

- Verfügbarkeit,
- Leistung,
- Funktionen,
- oder technische Messwerte.

Sie erleben ihn auch über die Interaktionen mit der Serviceorganisation.

Dazu gehören:

- Portaltexte,
- Fehlermeldungen,
- Telefongespräche,
- Chatnachrichten,
- E-Mails,
- Statusinformationen,
- Wartungsankündigungen,
- Rückfragen,
- Eskalationen,
- und Abschlussmeldungen.

Ein Service kann technisch wiederhergestellt sein und trotzdem eine schlechte Erfahrung hinterlassen.

Beispiele:

- Der Benutzer erhält stundenlang keine Statusinformation.
- Mehrere Mitarbeiter stellen dieselben Fragen.
- Der Benutzer muss technische Begriffe verstehen, die für seine Aufgabe nicht relevant sind.
- Eine versprochene Rückmeldung erfolgt nicht.
- Das Ticket wird geschlossen, obwohl die Arbeitsfähigkeit noch nicht wiederhergestellt ist.
- Ein Mitarbeiter macht den Benutzer für den Fehler verantwortlich.
- Eine Störung wird verharmlost, obwohl sie einen wichtigen Arbeitsprozess blockiert.
- Es wird eine Lösung versprochen, obwohl Ursache und Zeitbedarf noch unbekannt sind.

> **Merke**
>
> Kommunikation ist kein Zusatz zur technischen Bearbeitung.
>
> Sie ist ein sichtbarer Bestandteil der gesamten Serviceerfahrung.

---

**Technische Qualität und Kommunikation wirken zusammen**

| Technische Bearbeitung | Kommunikation | Mögliche Wahrnehmung |
|---|---|---|
| schnell und wirksam | verständlich und zuverlässig | sehr positive Erfahrung |
| schnell und wirksam | unfreundlich oder unklar | technisch erfolgreich, aber negatives Vertrauen |
| langsam oder komplex | transparent und regelmäßig | Situation bleibt belastend, aber nachvollziehbar |
| langsam oder komplex | keine verlässlichen Informationen | starke Unsicherheit und negative Erfahrung |
| technisch nicht lösbar | Alternativen und Grenzen werden verständlich erklärt | realistische und professionelle Behandlung |
| technisch scheinbar gelöst | Benutzer kann weiterhin nicht arbeiten | tatsächliches Outcome nicht erreicht |

Eine freundliche Kommunikation kann eine schlechte technische Leistung nicht dauerhaft ausgleichen.

Eine gute technische Leistung kann jedoch ebenfalls an Wert verlieren, wenn die Kommunikation:

- respektlos,
- unverständlich,
- widersprüchlich,
- oder unzuverlässig

ist.

---

**Ziel professioneller Benutzerkommunikation**

Professionelle Kommunikation soll dazu beitragen, dass:

- das Anliegen richtig verstanden wird,
- notwendige Informationen vollständig vorliegen,
- der Benutzer den nächsten Schritt kennt,
- Missverständnisse vermieden werden,
- Auswirkungen angemessen berücksichtigt werden,
- Vertrauen erhalten bleibt,
- Sicherheitsregeln eingehalten werden,
- und das gewünschte Outcome gemeinsam erreicht werden kann.

Sie soll nicht nur möglichst freundlich klingen.

Sie muss außerdem:

- fachlich korrekt,
- situationsgerecht,
- nachvollziehbar,
- und handlungsorientiert

sein.

---

**Kommunikation an Wissen und Kontext anpassen**

Service-Desk-Mitarbeiter sprechen mit Personen mit unterschiedlichen:

- technischen Kenntnissen,
- Aufgaben,
- Verantwortlichkeiten,
- Sprachkenntnissen,
- Erfahrungen,
- und Stresssituationen.

Eine identische Erklärung ist deshalb nicht für jede Person geeignet.

Beispiel für einen technisch erfahrenen Ansprechpartner:

> Die Namensauflösung funktioniert, aber die TCP-Verbindung zum Dienst wird am Standort blockiert. Das Netzwerkteam prüft aktuell Firewall und Routing.

Beispiel für einen Benutzer ohne technischen Schwerpunkt:

> Ihr Computer erreicht den zentralen Dienst derzeit nicht. Das zuständige Netzwerkteam prüft die Verbindung. Sie müssen im Moment keine weiteren Einstellungen verändern.

Beide Aussagen können dieselbe Situation beschreiben.

Die Formulierung wird an die jeweilige Zielgruppe angepasst.

> **Merke**
>
> Verständliche Kommunikation bedeutet nicht, Informationen ungenau oder falsch darzustellen.
>
> Sie bedeutet, die benötigte Information in einer geeigneten Sprache und Detailtiefe zu vermitteln.

---

**Fachsprache bewusst verwenden**

Technische Fachbegriffe sind sinnvoll, wenn:

- die Gesprächspartner sie verstehen,
- sie für die Entscheidung notwendig sind,
- oder sie eine Situation präziser beschreiben.

Sie sind ungeeignet, wenn sie:

- den Benutzer verwirren,
- Kompetenz demonstrieren sollen,
- Verantwortung auf den Benutzer verlagern,
- oder den eigentlichen nächsten Schritt verdecken.

Ungeeignet:

> Der SAML-Assertion-Consumer-Service liefert aufgrund eines fehlerhaften IdP-Mappings einen Authentifizierungsfehler.

Verständlicher:

> Die Anmeldung zwischen dem Identitätsdienst und der Anwendung funktioniert derzeit nicht korrekt. Das zuständige Team prüft die Zuordnung. Ihr Kennwort müssen Sie nicht erneut ändern.

Für ein technisches Fachteam kann die detaillierte Beschreibung weiterhin notwendig sein.

Benutzerkommunikation und technische Dokumentation dürfen deshalb unterschiedliche Detailstufen besitzen.

---

**Aktives Zuhören**

Aktives Zuhören bedeutet, den Benutzer nicht nur sprechen zu lassen, sondern seine Informationen bewusst aufzunehmen und zu überprüfen.

Dazu gehören:

- nicht unnötig unterbrechen,
- relevante Aussagen erkennen,
- gezielt nachfragen,
- das Verstandene zusammenfassen,
- Unsicherheiten klären,
- und Auswirkungen ernst nehmen.

Beispiel:

Benutzer:

> Seit heute Morgen geht bei mir gar nichts mehr.

Ungeeignete Reaktion:

> Haben Sie den Computer schon neu gestartet?

Bessere Reaktion:

> Ich kläre kurz, was genau betroffen ist. Können Sie sich nicht am Computer anmelden oder funktionieren nach der Anmeldung bestimmte Anwendungen nicht?

Die zweite Reaktion verhindert, dass sofort eine Lösung versucht wird, bevor das Problem ausreichend verstanden ist.

---

**Offene und geschlossene Fragen**

Beide Fragearten können sinnvoll sein.

**Offene Fragen**

Sie ermöglichen eine freie Beschreibung.

Beispiele:

- Was wollten Sie durchführen?
- Was ist stattdessen geschehen?
- Welche Auswirkungen hat die Störung auf Ihre Arbeit?
- Was wurde bereits ausprobiert?
- Was hat sich seit gestern verändert?

**Geschlossene Fragen**

Sie klären konkrete Punkte.

Beispiele:

- Sind weitere Benutzer betroffen?
- Wird eine Fehlermeldung angezeigt?
- Funktioniert die Anmeldung im Browser?
- Ist das Gerät mit dem Netzwerk verbunden?
- Besteht eine alternative Arbeitsmöglichkeit?

Eine sinnvolle Gesprächsführung beginnt häufig mit einer offenen Frage und wird anschließend durch konkrete Fragen präzisiert.

---

**Das Verstandene zusammenfassen**

Eine kurze Zusammenfassung hilft, Missverständnisse früh zu erkennen.

Beispiel:

> Ich fasse kurz zusammen: Sie können sich seit ungefähr 09:15 Uhr am Zeiterfassungssystem anmelden, aber beim Speichern erscheint die Meldung „Zugriff verweigert“. Zwei Kollegen in derselben Abteilung sind ebenfalls betroffen. Andere Anwendungen funktionieren. Ist das korrekt?

Vorteile:

- Benutzer kann Fehler korrigieren.
- technische Bearbeitung erhält eine klare Ausgangslage.
- unnötige Rückfragen werden reduziert.
- der Benutzer erkennt, dass sein Anliegen verstanden wurde.

---

**Empathie**

Empathie bedeutet, die Situation und Perspektive einer anderen Person wahrzunehmen und angemessen darauf zu reagieren.

Sie bedeutet nicht:

- jeder Forderung zuzustimmen,
- Prioritätsregeln aufzugeben,
- technische Tatsachen zu verändern,
- Sicherheitskontrollen zu umgehen,
- oder die Verantwortung für alle Gefühle des Benutzers zu übernehmen.

Geeignete empathische Aussagen:

- Ich verstehe, dass die Unterbrechung Ihren heutigen Termin gefährdet.
- Das ist besonders ungünstig, weil Sie den Zugriff gerade für den Monatsabschluss benötigen.
- Ich kann nachvollziehen, dass die wiederholte Anmeldung frustrierend ist.
- Ich sehe, dass Sie die Datei dringend benötigen. Ich prüfe jetzt zuerst, ob eine sichere Zwischenlösung möglich ist.

Ungeeignete Aussagen:

- Das ist doch nicht so schlimm.
- Bei mir funktioniert es.
- Sie sind der einzige Benutzer mit diesem Problem.
- Dafür können wir nichts.
- Beruhigen Sie sich erst einmal.

> **Wichtig**
>
> Empathie erkennt die Auswirkung an.
>
> Sie verspricht nicht automatisch eine sofortige Lösung.

---

**Empathie und Priorisierung unterscheiden**

Ein Benutzer kann stark belastet sein, während die organisatorisch bestimmte Priorität trotzdem nicht die höchste Stufe erreicht.

Beispiel:

> Ich verstehe, dass Sie die Anwendung für Ihre aktuelle Aufgabe benötigen. Nach unseren Kriterien ist derzeit nur Ihr Arbeitsplatz betroffen und ein Ersatzarbeitsplatz steht zur Verfügung. Der Vorgang wird deshalb mit Priorität 3 bearbeitet. Sollte auch die Alternative ausfallen oder weitere Benutzer betroffen sein, bewerten wir die Priorität erneut.

Diese Aussage:

- erkennt die Situation an,
- erklärt die Entscheidung,
- nennt die Alternative,
- und beschreibt, wann eine Neubewertung erfolgt.

Ungeeignet:

> Dafür bekommen Sie keine höhere Priorität.

---

**Eine professionelle Gesprächsstruktur**

Eine mögliche Struktur für einen Benutzerkontakt ist:

1. Kontakt eröffnen
2. Identität und Zuständigkeit klären
3. Anliegen frei beschreiben lassen
4. Situation und Auswirkungen präzisieren
5. das Verstandene zusammenfassen
6. Einordnung und nächsten Schritt erklären
7. Erwartungen und Zeitpunkte klären
8. Maßnahme durchführen oder weiterleiten
9. Ergebnis prüfen
10. Kontakt professionell abschließen

Diese Struktur ist eine Praxisempfehlung und kein für jede Situation vorgeschriebener ITIL-Prozess.

---

**1. Kontakt eröffnen**

Eine geeignete Eröffnung sollte:

- freundlich,
- eindeutig,
- und dem Kanal angemessen

sein.

Telefon:

> Guten Morgen, IT-Service-Desk, Max Mustermann. Wie kann ich Sie unterstützen?

Chat:

> Hallo, Sie sind beim IT-Service-Desk. Ich schaue mir Ihr Anliegen gern an. Wobei benötigen Sie Unterstützung?

E-Mail:

> Guten Tag, vielen Dank für Ihre Meldung. Ich prüfe zunächst die betroffene Anwendung und die bisher bekannten Auswirkungen.

Bei bereits bekannten Vorgängen:

> Guten Tag, ich melde mich zu Ihrem Vorgang 4711 bezüglich des Dateizugriffs.

---

**2. Identität und Zuständigkeit klären**

Abhängig vom Anliegen kann geprüft werden:

- Wer meldet?
- Wer ist tatsächlich betroffen?
- Für welche Organisationseinheit?
- Welcher Service wird benötigt?
- Darf die meldende Person die gewünschte Änderung veranlassen?
- Ist eine zusätzliche Identitätsprüfung erforderlich?

Eine starke Identitätsprüfung darf nicht durch freundliches Auftreten oder angeblichen Zeitdruck ersetzt werden.

Ungeeignet:

> Sie klingen glaubwürdig. Ich setze das Kennwort direkt zurück.

Besser:

> Für die Kennwortzurücksetzung muss ich Ihre Identität nach unserem festgelegten Verfahren prüfen. Ich führe Sie kurz durch die erforderlichen Schritte.

---

**3. Anliegen beschreiben lassen**

Der Benutzer sollte zunächst ausreichend Gelegenheit erhalten, seine Beobachtung zu schildern.

Hilfreiche Einstiegsfragen:

- Was möchten Sie durchführen?
- Was funktioniert dabei nicht wie erwartet?
- Welche Meldung sehen Sie?
- Welche Auswirkung entsteht für Ihre Arbeit?

Zu frühe technische Vermutungen können die Beschreibung verfälschen.

Beispiel:

Ungeeignet:

> Dann ist bestimmt Ihr VPN kaputt.

Besser:

> Ich prüfe zunächst, ob die Verbindung oder die Anwendung selbst betroffen ist.

---

**4. Auswirkungen präzisieren**

Wichtige Fragen:

- Welche Tätigkeit ist blockiert?
- Sind weitere Personen betroffen?
- Welcher Service oder Geschäftsprozess ist betroffen?
- Besteht eine sichere Zwischenlösung?
- Gibt es einen zeitkritischen Termin?
- Besteht ein möglicher Sicherheits- oder Datenverlustbezug?

Die Kommunikation sollte nicht nur das technische Symptom erfassen.

Beispiel:

> Der Drucker funktioniert nicht.

Die tatsächliche Auswirkung kann reichen von:

- ein Benutzer kann einen internen Entwurf nicht ausdrucken

bis zu:

- der gesamte Warenausgang kann keine Versandetiketten erzeugen.

---

**5. Zusammenfassen und bestätigen**

Beispiel:

> Sie können seit etwa 13:00 Uhr keine Versandetiketten drucken. Betroffen sind alle vier Arbeitsplätze im Warenausgang. Andere Drucker funktionieren, aber es gibt dort keine zulässige Alternative für die Etiketten. Der Versand steht deshalb momentan still. Ist diese Zusammenfassung korrekt?

Diese Informationen unterstützen:

- Priorisierung,
- technische Diagnose,
- Eskalation,
- und Statuskommunikation.

---

**6. Nächsten Schritt erklären**

Der Benutzer sollte wissen:

- was jetzt geschieht,
- wer beteiligt wird,
- ob er selbst etwas tun muss,
- und wann eine weitere Information erfolgt.

Beispiel:

> Ich prüfe zunächst, ob bereits eine allgemeine Störung bekannt ist. Danach teste ich die Verbindung zum Druckservice. Falls die Ursache dort nicht erkennbar ist, binde ich das zuständige Druck- und Netzwerkteam ein.

Ungeeignet:

> Ich gebe das weiter.

Besser:

> Ich gebe den Vorgang mit den bisherigen Prüfergebnissen an das Netzwerkteam. Der Service Desk behält die Kommunikation. Sie erhalten spätestens um 14:30 Uhr eine Statusmeldung, auch wenn die Ursache dann noch nicht vollständig behoben ist.

---

**7. Erwartungen realistisch steuern**

Zu klären sind:

- Was kann sofort getan werden?
- Was benötigt weitere Analyse?
- Welche Abhängigkeiten bestehen?
- Liegt eine bekannte Zielzeit vor?
- Wann erfolgt die nächste Statusmeldung?
- Besteht eine Zwischenlösung?
- Welche Grenzen gelten?

Eine realistische Aussage ist besser als eine beruhigend gemeinte, aber unbelegte Zusage.

Ungeeignet:

> Das ist gleich erledigt.

Besser:

> Die Ursache ist noch nicht bestätigt. Das zuständige Team beginnt jetzt mit der Analyse. Eine verlässliche Lösungszeit kann ich noch nicht nennen. Die nächste Rückmeldung erfolgt spätestens um 16:00 Uhr.

---

**8. Maßnahme durchführen oder weiterleiten**

Während einer Maßnahme sollte erklärt werden:

- was durchgeführt wird,
- warum es durchgeführt wird,
- ob eine Unterbrechung entsteht,
- und welches Ergebnis erwartet wird.

Beispiel:

> Ich starte nicht den gesamten Computer neu. Zuerst beende ich nur den betroffenen Druckdienst, weil die anderen Anwendungen ordnungsgemäß funktionieren.

Bei einer Remote-Sitzung:

> Ich öffne jetzt die Netzwerkeinstellungen und prüfe die bestehende Verbindung. Ich ändere noch keine Konfiguration. Sollte eine Änderung erforderlich sein, erkläre ich sie vorher.

---

**9. Ergebnis prüfen**

Nach einer technischen Maßnahme sollte nicht nur gefragt werden:

> Geht es jetzt?

Präzisere Prüfung:

- Können Sie sich jetzt anmelden?
- Können Sie die zuvor fehlgeschlagene Datei öffnen?
- Können Sie den vollständigen Arbeitsschritt durchführen?
- Erscheint die Fehlermeldung erneut?
- Funktioniert die Anwendung nur vorübergehend oder stabil?
- Sind weitere Benutzer weiterhin betroffen?

Das Ergebnis sollte sich am ursprünglichen Outcome orientieren.

---

**10. Kontakt abschließen**

Ein professioneller Abschluss kann enthalten:

- kurze Zusammenfassung,
- bestätigtes Ergebnis,
- offene Punkte,
- Vorgangsnummer,
- nächsten Schritt,
- und Kontaktmöglichkeit.

Beispiel:

> Die Anmeldung funktioniert wieder und Sie konnten den Auftrag erfolgreich speichern. Die Ursache war eine fehlerhafte Gruppenmitgliedschaft. Der Vorgang bleibt noch bis morgen zur Kontrolle geöffnet. Sollte der Fehler erneut auftreten, antworten Sie bitte unter Angabe der Vorgangsnummer 4711.

Bei ungelöster Situation:

> Die Störung ist noch nicht behoben. Das Anwendungsteam untersucht aktuell die fehlerhafte Berechtigung. Als Zwischenlösung können Sie den Auftrag über Arbeitsplatz 12 bearbeiten. Die nächste Statusmeldung erfolgt spätestens um 11:30 Uhr.

---

**Klare Sprache verwenden**

Klare Sprache zeichnet sich aus durch:

- kurze und vollständige Sätze,
- eindeutige Handlungsanweisungen,
- bekannte Begriffe,
- nachvollziehbare Reihenfolge,
- und sichtbare nächste Schritte.

Ungeeignet:

> Bitte führen Sie das übliche Prozedere durch und melden Sie sich gegebenenfalls erneut.

Besser:

> Starten Sie die Anwendung einmal neu. Melden Sie sich anschließend erneut an. Falls wieder die Meldung „Zugriff verweigert“ erscheint, antworten Sie bitte direkt auf diese Nachricht.

---

**Nur eine Handlung pro Schritt**

Besonders bei Telefon, Chat oder E-Mail sollten technische Anweisungen klar gegliedert sein.

Ungeeignet:

> Öffnen Sie die Einstellungen, prüfen Sie die Verbindung, löschen Sie den Cache, starten Sie neu und probieren Sie es noch einmal.

Besser:

1. Öffnen Sie die Anwendung noch nicht erneut.
2. Prüfen Sie unten rechts, ob das Netzwerksymbol eine Verbindung anzeigt.
3. Teilen Sie mir bitte mit, welches Symbol angezeigt wird.
4. Danach bestimmen wir den nächsten Schritt.

Dadurch kann das Ergebnis jedes einzelnen Schritts bewertet werden.

---

**Richtung und Ort eindeutig beschreiben**

Ungeeignet:

> Klicken Sie da links auf das Symbol.

Besser:

> Öffnen Sie oben rechts das Benutzermenü und wählen Sie anschließend „Abmelden“.

Bei mehreren Betriebssystemen oder Versionen sollte vorher geklärt werden:

- welches Gerät,
- welches Betriebssystem,
- welche Anwendung,
- und welche Version

verwendet wird.

---

**Keine unnötigen Vermutungen als Tatsache darstellen**

Ungeeignet:

> Das liegt sicher an Ihrem WLAN.

Besser:

> Eine instabile Verbindung ist eine mögliche Ursache. Ich prüfe zunächst, ob auch andere Benutzer oder Netzwerkverbindungen betroffen sind.

Ungeeignet:

> Der Hersteller hat gerade eine Störung.

Besser:

> Beim Hersteller ist derzeit eine mögliche Störung gemeldet. Wir prüfen noch, ob sie mit Ihrem Problem zusammenhängt.

---

**Transparenz über Unsicherheit**

Professionelle Kommunikation darf Unsicherheit enthalten.

Geeignete Aussagen:

- Die genaue Ursache ist noch nicht bestätigt.
- Wir haben zwei mögliche Ursachen eingegrenzt.
- Der erste Wiederherstellungsversuch war nicht erfolgreich.
- Die technische Funktion ist wiederhergestellt, aber wir überwachen den Service noch.
- Die Zeitangabe ist eine aktuelle Schätzung und kann sich ändern.
- Wir benötigen für die weitere Analyse Informationen des Herstellers.

Ungeeignet ist, Unsicherheit durch scheinbare Gewissheit zu verdecken.

> **Merke**
>
> Ehrliche Unsicherheit kann Vertrauen erhalten.
>
> Falsche Sicherheit beschädigt Vertrauen, sobald eine Zusage nicht eingehalten wird.

---

**Zusagen einhalten**

Zusagen können sein:

- Rückruf,
- Statusmeldung,
- Prüfung,
- Weiterleitung,
- Dokumentation,
- oder ein vereinbarter Termin.

Kann eine Zusage nicht eingehalten werden, sollte die Information vor Ablauf des zugesagten Zeitpunkts erfolgen.

Beispiel:

> Die angekündigte Rückmeldung um 14:00 Uhr kann ich noch nicht mit einer Lösung verbinden. Das Netzwerkteam prüft weiterhin die Standortverbindung. Der Provider wurde inzwischen einbezogen. Die nächste Aktualisierung erfolgt spätestens um 15:00 Uhr.

Ungeeignet:

- keine Rückmeldung geben,
- bis zur vollständigen Lösung warten,
- oder erst nach einer erneuten Nachfrage reagieren.

---

**Statuskommunikation**

Eine hilfreiche Statusmeldung beantwortet möglichst:

- Was ist betroffen?
- Welche Auswirkungen sind bekannt?
- Was wird aktuell getan?
- Gibt es eine Zwischenlösung?
- Was müssen Benutzer tun?
- Wann folgt die nächste Information?

Beispiel:

> Seit 10:20 Uhr ist die zentrale Dateiablage für die Standorte Nord und West nicht erreichbar. Das Netzwerkteam untersucht die Verbindung zum Rechenzentrum. Lokal gespeicherte Dateien sind nicht betroffen. Bitte führen Sie keine wiederholten Neustarts durch. Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr.

---

**Statusmeldung ohne neue technische Erkenntnis**

Auch wenn noch keine Lösung vorliegt, kann eine Statusmeldung sinnvoll sein.

Beispiel:

> Die Analyse läuft weiter. Eine eindeutige Ursache wurde noch nicht bestätigt. Der Hersteller prüft derzeit die Protokolldaten. Die bisher genannte Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt um 16:30 Uhr.

Dadurch weiß der Benutzer:

- der Vorgang wird weiterhin bearbeitet,
- die Organisation hat ihn nicht vergessen,
- und wann eine neue Information zu erwarten ist.

---

**Kommunikationshäufigkeit an die Situation anpassen**

Ein kritischer Incident benötigt häufigere Statusinformationen als eine normale Serviceanfrage.

Mögliche Einflussfaktoren:

- Auswirkung,
- Dringlichkeit,
- Anzahl betroffener Benutzer,
- Dauer,
- Unsicherheit,
- verfügbare Zwischenlösung,
- und Informationsbedarf der Stakeholder.

Zu häufige Meldungen ohne Inhalt können:

- Bearbeitung unterbrechen,
- Verwirrung erzeugen,
- oder wichtige Informationen verdecken.

Zu seltene Meldungen erzeugen:

- Unsicherheit,
- Rückfragen,
- Mehrfachmeldungen,
- und Vertrauensverlust.

---

**Zielgruppengerechte Statusinformationen**

Unterschiedliche Stakeholder benötigen unterschiedliche Informationen.

| Zielgruppe | Häufig benötigte Information |
|---|---|
| Benutzer | Auswirkung, Zwischenlösung, nächstes Update |
| Service Desk | bekannte Symptome, betroffene Gruppen, freigegebene Formulierung |
| technisches Team | Diagnose, Protokolle, Hypothesen, nächste Maßnahmen |
| Service Owner | Serviceauswirkung, Risiken, Fortschritt und Entscheidungen |
| Führungskräfte | Geschäftsfolgen, erwartete Dauer, Risiken und benötigte Entscheidungen |
| Lieferant | technische Nachweise, Vertragsbezug, Priorität und gewünschte Unterstützung |
| Informationssicherheit | mögliche Daten- oder Sicherheitsauswirkung und gesicherte Beweise |

Eine technische Arbeitsnotiz sollte nicht unverändert an alle Benutzer gesendet werden.

---

**Kommunikation bei geplanten Wartungen**

Eine Wartungsankündigung sollte möglichst enthalten:

- betroffener Service,
- Datum und Zeitraum,
- erwartete Auswirkung,
- betroffene Benutzer oder Standorte,
- Grund der Maßnahme,
- notwendige Vorbereitung,
- mögliche Alternative,
- Kontaktweg,
- und Abschlussinformation.

Beispiel:

> Am Sonntag, 9. August 2026, wird der zentrale Dateiservice zwischen 08:00 und 10:00 Uhr aktualisiert. In diesem Zeitraum können Dateien vorübergehend nicht geöffnet oder gespeichert werden. Bitte schließen Sie geöffnete Dateien bis 07:45 Uhr. Eine Statusmeldung erfolgt nach Abschluss der Arbeiten.

Ungeeignet:

> Am Wochenende finden Wartungsarbeiten statt.

---

**Unterschied zwischen Information und Handlungsaufforderung**

Benutzer sollten erkennen können, ob sie:

- nur informiert werden,
- etwas vorbereiten,
- eine Handlung ausführen,
- oder eine Rückmeldung geben

müssen.

Beispiel:

> **Keine Handlung erforderlich:** Die Aktualisierung wird automatisch installiert.

Beispiel:

> **Handlung erforderlich:** Speichern Sie Ihre Arbeit und starten Sie das Gerät spätestens am Freitag neu.

Eine klare Kennzeichnung reduziert Missverständnisse.

---

**Schriftliche Kommunikation**

Schriftliche Kommunikation sollte:

- einen eindeutigen Betreff,
- eine verständliche Einleitung,
- die wichtigste Aussage zuerst,
- klare Handlungsschritte,
- Zeitangaben,
- und einen erkennbaren Ansprechpartner

enthalten.

Ungeeigneter Betreff:

> Update

Besser:

> Status zum Ausfall der Dateiablage – nächstes Update um 15:00 Uhr

Ungeeignete Nachricht:

> Wir arbeiten daran.

Besser:

> Die Dateiablage ist weiterhin für die Standorte Nord und West nicht erreichbar. Der Provider untersucht aktuell die externe Verbindung. Lokal gespeicherte Dateien können weiterverwendet werden. Die nächste Statusmeldung erfolgt spätestens um 15:00 Uhr.

---

**E-Mail-Kommunikation strukturieren**

Eine praktische Struktur:

- Anlass
- aktueller Status
- Auswirkung
- Handlung des Benutzers
- nächster Schritt
- nächste Rückmeldung
- Vorgangsnummer

Beispiel:

> Guten Tag,
>
> der Zugriff auf das Abrechnungssystem ist seit 09:40 Uhr für mehrere Benutzer eingeschränkt.
>
> Das Anwendungsteam untersucht aktuell die Anmeldung. Bitte ändern Sie Ihr Kennwort nicht erneut, da das Problem nicht durch ein falsches Kennwort verursacht wird.
>
> Eine nächste Statusmeldung erfolgt spätestens um 11:00 Uhr.
>
> Vorgangsnummer: 4711

---

**Chat-Kommunikation**

Im Chat sollten Nachrichten:

- kurz,
- aber vollständig,
- in sinnvoller Reihenfolge,
- und ohne unklare Abkürzungen

geschrieben werden.

Ungeeignet:

> ok warte

Besser:

> Ich prüfe jetzt, ob bereits eine allgemeine Störung bekannt ist. Das dauert voraussichtlich wenige Minuten. Bitte lassen Sie das Chatfenster geöffnet.

Bei längerer Unterbrechung:

> Die Prüfung dauert länger als erwartet. Ich erstelle einen Vorgang und informiere Sie per E-Mail weiter. Ihre Vorgangsnummer lautet 4711.

---

**Telefonische Kommunikation**

Beim Telefonkontakt sind besonders wichtig:

- aktiv zuhören,
- langsam und deutlich sprechen,
- technische Schritte einzeln erklären,
- Pausen zulassen,
- Ergebnisse wiederholen lassen,
- und wichtige Vereinbarungen am Ende zusammenfassen.

Beispielabschluss:

> Wir haben die Anwendung neu angemeldet und der Zugriff funktioniert wieder. Ich dokumentiere die Lösung unter Vorgang 4711. Sollte die Meldung erneut erscheinen, rufen Sie bitte nicht alle Schritte erneut durch, sondern nennen Sie direkt diese Vorgangsnummer.

---

**Persönlicher Kontakt**

Beim Vor-Ort-Support sollte der Mitarbeiter:

- sich vorstellen,
- erklären, was geprüft wird,
- Zustimmung vor Eingriffen einholen,
- sensible Inhalte beachten,
- und das Ergebnis dokumentieren.

Ungeeignet:

- ohne Erklärung Maus und Tastatur übernehmen,
- private oder vertrauliche Dateien öffnen,
- oder den Arbeitsplatz verlassen, ohne das Ergebnis zu erklären.

---

**Kommunikation bei Remote-Support**

Vor einer Remote-Sitzung sollte geklärt werden:

- welches zugelassene Werkzeug verwendet wird,
- ob der Benutzer zustimmt,
- welche Aktionen durchgeführt werden,
- und wie die Sitzung beendet wird.

Geeignete Formulierung:

> Mit Ihrer Zustimmung starte ich eine Remote-Sitzung. Sie können alle Schritte sehen und die Sitzung jederzeit beenden. Ich prüfe nur die Einstellungen der betroffenen Anwendung. Bitte schließen Sie vorher vertrauliche Dokumente.

Während der Sitzung:

> Ich öffne jetzt die Anwendungsprotokolle. Dabei werden keine persönlichen Dateien verändert.

Nach der Sitzung:

> Die Remote-Verbindung ist beendet. Wir haben nur die Anwendungseinstellungen angepasst. Bitte testen Sie jetzt den vollständigen Arbeitsschritt.

---

**Fehler nicht vorschnell dem Benutzer zuschreiben**

Ungeeignet:

- Sie haben das falsch gemacht.
- Das Problem sitzt vor dem Bildschirm.
- Sie hätten die Anleitung lesen müssen.
- Warum haben Sie das nicht früher gemeldet?

Besser:

- Die bisherige Anleitung beschreibt den neuen Anmeldeweg nicht ausreichend.
- Der Zugriff wurde mit einer Rolle beantragt, die für diese Tätigkeit nicht ausreicht.
- Die Fehlermeldung macht nicht deutlich, welcher Schritt erforderlich ist.
- Für die weitere Untersuchung ist wichtig, wann das Problem erstmals aufgetreten ist.

Auch wenn ein Bedienfehler vorliegt, sollte die Organisation prüfen:

- War die Funktion verständlich?
- War die Anleitung auffindbar?
- War die Fehlermeldung hilfreich?
- Ist derselbe Fehler bei mehreren Benutzern aufgetreten?
- Kann das Design verbessert werden?

---

**Keine Schuldzuweisung zwischen Teams**

Ungeeignet gegenüber Benutzern:

- Das Netzwerkteam hat wieder etwas falsch konfiguriert.
- Der Hersteller ist schuld.
- Die Entwicklung bekommt das nie richtig hin.
- Dafür ist der Service Desk nicht verantwortlich.

Besser:

- Das Netzwerkteam prüft aktuell die Verbindung.
- Wir haben den Hersteller einbezogen und koordinieren die weitere Bearbeitung.
- Die Ursache liegt möglicherweise in der aktuellen Anwendungsversion und wird untersucht.
- Der Vorgang benötigt zusätzliche technische Analyse. Ich sorge für die Weitergabe und halte Sie informiert.

Interne Ursachen können später sachlich untersucht werden.

Die Benutzerkommunikation sollte nicht zur öffentlichen Schuldzuweisung verwendet werden.

---

**Umgang mit verärgerten Benutzern**

Ein verärgerter Benutzer kann:

- laut sprechen,
- wiederholt nachfragen,
- Vorwürfe äußern,
- oder eine sofortige Lösung verlangen.

Eine mögliche Vorgehensweise:

1. nicht sofort in die Verteidigung gehen
2. ausreden lassen, soweit möglich
3. Auswirkung anerkennen
4. Sachverhalt zusammenfassen
5. konkrete nächste Schritte nennen
6. realistische Grenzen erklären
7. vereinbaren, wann die nächste Information erfolgt

Beispiel:

> Ich verstehe, dass der wiederholte Ausfall Ihren Monatsabschluss erheblich behindert. Der Service ist noch nicht stabil. Das Anwendungsteam und der Hersteller arbeiten gemeinsam an der Ursache. Als Zwischenlösung können Sie die Buchungen derzeit über Arbeitsplatz 4 durchführen. Ich informiere Sie spätestens um 13:00 Uhr erneut.

---

**Nicht jede Beschwerde persönlich nehmen**

Benutzerfrust richtet sich häufig gegen:

- die Unterbrechung,
- wiederholte Fehler,
- fehlende Informationen,
- oder die Organisation insgesamt.

Mitarbeiter sollten Beschwerden ernst nehmen, ohne jede Aussage als persönliche Bewertung zu übernehmen.

Gleichzeitig muss respektloses Verhalten nicht unbegrenzt akzeptiert werden.

---

**Grenzen bei aggressivem oder beleidigendem Verhalten**

Professioneller Umgang gilt für alle Beteiligten.

Mitarbeiter müssen:

- Beleidigungen,
- Drohungen,
- Diskriminierung,
- oder gezielte Einschüchterung

nicht akzeptieren.

Eine mögliche Reaktion:

> Ich möchte Ihr Anliegen gern weiter bearbeiten. Dafür benötige ich ein respektvolles Gespräch. Wenn die Beleidigungen fortgesetzt werden, muss ich den Kontakt beenden und nach unserem Eskalationsverfahren weitergeben.

Bei konkreten Drohungen oder Sicherheitsrisiken sind die internen Sicherheits- und Eskalationsverfahren anzuwenden.

> **Wichtig**
>
> Empathie bedeutet nicht, missbräuchliches Verhalten hinzunehmen.

---

**Deeskalation**

Hilfreiche Maßnahmen:

- ruhig und langsam sprechen,
- nicht gleichzeitig widersprechen und erklären,
- keine Ironie verwenden,
- konkrete Fakten nennen,
- Handlungsmöglichkeiten anbieten,
- Verantwortung für den nächsten Schritt übernehmen,
- und unbelegten Versprechen widerstehen.

Ungeeignet:

> Wenn Sie mich nicht ausreden lassen, kann ich auch nichts machen.

Besser:

> Ich möchte die Situation lösen. Dafür fasse ich kurz zusammen, was bereits bekannt ist, und erkläre anschließend die zwei möglichen nächsten Schritte.

---

**Umgang mit Beschwerden**

Eine Beschwerde kann Hinweise liefern auf:

- schlechte Kommunikation,
- unklare Erwartungen,
- wiederkehrende Störungen,
- ungeeignete Prozesse,
- fehlende Barrierefreiheit,
- oder nicht erfüllte Serviceziele.

Eine Beschwerde sollte:

- sachlich erfasst,
- nicht abgewertet,
- entsprechend ihrer Bedeutung eskaliert,
- und hinsichtlich möglicher Verbesserungen ausgewertet

werden.

Geeignete Antwort:

> Vielen Dank für die konkrete Rückmeldung. Sie haben an drei aufeinanderfolgenden Tagen keine angekündigte Statusmeldung erhalten. Ich dokumentiere das als Abweichung und lasse zusätzlich prüfen, warum die Kommunikationsintervalle nicht eingehalten wurden.

Ungeeignet:

> Dafür müssen Sie sich an jemand anderen wenden.

---

**Umgang mit Führungskräften und wichtigen Stakeholdern**

Hierarchische Positionen können besondere Informationsbedürfnisse erzeugen.

Sie dürfen jedoch nicht automatisch:

- Sicherheitskontrollen aufheben,
- Prioritätskriterien ersetzen,
- oder andere kritische Incidents verdrängen.

Professionelle Kommunikation:

> Ich verstehe die geschäftliche Bedeutung Ihres Termins. Für eine höhere Priorität benötige ich noch die Information, ob weitere Benutzer oder ein zentraler Geschäftsprozess betroffen sind. Die Identitätsprüfung für den Zugriff muss trotzdem vollständig durchgeführt werden.

Bei Bedarf kann eine hierarchische Eskalation erfolgen.

---

**Umgang mit wiederholten Nachfragen**

Wiederholte Nachfragen können ein Hinweis sein auf:

- fehlende Statusinformationen,
- unklare Zuständigkeit,
- schlechte Erwartungssteuerung,
- oder hohe geschäftliche Auswirkungen.

Die Antwort sollte nicht nur lauten:

> Wir arbeiten noch daran.

Besser:

> Seit der letzten Meldung wurde der Fehler auf die Verbindung zwischen Anwendung und Datenbank eingegrenzt. Das Datenbankteam prüft aktuell die fehlgeschlagenen Verbindungen. Eine Wiederherstellungszeit liegt noch nicht vor. Die nächste Statusmeldung erfolgt um 16:00 Uhr.

---

**Umgang mit nicht erfüllbaren Forderungen**

Manche Forderungen können nicht erfüllt werden, weil sie:

- technisch unmöglich,
- nicht genehmigt,
- sicherheitswidrig,
- rechtlich unzulässig,
- oder außerhalb des Serviceumfangs

sind.

Eine professionelle Ablehnung enthält möglichst:

1. klare Aussage
2. verständliche Begründung
3. mögliche Alternative
4. gegebenenfalls Eskalations- oder Antragsweg

Beispiel:

> Ich kann die Mehrfaktor-Authentifizierung nicht dauerhaft deaktivieren, da sie für administrative Konten verbindlich ist. Ich kann jedoch prüfen, ob ein zugelassenes alternatives Authentifizierungsverfahren für Ihr Gerät eingerichtet werden kann.

---

**„Nein“ verständlich erklären**

Ungeeignet:

> Das geht nicht. Prozess ist Prozess.

Besser:

> Der direkte Zugriff kann nicht eingerichtet werden, weil dadurch personenbezogene Daten ohne die erforderliche Berechtigung sichtbar wären. Möglich ist stattdessen ein Antrag auf die freigegebene Leseberechtigung. Ich sende Ihnen das passende Serviceangebot.

---

**Kommunikation bei Fehlern der Serviceorganisation**

Hat die Serviceorganisation einen Fehler verursacht, sollte sie:

- den Fehler nicht verschleiern,
- die bekannte Auswirkung benennen,
- notwendige Korrekturen erklären,
- und keine unbelegten Schuldzuweisungen vornehmen.

Beispiel:

> Bei der gestrigen Änderung wurde eine benötigte Berechtigungsgruppe nicht übernommen. Dadurch konnten zwölf Benutzer die Anwendung heute Morgen nicht öffnen. Die Gruppe wurde wiederhergestellt. Wir prüfen zusätzlich, warum der Test die fehlende Berechtigung nicht erkannt hat.

Ungeeignet:

> Es gab ein kleines technisches Problem.

wenn die tatsächliche Auswirkung erheblich war.

---

**Entschuldigung professionell verwenden**

Eine Entschuldigung sollte konkret und angemessen sein.

Geeignet:

> Es tut uns leid, dass Sie trotz der zugesagten Rückmeldung keine Statusinformation erhalten haben.

Weniger hilfreich:

> Entschuldigung für die Unannehmlichkeiten.

ohne zu benennen, was geschehen ist.

Eine Entschuldigung ersetzt nicht:

- Korrektur,
- Information,
- Verantwortung,
- oder Verbesserung.

---

**Kommunikation bei Major Incidents**

Bei einem Major Incident müssen Informationen:

- konsistent,
- zeitnah,
- zielgruppengerecht,
- und kontrolliert

bereitgestellt werden.

Zu klären sind:

- Wer darf offizielle Statusmeldungen veröffentlichen?
- Welche Informationen sind bestätigt?
- Welche Vermutungen dürfen nicht veröffentlicht werden?
- Welche Zielgruppen benötigen welche Details?
- Welche Intervalle gelten?
- Welche Kanäle werden verwendet?
- Wer genehmigt sensible Aussagen?
- Wie wird die Abschlussinformation gestaltet?

---

**Inhalt einer Major-Incident-Meldung**

Eine erste Meldung kann enthalten:

- betroffener Service,
- bekannte Auswirkung,
- Beginn,
- aktueller Bearbeitungsstatus,
- mögliche Zwischenlösung,
- und nächster Aktualisierungszeitpunkt.

Beispiel:

> Seit 08:45 Uhr ist die zentrale Anmeldung für mehrere interne Anwendungen gestört. Benutzer können sich teilweise nicht neu anmelden. Bereits aktive Sitzungen sind nach aktuellem Stand nicht betroffen. Die zuständigen Identitäts- und Anwendungsteams untersuchen die Ursache. Bitte ändern Sie Ihr Kennwort nicht. Die nächste Statusmeldung erfolgt spätestens um 09:30 Uhr.

---

**Keine unbestätigten Ursachen veröffentlichen**

Ungeeignet:

> Der Ausfall wurde durch einen Cyberangriff verursacht.

wenn dies noch nicht bestätigt ist.

Besser:

> Die Ursache wird untersucht. Das Informationssicherheitsteam ist vorsorglich einbezogen. Eine bestätigte Sicherheitsauswirkung liegt derzeit noch nicht vor.

---

**Abschlusskommunikation nach einem Major Incident**

Eine Abschlussmeldung kann enthalten:

- Zeitpunkt der Wiederherstellung,
- bestätigten aktuellen Zustand,
- mögliche Restbeeinträchtigungen,
- notwendige Benutzeraktionen,
- und Hinweis auf weitere Untersuchung.

Beispiel:

> Der Anmeldeservice ist seit 12:20 Uhr wieder verfügbar. Neue Anmeldungen funktionieren nach aktueller Prüfung. Benutzer mit einer weiterhin angezeigten Fehlermeldung sollen die Anwendung einmal vollständig schließen und erneut öffnen. Die zugrunde liegende Ursache wird noch untersucht. Weitere Erkenntnisse fließen in die nachgelagerte Incident-Überprüfung ein.

---

**Kommunikation bei Sicherheitsvorfällen**

Bei möglichen Sicherheitsvorfällen gelten häufig besondere Regeln.

Der Service Desk sollte:

- nur freigegebene Aussagen verwenden,
- keine unbestätigten Details verbreiten,
- sensible Informationen schützen,
- keine Beweise verändern,
- und das zuständige Sicherheitsteam einbeziehen.

Ungeeignet:

> Ihr Konto wurde gehackt.

Besser:

> Es gibt Hinweise auf eine möglicherweise unberechtigte Anmeldung. Das Sicherheitsteam prüft den Vorgang. Bitte verwenden Sie das betroffene Konto bis zur weiteren Rückmeldung nicht.

Die genaue Kommunikation richtet sich nach dem Sicherheitsverfahren der Organisation.

---

**Datenschutz in der Kommunikation**

Kommunikation kann personenbezogene oder vertrauliche Informationen enthalten.

Zu vermeiden sind:

- unnötige Empfänger,
- vollständige vertrauliche Dokumente,
- Kennwörter,
- private Gesundheitsinformationen ohne erforderlichen Zweck,
- technische Zugangsdaten,
- oder interne Sicherheitsdetails in offenen Kanälen.

Vor dem Versand sollte geprüft werden:

- Wer benötigt die Information?
- Ist der Kanal geeignet?
- Kann der Inhalt minimiert werden?
- Müssen Anhänge geschützt werden?
- Ist die Identität des Empfängers ausreichend geprüft?

---

**Adressaten und Verteiler prüfen**

Besonders bei größeren Störungen kann eine falsche Empfängerliste:

- vertrauliche Informationen offenlegen,
- unnötige Unruhe erzeugen,
- oder Personen mit irrelevanten Meldungen überlasten.

Vor dem Versand:

- Empfängerkreis prüfen,
- offene und verborgene Empfänger angemessen verwenden,
- automatische Verteiler verstehen,
- und gegebenenfalls Freigabe einholen.

---

**Barrierearme Kommunikation**

Professionelle Kommunikation berücksichtigt unterschiedliche Fähigkeiten und Voraussetzungen.

Mögliche Maßnahmen:

- verständliche Sprache,
- gut strukturierte Texte,
- ausreichende Kontraste in Statusseiten,
- keine Information ausschließlich durch Farbe,
- Untertitel oder Textalternativen,
- zugängliche Dokumente,
- alternative Kontaktkanäle,
- und ausreichend Zeit für Rückfragen.

Ein Benutzer darf nicht als schwierig bewertet werden, weil er:

- mehr Zeit benötigt,
- einen anderen Kommunikationskanal bevorzugt,
- technische Anweisungen wiederholen lässt,
- oder Unterstützung aufgrund einer Einschränkung benötigt.

---

**Mehrsprachige Kommunikation**

Bei mehrsprachigen Benutzern sollte geklärt sein:

- welche Sprachen unterstützt werden,
- welche Sprache für technische Dokumentation gilt,
- wann Übersetzung verwendet wird,
- und wie kritische Aussagen überprüft werden.

Automatische Übersetzung kann unterstützen, muss aber bei wichtigen Inhalten kontrolliert werden.

Besonders kritisch sind:

- Sicherheitsanweisungen,
- rechtliche Hinweise,
- Datenverlustwarnungen,
- und technische Maßnahmen mit hohem Risiko.

---

**Kulturelle Unterschiede**

Kommunikationsstile können sich unterscheiden hinsichtlich:

- Direktheit,
- Höflichkeitsformen,
- Umgang mit Hierarchie,
- Rückfragen,
- und Ausdruck von Kritik.

Professioneller Umgang bedeutet:

- keine vorschnellen Bewertungen,
- verständliche und respektvolle Sprache,
- und Nachfrage bei möglichen Missverständnissen.

Es dürfen keine Annahmen über Fähigkeiten oder Verhalten allein aufgrund von:

- Herkunft,
- Sprache,
- Alter,
- Geschlecht,
- Position,
- oder anderen persönlichen Merkmalen

getroffen werden.

---

**Interne Kommunikation zwischen Supportgruppen**

Benutzerkommunikation kann nur zuverlässig sein, wenn auch die interne Kommunikation funktioniert.

Eine interne Übergabe sollte enthalten:

- betroffenen Service,
- genaue Auswirkung,
- bisherige Diagnose,
- Ergebnisse,
- bereits durchgeführte Maßnahmen,
- relevante Zeitpunkte,
- gewünschte Unterstützung,
- und aktuelle Benutzerkommunikation.

Ungeeignet:

> Bitte übernehmen.

Besser:

> Seit 10:05 Uhr können alle zwölf Benutzer am Standort Süd keine Verbindung zum Warenwirtschaftssystem herstellen. DNS und allgemeine Internetverbindung funktionieren. Der Zugriff auf TCP-Port 443 der Zieladresse schlägt nur vom Standort Süd fehl. Der Standort-Router wurde nicht neu gestartet. Benötigt wird die Prüfung von Standorttunnel und Firewall. Nächste Benutzerinformation ist für 11:00 Uhr angekündigt.

---

**Kommunikation bei Schicht- oder Teamübergaben**

Eine Übergabe sollte nicht nur den Ticketstatus nennen.

Hilfreich sind:

- aktueller technischer Zustand,
- bekannte Auswirkungen,
- offene Hypothesen,
- nächste geplante Maßnahme,
- ausstehende Entscheidung,
- Kommunikationszeitpunkt,
- und verantwortliche Rolle.

Beispiel:

> Der Service ist teilweise wiederhergestellt. Neue Benutzer können sich anmelden, bestehende Sitzungen zeigen vereinzelt Fehler. Der Hersteller prüft noch die Protokolle. Keine weitere Konfigurationsänderung ohne Abstimmung mit der Incident-Koordination. Nächstes Benutzerupdate um 18:00 Uhr.

---

**Kommunikationsverantwortung klären**

Bei mehreren beteiligten Teams sollte festgelegt sein:

- Wer spricht mit dem Benutzer?
- Wer veröffentlicht allgemeine Statusmeldungen?
- Wer kommuniziert mit dem Lieferanten?
- Wer informiert Führungskräfte?
- Wer dokumentiert technische Details?
- Wer genehmigt sensible Aussagen?

Andernfalls entstehen möglicherweise:

- widersprüchliche Informationen,
- doppelte Nachrichten,
- unbestätigte Aussagen,
- oder lange Kommunikationslücken.

---

**Vorlagen und Textbausteine**

Vorlagen können Kommunikation:

- beschleunigen,
- vereinheitlichen,
- und bei Stress unterstützen.

Sie dürfen jedoch nicht unreflektiert verwendet werden.

Eine Vorlage sollte angepasst werden an:

- tatsächlichen Sachverhalt,
- Zielgruppe,
- Auswirkungen,
- nächsten Schritt,
- und aktuellen Zeitpunkt.

Ungeeigneter Textbaustein:

> Ihr Anliegen wurde erfolgreich gelöst.

wenn der Benutzer die Funktion noch nicht bestätigt hat.

Besser:

> Die technische Funktion wurde wiederhergestellt. Bitte prüfen Sie, ob Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen können.

---

**Beispiel: Eingangsbestätigung**

> Ihre Meldung wurde unter der Vorgangsnummer 4711 erfasst.
>
> Betroffener Service: zentrale Dateiablage  
> Gemeldete Auswirkung: Dateien lassen sich nicht öffnen
>
> Der Service Desk prüft zunächst, ob eine allgemeine Störung vorliegt. Die nächste Rückmeldung erfolgt innerhalb der vereinbarten Servicezeit.

---

**Beispiel: Rückfrage**

> Für die weitere Analyse benötigen wir noch folgende Information:
>
> - genaue Fehlermeldung,
> - Zeitpunkt des letzten erfolgreichen Zugriffs,
> - und die Angabe, ob weitere Benutzer betroffen sind.
>
> Bitte senden Sie keine Kennwörter oder vollständigen vertraulichen Dokumente.

---

**Beispiel: Weiterleitung**

> Die erste Prüfung zeigt, dass zusätzliche Analyse durch das Netzwerkteam erforderlich ist.
>
> Der Vorgang wurde mit den bisherigen Prüfergebnissen weitergegeben. Der Service Desk bleibt Ihr Kontaktpunkt. Die nächste Statusmeldung erfolgt spätestens um 14:00 Uhr.

---

**Beispiel: Verzögerung**

> Die Bearbeitung dauert länger als zunächst erwartet, weil zusätzliche Protokolldaten des Herstellers benötigt werden.
>
> Die Störung wird weiterhin aktiv untersucht. Die bisherige Zwischenlösung bleibt gültig. Die nächste Aktualisierung erfolgt spätestens um 16:30 Uhr.

---

**Beispiel: Wiederherstellung**

> Der Zugriff auf die Anwendung ist wiederhergestellt.
>
> Bitte melden Sie sich erneut an und führen Sie den zuvor fehlgeschlagenen Arbeitsschritt vollständig durch. Teilen Sie uns anschließend kurz mit, ob die Funktion wieder wie erwartet arbeitet.

---

**Beispiel: Abschluss**

> Sie haben bestätigt, dass die Anwendung wieder vollständig nutzbar ist.
>
> Ursache war eine fehlerhafte Berechtigungszuordnung. Diese wurde korrigiert. Der Vorgang 4711 wird abgeschlossen.
>
> Die wiederkehrende Ursache wird zusätzlich durch Problem Management untersucht.

---

**Beispiel: Ablehnung mit Alternative**

> Die gewünschte lokale Administratorberechtigung kann nicht dauerhaft freigegeben werden, da sie nicht dem Sicherheitsstandard für Arbeitsplatzgeräte entspricht.
>
> Für die Installation der benötigten Anwendung steht ein genehmigtes Serviceangebot zur Verfügung. Ich habe Ihnen den entsprechenden Antrag verlinkt.

---

**KI-gestützte Kommunikation**

KI kann unterstützen bei:

- Zusammenfassung von Gesprächen,
- Übersetzung,
- Vorschlägen für Antworten,
- Anpassung der Detailtiefe,
- Erkennung wiederkehrender Themen,
- und Erstellung erster Statusentwürfe.

Mögliche Vorteile:

- schnellere Erstellung,
- einheitlichere Formulierungen,
- Unterstützung mehrsprachiger Kontakte,
- und Entlastung bei wiederkehrenden Mitteilungen.

Mögliche Risiken:

- erfundene Fakten,
- falsche technische Aussagen,
- unangemessener Ton,
- Weitergabe vertraulicher Daten,
- falsche Priorisierung,
- und fehlender Bezug zur tatsächlichen Situation.

---

**KI-Ausgaben prüfen**

Vor dem Versand einer KI-gestützten Antwort sollte geprüft werden:

- Stimmen alle Tatsachen?
- Ist der aktuelle Status korrekt?
- Ist die Zielgruppe richtig angesprochen?
- Sind keine vertraulichen Informationen enthalten?
- Werden keine unbelegten Zusagen gemacht?
- Ist die technische Anleitung sicher?
- Ist der nächste Schritt eindeutig?
- Ist eine menschliche Übergabe erforderlich?

> **Sicherheitsrelevant**
>
> KI darf keine unbekannten technischen Schritte oder produktiven Änderungen allein aufgrund plausibel klingender Formulierungen veranlassen.

---

**Automatisierte Nachrichten menschlich und präzise gestalten**

Ungeeignet:

> Ihr Ticket wurde aktualisiert.

Besser:

> Das Anwendungsteam hat die Analyse übernommen. Für die weitere Prüfung werden derzeit die Anmeldeprotokolle ausgewertet. Sie müssen aktuell nichts weiter tun. Die nächste Statusmeldung erfolgt spätestens um 12:00 Uhr.

Automatisierung darf nicht nur interne Statuscodes an Benutzer weitergeben.

---

**Kommunikationsqualität messen**

Mögliche Informationen:

| Messgröße | Mögliche Aussage |
|---|---|
| Benutzerzufriedenheit | allgemeine Wahrnehmung des Kontakts |
| wahrgenommener Aufwand | wie aufwendig der Kontakt für den Benutzer war |
| Verständlichkeit | ob Informationen und Anweisungen verstanden wurden |
| Vertrauen | ob Benutzer Aussagen und Zusagen als verlässlich erleben |
| Wiederholungskontakte | mögliche Hinweise auf fehlende Information oder Lösung |
| eingehaltene Statuszusagen | Zuverlässigkeit der Kommunikation |
| Anzahl notwendiger Rückfragen | mögliche Hinweise auf unvollständige Erfassung |
| Beschwerden | Hinweise auf wiederkehrende Kommunikationsprobleme |
| Kanalwechsel | möglicher Hinweis auf ungeeigneten Erstkanal |
| Wiedereröffnungsquote | möglicher Hinweis auf voreiligen Abschluss |
| Benutzerbestätigung | ob das gewünschte Ergebnis tatsächlich erreicht wurde |

Eine einzelne Zufriedenheitszahl reicht nicht aus.

---

**Feedback richtig einordnen**

Eine negative Bewertung kann sich beziehen auf:

- den Mitarbeiter,
- die lange Wartezeit,
- die technische Produktqualität,
- fehlende Befugnisse,
- einen Lieferanten,
- oder eine organisatorische Vorgabe.

Vor Schlussfolgerungen sollte geprüft werden:

- Was genau wurde bewertet?
- War die Frage verständlich?
- Wie hoch ist die Rücklaufquote?
- Bestehen wiederkehrende Muster?
- Welche Verbesserung ist tatsächlich möglich?

Mitarbeiter sollten nicht allein anhand einzelner emotionaler Bewertungen beurteilt werden.

---

**Kommunikationsreviews**

Eine Organisation kann ausgewählte Kontakte prüfen auf:

- sachliche Richtigkeit,
- Verständlichkeit,
- Respekt,
- Vollständigkeit,
- Datenschutz,
- Sicherheitskonformität,
- Erwartungssteuerung,
- und Ergebnisorientierung.

Die Prüfung sollte der:

- Entwicklung,
- Schulung,
- und Verbesserung

dienen.

Sie sollte nicht ausschließlich als Überwachung oder Fehlersuche wahrgenommen werden.

---

**Gesundheit und emotionale Belastung der Mitarbeiter**

Service-Desk-Mitarbeiter bearbeiten möglicherweise:

- verärgerte Benutzer,
- kritische Ausfälle,
- Datenverluste,
- Sicherheitsvorfälle,
- und dauerhaft hohe Kontaktmengen.

Organisationen sollten berücksichtigen:

- ausreichende Pausen,
- erreichbare Führungskräfte,
- Unterstützung nach belastenden Kontakten,
- klare Grenzen bei missbräuchlichem Verhalten,
- realistische Kennzahlen,
- und angemessene Personalkapazität.

> **Merke**
>
> Empathische Kommunikation ist qualifizierte Arbeit.
>
> Sie benötigt Fähigkeiten, Unterstützung und ausreichende Arbeitsbedingungen.

---

**Continual Improvement der Kommunikation**

Verbesserungsmöglichkeiten können entstehen durch:

- Benutzerfeedback,
- Beschwerden,
- wiederholte Rückfragen,
- abgebrochene Kontakte,
- unklare Statusmeldungen,
- Fehler in Vorlagen,
- und Erfahrungen aus Major Incidents.

Mögliche Verbesserungen:

- Textbausteine überarbeiten,
- Fachbegriffe vereinfachen,
- Statusintervalle definieren,
- Kommunikationsverantwortung klären,
- Mitarbeiterschulungen durchführen,
- Portaltexte verbessern,
- sichere Übersetzungsunterstützung bereitstellen,
- und Zielgruppen genauer unterscheiden.

---

**Praxisbeispiel: keine Anmeldung möglich**

Benutzer:

> Ich kann mich nicht anmelden und brauche die Anwendung sofort.

Ungeeignete Antwort:

> Haben Sie Ihr Kennwort falsch eingegeben?

Bessere Antwort:

> Ich verstehe, dass Sie die Anwendung gerade benötigen. Ich kläre zunächst, ob Ihr Konto oder der gesamte Anmeldedienst betroffen ist. Welche Meldung wird angezeigt und können sich Kollegen in derselben Anwendung anmelden?

Nach der Prüfung:

> Weitere Benutzer sind ebenfalls betroffen. Ihr Kennwort ist deshalb wahrscheinlich nicht die Ursache. Der Identitätsdienst wird bereits untersucht. Bitte ändern Sie Ihr Kennwort nicht erneut. Die nächste Statusmeldung erfolgt um 10:30 Uhr.

---

**Praxisbeispiel: verlorene Datei**

Benutzer:

> Meine Datei ist weg. Da waren zwei Tage Arbeit drin.

Ungeeignet:

> Sie hätten regelmäßig speichern müssen.

Bessere Antwort:

> Ich verstehe, dass der mögliche Verlust sehr belastend ist. Bitte speichern oder überschreiben Sie an diesem Speicherort zunächst nichts weiter. Ich prüfe, ob eine frühere Version oder Sicherung verfügbar ist. Wann und unter welchem Namen wurde die Datei zuletzt gespeichert?

Wichtig:

- keine Schuldzuweisung,
- keine unbelegte Wiederherstellungszusage,
- und keine Maßnahmen, die vorhandene Wiederherstellungsmöglichkeiten gefährden.

---

**Praxisbeispiel: angekündigter Rückruf wurde vergessen**

Benutzer:

> Mir wurde gestern ein Rückruf versprochen. Es hat sich niemand gemeldet.

Geeignete Antwort:

> Das hätte nicht passieren dürfen. Der zugesagte Rückruf wurde nicht durchgeführt. Ich prüfe jetzt den aktuellen Bearbeitungsstand und übernehme die Koordination. Sie erhalten spätestens um 11:00 Uhr eine Rückmeldung von mir, auch wenn die technische Analyse dann noch läuft.

Zusätzlich sollte intern geprüft werden:

- Warum ging die Zusage verloren?
- War kein Verantwortlicher eingetragen?
- Fehlte eine Erinnerung?
- War die Kapazität unzureichend?
- Muss der Arbeitsablauf verbessert werden?

---

**Praxisbeispiel: Sicherheitskontrolle wird unter Zeitdruck abgelehnt**

Benutzer:

> Ich bin in fünf Minuten im Termin. Setzen Sie das Kennwort einfach zurück.

Geeignete Antwort:

> Ich verstehe den Zeitdruck. Die Identitätsprüfung kann ich trotzdem nicht überspringen, weil dadurch ein fremdes Konto übernommen werden könnte. Wir führen jetzt das vorgesehene schnelle Prüfverfahren durch. Danach kann ich die Zurücksetzung sofort veranlassen.

---

**Praxisbeispiel: technisches Team benötigt mehr Zeit**

Statusmeldung:

> Die Anwendung ist weiterhin nicht verfügbar. Das Team hat die Datenbankverbindung als Fehlerbereich eingegrenzt, aber die genaue Ursache ist noch nicht bestätigt. Eine Wiederherstellungsschätzung liegt deshalb noch nicht vor. Die alternative Anwendung kann weiterhin verwendet werden. Nächste Statusmeldung: 15:30 Uhr.

Diese Meldung:

- benennt den aktuellen Stand,
- vermeidet eine ungesicherte Zeitangabe,
- nennt eine Alternative,
- und gibt einen verbindlichen nächsten Informationszeitpunkt.

---

**Praxisbeispiel: Ticket wurde voreilig geschlossen**

Benutzer:

> Das Ticket ist geschlossen, aber der Fehler ist noch da.

Geeignete Antwort:

> Danke für den Hinweis. Der Vorgang wurde zu früh geschlossen. Ich öffne ihn erneut und dokumentiere, dass die technische Maßnahme das Benutzerproblem nicht gelöst hat. Wir prüfen jetzt den vollständigen Arbeitsschritt noch einmal.

Anschließend sollte untersucht werden:

- Wurde nur eine technische Komponente geprüft?
- Fehlte die Benutzerbestätigung?
- Belohnte eine Kennzahl den schnellen Abschluss?
- War die Abschlussregel unklar?

---

**Typische Kommunikationsfehler**

**Fehler 1: Zu früh eine Lösung vermuten**

Der Benutzer wird in eine falsche Diagnoserichtung gelenkt.

---

**Fehler 2: Fachbegriffe ohne Erklärung verwenden**

Der Benutzer versteht weder Situation noch nächsten Schritt.

---

**Fehler 3: Auswirkungen verharmlosen**

Die technische Störung wirkt klein, blockiert aber einen wichtigen Arbeitsprozess.

---

**Fehler 4: Unbelegte Zeitversprechen geben**

Vertrauen sinkt, sobald die Zusage nicht eingehalten wird.

---

**Fehler 5: Nur bei neuen Erkenntnissen informieren**

Benutzer bleiben lange ohne Status.

---

**Fehler 6: „Ich gebe es weiter“ ohne Verantwortung**

Nächster Schritt, Kommunikationsweg und Zuständigkeit bleiben unklar.

---

**Fehler 7: Benutzer oder andere Teams beschuldigen**

Zusammenarbeit und Vertrauen werden beschädigt.

---

**Fehler 8: Empathie mit Zustimmung verwechseln**

Prioritäts-, Sicherheits- oder Genehmigungsregeln werden unnötig aufgegeben.

---

**Fehler 9: Standardtexte unverändert senden**

Die Nachricht passt nicht zur tatsächlichen Situation.

---

**Fehler 10: Technische Wiederherstellung mit Benutzer-Outcome verwechseln**

Ticket wird geschlossen, obwohl die Tätigkeit weiterhin nicht möglich ist.

---

**Fehler 11: Verärgerte Benutzer persönlich angreifen**

Die Situation eskaliert weiter.

---

**Fehler 12: Beleidigungen unbegrenzt akzeptieren**

Mitarbeiterschutz und professionelle Grenzen fehlen.

---

**Fehler 13: Sensible Informationen im falschen Kanal teilen**

Datenschutz- oder Sicherheitsrisiken entstehen.

---

**Fehler 14: Widersprüchliche Meldungen mehrerer Teams**

Es fehlt eine geklärte Kommunikationsverantwortung.

---

**Fehler 15: KI-Entwürfe ungeprüft versenden**

Falsche Aussagen oder unangemessene Formulierungen erreichen Benutzer.

---

**Bedeutung für Fachinformatiker für Systemintegration**

Fachinformatiker kommunizieren nicht nur innerhalb des Service Desk.

Sie kommunizieren ebenfalls bei:

- technischen Rückfragen,
- Remote-Support,
- Changes,
- Wartungsarbeiten,
- Incidents,
- Lieferantenkontakten,
- und Übergaben an andere Teams.

Eine gute technische Rückmeldung sollte beantworten:

- Was wurde geprüft?
- Welches Ergebnis liegt vor?
- Was ist weiterhin unbekannt?
- Welche Auswirkungen bestehen?
- Was ist der nächste Schritt?
- Wer übernimmt ihn?
- Wann ist mit einer Rückmeldung zu rechnen?
- Welche Benutzerinformation ist geeignet?

Ungeeignete technische Rückmeldung:

> Server läuft wieder.

Besser:

> Der Anwendungsdienst wurde um 14:20 Uhr wiederhergestellt. Technische Funktionsprüfungen sind erfolgreich. Zwei Testbenutzer konnten sich anmelden und Datensätze speichern. Der Service wird bis 16:00 Uhr verstärkt überwacht. Die Ursache wird noch durch Problem Management untersucht.

---

**30-Sekunden-Prüfung einer Benutzerkommunikation**

1. **Zielgruppe:** Mit wem kommuniziere ich?
2. **Anliegen:** Was benötigt die Person tatsächlich?
3. **Auswirkung:** Welche Arbeit oder welches Outcome ist betroffen?
4. **Verständlichkeit:** Ist die Sprache für die Zielgruppe geeignet?
5. **Fakten:** Welche Aussagen sind bestätigt?
6. **Unsicherheit:** Was ist noch nicht bekannt?
7. **Handlung:** Was geschieht als Nächstes?
8. **Verantwortung:** Wer übernimmt die nächste Aufgabe?
9. **Zeit:** Wann folgt die nächste Information?
10. **Sicherheit:** Darf der Inhalt über diesen Kanal geteilt werden?
11. **Ergebnis:** Wie wird das Outcome bestätigt?
12. **Respekt:** Ist die Formulierung sachlich und professionell?

---

**Checkliste für ein professionelles Gespräch**

- [ ] Wurde freundlich und eindeutig eröffnet?
- [ ] Wurde die Identität bei Bedarf geprüft?
- [ ] Konnte der Benutzer das Anliegen zunächst beschreiben?
- [ ] Wurden gezielte Rückfragen gestellt?
- [ ] Wurden Auswirkungen und Umfang verstanden?
- [ ] Wurde das Verstandene zusammengefasst?
- [ ] Wurden Fachbegriffe erklärt oder vermieden?
- [ ] Wurde der nächste Schritt beschrieben?
- [ ] Wurden keine unbelegten Zusagen gemacht?
- [ ] Wurde ein nächster Informationszeitpunkt genannt?
- [ ] Wurde das Ergebnis aus Benutzersicht geprüft?
- [ ] Wurde der Kontakt klar abgeschlossen?

---

**Checkliste für schriftliche Nachrichten**

- [ ] Ist der Betreff eindeutig?
- [ ] Steht die wichtigste Information am Anfang?
- [ ] Ist der betroffene Service genannt?
- [ ] Sind bekannte Auswirkungen beschrieben?
- [ ] Sind Fakten und Vermutungen getrennt?
- [ ] Ist eine Handlung des Benutzers eindeutig gekennzeichnet?
- [ ] Ist der nächste Schritt genannt?
- [ ] Ist der nächste Statuszeitpunkt angegeben?
- [ ] Sind technische Begriffe für die Zielgruppe verständlich?
- [ ] Sind Empfänger und Kanal datenschutzgerecht?
- [ ] Wurden vertrauliche Details entfernt?
- [ ] Ist die Vorgangsnummer enthalten?

---

**Checkliste für Statusmeldungen**

- [ ] Was ist betroffen?
- [ ] Seit wann besteht die Situation?
- [ ] Welche Auswirkungen sind bekannt?
- [ ] Welche Bearbeitung läuft?
- [ ] Welche Informationen sind bestätigt?
- [ ] Gibt es eine Zwischenlösung?
- [ ] Müssen Benutzer etwas tun?
- [ ] Wann folgt die nächste Meldung?
- [ ] Ist die Zielgruppe richtig gewählt?
- [ ] Ist die Aussage mit der Incident-Koordination abgestimmt?
- [ ] Wurden Sicherheits- und Datenschutzanforderungen beachtet?

---

**Checkliste für schwierige Gespräche**

- [ ] Bleibt die eigene Stimme ruhig und sachlich?
- [ ] Wurde die Auswirkung anerkannt?
- [ ] Wurde nicht vorschnell widersprochen?
- [ ] Wurden Fakten und nächste Schritte genannt?
- [ ] Wurden klare Grenzen erklärt?
- [ ] Werden Sicherheitskontrollen nicht umgangen?
- [ ] Wurde ein realistischer nächster Zeitpunkt vereinbart?
- [ ] Ist bei Beleidigungen oder Drohungen eine Eskalation vorgesehen?
- [ ] Benötigt der Mitarbeiter nach dem Kontakt Unterstützung?
- [ ] Muss die Beschwerde oder das Muster ausgewertet werden?

---

**Checkliste vor dem Abschluss eines Vorgangs**

- [ ] Wurde das ursprüngliche Anliegen erneut betrachtet?
- [ ] Ist die technische Funktion wiederhergestellt?
- [ ] Kann der Benutzer den vollständigen Arbeitsschritt durchführen?
- [ ] Wurde das Ergebnis bestätigt?
- [ ] Sind offene Risiken oder Einschränkungen kommuniziert?
- [ ] Wurde die Lösung verständlich dokumentiert?
- [ ] Sind weitere Maßnahmen eindeutig zugeordnet?
- [ ] Muss Problem Management einbezogen werden?
- [ ] Muss ein Wissensartikel aktualisiert werden?
- [ ] Muss eine Verbesserung erfasst werden?

---

**Checkliste für KI-gestützte Kommunikation**

- [ ] Wurde der Text von einer zuständigen Person geprüft?
- [ ] Sind alle technischen Aussagen korrekt?
- [ ] Entspricht der Status dem aktuellen Vorgang?
- [ ] Werden keine Ursachen erfunden?
- [ ] Werden keine unbelegten Zeitangaben gemacht?
- [ ] Ist die Sprache respektvoll und zielgruppengerecht?
- [ ] Sind keine vertraulichen Daten enthalten?
- [ ] Sind Handlungsanweisungen sicher?
- [ ] Ist ein menschlicher Kontaktweg vorhanden?
- [ ] Wird die Verwendung der KI entsprechend den Vorgaben der Organisation gesteuert?

---

**Schnellreferenz für Formulierungen**

| Situation | Geeignete Formulierung |
|---|---|
| Auswirkung anerkennen | Ich verstehe, dass die Störung Ihren Arbeitsablauf gerade vollständig blockiert. |
| Verständnis prüfen | Ich fasse kurz zusammen, damit ich nichts übersehen habe. |
| Ursache unbekannt | Die genaue Ursache ist noch nicht bestätigt. |
| keine Lösungszeit bekannt | Eine verlässliche Wiederherstellungszeit liegt noch nicht vor. |
| nächste Rückmeldung | Sie erhalten spätestens um 14:00 Uhr eine weitere Statusmeldung. |
| Weiterleitung | Ich binde das Netzwerkteam mit den bisherigen Prüfergebnissen ein. |
| Verantwortung behalten | Der Service Desk bleibt Ihr Kontaktpunkt und informiert Sie weiter. |
| Sicherheitsregel erklären | Die Identitätsprüfung kann ich aus Sicherheitsgründen nicht überspringen. |
| Alternative anbieten | Als Zwischenlösung können Sie derzeit Arbeitsplatz 4 verwenden. |
| Ergebnis prüfen | Können Sie den zuvor fehlgeschlagenen Arbeitsschritt jetzt vollständig durchführen? |
| Fehler eingestehen | Der zugesagte Rückruf ist nicht erfolgt. Ich übernehme jetzt die weitere Koordination. |
| respektvolle Grenze | Ich bearbeite Ihr Anliegen gern weiter, benötige dafür aber ein Gespräch ohne Beleidigungen. |

---

**Zusammenfassende Darstellung**

> Benutzer schildert ein Anliegen  
> ↓  
> aufmerksam zuhören und Auswirkung verstehen  
> ↓  
> gezielt nachfragen  
> ↓  
> das Verstandene zusammenfassen  
> ↓  
> Situation fachlich und verständlich einordnen  
> ↓  
> nächsten Schritt und Verantwortung erklären  
> ↓  
> realistische Erwartungen und Statuszeitpunkt vereinbaren  
> ↓  
> regelmäßig, ehrlich und zielgruppengerecht informieren  
> ↓  
> technisches Ergebnis und Benutzer-Outcome prüfen  
> ↓  
> Kontakt professionell abschließen  
> ↓  
> Feedback, Beschwerden und Kommunikationsprobleme verbessern

---

**Verwandte Seiten**

- 3.1 Der Service Desk als zentraler Kontaktpunkt
- 3.2 Kontaktkanäle und Erreichbarkeit
- 3.4 Tickets vollständig erfassen und kategorisieren
- 3.5 Auswirkungen, Dringlichkeit und Priorität
- 3.6 Erstdiagnose, Lösung und funktionale Eskalation
- 3.7 Ownership, hierarchische Eskalation und Major Incidents
- 3.8 Self-Service, Wissensnutzung und Automatisierung
- 3.9 Kennzahlen, Qualität und Continual Improvement im Service Desk
- Incident Management
- Service Request Management
- Knowledge Management
- Relationship Management
- Service Level Management
- Information Security Management

---

**Quellen und Versionsstand**

**Offizielle Grundlagen**

- [PeopleCert: ITIL 4 Practitioner – Service Desk](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil4-practices-service-desk-3706)
- [ITIL: The ongoing relevance of the service desk in an AI world](https://www.itil.com/Itil-News-and-Announcements/service-desk-relevance-ai-world)
- [ITIL: ITIL Service – Version 5](https://www.itil.com/professionals/certifications/ITIL-Service-Version-5)
- [ITIL: ITIL Service Version 5 – An enterprise-wide approach to service thinking](https://www.itil.com/Itil-News-and-Announcements/itil-service-version-5)
- [ITIL: ITIL Experience – Version 5](https://www.itil.com/professionals/certifications/ITIL-Experience-Version-5)
- [ITIL: ITIL Experience Version 5 – Making digital technology feel as good as it functions](https://www.itil.com/Itil-News-and-Announcements/itil-experience-version-5)
- [ITIL: How ITIL Experience Version 5 puts user experience at the core of service and availability](https://www.itil.com/Itil-News-and-Announcements/itil-version-5-experience-user-experience)
- [PeopleCert: ITIL Foundation – Version 5](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154)

**Offiziell bestätigter Stand**

Die offiziellen ITIL- und PeopleCert-Quellen bestätigen:

- Der Service Desk stellt einen zentralen Kontaktpunkt zwischen Service Provider und Benutzern bereit und unterstützt eine wirksame Kommunikation.
- Service-Desk-Mitarbeiter benötigen überdurchschnittliche Kommunikationsfähigkeiten und müssen Gespräche an unterschiedliche Kenntnisse und Bedürfnisse der Benutzer anpassen.
- Empathie und Verständnis des Benutzerkontexts sind wesentliche Fähigkeiten moderner Service-Desk-Arbeit.
- ITIL Version 5 stärkt die Betrachtung von Benutzer- und Kundenerfahrung innerhalb des digitalen Produkt- und Service-Managements.
- Eine technisch funktionierende Leistung kann trotzdem eine unzureichende Erfahrung erzeugen.
- Kommunikation während Störungen beeinflusst Vertrauen, Wahrnehmung und Serviceerfahrung.
- KI kann Kommunikation, Zusammenfassung, Übersetzung und Personalisierung unterstützen, benötigt aber Governance, menschliche Kontrolle und definierte Übergaberegeln.
- Menschliche Kommunikation bleibt besonders bei komplexen, emotional belastenden und unsicheren Situationen wichtig.

**Einordnung**

Die auf dieser Seite dargestellten:

- Gesprächsstrukturen,
- Formulierungsbeispiele,
- Statusvorlagen,
- Deeskalationshinweise,
- Checklisten,
- Kommunikationsregeln,
- und Praxisbeispiele

sind herstellerneutrale redaktionelle Empfehlungen dieses unabhängigen Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Skripte und keine für jede Organisation verbindlichen Kommunikationsabläufe dar.

Die konkrete Kommunikation muss angepasst werden an:

- Zielgruppe,
- Kanal,
- Service,
- Auswirkung,
- Sicherheitsanforderungen,
- Datenschutz,
- organisatorische Rollen,
- und die jeweils bestätigte Informationslage.

**Behandelter Framework-Stand:** ITIL Version 5  
**Zusätzlich berücksichtigt:** aktuelle öffentlich zugängliche ITIL-4-Service-Desk-Guidance  
**Fachlicher Stand:** August 2026