Kurz gesagt
- Kunden müssen nicht wissen, wie es funktioniert. Sie müssen wissen, was es kostet, wie lange es dauert, welches Risiko es gibt und was sich für sie ändert.
- Zeig die Auswirkung auf dem Bildschirm, etwa die langsame Seite oder den kaputten Checkout, statt sie zu beschreiben.
- Ein Vergleich aus der Welt des Kunden hilft; sag, wo er nicht mehr passt.
- Biete zwei oder drei Optionen mit Kosten, Zeit und Risiko an und empfiehl eine.
- Zeig nie Code, nach dem der Kunde nicht gefragt hat, und nie Zugangsdaten.
Um Kunden ohne Technikwissen technische Entscheidungen zu erklären, sprich darüber, was sich für sie ändert, nicht wie es funktioniert: was es kostet, wie lange es dauert, was passiert, wenn man es nicht macht, und was sich für ihr Team ändert. Zeig das Problem auf dem Bildschirm, statt es zu beschreiben, biete zwei oder drei Optionen mit ihren Kompromissen an und empfiehl eine. Eine kurze Bildschirmaufnahme ist dafür ein gutes Format, weil der Kunde die langsame Seite oder den kaputten Button mit eigenen Augen sieht.
Dieser Leitfaden richtet sich an freie Entwickler und Agenturteams, die eine Entscheidung des Kunden zu etwas brauchen, das er allein nicht beurteilen kann.
Über Ergebnisse und Kompromisse sprechen
Deinem Kunden ist das Framework egal, die Datenbank, das Plugin. Ihn interessieren vier Dinge:
- Kosten: wie viel jetzt, und wie viel danach jeden Monat.
- Zeit: wie lange, und ob sich dadurch der Launch verschiebt.
- Risiko: was passiert, wenn wir es nicht machen.
- Veränderung: was danach für ihn und sein Team anders ist.
Übersetz jeden technischen Punkt in diese Begriffe, bevor du ihn erklärst:
| Was du einem Kollegen sagen würdest | Was der Kunde hören muss |
|---|---|
| „Das Buchungs-Plugin wird nicht mehr gepflegt.“ | „Das Buchungssystem bekommt keine Sicherheitsupdates mehr. Heute funktioniert es, aber mit jedem Monat, den es bleibt, steigt das Risiko.“ |
| „Wir sollten Caching einbauen.“ | „Die Seiten laden schneller. Wenn du eine Seite bearbeitest, kann es ein paar Minuten dauern, bis die Änderung erscheint.“ |
| „Lass uns auf ein Headless-CMS umsteigen.“ | „Mehr Freiheit beim Design, aber zwei Systeme zu pflegen statt einem, und höhere monatliche Kosten.“ |
| „Wir haben viele technische Schulden.“ | „Abkürzungen von früher machen jede neue Funktion langsamer und teurer in der Umsetzung.“ |
Wenn ein Satz immer noch ein Fachwort braucht, um Sinn zu ergeben, erklär das Wort einmal nebenbei und mach weiter.
Zeigen statt erzählen
„Die Seite ist mobil langsam“ ist eine Meinung. Eine Aufnahme der Seite, die in einem Fenster in Handygröße ewig braucht, um die Produktfotos zu zeigen, ist ein Fakt, den der Kunde sehen kann. Video ist der einfachste Weg, ein technisches Problem jemandem zu zeigen, der nicht vor deinem Bildschirm sitzt:
- Das Problem, wie der Endkunde es sieht: der Checkout-Button, der in Safari nichts tut, das Formular, das verliert, was man eingetippt hat.
- Vorher und nachher: die alte Seite und die schnellere, nebeneinander.
- Der Bildschirm, den er nutzen wird: der Admin-Bereich nach der Änderung, damit „ein neuer Editor“ nicht mehr abstrakt bleibt.
Kreis den Teil ein, auf den es ankommt, während du sprichst. Auf dem Bildschirm zu zeichnen, während du aufnimmst, funktioniert dafür gut; siehe Auf dem Mac-Bildschirm zeichnen, während du aufnimmst.
Vergleiche mit Bedacht einsetzen
Ein guter Vergleich aus der Welt des Kunden lässt den Groschen fallen. Ein paar, die meist funktionieren:
- Wartung und Updates sind wie die Inspektion beim Auto: Lässt du sie aus, fährt es trotzdem, bis es eben nicht mehr fährt.
- Technische Schulden sind wie eine Restaurantküche, die zwischen den Schichten nicht geputzt wird: Jede Schicht ist langsamer als die vorige.
- Backups sind wie eine Versicherung, nur dass du prüfen solltest, ob sie funktionieren, bevor du sie brauchst.
Nimm einen pro Entscheidung, nicht einen pro Satz. Und sag, wo er nicht mehr passt: „Anders als beim Auto kann jemand anderes eine Sicherheitslücke ausnutzen, bevor irgendetwas falsch aussieht.“ Ein Vergleich, der Kosten oder Risiken verdeckt, ist schlimmer als keiner.
Optionen mit ihren Kosten anbieten
Die meisten technischen Entscheidungen haben mehr als eine Antwort. Stell zwei oder drei vor, einschließlich „nichts tun“, wenn das wirklich eine Option ist, und stell sie nebeneinander:
| Option | Zeit | Laufende Kosten | Risiko |
|---|---|---|---|
| So lassen, wie es ist | Jetzt keine | Keine | Wächst jeden Monat ohne Updates |
| Durch ein gepflegtes Plugin ersetzen | Etwa zwei Tage | Eine jährliche Lizenz | Gering; die Buchungen ziehen mit um |
| Ein eigenes Buchungsformular bauen | Etwa zwei Wochen | Unsere Wartungszeit | Gering, aber mehr zu betreuen |
Ein ausgedachtes Beispiel: Zeiten und Kosten hängen vom Projekt ab.
Dann empfiehl eine und sag in einem Satz, warum: „Wir würden es durch das gepflegte Plugin ersetzen: zwei Tage Arbeit, und das Risiko ist weg.“ Kunden entscheiden schneller, wenn du das Nachdenken übernommen hast und sie nur noch zustimmen müssen. Für die Geldseite nutzt Angebot per Video erklären denselben Ansatz.
Ein Aufbau für die Erklärung
Egal ob du ein Video aufnimmst oder eine E-Mail schreibst, diese Reihenfolge funktioniert:
- Die Entscheidung in einem Satz. „Wir müssen entscheiden, was wir mit dem Buchungssystem machen.“
- Warum jetzt. Was passiert, wenn ihr wartet, in seinen Worten.
- Zeig es. Das Problem auf dem Bildschirm, dreißig Sekunden oder weniger.
- Die Optionen, mit Zeit, Kosten und Risiko.
- Deine Empfehlung und der Grund.
- Die Bitte, mit Datum. „Kannst du mir bis Freitag sagen, welche Option du bevorzugst?“
Technische Entscheidung: ein nicht mehr gepflegtes Plugin
Freier Entwickler an einen Kunden aus einem kleinen Betrieb · Etwa 3 Minuten
Hi Nina, ich brauche eine Entscheidung von dir zum Buchungssystem. Heute ist nichts kaputt, aber das Plugin, auf dem es läuft, wird nicht mehr gepflegt, das heißt: keine Sicherheitsupdates mehr.
Hier ist die Buchungsseite, so wie deine Kunden sie sehen. Es gibt drei Optionen: so lassen, das kostet jetzt nichts, wird aber jeden Monat riskanter; durch ein gepflegtes Plugin ersetzen, etwa zwei Tage Arbeit plus eine jährliche Lizenz; oder ein eigenes Formular bauen, etwa zwei Wochen. Ich würde die zweite nehmen: Sie beseitigt das Risiko, und dein Team merkt von der Umstellung nichts. Kannst du mir bis Freitag Bescheid geben?
Schick es mit der Bitte auch schriftlich, damit Nina vom Handy aus antworten kann, ohne das Video noch mal abzuspielen:
Hi Nina, drei Minuten zum Buchungssystem. Nichts ist kaputt, aber das Plugin bekommt keine Sicherheitsupdates mehr. Ich empfehle, es zu ersetzen (etwa zwei Tage Arbeit). Kannst du mir bis Freitag sagen, welche Option du bevorzugst?
https://justrec.app/v/k3f9Qa
Was du nicht zeigst
Eine Bildschirmaufnahme für einen Kunden ist kein Code-Review. Lass weg:
- Code. Wenn der Kunde nicht danach gefragt hat, signalisiert Code nur „Das ist kompliziert“ und sonst nichts.
- Zugangsdaten. Passwörter, API-Schlüssel, Umgebungsdateien, ein Terminal-Verlauf mit Tokens. Schick Zugänge über einen Passwortmanager, nie in einem Video.
- Logs mit Kundendaten. Fehlerlogs enthalten oft Namen, E-Mail-Adressen und Bestelldetails.
- Projekte anderer Kunden. Die Seitenleiste deines Editors und deine Browser-Tabs können sie zeigen.
- Interne Chats über den Kunden oder das Problem.
Wann du es live erklärst
Manche technischen Entscheidungen sind für ein Video allein zu groß: ein Neubau, ein Plattformwechsel, alles, was das Budget stark verändert. Schick das Video zur Vorbereitung und entscheidet dann in einem kurzen Call. Wo die Grenze zwischen beidem liegt, behandeln wir in wann du Kunden besser kein Video schickst.
Und heb dir die Erklärungen für später auf. Am Projektende ergibt derselbe Ansatz eine gute Übergabe: Eine Website-Übergabe per Video zeigt dem Kunden, wie alles funktioniert, ohne eine einzige Zeile Code. Der Leitfaden zur asynchronen Kommunikation mit Kunden per Video bringt alles zusammen, und unsere Seite für Freelancer zeigt, wie JustRec zu einem Ein-Personen-Business passt.
Häufige Fragen
Wie erklärt man einem Kunden ohne Technikwissen eine technische Entscheidung?
Fang mit dem an, was sich für ihn ändert: Kosten, Zeit, Risiko und Arbeitsalltag. Zeig das Problem auf dem Bildschirm, biete zwei oder drei Optionen mit ihren Kompromissen an, empfiehl eine und bitte um eine Entscheidung mit Datum.
Soll ich einem Kunden Code zeigen?
Fast nie. Code sagt einem Kunden ohne Technikwissen nur, dass etwas kompliziert ist, nicht, warum es wichtig ist. Zeig stattdessen die Seite, den Fehler oder den Admin-Bildschirm, den er nutzen wird.
Sind Vergleiche eine gute Idee, um technische Themen zu erklären?
Ja, einer nach dem anderen und aus der Welt des Kunden. Sag, wo der Vergleich nicht mehr passt, damit er keine Kosten und kein Risiko verdeckt.
Was, wenn der Kunde nach den technischen Details fragt?
Gib sie ihm, kurz, nach dem Ergebnis. Manche Kunden haben eine technische Person auf ihrer Seite, die sie haben will; biete für diese Person eine kurze schriftliche Notiz an.
Sollte man technische Entscheidungen per Video oder im Meeting erklären?
Für die meisten Entscheidungen funktioniert ein kurzes Video, weil der Kunde das Problem sieht und die Optionen noch mal ansehen kann. Bei großen oder teuren Entscheidungen schick zuerst das Video und entscheidet dann im Call.
