Kommunikation im IT-Support

Warum Kommunikation im IT-Support eine eigene Disziplin ist

Technisches Wissen bringt dich im IT-Support nur halb ans Ziel. Die andere Haelfte ist Kommunikation. Laut einer Umfrage des Help Desk Institute nennen 68 % der Befragten Kommunikationsfaehigkeit als das wichtigste Merkmal eines Helpdesk-Mitarbeiters – noch vor Problemloesungskompetenz (63 %).

Das macht Sinn: Du kannst das Problem loesen, aber wenn der User danach verwirrt, veraergert oder unsicher ist, ob das wirklich behoben wurde, ist das Ticket trotzdem ein Misserfolg. Gute Kommunikation bedeutet, dass der User versteht was passiert ist, sich respektiert fuehlt und weiss, was er als naechstes tun soll.

Diese Seite zeigt dir die konkreten Techniken, die du im IT-Alltag eines KMU brauchst.

Sprache an den Gegenueber anpassen

Die wichtigste Grundregel: Sprich die Sprache deines Gegenueber. Mit einem Entwickler redest du anders als mit einer Sekretaerin, die zum ersten Mal ein Ticket eroeffnet.

Nicht-technische User:

• Kein Fachjargon, keine Abkuerzungen ohne Erklaerung
• Vermeide passive Formulierungen wie “Das System hat sich aufgehaengt” – sag lieber “Dein Computer hat nicht mehr reagiert”
• Analogien helfen: “Der Cache ist wie der Notizblock deines Browsers – den leeren wir jetzt kurz”

Beispiel – schlechte Formulierung:

“Der DNS-Resolver kann den FQDN nicht aufloesen, wahrscheinlich ein TTL-Problem oder falsche Forwarder.”

Beispiel – gute Formulierung:

“Dein Computer kann die Adresse der Webseite gerade nicht finden. Ich pruefe unsere Netzwerkkonfiguration – das sollte in ein paar Minuten erledigt sein.”

Technische Kollegen oder Entwickler: Hier darfst und sollst du Fachbegriffe nutzen. Ein Kollege, der selbst in der IT arbeitet, will keine vereinfachten Erklaerungen, sondern praezise Informationen.

Aktives Zuhoeren – mehr als nur Warten bis der andere fertig ist

Aktives Zuhoeren ist eine konkrete Technik, kein vages Konzept. Sie hilft dir, das Problem schneller und korrekt zu erfassen und dem User das Gefuehl zu geben, ernst genommen zu werden.

Die drei Kernelemente:

1. Ausreden lassen Unterbreche nie. Auch wenn du das Problem nach dem ersten Satz schon erkannt hast – lass den User fertig erzaehlen. Oft kommen noch Details, die du sonst verpasst haettest.

2. Zusammenfassen und bestaetigen Paraphrasiere das Problem in eigenen Worten:

“Wenn ich das richtig verstehe, funktioniert Outlook seit heute Morgen nicht mehr – du siehst eine Fehlermeldung beim Oeffnen?”

Das hat zwei Vorteile: Du bestaetigst, dass du zugehoert hast, und du pruefst ob du das Problem richtig verstanden hast.

3. Offene Fragen stellen Offene Fragen liefern mehr Informationen als Ja/Nein-Fragen:

Die klassischen W-Fragen sind dein Werkzeug: Was passiert genau? Wann ist es aufgetreten? Wo (auf welchem Geraet, in welcher Applikation)? Was hat sich zuletzt geaendert?

Erwartungen setzen und Transparenz schaffen

Einer der haeufigsten Fehler im IT-Support: Der User hoert nichts und weiss nicht, ob sein Problem in Bearbeitung ist oder vergessen wurde. Das ist der direkteste Weg zu Unzufriedenheit – auch wenn das Problem am Ende geloest wird.

Zeitrahmen kommunizieren: Gib immer einen konkreten Zeitrahmen an, auch wenn er geschaetzt ist:

“Ich schaue mir das an und melde mich spaetestens in 30 Minuten.”

Wenn sich abzeichnet, dass es laenger dauert – proaktiv informieren, nicht auf Nachfrage warten:

“Ich arbeite noch daran. Es ist etwas komplexer als erwartet – schaetze noch ca. eine Stunde. Ich melde mich dann.”

Zwischenstatus geben: Bei Problemen, die laenger als 2 Stunden dauern, solltest du den User regelmaessig auf dem Laufenden halten. Das gilt besonders bei Systemausfaellen, die mehrere User betreffen.

Workaround kommunizieren: Wenn die dauerhafte Loesung noch Zeit braucht, aber ein Workaround existiert:

“Ich habe noch keine vollstaendige Loesung, aber du kannst inzwischen so weiterarbeiten: [Workaround erklaeren]. An der eigentlichen Ursache arbeite ich noch.”

Schwierige Situationen meistern

Ungeduldiger oder veraergerter User

Frustration ist in der Regel nicht persoenlich gemeint – der User ist frustriert ueber die Situation, nicht ueber dich. Deine Aufgabe ist Deeskalation.

Technik: Verstaendnis zeigen, dann handeln

“Ich verstehe vollstaendig, dass das frustrierend ist – besonders wenn du gerade unter Zeitdruck stehst. Ich behandle dein Problem als hoechste Prioritaet und melde mich in 20 Minuten mit einem Update.”

Was hier passiert:

1. Verstaendnis zeigen (Empathie)
2. Keine Rechtfertigung, keine Schuldzuweisung
3. Konkretes Commitment (20 Minuten, nicht “bald”)

Was du vermeiden solltest:

• “Ich kann das nicht aendern, das ist halt so”
• “Das ist nicht mein Problem”
• Defensiv werden oder das Problem kleinreden

User gibt sich selbst die Schuld

Manche User entschuldigen sich uebertrieben oder sagen “Ich bin halt kein Computer-Mensch”. Nimm das nicht auf die leichte Schulter:

“Das ist kein Benutzerfehler – solche Probleme passieren auch erfahrenen IT-Leuten. Es gibt eine technische Ursache, und wir finden sie.”

Das schafft Vertrauen und sorgt dafuer, dass User kuenftig schneller melden, wenn etwas nicht stimmt.

Problem kann aktuell nicht geloest werden

Manchmal hast du keine Loesung – sei es weil externe Abhaengigkeiten bestehen, eine Eskalation noetig ist oder du mehr Zeit brauchst.

“Ich kann das Problem gerade noch nicht vollstaendig beheben. Ich habe einen Workaround, damit du sofort weiterarbeiten kannst: [Workaround]. An der dauerhaften Loesung arbeite ich weiter und melde mich heute Nachmittag mit einem Update.”

Niemals: Einfach nichts sagen und hoffen, dass der User nicht mehr fragt.

Eskalation ankuendigen

Wenn du ein Problem an den 2nd oder 3rd Level weitergeben musst, kommuniziere das klar:

“Ich habe alles analysiert, was ich aus dem First Level beurteilen kann. Fuer die naechsten Schritte brauche ich unseren Netzwerk-Spezialisten. Ich uebergebe das Ticket jetzt und stelle sicher, dass er alle Infos hat. Du bekommst eine Bestaetigung, sobald er es uebernommen hat.”

Abschlusskommunikation – der letzte Eindruck zaehlt

Das Ticket-Abschlussgespraech oder die Abschluss-E-Mail ist genauso wichtig wie der erste Kontakt. Viele User bewerten den Support hauptsaechlich danach, wie das Gespraech geendet hat.

Eine gute Abschlussnachricht enthaelt:

1. Was wurde gemacht
2. Was war die Ursache
3. Was kann der User tun, wenn es erneut auftritt
4. Einladung zur Rueckmeldung

Beispiel – Outlook-Profil-Problem:

“Ich habe dein Outlook-Profil geloescht und neu erstellt. Das Problem war ein beschaedigter Profilordner – das kann nach einem unterbrochenen Update passieren. Outlook sollte jetzt normal funktionieren. Falls das Problem nochmals auftritt, melde es sofort – dann schauen wir uns das Update-Verhalten naeher an.”

Nicht:

“Ticket geloest. Problem war Outlook.” (zu knapp, keine Erklaerung)

Kommunikation per E-Mail und Ticketsystem

Viele Supportanfragen kommen schriftlich. Hier gelten dieselben Grundprinzipien, aber mit zusaetzlichen Besonderheiten.

Struktur einer Support-Antwort-E-Mail:

Betreff: Re: Outlook oeffnet sich nicht [Ticket #4521]

Hallo [Name],

danke fuer deine Meldung.

Ich habe das Problem analysiert und folgendes festgestellt:
[Kurze Erklaerung der Ursache]

Bitte fuehre diese Schritte durch:
1. [Schritt 1]
2. [Schritt 2]
3. [Schritt 3]

Falls das Problem danach bestehen bleibt, melde dich direkt bei mir.
Ich bin heute bis 17:00 Uhr erreichbar.

Freundliche Gruesse
[Dein Name] | IT-Support

Tipps fuer schriftliche Kommunikation:

• Nummerierte Schritte statt langer Fliesstexterklaerungen
• Kein ALL CAPS (wirkt wie Schreien)
• Aktiv statt passiv: “Starte den Computer neu” statt “Der Computer sollte neu gestartet werden”
• Screenshots oder kurze Erklaerungen anhaengen bei komplexen Schritten
• Antwortzeit: Bestaetige Eingang schnell, auch wenn die Loesung noch Zeit braucht

Telefonkommunikation im Support

Telefon-Support hat seine eigenen Regeln. Der User sieht dich nicht – das heisst, Tonfall und Wortwahl zaehlen doppelt.

Gespraech eroeffnen:

“IT-Support, hier spricht [Name]. Was kann ich fuer dich tun?”

Klar, freundlich, kurz. Kein langes Firmen-Intro, das den User nervt.

Waehrend der Diagnose:

• Sage was du tust: “Ich schaue jetzt in den Ereignisprotokollen nach…”
• Lange Stille verursacht Unsicherheit beim User – erklaere was du gerade machst
• Bei Wartezeiten: “Ich stelle dich kurz auf Warteschleife – bin in ca. 2 Minuten zurueck”

Gespraech abschliessen:

• Zusammenfassen was gemacht wurde
• Naechste Schritte benennen falls noetig
• “Gibt es sonst noch etwas, womit ich dir helfen kann?”
• Ticket erwaehnen: “Ich habe das in Ticket #4521 dokumentiert – du bekommst eine Bestaetigung per E-Mail”

Dos and Don’ts – Schnellreferenz

Zusammenspiel mit Ticketsystem und ITIL

Gute Kommunikation und ein sauberes Ticketsystem gehoeren zusammen. Jedes Gespraech, jede Massnahme, jede Eskalation wird im Ticket dokumentiert – nicht nur fuer dich, sondern fuer alle Kollegen, die das Ticket vielleicht uebernehmen muessen.

Was ins Ticket gehoert:

• Gemeldetes Symptom (in den Worten des Users)
• Diagnose-Schritte mit Ergebnis
• Kommunizierte Massnahmen und Zeitrahmen
• Loesung und Ursache
• Workaround falls eingesetzt

Das ist kein Buerokratismus – es ist professionelle Arbeit. Mehr dazu auf den Seiten Ticketsystem – Grundlagen und ITIL – Grundlagen.

Fuer die Methodik hinter der Fehlersuche – also wie du das Problem systematisch isolierst, bevor du kommunizierst – lies Troubleshooting-Methodik.

Bei Remote-Support gelten dieselben Kommunikationsregeln, nur mit dem Zusatz: Immer erklaeren, was du gerade auf dem Bildschirm des Users tust. Mehr dazu auf Remote Support Tools.

Weiterlernen

• NinjaOne: 12 Strategien zur Verbesserung der IT-Kommunikation
• mITSM: Incident Management nach ITIL
• Buchanan Technologies: 5 Help Desk Communication Tips
• SysAid: Top Soft Skills for Service Desk
• Haufe Akademie: Wirksame Kommunikation fuer IT-Mitarbeiter
• IT Process Wiki: Incident Management