Angebotserstellung automatisieren: Entwurf, Preisregeln und Freigabe

Kurzantwort: Wie lässt sich die Angebotserstellung automatisieren?

Ein sicher automatisierter Angebotsprozess übernimmt die wiederkehrende Vorarbeit: Anfrage und Anlagen erfassen, Kundenzuordnung prüfen, Positionen strukturieren, freigegebene Produkt- und Preisdaten abrufen, einen Entwurf erzeugen und offene Punkte sichtbar machen. Ein verantwortlicher Mitarbeiter prüft Kalkulation, Leistungsumfang, Bedingungen und Empfänger. Erst eine ausdrückliche Freigabe erlaubt die Erzeugung der finalen Fassung und anschließend den Versand.

Entscheidend ist die Systemgrenze. Ein Sprachmodell darf Inhalte verstehen und verständlich formulieren, ist aber kein verlässliches Preis- oder Vertragssystem. Artikelstamm, Preislisten, kundenspezifische Konditionen, Steuern, Lieferbarkeit und Gültigkeit müssen aus den dafür verantwortlichen Quellen kommen und durch deterministische Regeln verarbeitet werden.

Vom Dokumentgenerator zum gesteuerten Angebotsvorgang

Viele Ansätze beginnen mit einer PDF-Vorlage. Das greift zu kurz: Der eigentliche Gegenstand ist ein Vorgang mit Daten, Entscheidungen und einem aktuellen Zustand. Während der Entwurf entsteht, können Informationen fehlen, Preise ablaufen, eine Sonderkondition eine weitere Freigabe erfordern oder die Anfrage geändert werden. Diese Ereignisse müssen den Vorgang steuern, nicht nur Textfelder in einem Dokument füllen.

Das Zielbild trennt mindestens Anfrage, strukturierte Bedarfsdaten, Kalkulation, Angebotsversion und Kommunikation. Das CRM kann Kunde und Verkaufschance führen, das ERP Produkt-, Leistungs- und Preisdaten, ein DMS freigegebene Vorlagen und Bedingungen. Die Workflow-Schicht koordiniert Übergaben, Prüfungen, Fristen und Ausnahmen, ohne die Fachverantwortung dieser Systeme zu duplizieren.

Anfragen erfassen, ohne fehlende Angaben zu erraten

Anfragen kommen per E-Mail, Formular, PDF, Tabelle oder aus dem CRM. Zuerst werden Originalnachricht und Anlagen unverändert einem Vorgang zugeordnet. Danach extrahiert die Automatisierung beispielsweise Ansprechpartner, Leistungsbeschreibung, Menge, Termin, Lieferort und Referenzen. Jedes Feld erhält Herkunft und Prüfstatus; das Original bleibt für Rückfragen erreichbar.

Pflichtangaben hängen vom Angebotstyp ab. Bei einem Standardprodukt können Artikel und Menge genügen, bei einer technischen Leistung braucht es möglicherweise Standort, Ausführung, Abnahme oder Voraussetzungen. Fehlt eine entscheidende Angabe, wechselt der Vorgang in den Zustand ‚Klärung erforderlich‘. Eine vorbereitete Rückfrage ist hilfreicher als ein scheinbar vollständiger, aber fachlich falscher Entwurf.

• Originaleingang und Anhänge unverändert sichern
• Kunde, Kontakt und Anfrage gegen CRM-Daten abgleichen
• extrahierte Werte mit Quelle und Konfidenz kennzeichnen
• Pflichtfelder je Angebotsart prüfen
• Widersprüche und fehlende Angaben als Aufgaben ausgeben
• erst nach Klärung in Kalkulation und Entwurf übergehen

Preislogik aus dem Sprachmodell herauslösen

Preise, Rabatte und Zuschläge brauchen eine benannte fachliche Quelle. Dazu können ERP-Preiskonditionen, ein freigegebener Leistungskatalog, kundenspezifische Vereinbarungen oder eine kontrollierte Kalkulation gehören. Die Automatisierung liest den zum Stichtag gültigen Stand und dokumentiert, welche Regel angewendet wurde. Sie sollte weder aus alten Angeboten extrapolieren noch eine Lücke mit einem marktüblich wirkenden Betrag füllen.

Regeln müssen auch Reihenfolge und Grenzen festlegen: Mengenstaffel vor Kundenrabatt, Mindestmarge, Genehmigung oberhalb eines Nachlasses, Zuschlag für Sonderausführung, Steuer- und Währungsbehandlung sowie Gültigkeitszeitraum. Ist eine Kombination nicht vorgesehen, entsteht keine stillschweigende Ausnahme, sondern eine Prüfaufgabe. Damit bleibt die Kalkulation reproduzierbar und kann unabhängig vom erzeugten Text getestet werden.

Den Ablauf mit eindeutigen Zuständen modellieren

Ein Angebotsvorgang braucht genau einen nachvollziehbaren Zustand. Bezeichnungen dürfen an vorhandene Systeme angepasst werden, müssen aber fachlich eindeutig bleiben. Der Status ‚Entwurf‘ darf nicht mit ‚freigegeben‘ oder ‚versandt‘ gleichgesetzt werden. Jede Änderung erhält einen zulässigen Auslöser, eine verantwortliche Rolle und ein protokolliertes Ergebnis.

Ein praktikabler Grundablauf lautet: eingegangen, strukturiert, Klärung erforderlich, kalkuliert, Entwurf erstellt, in Prüfung, freigegeben, finalisiert, versandt, angenommen, abgelehnt oder abgelaufen. Fehlerzustände für fehlgeschlagene Systemübergaben bleiben sichtbar. Ein technischer Wiederholungsversuch darf den fachlichen Zustand nicht unkontrolliert überspringen.

Freigaben an die geprüfte Version binden

Die Freigabe gilt nur für den tatsächlich geprüften Stand. Deshalb erhält jeder Entwurf eine Version und verweist auf Anfrage, Positionen, Mengen, Preisstand, Regelversion, Vorlage und Bedingungen. Ändert sich danach ein freigaberelevanter Wert, wird eine neue Version erzeugt und der Status zurück auf Prüfung gesetzt.

Nicht jede redaktionelle Korrektur muss denselben Freigabeweg auslösen. Das Unternehmen legt fest, welche Felder kaufmännisch oder rechtlich wesentlich sind. So kann eine Tippfehlerkorrektur anders behandelt werden als ein geänderter Preis, Leistungsumfang, Liefertermin oder Haftungstext. Entscheidend ist, dass die Regel vorab definiert und nicht nachträglich passend gemacht wird.

Die Freigabe als vollständiges Entscheidungspaket gestalten

Prüfende brauchen nicht nur das fertige PDF. Das Entscheidungspaket zeigt erkannte Anfrage, offene Annahmen, Positionen, Preisquellen, angewendete Rabatte, Abweichungen von Standardbedingungen und die vorherige Version. Unsichere Zuordnungen werden hervorgehoben. So konzentriert sich die Prüfung auf echte Entscheidungen statt auf eine vollständige manuelle Neuerfassung.

Freigabeschwellen können sich nach Betrag, Rabatt, Marge, Abweichung, Kundengruppe oder Leistungsart richten. Vertretungen und Eskalationen müssen geregelt sein. Eine automatische Erinnerung darf eine Entscheidung nicht ersetzen. Das Protokoll hält fest, wer welche Version mit welchem Ergebnis geprüft und welche Begründung bei einer Ausnahme erfasst hat.

Finalisierung und Versand bewusst trennen

Nach der Freigabe wird aus den bestätigten Daten die finale, nicht mehr still veränderbare Angebotsfassung erzeugt. Dokumentnummer, Version, Gültigkeit, Anlagen und Empfänger werden nochmals technisch geprüft. Erst ein eigener Versandauftrag übergibt das Dokument an E-Mail, Kundenportal oder anderes Ziel. Diese Trennung verhindert, dass eine Prüfung versehentlich externe Kommunikation auslöst.

Der Versand erhält einen eindeutigen Schlüssel und einen Nachweis über Ziel, Zeitpunkt, Kanal und verwendete Dokumentversion. Schlägt die Verbindung nach dem Absenden ab, prüft das System zuerst den vorhandenen Status, bevor es wiederholt. RFC 9110 beschreibt, warum nicht-idempotente Aktionen nicht blind erneut ausgeführt werden dürfen. Für Angebote bedeutet das: Wiederanlauf und Dublettenprüfung gehören ausdrücklich ins Design.

KI dort einsetzen, wo ihre Ausgabe kontrollierbar bleibt

Das BSI weist in seiner Veröffentlichung zu generativen KI-Modellen auf unzutreffende Ausgaben und die Notwendigkeit geeigneter Gegenmaßnahmen hin. Das NIST-Profil zum AI Risk Management Framework empfiehlt, Risiken über den Lebenszyklus zuzuordnen, zu messen und zu steuern. Für die Angebotserstellung folgt daraus eine klare Aufgabenverteilung: KI strukturiert Sprache und schlägt Formulierungen vor; verlässliche Systeme und prüfbare Regeln entscheiden über verbindliche Werte.

Testfälle müssen typische und kritische Situationen enthalten: unbekannter Artikel, widersprüchliche Mengen, veraltete Preisliste, Sonderrabatt, geänderte Anfrage, doppelte E-Mail, Systemausfall nach Freigabe und Versandwiederholung. Gemessen werden nicht nur Durchlaufzeiten, sondern auch Klärungsquote, Korrekturarten, falsch zugeordnete Positionen, zurückgezogene Freigaben und technische Dubletten.

Mit einem begrenzten Angebotssegment starten

Ein guter Pilot umfasst eine häufige, ausreichend standardisierte Angebotsart mit klarer Datenquelle und benannten Prüfern. Historische Anfragen helfen beim Test, dürfen aber nicht als Beleg für künftig gültige Preise dienen. Vor dem Produktivstart werden Pflichtfelder, Regeln, Zustände, Schnittstellen und Abbruchwege mit realistischen Testfällen geprüft.

Die Einführung sollte die fachliche Entscheidung sichtbar verbessern, nicht nur Dokumente schneller erzeugen. Beginnen Sie deshalb mit Erfassung, Klärung und Entwurf. Automatisieren Sie Finalisierung und Versand erst, wenn Versionierung, Freigabe, Dublettenvermeidung und Nachweise zuverlässig funktionieren.

• 1. Angebotsart, Eingangskanäle und verantwortliche Systeme abgrenzen.
• 2. Pflichtangaben, Preisquellen, Regeln und Ausnahmefälle dokumentieren.
• 3. Zustände, Rollen, Freigabeschwellen und Vertretungen festlegen.
• 4. Entwurfserzeugung mit bekannten Fällen und absichtlichen Fehlern testen.
• 5. Versionierung, Rücksetzung der Freigabe und Wiederanlauf prüfen.
• 6. Begrenzten Pilot mit manueller Endfreigabe produktiv begleiten.
• 7. Befunde auswerten und den Automatisierungsumfang schrittweise erweitern.