Vom Lead zum formalisierten Pre-Sales

Chronologie: 15. September 2026 · vierte Veranstaltung. Primärquelle: vollständiges Transkript. Ausgangspunkt ist ein Kontakt durch Empfehlung, Veranstaltung oder Fachinhalt. Ziel ist, den Lead zu einem technischen Folgegespräch und den ersten formalen Pre-Sales-Arbeitsprodukten zu führen.

1. Eine Veranstaltung ist der Anfang des Trichters, nicht sein Ende

Diese Sitzung führt das Konferenzthema fort und betrachtet es nun als gesteuerten Geschäftsentwicklungsprozess statt bloßes Networking.

Die zugrunde liegende Abfolge:

Sichtbarkeit / Veranstaltung
          ↓
Erstkontakt
          ↓
Lead
          ↓
Erstgespräch
          ↓
erkanntes Problem
          ↓
technisches Folgegespräch
          ↓
formaler Informationsaustausch

Eine erfolgreiche Geschäftsreise bemisst sich nicht an der Zahl verteilter Visitenkarten, sondern an Kontakten mit einer konkreten Folgeaktion.

2. Ein Vortragender ist Teil einer Kampagne, keine isolierte Person auf einer Bühne

Die Vorlesung verdeutlicht: Ein Vortragsplatz wirkt nur, wenn er mit Vorbereitung vor der Veranstaltung und konsequenten Maßnahmen danach verbunden ist.

Vor der Veranstaltung

• Ein Thema anhand seines Bezugs zum Geschäftsziel wählen;
• den Vortragenden vorbereiten;
• Ankündigungen veröffentlichen;
• Zielunternehmen und Kontaktpersonen identifizieren;
• unterstützendes Team und Fallbeispiele vorbereiten.

Während der Veranstaltung

• Der Vortragende gewinnt Aufmerksamkeit und schafft fachliche Autorität;
• das Team knüpft im Veranstaltungsraum Kontakte und hört gezielt auf Kundenprobleme;
• Kontakte und Gesprächskontext werden sofort festgehalten.

Nach der Veranstaltung

• Zeitnah nachfassen;
• ein konkretes Folgegespräch vorschlagen;
• intern zwischen Kontakt, Lead und Geschäftschance unterscheiden.

3. Im Erstgespräch bewertet der Kunde konkrete Menschen, nicht nur eine Firma

Vor einem ersten vertieften Gespräch muss das Team recherchieren: Profil des potenziellen Kunden, seine Produkte, öffentlich dokumentierte Technologiegebiete und Rollen der Teilnehmenden.

Die Präsentation des Anbieters wird in drei große Teile gegliedert:

1. Wer wir sind: Unternehmensgröße, Geografie, Branchen und Lieferfähigkeit.
2. Warum wir vertrauenswürdig sind: Fallstudien, Prozesse sowie einschlägige Normen oder Zertifizierungen.
3. Welche vergleichbaren Aufgaben wir bereits bearbeitet haben: wenige, genau auf die Zielgruppe abgestimmte Beispiele.

Eine wesentliche Regel: Dem Kunden nicht das gesamte Portfolio auf einmal vorführen. Ausgewählte Fallstudien müssen zu seinem Kontext passen.

4. Von der Firmenpräsentation zur Bedarfsermittlung

Die Präsentation öffnet nur die Tür. Der eigentliche Wert entsteht, wenn der Dienstleister konkrete Fragen stellt und Domänenkompetenz zeigt.

Firmenvorstellung
          ↓
passende Fallstudien
          ↓
technische Fragen
          ↓
konkretes Kundenproblem
          ↓
„Darüber sollten wir gesondert sprechen“

Metaphorisch spricht die Vorlesung davon, „den Verband genau dort anzulegen, wo es schmerzt“: Ziel ist nicht, beim ersten Treffen das ganze Problem zu lösen, sondern es zu erkennen und einschlägige Fähigkeiten glaubwürdig zu belegen.

5. Technisches Folgegespräch

Zum nächsten Treffen gehören Personen, die im betreffenden Fachgebiet fundiert sprechen können. Wiedererkennbare Gesprächspartner sind wichtig: Die Schlüsselpersonen des Erstkontakts sollen nicht vollständig verschwinden, sodass Vertrauen erneut von Grund auf aufgebaut werden müsste.

Ziele des Folgegesprächs in diesem Kurs:

• Kundenproblem präzisieren;
• technische Tiefe belegen;
• Randbedingungen verstehen;
• nicht kostenlos ein vollständiges Produkt entwerfen;
• zu einem strukturierten Informationsaustausch übergehen.

6. RFI — Request for Information

Mit einem RFI bewertet ein potenzieller Kunde die Leistungsfähigkeit eines Anbieters. Es kann sich um eine einfache Tabelle mit Fragen und Spalten für Antworten und Nachweise handeln.

Typische Themen sind:

• Unternehmensprofil;
• relevante Fachgebiete;
• Ingenieurrollen und Kapazitäten;
• Werkzeuge;
• Programmiersprachen und Technologie-Stack;
• Qualitäts-, Safety- und Security-Prozesse;
• Erfahrung mit Normen und Frameworks;
• Labore, Ausstattung und Fertigungsmöglichkeiten;
• zur Veröffentlichung freigegebene Referenzen oder Fallbeschreibungen.

Bei größeren Beschaffungsvorgängen erhalten oft mehrere Anbieter denselben RFI. Die Antworten sollten deshalb vergleichbar, belegbar und frei von vagen Werbeaussagen sein.

7. RFQ — Request for Quotation

Ein RFQ verlangt mehr als eine Beschreibung der Fähigkeiten: Gefragt wird nach Kostenschätzung, Umfang und Lieferzeit. In Embedded-Projekten ist das komplexer als das Zählen von Ingenieurstunden, denn zu berücksichtigen sind unter anderem:

• Entwicklungsaufwand;
• Bauteile;
• Leiterplatten- und Mechanikfertigung;
• Montage;
• Prüfausrüstung;
• Prototypen und Überarbeitungsschleifen;
• externe Labore;
• Transport und Zoll;
• Muster sowie Maßnahmen im Zusammenhang mit Zertifizierung.

Trifft ein RFQ ein, bevor das technische Problem ausreichend definiert ist, fällt die Schätzung grob aus oder hängt stark von Annahmen ab. Diese Unsicherheit muss offen dargestellt werden.

8. RFC in diesem Kurs

Die Vorlesung verwendet RFC im Sinne von Request for Clarification, also einer strukturierten Anfrage zur Präzisierung der vorgeschlagenen Lösung oder Problembeschreibung.

Redaktionelle Präzisierung 01 — Abkürzungen

RFC hat im B2B-Einkauf keine universell eindeutige Bedeutung. Im Software Engineering steht es häufig für Request for Comments; einzelne Unternehmen verwenden weitere Bedeutungen. Die Kursunterlagen müssen deshalb die Bedeutung bei der ersten Nennung ausschreiben: RFC (Request for Clarification – Terminologie dieses Kurses).

9. Das Angebot integriert das zuvor erworbene Wissen

Ein Angebot entsteht nicht ohne Vorarbeit. Es bündelt Informationen aus Gesprächen, RFI, RFQ, RFC und der eigenen Analyse des Dienstleisters.

Gespräche + RFI + RFQ + RFC + Recherche → Proposal / Angebot

Ein erster Angebotsentwurf enthält:

• Zusammenfassung für das Management und Lösungsskizze;
• Verständnis des Problems;
• Annahmen und offene Fragen;
• Grobarchitektur oder Lösungsansatz;
• Engineering-Arbeitsbereiche;
• geplante Verifikation und Validierung;
• Team und Ressourcen;
• Termin- und Aufwandsschätzung;
• Risiken und Abhängigkeiten;
• kommerzielles Modell.

Die nächste Veranstaltung vertieft Normen, Geschäftsmodelle und die Verteilung von Risiken.

10. Versionskontrolle für Pre-Sales-Unterlagen

Die Vorlesung empfiehlt, ein Angebot wie ein kontrolliertes Engineering-Arbeitsprodukt zu verwalten. Ein möglicher Ablauf ist:

0.1 → 0.2 → 0.3: interne Entwürfe
          ↓
1.0: externe Ausgabe
          ↓
Kundenfeedback
          ↓
1.1 → 1.2: interne Bearbeitung
          ↓
2.0: nächste externe Ausgabe

Nicht die Versionsnummer allein ist entscheidend. Erkennbar sein muss:

• wann die Version herausgegeben wurde;
• wer sie verfasst beziehungsweise verantwortet;
• wie ihre Änderungshistorie aussieht;
• was auf Kundenfeedback hin geändert wurde;
• welche genaue Fassung einer Schätzung oder Entscheidung zugrunde liegt.

11. Nicht das gesamte Engineering vor Vertragsabschluss verschenken

Pre-Sales-Engineering hat Grenzen. Je mehr fertige Entwurfsdetails ein Anbieter preisgibt, desto mehr unbezahlte Ingenieurleistung kann er abgeben, bevor eine Geschäftsentscheidung gefallen ist.

Die interne Überprüfung sollte daher fragen:

• Genügen die Nachweise zum Beleg unserer Kompetenz?
• Ist aus dem Angebot ein kostenloser Detailentwurf geworden?
• Sind die Annahmen transparent?
• Ist die Schätzung nachvollziehbar?
• Können die Zusagen realistisch erfüllt werden?

12. Kontrollfragen

1. Wie unterscheidet sich ein Lead von einem zufälligen Kontakt?
2. Welchen Zweck hat das Erstgespräch?
3. Weshalb müssen Fallstudien auf den Kunden zugeschnitten sein?
4. Was unterscheidet ein RFI von einem RFQ?
5. Warum umfasst eine Embedded-Projektschätzung mehr als Ingenieurstunden?
6. Weshalb muss die Bedeutung von RFC im jeweiligen Prozess explizit festgelegt werden?
7. Welche Informationen bündelt ein Proposal aus früheren Phasen?
8. Warum brauchen Pre-Sales-Dokumente Versionsverwaltung?
9. Wo liegt die Grenze zwischen Kompetenznachweis und kostenloser Ingenieurleistung?

13. Vergleich der Arbeitsprodukte

14. Übergang zum 16. September 2026

Im nächsten Schritt wird das Proposal zu einem ausgereiften technischen und kommerziellen Dokument: Welche Normen und Referenzen gelten? Wie beeinflussen Zertifizierung und Konformität die Arbeit? Wann eignet sich Time & Materials oder Fixed Price, und wer übernimmt welche Risiken?