Vom Lastenheft zur Rückfragenliste: Unvollständige Kundenanfragen systematisch klären

Eine technische Anfrage kommt selten als sauber ausgefüllter Datensatz. In einer E-Mail steht der gewünschte Termin, im PDF die technische Beschreibung, in einer Tabelle die Mengen und in einer Zeichnung eine Variante, die im Text nicht erwähnt wird. Für Vertrieb und Technik beginnt die eigentliche Arbeit deshalb oft vor dem Angebot: Sie müssen erkennen, was bereits belastbar ist und was noch geklärt werden muss.

Dieser Beitrag zeigt dafür ein Trixner Working Model. Es ist kein allgemeingültiger Standard, sondern eine praktische Struktur für einen Workshop oder einen begrenzten Automatisierungspiloten. Das Ziel ist nicht, jede Anfrage automatisch zu beantworten. Das Ziel ist eine prüfbare Rückfragenliste, die fehlende Entscheidungen sichtbar macht.

Ein leeres Pflichtfeld lässt sich vergleichsweise leicht erkennen. Schwieriger sind Angaben, die vorhanden wirken, aber nicht eindeutig zusammenpassen: eine Mengenangabe ohne Einheit, zwei unterschiedliche Revisionsstände oder ein gewünschter Liefertermin ohne geklärten Leistungsumfang.

Eine brauchbare Rückfrage sollte deshalb vier Informationen verbinden:

• Beobachtung: Was wurde in den Unterlagen gefunden?
• Fundstelle: In welcher E-Mail, Datei, Tabelle oder Zeichnung steht die Angabe?
• Klärungsbedarf: Welche konkrete Entscheidung oder Ergänzung fehlt?
• Auswirkung: Welcher nächste Arbeitsschritt wartet auf die Antwort?

Practical Tip: Formulieren Sie nicht „Angabe fehlt“, sondern nennen Sie die vorliegende Information und die offene Entscheidung gemeinsam. Das erleichtert dem Empfänger eine eindeutige Antwort.

Für eine erste Sichtung kann eine Anfrage in fünf Prüfbereiche gegliedert werden. Die Einteilung hilft beim Ordnen; welche Fragen im konkreten Unternehmen relevant sind, muss fachlich festgelegt werden.

Ein kontrollierter Ablauf kann in sechs Schritten aufgebaut werden:

1. Eingang zusammenführen: E-Mail, Anhänge und vorhandene Vorgangsdaten werden einer Anfrage zugeordnet.
2. Angaben extrahieren: Relevante Werte und Textstellen werden erfasst, ohne sie bereits als richtig oder verbindlich zu behandeln.
3. Fundstellen erhalten: Jede extrahierte Angabe bleibt mit ihrer Quelle und dem erkennbaren Dokumentstand verbunden.
4. Regeln prüfen: Definierte Pflichtangaben, Einheiten, Wertebereiche und Abhängigkeiten werden kontrolliert.
5. Konflikte markieren: Mehrdeutige, widersprüchliche oder nicht zuordenbare Angaben werden als Klärungsfälle ausgegeben.
6. Rückfragen freigeben: Eine fachlich zuständige Person prüft Priorität, Formulierung und Empfänger.

Das Ergebnis ist noch kein Angebotsentwurf. Es ist ein nachvollziehbarer Arbeitsstand, mit dem Vertrieb und Technik entscheiden können, welche Informationen zuerst eingeholt werden müssen.

Nicht jeder Prüfschritt benötigt generative KI. Für einen belastbaren Prozess sollten die technischen Bausteine nach ihrer Aufgabe getrennt werden.

Practical Tip: Lassen Sie ein System Lücken zunächst markieren, nicht automatisch schließen. Eine offen ausgewiesene Unklarheit ist für den Angebotsprozess wertvoller als eine plausibel klingende Annahme ohne bestätigte Grundlage.

Wenn jede Datei einzeln abgearbeitet wird, entstehen leicht mehrere Fragen zum selben Sachverhalt. Für den Empfänger ist eine Sortierung nach Entscheidung meist übersichtlicher. Ein mögliches Raster unterscheidet:

• Blockierend: Ohne Antwort kann die technische Auswahl oder Kalkulation nicht begonnen werden.
• Variantenbildend: Die Antwort entscheidet, welche Ausführung oder Option angeboten wird.
• Bestätigend: Eine Annahme ist möglich, soll aber vor der weiteren Verwendung bestätigt werden.
• Nachgelagert: Die Information wird für Angebotstext, Lieferung oder Dokumentation benötigt, blockiert die erste Kalkulation jedoch nicht.

Auch diese Priorisierung ist eine Arbeitsstruktur. Ob ein Punkt tatsächlich blockiert, entscheiden Produkt, Risiko und interner Ablauf.

Angenommen, eine Anfrage enthält eine Zeichnung mit Revisionsstand B, eine Stückliste mit Revisionsstand C und in der E-Mail den Hinweis „Lieferung bis Ende Oktober“. Daraus sollten nicht automatisch technische Werte ergänzt werden. Eine prüfbare Rückfragenliste könnte stattdessen so aussehen:

Wichtig ist die Verbindung zwischen Feststellung und Frage. Dadurch bleibt erkennbar, warum die Rückfrage gestellt wurde und welche Unterlage nach der Antwort aktualisiert werden muss.

Für einen begrenzten Test genügt zunächst eine Tabelle mit diesen Spalten:

• Vorgang oder Anfrage-ID
• Prüfbereich
• gefundene Angabe
• Quelle und Dokumentstand
• offene Rückfrage
• Auswirkung oder Priorität
• zuständige Rolle
• Antwort und Freigabestatus

Practical Tip: Ergänzen Sie eine Spalte „Woran hätten wir die Lücke automatisch erkennen können?“. Nach einigen realen Vorgängen wird sichtbar, welche Prüfungen als feste Regel taugen und welche weiterhin fachliche Einordnung brauchen.

Ein Pilot sollte nicht daran gemessen werden, ob das System besonders viele Fragen erzeugt. Prüfen lässt sich vielmehr, ob die ausgegebenen Rückfragen für die weitere Bearbeitung brauchbar sind:

• Ist jede Frage einer konkreten Fundstelle oder Regel zugeordnet?
• Werden identische Klärungspunkte aus mehreren Dateien zusammengeführt?
• Bleiben Widersprüche sichtbar, statt still durch eine Annahme ersetzt zu werden?
• Kann eine Fachperson eine Frage ändern, zurückweisen oder ergänzen?
• Wird nach der Antwort nachvollziehbar, welche Daten und Dokumente aktualisiert wurden?

Für die Vorbereitung eines solchen Piloten hilft die Data Inventory Before Quotation Automation. Das übergeordnete Zielbild vom Eingang bis zum prüfbaren Entwurf beschreibt der Beitrag Automating Technical Customer Enquiries.

Eine gute Rückfragenliste macht nicht nur fehlende Felder sichtbar. Sie verbindet Angaben, Quellen, Widersprüche, Auswirkungen und Verantwortlichkeiten. Dadurch entsteht zwischen eingehender Anfrage und Angebotsentwurf ein eigener, kontrollierbarer Arbeitsschritt.

Regeln können eindeutige Prüfungen übernehmen, Suche und RAG können freigegebenes Wissen bereitstellen, und ein Sprachmodell kann offene Punkte bündeln und verständlich formulieren. Die fachliche Entscheidung, welche Frage gestellt und welche Grundlage verwendet wird, bleibt davon getrennt. Wer diesen Klärungsschritt für den eigenen Prozess strukturieren möchte, findet im Quotation Process Assessment den passenden Einstieg.