Ein Tag im Leben eines Sales Engineers

Wie diese Rolle wirklich aussieht

• Ein durchschnittlicher SE betreut jederzeit 4 bis 6 aktive Deals im Mid-Market-B2B-SaaS, davon 2 bis 3 in einem aktiven POC.
• Die beste technische Gewinnrate liegt bei 70 bis 80 %: 7 bis 8 von 10 POCs, an denen der SE beteiligt ist, werden zu Closed-Won, laut Benchmarks, die im Presales Leadership Collective geteilt wurden.
• Verhältnis der Demo-Vorbereitung: 1,5 bis 2 Stunden Vorbereitung für jede 30 Minuten Live-demo bei einer maßgeschneiderten, discovery-geführten demo. Der Weg "die Standard-demo anwerfen" ist schneller, konvertiert aber halb so gut.
• Der SE ist bei 60 bis 80 % der Closed-Won-Deals im Mid-Market im Deal-Team in Unternehmen mit einer formalen SE-Funktion, laut Forrester-Pre-Sales-Benchmarking.
• Der Wissensbeitrag ist der nachlaufende Indikator, auf den es ankommt: Ein SE, der Demos liefert, aber nie dokumentiert, ist ein Single Point of Failure, der nur darauf wartet, einzutreten.

Der SE-Tag in einem Diagramm

Fünf Blöcke: Vorbereiten, Demo, Abstimmen, Bauen, Dokumentieren. Sie beginnen damit, zu lesen, was der AE erfasst hat. Sie führen den Call. Sie sortieren die Pipeline mit dem AE beim Mittagessen. Sie bauen, was der Interessent braucht, um zu glauben: Sandbox, Integrationsspezifikation, Sicherheitsantwort. Sie schreiben auf, was Sie gelernt haben, damit der nächste SE es nicht neu erfinden muss. Lassen Sie den letzten Block weg, und das kollektive Wissen Ihres Teams setzt sich jedes Quartal zurück.

Es ist 9:47 Uhr. Vier Demos im Kalender, eine POC-Review um 14 Uhr mit dem Architekten eines Interessenten, der beim Datenmodell schon zweimal Widerspruch eingelegt hat, und Daniel (einer der AEs) hat gerade zum dritten Mal in dieser Woche per Slack geschrieben "kann es mit X integrieren?" Zum dritten Mal, weil die ersten beiden Antworten "ja, mit diesen Einschränkungen" lauteten und niemand sie aufgeschrieben hat.

Das ist der SE-Tag. Nicht die Version aus dem Recruiting-Deck. Die echte Version, in der Sie der Stoßdämpfer zwischen Vertriebsdringlichkeit und Produktrealität sind.

Wenn Sie ein angehender SE sind, ein AE, der sich fragt, was Ihr SE den ganzen Tag tut, oder ein Engineer, der über einen Wechsel nachdenkt: Dieser Leitfaden geht den Rhythmus Stunde für Stunde durch. Der Job steht und fällt mit einer Sache, über die niemand spricht: Der SE ist der Vertrauensvektor des Käufers. Sie glauben dem SE ein "Nein, das wird für Ihren Stack nicht funktionieren", das sie vom AE niemals akzeptieren würden. Diese Glaubwürdigkeit zu schützen, ist das ganze Handwerk.

Warum die SE-Rolle wichtiger ist, als das Organigramm vermuten lässt

In den meisten Organigrammen sitzt der SE unterhalb des Vertriebs und sieht aus wie ein Funktionserklärer, der an den AE angehängt ist. Diese Sichtweise verfehlt die eigentliche Aufgabe.

Der SE ist das technische Gewissen des Deals. Der technische Bewerter des Käufers (in der Regel ein Director of Engineering, ein Sicherheitsverantwortlicher, ein Head of Ops) wurde schon einmal verbrannt. Er hat eine geschliffene demo gesehen, den Vertrag unterschrieben und sechs Wochen später entdeckt, dass die Integration, die sein Stack braucht, auf einer roadmap steht, die still und leise verschoben wurde. Diese Erinnerung ist jedes Mal im Raum, wenn Sie Zoom öffnen.

Was der Käufer unter jedem "wie handhabt das X?" wirklich fragt, ist: Wird das bei uns in der Produktion funktionieren, oder bin ich gleich dabei, sechs Monate damit zu verbringen, meinem CTO zu erklären, warum ich das falsche Tool gewählt habe?

Der SE ist derjenige, der das beantwortet. Denn der SE wird sagen "ja, diese Integration wird unterstützt, aber bei Ihrem Volumen stoßen Sie an unser Rate-Limit, und so würden wir das tatsächlich lösen." Dieser Satz ist mehr wert als jede Funktion im Produkt. In dem Moment, in dem der SE nicht mehr bereit ist, ihn zu sagen, bricht das Vertrauen zusammen. Also muss der Tagesrhythmus diese Glaubwürdigkeit schützen.

Der Rhythmus, Stunde für Stunde

8:00 bis 9:30 Uhr: Demo-Vorbereitung

Die ersten 90 Minuten sind nicht für die Inbox-Sortierung da. Sie sind für die demo um 9:30 Uhr. Wenn Sie um 9:25 Uhr mit dem Kaffee in der Hand mit der Vorbereitung beginnen, greifen Sie auf den Standardablauf zurück, und der Standardablauf ist das, was Ihr Interessent bereits auf Ihrer Website gesehen hat.

Wie echte Vorbereitung aussieht:

• Lesen Sie die Discovery-Notizen des AE vollständig. Unterstreichen Sie die konkreten Worte, mit denen der Interessent den Schmerz beschrieben hat. "Die Akzeptanz bei den Reps ist brutal", "wir verlieren die Hälfte unserer Leads in 24 Stunden", "Ops kommt mit dem Reporting nicht hinterher": Diese Sätze sind das Grundgerüst der demo.
• Bauen Sie ein maßgeschneidertes 3-Folien-Intro. Folie eins: ihr Schmerz, in ihren Worten. Folie zwei: wie Sie das in ähnlichen Accounts ablaufen sahen. Folie drei: was Sie ihnen in den nächsten 20 Minuten zeigen, in der Reihenfolge ihrer Prioritäten. Keine "Über uns"-Folie. Keine Kundenwand mit 14 Logos.
• Richten Sie die Demo-Umgebung mit der Form ihrer Daten ein. Nicht ihre echten Daten, sondern die Form: ihre Teamgröße, die Namen ihrer Vertriebszyklus-Phasen, ihre Gebietsaufteilung. Wenn es ein 12-köpfiges Team in der EMEA-Region ist, sollte die demo nicht mit einer US-Organisation von 200 Reps starten.
• Laden Sie 2 bis 3 "falls sie nach X fragen"-Zweige vor. Aus den Discovery-Notizen können Sie meist die drei wichtigsten Fragen vorhersagen: eine Integration, eine Berechtigungsfrage, eine Frage zu Legacy-Systemen. Halten Sie die Antwort in einem Tab bereit, nicht als "lassen Sie mich das nachreichen".

Das Verhältnis, nach dem ich arbeite: 90 Minuten Vorbereitung für eine 30-minütige demo. Der Weg "Standard-demo anwerfen und improvisieren" schließt vielleicht in 30 bis 35 % der Fälle ab. Der discovery-geführte, vorbereitungsintensive Weg schließt in 60 bis 70 %+ ab. Die Rechnung ist nicht subtil.

9:30 bis 11:30 Uhr: Discovery plus demo

Die ersten 15 Minuten sind nicht die demo. Sie sind echte Discovery, auch wenn der AE im ersten Call bereits Discovery gemacht hat, auch wenn der Interessent "es nur sehen will".

Die Fragen klingen einfach, verdienen aber den Rest des Calls:

• "Beschreiben Sie mir, wie ein großartiges Ergebnis 90 Tage nach dem Kauf von so etwas aussieht."
• "Welche Behelfslösung nutzen Sie heute, und welcher Teil davon bricht tatsächlich zusammen?"
• "Wer nutzt das sonst noch, und was müssten die sehen?"

Dann, und erst dann, machen Sie die demo. In der Reihenfolge des Schmerzes, nicht in Menü-Reihenfolge. Wenn sie sagten, die Akzeptanz bei den Reps sei der Knackpunkt, beginnen Sie mit der mobilen Rep-Erfahrung, nicht mit Ihrer Admin-Konsole. Technische Discovery, die wirklich den Fit findet geht tiefer auf das Fragenset ein.

Eine praktische Regel: Halten Sie alle 4 bis 5 Minuten inne und fragen Sie "ist das, was Sie sehen wollten?" Lautet die Antwort "ja, aber die Frage, die mich wirklich interessiert, ist X", hat man Ihnen den Rest der demo auf dem Silbertablett serviert. Demo-Design rund um den Pain Point des Käufers, nicht Funktionstouren ist die ausführlichere Version.

11:30 bis 12:30 Uhr: Deal-Strategie-Mittagessen mit dem AE

Das ist die am meisten unterschätzte Stunde des SE-Tages und die, die am ehesten geopfert wird. Opfern Sie sie nicht.

Mittagessen mit dem AE (oder Kaffee oder ein 30-minütiges Zoom) ist Pipeline-Triage. Welche Deals sind tatsächlich real? Bei welchen erzählt sich der AE eine Geschichte? Welcher technische Einwand von letzter Woche ist ein Deal-Killer, von dem der AE hofft, er löse sich von selbst? Wer braucht jetzt einen Weg für die Sicherheitsprüfung, weil die Beschaffung ihn sonst in Woche sechs blockiert?

Ein beispielhafter Austausch:

Daniel (AE): "Acme liegt bei 180.000 $ ARR, der champion ist der VP Ops, der Deal ist solide. Brauchen nur einen POC." Ich (SE): "Was ist das Erfolgskriterium für den POC?" Daniel: "Äh... sie wollen es ausprobieren." Ich: "Das ist kein POC, das ist eine Sandbox. Wer gibt grünes Licht für den Erfolg des POC, und was genau müssen sie sehen? Wenn wir das nicht schriftlich haben, sollten wir ihn nicht aufsetzen. Wir verbrennen drei Wochen und sie tauchen ab." Daniel: "...ja, fair."

Dieses Gespräch, wöchentlich wiederholt, ist für die Deal-Geschwindigkeit mehr wert als jede Funktion, die Sie je liefern werden.

12:30 bis 14:30 Uhr: POC-Support / RFP-Antwort

Nachmittage sind meist Konzentrationsarbeit. Die harte, unglamouröse Arbeit des SE: Debugging in der Sandbox des Interessenten, das Beantworten des Sicherheitsfragebogens mit 184 Fragen, das Schreiben der Integrationsspezifikation, die der Architekt morgen prüft.

POC-Arbeit ist der Ort, an dem SE-Zeit verpufft, wenn man nicht diszipliniert ist. Vor jedem POC-Start stellt der SE fünf Fragen, und der AE darf sie nicht umgehen:

1. champion identifiziert: Wer beim Interessenten wird dafür kämpfen? Wenn niemand, kein POC.
2. Erfolgskriterien schriftlich: Was beweisen wir, in je einem Satz, mit messbaren Bedingungen?
3. Entscheidungstermin: Wann endet der POC und wann fällt die Kaufentscheidung? "Irgendwann in Q3" ist kein Termin.
4. Integrationsbeschränkungen: Welche Systeme muss das berühren, und haben wir den Zugang bestätigt?
5. Sicherheitsweg: Wurde die Sicherheit eingebunden, oder überrascht sie uns in Woche fünf?

Wenn drei von fünf fehlen, ist der POC nicht real, und ihn aufzusetzen kostet Sie 40 Stunden, die in einen Deal fließen sollten, der tatsächlich abschließt. POCs sind das Teuerste, was der SE tut. Nicht jeder Deal verdient einen.

14:30 bis 16:00 Uhr: Technischer Einwand im Detail

Heute ist der 14-Uhr-Call der Architekt des Interessenten, der angemerkt hat, dass das Datenmodell nicht zu ihrem bestehenden Warehouse passt. Er hat nicht unrecht. Die Art, wie unser Modell Events unter Accounts verschachtelt, ist nicht standardkonform.

Der falsche Zug: in die Defensive gehen. Vor seinem Team kontern. Eine roadmap-Lösung versprechen, die es nicht gibt.

Der richtige Zug: den Datenfluss mit ihm am Whiteboard durchgehen, zu seinen Bedingungen. "Sie haben recht, das ist eine andere Form als die, die Ihr Warehouse erwartet, hier ist der Grund, warum wir uns so entschieden haben, und hier sind die drei Optionen, die Teams in Ihrer Situation nutzen." Verpflichten Sie sich innerhalb von 24 Stunden schriftlich zu follow-ups. Binden Sie das Produkt ein, wenn die Lücke real ist.

Der Architekt braucht nicht, dass Sie die Diskussion gewinnen. Er muss wissen, dass Sie die Frage verstanden haben und sie ehrlich beantworten werden. Das ist der Vertrauensvektor. Technische Einwände ohne Zucken behandeln geht die Züge im Detail durch.

16:00 bis 17:30 Uhr: Beitrag zur Wissensdatenbank

Die letzten 90 Minuten sind der Teil, den fast jeder SE auslässt, und der Teil, der SEs, die ihr Team besser machen, von SEs trennt, die ein Engpass sind.

Wie diese Stunde aussieht:

• Schreiben Sie das Dokument "wie wir SAML mit Conditional Access in Azure AD handhaben". Drei SEs haben dieses Quartal dieselbe Frage bekommen. Keiner hat es aufgeschrieben. Heute tue ich es.
• Aktualisieren Sie die Demo-Umgebung. Fügen Sie das neue Dashboard hinzu, das das Produktteam letzte Woche ausgeliefert hat, damit der nächste SE keine veraltete Version vorführt.
• Schließen Sie mit dem Produkt den Kreis zu der Lücke, die ich heute Morgen bei der Vorbereitung gefunden habe. Drei Interessenten in Folge haben nach einem bestimmten Webhook-Event gefragt.

Der SE, der nur Demos liefert und nie dokumentiert, ist ein Single Point of Failure. Der SE, der schreibt, ist derjenige, dessen technische Team-Gewinnrate sich Quartal für Quartal verstärkt, weil jeder einmal beantwortete Einwand einer ist, den seine Teamkollegen in 30 Sekunden statt in 30 Minuten erledigen.

Häufige Fallstricke

Zu viel Demo ohne Discovery. Sich durch jede Funktion klicken statt durch die drei, auf die es ankommt. Die Demo-Länge wächst, die Aufmerksamkeit des Käufers schrumpft, und Sie beenden den Call, nachdem Sie alles gezeigt und nichts bewiesen haben. Streichen Sie das Menü, folgen Sie dem Schmerz.

Zum Recherche-Arm des AE werden. Wenn jedes "kann es X?" eine sofortige Slack-Antwort ohne asynchrone Dokumente bekommt, werden Sie zum Engpass bei fünf Deals gleichzeitig. Antworten Sie schriftlich, an einem Ort, den der nächste AE finden kann. Ein 10-minütiges Loom, im Team-Wiki abgelegt, erspart Ihnen dieselbe Frage 12 Mal.

Keine asynchrone Dokumentation. Jede Antwort stirbt in DMs und das Team lernt sie nächstes Quartal neu. Behandeln Sie die Wissensdatenbank als Teil des Deals.

Zu jeder individuellen POC-Anfrage ja sagen. POCs sind teuer. Nicht jeder Deal verdient einen.

Den AE die technische Erzählung steuern lassen. Der AE besitzt Preis, Dringlichkeit und den Kaufprozess. Der SE besitzt "wird das in der Produktion tatsächlich funktionieren". In dem Moment, in dem sich diese Drähte kreuzen, werden beide Rollen schwächer.

Die Vorlage für den SE-Tagesrhythmus

Nutzen Sie das als Leitplanke. Nicht jeder Tag passt, aber die Abweichungen sollten bewusst sein:

• 8:00 bis 9:30: Block für Demo-Vorbereitung (keine Inbox, kein Slack)
• 9:30 bis 11:30: demo / Discovery
• 11:30 bis 12:30: AE-Abstimmung / Pipeline-Triage
• 12:30 bis 14:30: POC / RFP / Sandbox-Arbeit
• 14:30 bis 16:00: Technischer Einwand oder Architekten-Call
• 16:00 bis 17:30: Wissensbeitrag plus Pflege der Demo-Umgebung

Der Block, der immer zuerst geopfert wird, ist der letzte. Schützen Sie ihn.

Checkliste für die Demo-Vorbereitung

Nutzen Sie diese vor jeder demo:

• Die Discovery-Notizen des AE vollständig gelesen und die exakte Schmerz-Sprache des Interessenten herausgezogen
• Ein maßgeschneidertes 3-Folien-Intro gebaut (ihr Schmerz, das Muster, das Sie gesehen haben, was Sie zeigen werden)
• Demo-Ablauf nach ihren Prioritäten geordnet, nicht nach dem Produktmenü
• Demo-Umgebung passt zu ihrer Teamgröße, ihrem Vertriebszyklus, ihrer Gebietsform
• 3 erwartete Einwände mit vorbereiteten Antworten und vorgeladenen Tabs
• Eine "was würde das für Ihr Team zu einem Ja machen?"-Frage bereit für den Abschluss
• Bestätigt, wer von ihrer Seite im Call ist und was jeder Rolle wichtig ist
• Notfallplan, falls die Live-Umgebung Probleme macht

Erfolg messen

Die Kennzahlen, auf die es für einen SE tatsächlich ankommt:

• Deal-Einfluss: % der Closed-Won-Deals, bei denen der SE im Deal-Team war. Liegt er im Mid-Market unter 50 %, wird die SE-Funktion nicht dort eingesetzt, wo sie sollte.
• Technische Gewinnrate: % der POCs, die zu Closed-Won werden. Das klarste Signal dafür, ob der SE POCs qualifiziert und sie gut führt.
• POC-Erfolgsquote: % der POCs, die ihre genannten Erfolgskriterien erreichen. Ein POC kann gelingen und trotzdem nicht abschließen, aber ein POC, der seine eigenen Kriterien verfehlt, schließt fast nie ab.
• Time-to-first-Value in der demo: Bestklasse ist unter 8 Minuten von "lass uns anfangen" bis "oh, genau das brauche ich."
• Wissensbeitrag: pro Quartal hinzugefügte Dokumente und Einwand-Behandlungen. Der nachlaufende Indikator, der gute SEs von Team-Multiplikator-SEs trennt.

Die SE-Kennzahlen, auf die es tatsächlich ankommt schlüsselt jede davon mit Zielwerten je Unternehmensphase auf.

Wie Rework den SE-Tag unterstützt

Der SE-Tag erstreckt sich über drei Oberflächen (die Pipeline-Ansicht des AE, die POC-Umgebung, die Wissensdatenbank des Teams), und die meisten SEs landen in drei verschiedenen Tools, die nicht miteinander reden. Rework CRM gibt dem AE und dem SE eine Pipeline-Ansicht mit Feldern für den technischen Fit, POC-Phasen-Gates und pro Opportunity erfasstem SE-Einsatz. Rework Work Ops kümmert sich um die eigene Arbeit des SE: POC-Aufgaben mit Verantwortlichen und Terminen, die Wissensdatenbank, in der Einwand-Behandlungen tatsächlich abgelegt werden, und das Änderungsprotokoll der Demo-Umgebung. CRM beginnt bei 12 $/Nutzer/Monat, Work Ops bei 6 $/Nutzer/Monat, und sie teilen sich Daten, statt um sie zu kämpfen. Die vollständige SE-Rollenbeschreibung steht in der Sales-Engineer-Stellenbeschreibung (begleitende JD).

Was als Nächstes kommt

Der Tag im Leben ergibt erst Sinn, wenn Sie in die vier Teilhandwerke eingetaucht sind: Discovery, die den Fit findet, Demo-Design, das dem Pain Point des Käufers folgt, technische Einwandbehandlung, die das Vertrauen intakt hält, und die Kennzahlen, die Ihnen sagen, ob irgendetwas davon funktioniert. Jedes ist ein eigenes Playbook in dieser Sammlung.

Der Job ist ehrliche Arbeit. Sie werden nicht die lauteste Person im Call sein. Sie werden die vertrauenswürdigste sein. Sobald Sie es in einem Deal haben einrasten spüren (der Moment, in dem ein skeptischer Architekt sich zurücklehnt und sagt "okay, ich glaube, das wird für uns funktionieren"), werden Sie wissen, warum es die Rolle gibt.