Interner RFQ-Copilot
Interner RFQ-Copilot für technische Angebotsprozesse
Der Copilot verarbeitet eingehende Anfragen intern und bereitet einen prüfbaren Entwurf für Vertrieb und Engineering vor. Kunden sehen keine ungeprüften Ergebnisse, und kein Preis wird ohne freigegebene Quelle erzeugt.
Kurz erklärt
Was ist ein RFQ-Copilot?
Ein interner RFQ-Copilot strukturiert technische Kundenanfragen, verbindet Anforderungen mit ihren Quellen und markiert Lücken, Widersprüche sowie nicht abgedeckte Sonderfälle. Er bereitet Entscheidungen vor, trifft aber keine autonome Machbarkeits-, Preis- oder Freigabeentscheidung.
Eingaben
- E-Mail-Text und Anhänge;
- Lastenhefte und Spezifikationen;
- Fotos und vorhandene Zeichnungen;
- Gesprächsnotizen;
- manuelle Ergänzungen des Vertriebs.
Ausgaben
- strukturierte Anforderungsakte;
- Quelle pro Feld;
- fehlende und widersprüchliche Angaben;
- priorisierte Rückfragen;
- Annahmen und Ausschlüsse;
- vorläufige Risikohinweise;
- mögliche Module ausschließlich aus freigegebenem Katalog;
- regelbasierte interne Budgetbasis, soweit abgedeckt;
- Entwurf für die weitere Übergabe.
Kontrollen
- Fakten, Interpretation und Annahmen werden getrennt.
- Jede wirtschaftliche Zeile verweist auf eine freigegebene Quelle.
- Regeln und Preise besitzen Version und Gültigkeitsdatum.
- Nicht abgedeckte Fälle werden blockiert.
- Export oder Weitergabe erfordert eine explizite menschliche Freigabe.
- Korrekturen werden nachvollziehbar protokolliert.
Einordnung
Was unterscheidet RFQ-Copilot, CPQ, CRM und Document AI?
Die vier Kategorien lösen unterschiedliche Aufgaben und können sich ergänzen. Entscheidend ist, an welcher Stelle des Angebotsprozesses strukturierte, freigegebene Daten bereits vorliegen.
RFQ-Copilot
Zweck: unstrukturierte technische Anfragen vor Kalkulation und Engineering qualifizieren.
- Eingabe: E-Mails, Spezifikationen, Anhänge und freigegebene Regeln.
- Ausgabe: Anforderungsakte, Quellen, Lücken, Widersprüche, Risiken und Rückfragen.
- Automatisiert: Strukturierung, Prüfhinweise und abgedeckte Regelanwendung.
- Entscheidet nicht: Machbarkeit, Preisfreigabe oder Kundenantwort.
- Freigabe: menschliche Prüfung ist vor jeder Weitergabe verpflichtend.
- Passt: wenn RFQs vor einem CPQ oder Engineering-Schritt noch unstrukturiert sind.
CPQ
Zweck: Produkte und Optionen innerhalb eines gepflegten Regel- und Preismodells konfigurieren.
- Eingabe: strukturierte Merkmale, Produktlogik, Kataloge und Preisregeln.
- Ausgabe: gültige Konfiguration, Preis oder Angebotsdokument.
- Automatisiert: Konfiguration und Kalkulation innerhalb des definierten Modells.
- Entscheidet nicht: unklare technische Anforderungen außerhalb des Modells.
- Freigabe: richtet sich nach Preis-, Ausnahme- und Angebotsregeln des Unternehmens.
- Passt: wenn Produkt- und Preisdaten bereits strukturiert und gepflegt sind.
CRM
Zweck: Kunden, Kontakte, Aktivitäten, Verkaufschancen und Kommunikation verwalten.
- Eingabe: Konto-, Kontakt-, Aktivitäts- und Opportunity-Daten.
- Ausgabe: Pipeline, Historie, Aufgaben und Vertriebsstatus.
- Automatisiert: Vertriebsabläufe, Erinnerungen und Datenübergaben.
- Entscheidet nicht: technische Eignung, Konfiguration oder Preis.
- Freigabe: folgt den Vertriebs- und Datenprozessen des Unternehmens.
- Passt: als führendes System für Kundenbeziehung und Opportunity-Status.
Document AI
Zweck: Inhalte aus Dokumenten und Bildern extrahieren, klassifizieren oder zuordnen.
- Eingabe: PDFs, Scans, Bilder und andere Dokumente.
- Ausgabe: Text, Felder, Klassen oder erkannte Dokumentstrukturen.
- Automatisiert: Erfassung und Vorstrukturierung von Dokumentinhalten.
- Entscheidet nicht: technische Machbarkeit, Preis oder Angebotsfreigabe.
- Freigabe: mehrdeutige oder geschäftskritische Inhalte benötigen Prüfung.
- Passt: als Extraktionsbaustein innerhalb eines fachlich kontrollierten Prozesses.
Warum intern beginnen
Ein interner Pilot kann mit historischen Fällen im Schattenbetrieb lernen. So gelangen keine ungeprüften Ergebnisse zu Kunden.
Pilotgrenzen
- ein klar abgegrenzter Angebotsprozess;
- wenige interne Nutzer;
- kein automatischer Versand;
- keine verbindliche Kalkulation;
- keine tiefe ERP-Integration;
- keine Abdeckung des gesamten Portfolios;
- klare technische Ausschlüsse.
Häufige Fragen
Fragen zum internen RFQ-Copiloten
Kann der Copilot Machbarkeit bestätigen?
Nein. Er kann bekannte Regeln prüfen und Abweichungen markieren. Technische Machbarkeit bleibt eine Entscheidung der zuständigen Experten.
Was passiert bei Sonderfällen?
Der Fall wird mit dem konkreten Blockiergrund an Engineering eskaliert. Das System soll Unsicherheit sichtbar machen, nicht durch eine erzwungene Antwort verdecken.
Können mehrere Produkt- oder Lösungsbereiche gleichzeitig pilotiert werden?
Für den ersten Pilot nicht. Zunächst sollte ein abgegrenzter Angebotsprozess stabil funktionieren.
Nächster Schritt
RFQ Readiness Workshop anfragen
Beschreiben Sie Anfragevolumen, beteiligte Rollen und den größten Engpass. Für die erste Einschätzung sind keine vertraulichen Dokumente erforderlich. Danach lässt sich ein geeigneter Workshop- oder No-Go-Schritt abgrenzen.
Kein automatischer Versand und keine verbindliche Kalkulation ohne menschliche Freigabe.