- 1 Section
- 11 Lessons
- unbegrenzt
- Kundenkommunikation & Beratungsgespräch11
- 1.1Sender-Empfänger-Modell
- 1.24-Ohren-Modell nach Schulz von Thun
- 1.3Aktives Zuhören, Fragetechniken und Bedarfsanalyse
- 1.4Beratungsgespräch strukturieren
- 1.5Zielgruppen unterscheiden und kommunizieren
- 1.6Englische IT-Fachsprache: Begriffe, Doku, Fehlermeldungen
- 1.7Marktbeobachtung: Preise und Wettbewerber vergleichen
- 1.8Marketing und Vertrieb unterstützen
- 1.9Daten multimedial aufbereiten und präsentieren
- 1.10Einwandbehandlung und Beschwerdemanagement
- 1.11Kunden einweisen und Kundenbeziehungen gestalten
Zielgruppen unterscheiden und kommunizieren
„Wir machen ein Kubernetes-basiertes Microservice-Refactoring mit GitOps-Pipeline." – ein Satz, der den Dev-Kollegen begeistert, den Endanwender ratlos zurücklässt und der Geschäftsführerin überhaupt keine Information liefert. Hier liegt einer der größten Hebel guter IT-Kommunikation: Zielgruppen-Differenzierung. Ein erfahrener IT-Profi spricht in einem Tag mit Geschäftsführung, Fachabteilungen, Endanwendern, externen Dienstleistern und Dev-Kollegen – und übersetzt denselben Inhalt jedes Mal in eine andere Sprache. Ohne diese Übersetzung scheitern Projekte nicht an Technik, sondern am Verständnis: Budget wird nicht freigegeben, Anwender lehnen Lösung ab, Dienstleister liefert das Falsche. Diese Lektion zeigt dir fünf Personas, die im IT-Alltag wiederkehren (CEO/Geschäftsführung, Fachabteilung, Endanwender, IT-Kollege, externe Dienstleister), pro Persona ihre Interessen, ihre Sprache und konkrete Beispiel-Formulierungen. Außerdem das Konzept der Übersetzung: derselbe technische Sachverhalt in fünf verschiedene Versionen. Wer das beherrscht, gewinnt im Beratungsalltag deutlich.
1) Die fünf IT-Personas
Klick die Personas an, um Interessen, Sprache und passende Formulierungen zu sehen:
führung
abteilung
anwender
Kollege
Dienstl.
2) Ein Inhalt – fünf Übersetzungen
Konkretes Beispiel: das ERP-System wird am Wochenende auf eine neue Version aktualisiert. Wie spricht man darüber je nach Zielgruppe?
3) Sprach-Niveaus
Eine vereinfachte Faustregel für Fachbegriffe und Tiefe:
| Zielgruppe | Sprach-Niveau | Beispiel |
|---|---|---|
| Geschäftsführung | Geschäftsbegriffe, fast keine IT-Fachsprache | „Verfügbarkeit", „Risiko", „Investition", „Wettbewerbsvorteil" |
| Fachabteilung | Eine Mischung aus Fach- und IT-Sprache | „Workflow", „Schnittstelle", „Reporting", „User" |
| Endanwender | Alltagssprache, sehr wenig IT | „Wartung", „funktioniert nicht", „klicken Sie auf" |
| IT-Kollege | Voll Fachsprache, präzise | „VLAN", „GPO", „CIDR", „IOPS" |
| Externer Dienstleister | Vertragssprache + Fachsprache | „SLA", „Lieferumfang", „Abnahme", „Verzug" |
4) Bedürfnis-Pyramide pro Persona
Was jede Persona im Kern wirklich wissen will, lässt sich oft auf einen Satz reduzieren:
| Persona | Kern-Frage | Was du als Erstes adressieren solltest |
|---|---|---|
| 👔 Geschäftsführung | „Was kostet/bringt das uns?" | ROI, Risiko, strategischer Wert |
| 📊 Fachabteilung | „Wie hilft mir das im Tagesgeschäft?" | Prozess-Auswirkung, Zeitersparnis, Effizienz |
| 🧑💻 Endanwender | „Muss ich jetzt was lernen / ändern?" | Konkrete Schritte, Schulung, Auswirkung auf Arbeitstag |
| ⚙ IT-Kollege | „Wie funktioniert das technisch?" | Architektur, Schnittstellen, Betriebs-Konsequenzen |
| 🤝 Externer Dienstleister | „Was muss ich liefern, bis wann, zu welchem Preis?" | SLA, Scope, Termine, Verantwortlichkeiten |
5) Tools, die helfen
- Stakeholder-Map vor jedem größeren Projekt: wer sind die Gesprächspartner, in welcher Rolle? (Verweis: Macht-Interesse-Matrix).
- Persona-Beschreibungen im Wiki/CRM: pro Schlüssel-Stakeholder ein kurzes Profil mit Interessen, Sprache, Vorlieben.
- Vorab-Brief bei wichtigen Terminen: kurzes Vorab-Dokument in der Sprache des Empfängers – Geschäftsführung kriegt Executive Summary, IT-Kollege kriegt Architektur-Skizze.
- Glossar pflegen: Begriffe in Übersetzungen sammeln. „Was heißt RBAC für die Buchhaltung? – Berechtigungs-Konzept nach Rollen."
- Templates für wiederkehrende Kommunikations-Anlässe: Wartungs-Ankündigung für Endanwender, Statusbericht für Geschäftsführung, Tech-Briefing für IT-Kollegen.
6) Schriftlich – nochmal anspruchsvoller
In E-Mails und Slack-Nachrichten verschmelzen oft Zielgruppen, weil man an Verteiler schreibt. Vorsicht:
- Cc-Verteiler kennen. Wenn Buchhaltung mit IT-Vorstand in CC sitzt – wem schreibe ich primär?
- Tldr / Zusammenfassung obendrauf. Vorstand liest nur den ersten Absatz. Buchhalter liest den Mittelteil. IT-Kollege bewertet die Details unten.
- Gemischte Sprache vermeiden. Lieber zwei verschiedene Mails als eine, die niemandem dient.
- Bei kritischen Themen einzeln informieren. Bei Sicherheits-Vorfällen passt nicht jeder Wortlaut für jede Zielgruppe.
7) Internationalisierung als Spezialfall
In international tätigen Unternehmen kommt eine weitere Dimension dazu: Kultur (mehr in Englische Fachsprache). Kurz angedeutet:
- USA: direkt, optimistisch, Verkaufs-Rhetorik üblich. Pragmatisch, Geschwindigkeit zählt.
- Asien (Japan, Südkorea): indirekter, höflicher, Hierarchie beachten, „Nein" wird selten ausgesprochen.
- Frankreich: intellektueller Diskurs vor Entscheidung, formelle Anrede länger.
- UK: Understatement („not bad" = sehr gut), Humor erlaubt, weniger Hierarchie als in DE.
- DACH: sachlich, gründlich, lange Vorbereitung, Werte-orientiert.
8) Antipatterns
- Fachsprache als Statussymbol. Wer „RBAC-Refactoring mit OIDC-Migration" sagt, will beeindrucken – verfehlt aber den Adressaten. Lösung: Kundensprache, nicht Selbstprofil.
- Vorstand mit Architektur-Details quälen. 20 Folien Topologie für die Geschäftsführung – nach 3 Minuten Augenausstecher-Reflex. Lösung: Executive Summary.
- Endanwender mit Risiko-Matrix konfrontieren. „Wir haben ein CVSS-9.8-Patch nicht eingespielt" – verängstigt unnötig. Lösung: „Wir haben heute ein wichtiges Sicherheits-Update durchgeführt."
- Externe wie interne ansprechen. Dienstleister kriegt SLA-Bezug, nicht Kollegen-Tonfall. Verwischt sonst Vertragsverhältnis.
- Eine Mail an alle gleich. Erste 3 Absätze für Vorstand, letzte 3 für IT-Kollegen – Inhalte fallen mittenrein. Besser: Mehrfach-Mail oder klare TL;DR-Struktur.
- Persona-Schubladen ohne Anpassung. Realität ist mehrdimensional – manche Endanwender sind technik-affiner als IT-Kollegen. Persona als Startpunkt, nicht Endurteil.
- Annahmen treffen statt fragen. „Sie sind doch IT, dann verstehen Sie X" – falsch! Erst fragen, dann anpassen.
- Schulungs-Material in Tech-Sprache. Endanwender-Doku mit Befehls-Zeilen-Beispielen – niemand liest's. Lösung: Bilder, Klick-Anleitungen, Alltagssprache.
Zusammenfassung
Zielgruppen-Differenzierung bedeutet: derselbe technische Inhalt wird je nach Adressat in eine andere Sprache übersetzt. Fünf typische Personas im IT-Alltag: Geschäftsführung (will ROI/Risiko), Fachabteilung (will Prozess-Auswirkung), Endanwender (will konkrete Handlungs-Anweisung), IT-Kollege (will technische Tiefe), externer Dienstleister (will klaren Lieferumfang und SLA). Pro Persona unterscheiden sich Sprach-Niveau, Detail-Tiefe und Kern-Frage – wer das nicht trifft, verliert seinen Adressaten. Hilfreich sind Stakeholder-Maps, gepflegte Personas im CRM/Wiki, und Templates für wiederkehrende Anlässe. Häufigster Fehler: Fachsprache als Statussymbol – wirkt eitel, verfehlt aber das Ziel.
Verwandte Lektionen: Sender-Empfänger-Modell · Aktives Zuhören · Beratungsgespräch · und mehrWeitere relevante Lektionen4-Ohren-ModellEnglische FachspracheMarketing & VertriebMultimedial präsentierenKunden einweisenStakeholder-Matrix
