Technische Kundenanfragen automatisieren: Vom E-Mail-Eingang zum prüfbaren Angebotsentwurf

Eine technische Kundenanfrage sieht auf den ersten Blick oft harmlos aus: eine E-Mail, zwei Anhänge und die Bitte um ein Angebot. In der Bearbeitung beginnt dann die eigentliche Arbeit. Welche Ausführung ist gemeint? Ist die Zeichnung aktuell? Fehlen Mengen, Material oder Lieferort? Passt die gewünschte Variante zum eigenen Sortiment? Und wer kann die technische Machbarkeit verbindlich beurteilen?

Genau an dieser Stelle wird Automatisierung interessant. Nicht, weil ein Sprachmodell selbstständig Preise versprechen oder ein Angebot versenden soll. Sondern weil sich ein großer Teil der Vorbereitung strukturieren lässt: Unterlagen zuordnen, Angaben erfassen, fehlende Informationen erkennen, freigegebenes Wissen finden und einen nachvollziehbaren Entwurf vorbereiten.

Der Punkt ist: Nicht das E-Mail-Postfach wird automatisiert. Automatisiert wird ein klar definierter Arbeitsprozess zwischen Anfrage, Wissen, Systemen und Freigabe.

Wer mit der Frage „Welches Modell sollen wir verwenden?“ startet, ist meistens einen Schritt zu früh. Zuerst muss klar sein, was heute tatsächlich passiert. Dazu reicht für den Anfang eine einzelne, repräsentative Anfrage.

Für diese Anfrage wird der Weg vom Eingang bis zum Angebot nachgezeichnet:

1. Eingang: Über welchen Kanal kommen Nachricht und Anhänge an?
2. Zuordnung: Woran erkennt das Team Kunde, Projekt, Produktgruppe und Zuständigkeit?
3. Klärung: Welche Pflichtangaben, Widersprüche und technischen Rückfragen werden geprüft?
4. Wissen: Welche Datenblätter, Preisstände, Regeln und früheren Lösungen werden herangezogen?
5. Entwurf: Welche Angaben werden für Kalkulation, Rückfrage oder Angebot vorbereitet?
6. Freigabe: Wer prüft Technik, Preis, Lieferfähigkeit und rechtliche Verbindlichkeit?

Diese Darstellung macht zwei Dinge sichtbar: wiederkehrende Handgriffe, die sich gut automatisieren lassen, und Entscheidungen, für die weiterhin fachliche Verantwortung nötig ist. Beides gehört in denselben Prozess.

Nicht jeder Arbeitsschritt braucht KI. Feste Regeln sind bei eindeutigen Prüfungen meist leichter zu testen und zu betreiben. Generative KI wird dort interessant, wo Sprache, unterschiedliche Dokumentformen oder mehrere mögliche Formulierungen ins Spiel kommen.

Diese Trennung ist mehr als technische Ordnung. Sie erleichtert die Fehlersuche. Wenn eine Materialangabe fehlt, muss erkennbar sein, ob sie im Original nicht vorhanden war, bei der Extraktion verloren ging oder bei der Übergabe in ein anderes System überschrieben wurde.

Viele Unternehmen denken zuerst an den fertigen Angebotstext. Für einen Pilot ist das häufig nicht der beste Startpunkt. Mehr Nutzen entsteht oft früher: bei der Frage, ob eine Anfrage überhaupt bereit für die fachliche Bearbeitung ist.

Dafür wird je Anfrageart ein kleines Informationsmodell benötigt. Es beschreibt nicht jedes denkbare Feld, sondern die Angaben, ohne die der nächste Schritt nicht sinnvoll möglich ist. Bei einem technischen Bauteil könnten das beispielsweise sein:

• Produkt oder Produktgruppe,
• Abmessungen und Toleranzen,
• Material und Oberfläche,
• Menge und gewünschter Termin,
• anzuwendende Normen oder Kundenvorgaben,
• Zeichnungsnummer und Versionsstand,
• Lieferort sowie besondere Prüf- oder Dokumentationspflichten.

Das ist ein vereinfachtes Beispiel, kein allgemeingültiger Pflichtkatalog. Die tatsächlichen Merkmale kommen aus dem eigenen Angebotsprozess. Genau darin liegt ein wichtiger Teil der Vorarbeit: Fachwissen, das heute nur als Routine im Kopf einzelner Personen steckt, wird als prüfbare Logik sichtbar.

Das Ergebnis sollte keine erfundene Ergänzung sein. Fehlt eine Angabe, wird sie als fehlend markiert. Widersprechen sich E-Mail und Zeichnung, entsteht eine Rückfrage. Ein System, das Unsicherheit sauber zeigt, ist im Angebotsprozess wertvoller als eines, das jede Lücke sprachlich elegant verdeckt.

Für die Zuordnung einer Anfrage reicht ein Sprachmodell allein nicht. Es kennt weder den aktuellen Preisstand noch automatisch die freigegebene Produktvariante oder die neueste technische Richtlinie. Dieses Wissen muss aus den vorhandenen Systemen und Dokumenten kommen.

RAG – also die Verbindung eines Sprachmodells mit einer gezielten Suche in freigegebenen Quellen – kann hier helfen. Der Europäische Datenschutzbeauftragte beschreibt RAG vereinfacht als Zusammenspiel aus Suche und Generierung. Er weist zugleich darauf hin, dass sensible Daten, Berechtigungen, Aktualität und mögliche Manipulationen der Quellen berücksichtigt werden müssen.

Für den Angebotsprozess bedeutet das:

• Jede verwendete Information braucht eine sichtbare Quelle.
• Dokumentversion und Gültigkeit müssen erkennbar sein.
• Die Suche darf nur Inhalte verwenden, die die jeweilige Person sehen darf.
• Ein ähnlicher früherer Auftrag ist ein Hinweis, aber kein Beweis für technische Eignung oder einen aktuellen Preis.
• Wenn keine belastbare Quelle vorhanden ist, muss das System nachfragen oder abbrechen.

Ob dafür RAG notwendig ist, hängt von den Quellen ab. Sind Produktmerkmale sauber im ERP oder PIM strukturiert, ist eine direkte Abfrage oft besser. RAG ist vor allem dort nützlich, wo relevantes Wissen in Datenblättern, Richtlinien, Handbüchern oder anderen längeren Dokumenten steckt.

Eine neue Automatisierung sollte nicht selbst zum nächsten Datensilo werden. Sie muss festlegen, welches System für welche Information führend bleibt.

Ein mögliches Rollenbild:

• CRM: Kunde, Kontakt, Vertriebschance, Kommunikation und Bearbeitungsstatus
• ERP: Artikel, Konditionen, Kalkulation, Verfügbarkeit und kaufmännischer Beleg
• DMS: Originalunterlagen, Versionen und nachvollziehbare Ablage
• Wissenssystem: freigegebene technische Quellen mit Suche und Berechtigungen
• Automatisierungsschicht: Übergaben, Prüfregeln, Protokollierung und Eskalationen

Dieses Bild ist keine Vorgabe für jede Systemlandschaft. In manchen Unternehmen übernimmt ein System mehrere Rollen. Entscheidend ist, dass nicht mehrere Stellen unbemerkt unterschiedliche Wahrheiten über denselben Vorgang führen.

Schreibende Zugriffe sollten schrittweise eingeführt werden. Ein Pilot kann Informationen zunächst nur lesen und einen Entwurf in einer Prüfoberfläche bereitstellen. Erst wenn Zuordnung, Rechte und Fehlerbehandlung funktionieren, wird geprüft, welche Daten kontrolliert in CRM oder ERP zurückgeschrieben werden dürfen.

Das NIST AI Risk Management Framework empfiehlt, Aufgabenbereich, Grenzen, mögliche Fehlerkosten sowie Rollen für menschliche Aufsicht klar zu dokumentieren. Das ist auch außerhalb formaler Hochrisiko-Szenarien ein vernünftiges Arbeitsprinzip.

Im technischen Vertrieb muss deshalb vorab geklärt werden, was die prüfende Person tatsächlich sieht und entscheiden kann:

• Originalanfrage und verwendete Anhänge,
• extrahierte Merkmale mit Fundstellen,
• fehlende oder widersprüchliche Angaben,
• verwendete Produkt- und Wissensquellen,
• Annahmen, die noch bestätigt werden müssen,
• Änderungen seit der letzten Bearbeitung,
• Protokoll der Freigabe und verantwortliche Person.

Eine Freigabe ist nur dann sinnvoll, wenn genügend Zeit, Fachwissen und Entscheidungsbefugnis vorhanden sind. Ein grüner Knopf am Ende eines undurchsichtigen Prozesses ist keine wirksame Kontrolle.

Der BSI-Bericht zu generativen KI-Modellen ordnet Risiken nicht nur dem Modell, sondern dem gesamten Lebenszyklus und der konkreten Nutzung zu. Für einen Angebotsprozess heißt das: Datenquelle, Verarbeitung, Ausgabe, Systemzugriff und Betrieb müssen gemeinsam geprüft werden.

Ein sinnvoller Pilot beginnt nicht mit allen Produkten, allen Kunden und einer vollständigen ERP-Integration. Besser ist eine begrenzte Anfrageart mit genügend echten, redigierten Beispielvorgängen.

Vor dem technischen Aufbau werden Ausgangswerte festgehalten:

Am Ende steht eine klare Entscheidung: weiterführen, gezielt nachbessern oder stoppen. Ein Pilot ist auch dann wertvoll, wenn er zeigt, dass zuerst Daten, Verantwortlichkeiten oder der bestehende Ablauf verbessert werden müssen.

Die stärkste Wirkung entsteht nicht durch einen möglichst autonomen Angebotsgenerator. Sie entsteht, wenn verstreute Informationen früher zusammenkommen, fehlende Angaben sichtbar werden und Fachkräfte einen nachvollziehbaren Entwurf statt eines leeren Dokuments erhalten.

Dafür braucht es einen klaren Prozess, verlässliche Quellen, definierte Systemrollen und echte Freigaben. Erst danach stellt sich die Frage, an welcher Stelle Regeln, RAG oder generative KI den größten Beitrag leisten.

Die Lösung Technische Anfrage bis Angebot zeigt das vollständige Zielbild. Wenn zuerst geklärt werden soll, welche Schritte im bestehenden Ablauf überhaupt sinnvoll automatisierbar sind, ist der Angebotsprozess-Check der passende Einstieg. Für eine breitere Einordnung weiterer Anwendungsfälle führt die KI-Beratung für Maschinenbauunternehmen direkt zum persönlichen Beratungstermin.

Quellenstand: 09.08.2026. Der Beitrag beschreibt ein Prozess- und Entscheidungsmodell, keine Rechtsberatung und keine automatisch auf jeden Betrieb übertragbare Systemarchitektur.

• NIST: AI Risk Management Framework – Core
• NIST: Generative Artificial Intelligence Profile (NIST AI 600-1)
• Europäischer Datenschutzbeauftragter: Retrieval-augmented generation (RAG)
• BSI: Generative AI Models – Opportunities and Risks for Industry and Authorities