Das erste Gespräch handelt vor allem von Erwartungen
Wir haben zwei Kunden im selben Quartal im Wesentlichen denselben Dokumentassistenten geliefert. Einer verlängerte und baute aus. Der andere stellte nach sechs Monaten ein — mit einem funktionierenden System, das niemand nutzte. Die Weichenstellung stand in den Notizen des Auftaktgesprächs.
Zwei Projekte, ein System
Beide Kunden wollten einen Assistenten über technische Dokumentation. Beide bekamen strukturbewusstes Chunking, hybriden Abruf, einen Ablehnungspfad und eine Prüfwarteschlange. Die gemessene Genauigkeit auf ihren jeweiligen Referenzsets lag zwei Punkte auseinander.
Einer baute das System auf eine zweite Abteilung aus. Der andere stellte ein, und das Abschlussgespräch handelte nicht von Qualität: Seine Nutzer hatten etwas erwartet, das alles beantwortet, trafen auf ein System, das etwa jede achte Frage ablehnt, und schlossen daraus, es funktioniere nicht.
Was in der ersten Stunde anders war
Der Auftakt des erfolgreichen Projekts erzeugte eine schriftliche Liste dessen, was der Assistent nicht tun wird. Nicht als Haftungsausschluss, sondern als Zuschnittsdokument, das die Abteilungsleitungen geprüft und gezeichnet haben. Sie benannte die Fragearten, die abgelehnt werden, und wohin diese stattdessen gehen.
Der andere Auftakt erzeugte eine Liste dessen, was er tun wird — was ein Auftakt üblicherweise erzeugt und was die Erwartung setzt, jede Ablehnung sei ein Defekt. Dieses Gespräch haben wir geführt. Das Versäumnis war unseres, bevor irgendetwas gebaut war.
Die Rahmung der Forschung
Vishwarupe und Kollegen veröffentlichten 2026 eine Arbeit zum Erwartungsmanagement in häuslichen KI-Systemen und argumentieren, dass Erwartungen als Nachgedanke behandelt oder an Compliance-Abteilungen delegiert werden, statt Teil des Entwurfs zu sein.
Das Umfeld unterscheidet sich von unserem, und das Argument überträgt sich genau. Erwartung ist keine Kommunikationsaufgabe nach der Lieferung; sie ist eine Eigenschaft des Systems, die festgelegt wird, sobald jemand zum ersten Mal beschreibt, was es sein wird — und danach ist sie sehr viel schwerer zu ändern.
| Satz, auf dem wir bestehen | Warum |
|---|---|
| Was er abzulehnen hat | Macht aus einer Ablehnung ein Merkmal |
| Wohin eine abgelehnte Frage geht | Macht aus einer Sackgasse einen Weg |
| Was eine falsche Antwort hier kostet | Legt die Prüftiefe fest |
| Wer prüft, ob es funktioniert | Benennt einen Eigentümer vor dem System |
Die vier Sätze
Was er ablehnen wird. Wohin eine Ablehnung führt. Was eine falsche Antwort in diesem Prozess kostet. Wer dafür verantwortlich ist zu bemerken, ob es funktioniert. Vier Sätze, vereinbart und aufgeschrieben, bevor der Entwurf beginnt — und die ersten beiden verändern, wie Nutzer das System erleben.
Keiner davon ist technisch, und alle vier sind Antworten, die wir nicht liefern können. Der Kunde muss sie schreiben, weshalb im ersten Workshop heute seine Abteilungsleitungen sitzen und nicht nur seine IT.
Wie der Ablehnungssatz das Verhalten ändert
Wem vorab gesagt wurde, dass der Assistent keine Fragen zu Preisen oder Personal beantwortet, der trifft auf eine Ablehnung und liest sie als korrektes Verhalten. Wem gesagt wurde, der Assistent beantworte Fragen zur Dokumentation, der trifft auf dieselbe Ablehnung und liest sie als kaputtes System.
Gleiches System, gleiche Meldung, gegenteiliger Schluss. Diese Asymmetrie erklärt den größten Teil der Divergenz zwischen beiden Projekten, und sie richtig zu setzen kostet nichts außer einem Gespräch, das niemand führen will, solange alle begeistert sind.
Was wir gelassen haben
Vorführungen mit eigenen Beispielen. Sie beeindrucken, setzen die Erwartung, dass alles wie in der Vorführung funktioniert, und sind aus dem Teil der Fragenverteilung gewählt, in dem das System stark ist.
Das erste Gespräch nutzt heute ihre Fragen auf ihren Dokumenten, einschließlich derer, die scheitern. Das ergibt ein schlechteres Gespräch und ein besseres Projekt, und es hat uns keine Aufträge gekostet: Die zwei Kunden, die nach gesehenen Fehlschlägen absagten, hätten sechs Monate später teurer abgesagt.
Die unangenehme Fassung dieses Beitrags
Das eingestellte Projekt war nicht das Versäumnis des Kunden. Er stellte vernünftige Fragen, wir beantworteten sie zutreffend, und wir haben nie den Satz gesagt, auf den es ankam: Etwa jede achte Frage wird nicht beantwortet, und hier ist der Grund, warum das das richtige Verhalten ist.
Wir wussten es. Es stand in unserem Angebot als technische Eigenschaft statt als Erwartung — und eine Zahl in einem Angebot ist nicht dasselbe wie ein geteiltes Verständnis unter denen, die das Ding benutzen werden.
Was wir nicht behaupten
Wir behaupten nicht, Erwartungen erklärten jedes gescheiterte Projekt. Unseres scheiterte aus diesem Grund, und andere sind an Kosten, an Datenqualität und einmal daran gescheitert, dass der unterstützte Prozess eingestellt wurde.
Wir behaupten auch nicht, vier Sätze seien ausreichend. Sie sind das Minimum, ohne das wir heute nicht beginnen, und eine größere Organisation mit mehr Beteiligten braucht ein längeres Gespräch, als ein Workshop fasst.