KI im Sales-Engineer-Workflow: Wo sie hilft, wo sie scheitert

Ein Sales Engineer, den ich kenne, hat letztes Quartal einen 400.000-Dollar-Deal verloren. Nicht in der demo. Nicht im POC. Im RFP.

Er hatte den Sicherheitsfragebogen durch eine KI laufen lassen, die selbstbewusste Antworten auf 180 Fragen entwarf. Er überflog sie und verschickte sie. Bei Frage 94 beschrieb die KI eine granulare Berechtigungsfunktion, die es nicht gab. Frei erfunden.

Der Engineer auf Käuferseite bemerkte es: "Behauptet eine Fähigkeit, die wir in der demo nicht reproduzieren konnten. Den Rest sollte man auch überprüfen." Sie gingen alles noch einmal durch. Sie fanden zwei weitere Erfindungen. Der Deal geriet ins Stocken und starb dann.

Das ist die Asymmetrie von KI in der SE-Arbeit. Die Zeit, die sie spart, ist real. Die Glaubwürdigkeit, die es kostet, wenn man beim Lügen ertappt wird, ist ebenfalls real, und der Schaden ist größer als die Ersparnis.

Warum das jetzt wichtig ist

Sales Engineering sitzt an einer eigenartigen Schnittstelle. Sie leisten mehr reine Recherche- und Entwurfsarbeit als fast jeder andere im GTM: Vorbereitung vor dem Call, RFP-Antworten, Demo-Nachbesprechungen, internes Enablement, Integrations-Dokumentationen. Genau das beschleunigt KI.

Außerdem werden Sie auf eine Weise an technischer Korrektheit gemessen, wie es bei einem AE oder CSM nicht der Fall ist. Wenn der leitende Engineer eines Käufers nach Ihrem Concurrency-Modell fragt und Ihre Antwort falsch ist, verliert die Beziehung an Autorität. Und sobald ein SE bei einem technischen Bewerter eines Käufers an Autorität verliert, kommt sie nicht zurück.

Die meisten SE-Teams regeln das nach Gefühl. Manche sind voll auf KI-überall umgestiegen und verlieren still und leise ihre Glaubwürdigkeit. Manche sind aus Prinzip KI-skeptisch und arbeiten doppelt so hart, wie sie müssten. Die richtige Antwort liegt dazwischen. KI wie einen einzigen Schalter zu behandeln, ist der Fehler.

Wo KI hilft: Nutzen Sie sie

Kategorien, in denen KI Ihnen echte Zeit zurückgibt, ohne das Kundenvertrauen aufs Spiel zu setzen. Der gemeinsame Nenner: Entweder fassen Sie Quellmaterial zusammen, das die KI erhalten hat, oder Sie entwerfen etwas, das Sie vor dem Versand gründlich prüfen werden.

Recherche vor der demo

Vor einem Discovery-Call müssen Sie das Geschäft des Interessenten kennen: ihren Earnings Call, das LinkedIn-Profil ihres CEO, ihren Engineering-Blog, was sich letztes Quartal am Produkt geändert hat. Früher dauerte das 90 Minuten. Mit KI sind es 10. Das Modell erfindet nichts. Sie füttern es mit Quellmaterial und bitten es, das Wesentliche herauszuziehen.

Prompt 1: Synthese der Recherche vor der Discovery

You are helping me prepare for a discovery call with [COMPANY].
I'll paste source material below. Read it and produce:

1. Business context (3-5 sentences): what they do, who they serve, recent strategic moves.
2. Stated priorities: any goals, initiatives, or pain points mentioned in the source.
3. Stack signals: any tools, platforms, or technical choices mentioned.
4. Three open questions I should ask on the call to validate or extend the above.

Only use what's in the source material. If something isn't there, say
"not stated in source." Do not infer or guess.

[paste: latest earnings call summary, recent blog posts, leadership LinkedIn,
G2 reviews, anything else relevant]

Die Zeile "only use what's in the source material" ist entscheidend. Ohne sie füllt die KI Lücken mit selbstbewusst klingenden Allgemeinplätzen. Mit ihr bekommen Sie eine saubere Destillation.

Entwürfe für Demo-Nachbesprechungen

Aus einer 45-minütigen Aufzeichnung wird in zwei Minuten eine strukturierte Nachbesprechung. Sie prüfen, bearbeiten und versenden. Niemals automatisch versenden.

Prompt 2: Entwurf der Nachbesprechung nach dem Call

Below is a transcript from a discovery call with [PROSPECT].
Draft a follow-up email recap that includes:

- Decisions made on the call (2-4 bullets)
- Open questions I owe an answer to (with my owner-name attached)
- Open questions they owe me an answer to (with their owner-name attached)
- Agreed next step + date

Tone: professional but not stiff. Short paragraphs. No marketing language.
Do not invent commitments or capabilities I didn't mention. If you're unsure
whether something was committed, flag it as "[verify]" instead of stating it.

[paste transcript]

Die "[verify]"-Anweisung ist der tragende Teil. KI neigt dazu, Dinge aufzurunden. Aus einem zögerlichen "wir könnten uns das wahrscheinlich ansehen" wird ein festes "wir werden liefern". Sie zu zwingen, Unsicherheit zu kennzeichnen, holt diese Momente an die Oberfläche, statt sie in einem sauber aussehenden Entwurf zu vergraben.

Auftakt für RFP-Entwürfe

In jedem RFP sind 60-70 % der Fragen ausgetreten: SSO, Audit-Protokolle, Standardwerte zur Datenaufbewahrung, grundlegende Sicherheitsaufstellung. KI entwirft diese gut, weil die Antworten stabil und dokumentiert sind.

Die anderen 30-40 % entscheiden den Deal. Diese brauchen einen Menschen. Nutzen Sie KI, um die leichten 60-70 % wegzuräumen, damit Sie Zeit haben, die schwierigen 30-40 % gut zu erledigen, nicht um das Ganze schlecht zu erledigen.

Prompt 3: Erster RFP-Entwurf

Below are questions from an RFP. For each question, classify it as:

- TIER A: Standard / well-trodden (SSO, basic security, common integrations)
- TIER B: Specific to our product (limits, scale numbers, integration behavior, roadmap)
- TIER C: Strategic / open-ended (vision, differentiation, risk)

For TIER A questions only, draft an answer using the source documents I've
provided below. For TIER B and TIER C, output "REQUIRES SE/PM REVIEW" and
note which subject-matter expert should answer.

Do not draft a TIER B or TIER C answer under any circumstances. Even a draft
that says "this is approximate" can leak into the final response.

[paste source: product docs, security posture doc, last 3 completed RFPs]
[paste RFP questions]

Achten Sie darauf, was dieser Prompt nicht tut: Er erzeugt keine Antworten für die schwierigen Punkte. Er segmentiert die Arbeit. Die Aufgabe der KI ist Triage, nicht Autorenschaft für die Fragen, auf die es ankommt.

Ideenfindung für das Demo-Storyboard

Nach der technischen Discovery wissen Sie, was dem Interessenten wichtig ist. Sie brauchen einen Demo-Ablauf. KI ist hier ein nützlicher Partner für divergentes Denken. Sie schlägt Blickwinkel vor, an die Sie nicht gedacht haben, darunter auch einige falsche, was Sie zwingt, Ihre Entscheidungen zu verteidigen.

Prompt 4: Brainstorming für den Demo-Ablauf

I have a demo with [PROSPECT]. Here's what I learned in discovery:

[paste discovery notes]

Propose three different demo flows I could run. For each flow:

- The narrative arc (what's the story?)
- The 4-6 specific moments I'd show
- Which discovery point each moment ties back to
- The risk of this flow (what could go wrong, what does it under-emphasize)

These are ideas, not scripts. Do not assume specific UI screens, exact
feature names, or current product behavior. I'll validate all of that
against the actual product before building the demo.

Das Ergebnis ist Brainstorming-Material. Sie werden einen der drei Vorschläge verwerfen, die Hälfte eines anderen übernehmen und sie mit Ihrem eigenen Urteilsvermögen kombinieren. Wenn Sie irgendeinen davon als einsatzbereites Skript behandeln, haben Sie das Werkzeug falsch verstanden. Siehe auch: Demos rund um den Pain Point des Käufers gestalten.

Asynchrone Dokumente und internes Enablement

One-Pager, battlecards, interne FAQs, Onboarding-Dokumente für neue SE-Mitarbeitende. Alles risikoarm, alles intern, alles leicht zu iterieren. Das ist der Wohlfühlbereich der KI. Sie kontrollieren, was verschickt wird, das Publikum ist nachsichtig, und Korrekturen passieren in Slack statt in einer Beschaffungsentscheidung.

Prompt 5: Wettbewerbsanalyse für den internen Gebrauch

We're building an internal battlecard for [COMPETITOR]. Below is source
material: their public website, recent G2 reviews, two analyst reports,
and three customer call transcripts where this competitor was mentioned.

Produce:

1. Their public positioning (in their words, 2-3 sentences).
2. The three things they do well (cite source for each).
3. The three things customers complain about (cite which review or call).
4. Where we land vs. them on the dimensions our buyers care about most.
5. Three traps an AE might fall into when this competitor is in the deal.

This is for internal use only. Cite sources for every claim. If you can't
cite a source, do not include the claim.

[paste source]

"Cite a source for every claim" verwandelt die KI von einem selbstbewussten Schaumschläger in eine Rechercheassistenz. Das Ergebnis ist nützlicher und die Fehlerquellen werden sichtbar.

Wo KI schadet: Nutzen Sie sie nicht

Kategorien, in denen die Asymmetrie gegen Sie kippt. Die gesparte Zeit ist gering, der Schaden, wenn die KI etwas falsch macht, ist groß, und "falsch" ist bei der Prüfung schwer zu erkennen.

Kundengerichtete RFP-Antworten ohne Überarbeitung

Jedes Wort in einem RFP ist eine schriftliche Zusage. Die KI weiß nicht, was im letzten Sprint ausgeliefert wurde, welche Funktion gestrichen wurde oder dass die Integration in der demo "funktioniert", aber in der Produktion ein bekanntes Zuverlässigkeitsproblem hat. Eine flüchtige Prüfung durch einen müden SE am Freitag um 16 Uhr fängt Halluzinationen nicht ab. Prüfen Sie entweder jede Zeile oder schreiben Sie die heiklen von Grund auf neu.

Aussagen zur technischen Korrektheit

Limits, Skalierungszahlen, SLA-Bedingungen, Sicherheitszertifizierungen, Integrationsverhalten. Niemals KI. Diese kommen aus Produktdokumentationen, von PMs oder vom Sicherheitsteam. Wenn Ihr PM sagt "wir unterstützen 10.000 gleichzeitige Nutzer mit einer Antwortzeit unter 200 ms", ist das eine Aussage, die Sie treffen können. Wenn die KI das sagt, raten Sie.

Diagramme zur Integrationsarchitektur

Die KI zeichnet ein plausibles Diagramm. Plausibel ist nicht korrekt. Ein falscher Pfeil wird zur roten Flagge in der Beschaffung, weil Sicherheitsteams Architektur genauer prüfen als Funktionslisten. Zeichnen Sie die Integrationsarchitektur von Hand, validiert gegen Ihr tatsächliches Produkt.

"Ist das möglich?"-Fragen

Wenn ein Interessent fragt "kann Ihr Produkt X?", lassen Sie das niemals die KI beantworten. Wenn die KI ja sagt und es stimmt, haben Sie 30 Sekunden gespart. Wenn die KI ja sagt und es falsch ist, haben Sie eine Zusage gemacht, die Ihr Team nicht halten kann. Die richtige Antwort ist immer: "Lassen Sie mich das mit dem Produktteam abklären und ich melde mich bis [Datum] bei Ihnen."

Häufige Fallstricke

Voll-KI-RFPs, die einen einzigen menschlichen Durchgang bekommen. Halluzinationen klingen flüssig. Sie verwenden die richtigen Produktnamen, die richtige Formulierung, den richtigen Rhythmus. Was falsch ist, ist eine einzige Faktenaussage, vergraben in einem Absatz, der sonst sauber liest. Beim Überfliegen werden Sie sie nicht entdecken. Prüfen Sie entweder jede Zeile oder schreiben Sie die technisch präzisen Abschnitte von Hand neu.

KI-Demo-Storyboards als einsatzbereit behandeln. Die KI kennt die tatsächlichen Bildschirme Ihres Produkts nicht, die neuesten UI-Änderungen oder den im letzten Release umsortierten Workflow. Storyboards sind Ideenfindung. Skripte werden von Hand am lebenden Produkt erstellt.

Die KI fragen "ist X in unserem Produkt möglich?" Das Modell wird raten, selbstbewusst. Beziehen Sie Aussagen zu Produktfähigkeiten immer aus dem tatsächlichen Produkt oder von jemandem, der daran arbeitet.

Verdeckter KI-Einsatz, der intern Vertrauen zerstört. Wenn ein PM eine KI-generierte Zusage in Ihrer follow-up-E-Mail findet, ist die Bereinigung schlimmer als die Zeit, die die KI gespart hat. Seien Sie gegenüber Ihrem Team offen darüber, wo Sie KI einsetzen.

"Gesparte Zeit" mit "gutem Ergebnis" verwechseln. KI spart Zeit. Ob das Ergebnis gut ist, ist eine separate Frage. Wenn Ihr Team die KI-Einführung anhand gesparter Stunden feiert, ohne die Gewinnrate und die Bestehensquote der Prüfung auf technische Korrektheit zu messen, fliegen Sie blind. Siehe häufige Sales-Engineer-Fallstricke.

Der Entscheidungsbaum "KI hier, nicht dort"

Bevor Sie KI für eine Aufgabe einsetzen, stellen Sie drei Fragen:

Geht das an einen Kunden? Wenn nein, ist KI in der Regel in Ordnung. Wenn ja, weiter.
Trifft es eine technische Aussage? Wenn nein, KI-Entwurf plus leichte Prüfung. Wenn ja, weiter.
Kann eine falsche Antwort einen Deal kosten? Wenn nein, KI-Entwurf plus gründliche Prüfung. Wenn ja, keine KI. Schreiben Sie von Hand, beziehen Sie Aussagen direkt aus der Quelle.

Die ehrliche Version davon ist noch einfacher: Je höher der Einsatz und je spezifischer die technische Aussage, desto weniger KI sollten Sie nutzen. Je geringer der Einsatz und je mehr es um das Destillieren von Quellmaterial geht, desto mehr KI sollten Sie nutzen.

Checkliste zur Prüfung von KI-Ergebnissen

Bevor KI-entworfene Inhalte nach außen gehen:

Jede Aussage zu Produktfähigkeiten aus Dokumentationen oder von einem Fachexperten belegt
Keine erfundenen Funktionen (durchsuchen Sie die Dokumentation nach jedem Funktionsnamen, den Sie nicht kennen)
Alle Zahlen verifiziert: Limits, SLAs, Performance-Benchmarks, Kundenzahlen
Inhalt auf dem Stand des neuesten Release (keine Aussagen über veraltetes Verhalten)
Tonfall passt zur Stimme Ihres Teams (KI-Floskeln und Füllverben entfernen, die nicht nach Ihrem Team klingen)
Keine erfundenen Kundenreferenzen (KI erfindet manchmal Logos oder Zitate)
Antworten zu Grenzfällen vom zuständigen PM geprüft
Alles, was mit "[verify]" markiert ist, ist jetzt tatsächlich verifiziert
Sie würden jede Zeile gegenüber dem technischen Bewerter des Käufers ohne Zögern verteidigen

Wenn ein Satz Sie zusammenzucken ließe, sollte er in einem späteren Gespräch auftauchen, beheben Sie ihn jetzt.

Erfolg messen

Wenn Sie KI in einem SE-Team ausrollen, verfolgen Sie monatlich drei Dinge.

Gesparte Recherchezeit pro Opportunity. Die Vorbereitungsstunden vor der demo sollten spürbar sinken. Ziel: 50 % Reduktion innerhalb des ersten Quartals.

RFP-Durchlaufzeit gegen RFP-Gewinnrate. Die Zeit von der Aufnahme bis zum ersten internen Entwurf sollte sinken. Die Gewinnrate bei RFPs sollte gehalten werden oder sich verbessern. Wenn die Gewinnrate sinkt, während sich die Durchlaufzeit verbessert, haben Sie Geschwindigkeit gegen Genauigkeit eingetauscht. Ziehen Sie zurück.

Bestehensquote der Prüfung auf technische Korrektheit. Welcher Prozentsatz der KI-entworfenen, kundengerichteten Inhalte besteht die SE-Prüfung ohne Überarbeitung? Liegt er über 90 %, nutzen Sie KI zu wenig. Liegt er unter 50 %, setzen Sie KI an den falschen Stellen ein. Gesunder Bereich: 60-80 %.

Das Ziel ist nicht KI überall. Es ist KI dort, wo sie sich bezahlt macht.

Die Fähigkeit, auf die es wirklich ankommt

Prompt Engineering wird als die SE-KI-Fähigkeit überschätzt. Die tragende Fähigkeit ist das Urteilsvermögen einer prüfenden Person: zu wissen, was man vertrauen, was man verifizieren, was man verwerfen und neu schreiben sollte. Das kommt aus Produktwissen, Zeit im Feld und dem Narbengewebe, einmal eine falsche Antwort verschickt zu haben.

Ein Junior-SE mit großartigen Prompts und ohne Produkttiefe produziert selbstbewusste, plausible, gelegentlich falsche Arbeit. Ein Senior-SE mit mittelmäßigen Prompts und tiefem Produktwissen fängt die Lügen ab und liefert sauberes Ergebnis. Stellen Sie für das zweite Profil ein. Die Werkzeuge sind einfach. Das Urteilsvermögen ist schwer.

Dieses Urteilsvermögen prägt den breiteren SE-Tool- und Tech-Stack. KI ist eine Schicht, die auf Produktwissen, Discovery-Fähigkeiten und Demo-Handwerk aufsitzt. Keine davon ist durch KI ersetzbar.

Wie Rework den SE-KI-Workflow unterstützt

Die meisten SE-Teams, die KI nutzen, haben Prompts in Notion, Nachbesprechungsentwürfe in Dokumenten, RFP-Antworten in einem separaten Tool und verlässliche Produktinformationen verstreut über Confluence, Slack und die Köpfe der PMs. Die KI entwirft am Ende aus unvollständigem Quellmaterial, und der SE ist der Einzige, der das in Einklang bringt.

Rework Work Ops zentralisiert, was die KI braucht: eine gemeinsame Bibliothek geprüfter Produktantworten, einen Tracker für "[verify]"-Punkte und eine Nachbesprechungsvorlage, die die Notizen nach der demo direkt mit der Opportunity in Rework CRM verknüpft. Genehmigte Nachbesprechungen liegen neben dem Deal, nicht in einer Slack-DM. Work Ops beginnt bei 6 $/Nutzer/Monat, CRM bei 12 $/Nutzer/Monat.

Der Punkt ist nicht "Rework macht KI für Sie". Es geht darum, dass KI nur so gut ist wie das Quellmaterial und die Prüfung drumherum.

Was Sie mitnehmen sollten

Die SEs, die in den nächsten zwei Jahren gewinnen, sind nicht die mit den meisten KI-Tools. Es sind die, die wissen, welche 30 % ihrer Woche die KI gut erledigt und welche 70 % weiterhin ihr Urteilsvermögen erfordern. Sie nutzen KI, um Entwurfsarbeit wegzuräumen, damit sie mehr Zeit für das haben, was Deals entscheidet: Discovery, Demo-Design, die technisch präzisen Antworten, die das Vertrauen des Käufers aufbauen.

KI macht keinen großartigen SE. Ein großartiger SE nutzt KI als ein Werkzeug unter vielen, mit klarem Blick dafür, wo sie sich bezahlt macht und wo sie still und leise den Deal kostet, von dem Sie dachten, Sie hätten ihn gewonnen.

Sales Engineer Playbooks