Sales Engineer
Stellenausschreibung, Gehalt, Sourcing, 15 Interviewfragen und 30/60/90-Plan, um eine:n Sales Engineer im B2B-SaaS-KMU in Deutschland einzustellen.
Zusammengestellt vom Join-Team auf Basis öffentlicher Daten und unserer Recruiting-Erfahrung.
Aktualisiert
Auf einen Blick
- Mediangehalt 70.000 € 58.000 € – 88.000 €
- Einstellungsdauer 50–80 Tage
- Erfahrung 4–8 Jahre
So stellen Sie eine:n Sales Engineer für Ihr KMU ein
Bevor Sie die Stellenausschreibung schreiben, klären Sie drei Fragen. Sie entscheiden, ob die Neueinstellung der richtige Hebel ist und welches Profil Sie wirklich brauchen.
Frage 1: Brauchen Sie eine:n Sales Engineer oder eine:n weitere:n Account Executive? Die:der Sales Engineer ist eine technische Verstärkungs-Rolle, kein Closer mit eigenem Quota. Sie:er unterstützt 2-5 AEs mit Demos, Proof-of-Concept-Begleitung und Architektur-Diskussionen. Eine grobe Faustregel: ab 3-4 Account Executives mit komplexen technischen Deals (B2B-SaaS mit API, Sicherheit, Compliance-Anforderungen) zahlt sich eine:n Sales Engineer aus; darunter ist es meist sinnvoller, eine:n weitere:n AE mit technischer Affinität einzustellen. Wenn Ihre AEs die Demos heute selbst halten und nur bei tiefer Architektur-Diskussion straucheln, ist eine:n Sales Engineer der richtige Hebel.
Frage 2: Wie tief muss die technische Tiefe wirklich sein? Eine:e Sales Engineer für ein API-getriebenes B2B-SaaS-Produkt (Workflow-Automatisierung, Datenintegration, Developer-Tooling) braucht Engineering- oder Implementierungs-Erfahrung mit konkretem Code-Kontakt. Eine:e Sales Engineer für ein klassisches Mittelstand-Produkt (ERP-Modul, Industrie-Steuerung, branchenspezifische Lösung) braucht eher Beratungs- und Prozessverständnis-Tiefe als reinen Code. Das ideale Profil und die erwartete Vergütung unterscheiden sich stark. Schreiben Sie den Tiefen-Level explizit in die Anzeige; sonst attrahieren Sie Solutions Architects aus Hyperscale-SaaS, die im Mittelstand die Geduld für lange Discovery-Zyklen nicht aufbringen.
Frage 3: Welchen Anteil POC-Begleitung erwarten Sie? Im DACH-B2B-Mittelstand entscheidet der Proof-of-Concept oft den Deal: 3-4 Wochen mit konkreten Erfolgskriterien, Stakeholder-Mapping und sauberer Übergabe an Customer Success. Ein:e gute:r Sales Engineer im KMU verbringt 30-50 % der Zeit mit POCs (nicht mit Demos). Wenn Ihre Vertriebsmotorik fast keine POCs kennt (transaktionale Verkäufe, Standard-Software ohne Customizing), brauchen Sie eher eine:n erweiterte:n AE mit Demo-Tiefe als eine:n echte:n Sales Engineer. Klären Sie das Verhältnis Demos vs. POCs in der Anzeige.
Wenn die drei Antworten auf eine:n Sales Engineer in Vollzeit zulaufen (und nicht auf eine:n weitere:n AE oder eine:n Solutions Architect), nutzen Sie die Vorlage unten.
Stellenausschreibung (Vorlage)
Sales Engineer (m/w/d) im B2B-SaaS-Vertrieb
Mission. Technische Verstärkung von [X] Account Executives in einem B2B-SaaS-Vertriebsteam: maßgeschneiderte Demos, Proof-of-Concept-Begleitung, Architektur-Diskussionen, Compliance- und Security-Antworten. Sie berichten an die:den [Head of Sales / Head of Pre-Sales / CTO].
Hauptverantwortlichkeiten.
- Vorbereitung und Durchführung maßgeschneiderter Discovery-Demos in einem durchschnittlichen Zyklus von [X] Tagen und einem Auftragswert von [Y] k€.
- Begleitung von Proof-of-Concept-Phasen über 3-4 Wochen mit klar definierten Erfolgskriterien, in Abstimmung mit Engineering, Produkt und Customer Success.
- Beantwortung technischer Fragen in Vorstands- und Architektur-Terminen (API, Integration, Skalierbarkeit, Sicherheit, DSGVO, ISO-27001).
- Strukturierte Übergabe der technischen Anforderungen an Customer Success nach dem Closing.
- Wöchentliche Pipeline-Reviews mit den [2-5] zugewiesenen Account Executives; strukturiertes Feedback zur technischen Qualifizierung.
- Strukturierte Übergabe priorisierter Feature-Requests an Produkt mit dokumentierter Business-Begründung.
Profil.
- Erforderlich: 4 bis 8 Jahre Berufserfahrung, davon mindestens 2 Jahre in Pre-Sales, Solutions Engineering, technischer Beratung oder einer vergleichbaren technisch-kommerziellen Rolle; nachgewiesene POC-Verantwortung; sicherer Umgang mit API-Konzepten (REST, Webhooks), Authentifizierung (SSO, SAML), Datenbank-Grundlagen.
- Gewünscht: Erfahrung mit B2B-SaaS oder komplexen Produkten in [Branche]; Vertrautheit mit deutschen Compliance-Patterns (DSGVO, ISO-27001, branchenspezifische Anforderungen); Skript-Niveau in Python, JavaScript oder SQL.
- Disqualifizierend: rein vertriebliche Vorerfahrung ohne nachweisbare technische Tiefe, oder rein technische Vorerfahrung ohne Vertriebs-Exposition (etwa Solutions Architect ohne Pre-Sales-Praxis).
Was wir bieten.
- Bruttojahresvergütung: Fix [58-88] k€ + Variabel [10-20] k€ bei OTE (80/20-Modell, gekoppelt an Team-Quotas oder AE-Performance). Details des Variablenplans werden im Interview kommuniziert.
- Modell: [Vollzeit, hybrid 2-3 Tage / Woche vor Ort, Basis in [Stadt]].
- Benefits: [Betriebliche Altersvorsorge, Fahrrad-Leasing, Mitarbeiteraktien, Urlaub, Homeoffice-Policy, Weiterbildungsbudget, Hardware-Budget].
- Stack: [CRM, Demo-Umgebung, POC-Tooling, Pipeline-Intelligence, Security-Dokumentation, Compliance-Plattform].
Gehaltsband
Festgehalt, brutto pro Jahr
Variabel bei OTE 15.000 € – 22.000 € 80/20 typisch in DE; Variable häufig an AE-Quota gekoppelt
Bruttofixgehalt pro Jahr für eine:n Sales Engineer auf Mid-Level (4 bis 8 Jahre, davon mindestens 2 in Pre-Sales oder technischer Beratung) im deutschen B2B-SaaS-KMU. SaaS-Scale-up-Profile in Berlin oder München tendieren zur Obergrenze (80-95 k€ Fix); klassische Mittelstand-Sales-Engineering-Profile (Industriesoftware, ERP, Cybersecurity) liegen oft zwischen 58-75 k€. Der variable Anteil (typisch 80/20 statt 70/30 wie bei reinen Account Executives) wird oft an Account-Executive-Quotas oder an gemeinsame Team-Ziele gekoppelt. Hinweis: der Titel Sales Engineer ist im DACH-Raum etabliert, viele Mittelstands-Unternehmen schreiben dieselbe Rolle als Pre-Sales Consultant, Solutions Engineer oder Technischer Vertrieb aus.
Quellen: Stepstone Gehaltsdaten Sales Engineer Deutschland 2026 ; Stepstone Gehaltsreport 2026 ; Destatis Verdiensterhebung (April 2025), Berufsgruppe 61 Einkaufs-, Vertriebs- und Handelsberufe ; kununu Gehaltscheck Sales Engineer 2025
Wo Sie diese Rolle finden
-
LinkedIn
Recruiter Lite ab 170 € / Monat, plus 200-400 € / Monat für Job SlotsFür Sales Engineer in deutschen SaaS- und Tech-KMUs der wichtigste Kanal. Aktives Sourcing über Recruiter Lite plus personalisierte InMails ist deutlich wirksamer als reine Job Posts: gute Sales-Engineering-Profile sind selten aktiv auf Jobsuche. Filtern Sie auf Vorerfahrung im passenden technischen Bereich (API-getriebene SaaS vs. On-Premise-Enterprise vs. Embedded-Hardware), bevor Sie anschreiben. Erwarten Sie 50-70 % der qualifizierten Bewerbungen von hier, wenn aktiv gesourct wird.
-
XING
ProJobs ab 195 € / MonatIm klassischen Mittelstand und in technischen B2B-Branchen außerhalb der Berliner Startup-Szene weiterhin stark, besonders für Sales Engineers in Maschinenbau, Industrie-Automatisierung, ERP, Cybersecurity, Logistik-Software. In NRW, Bayern und Baden-Württemberg auf Augenhöhe mit LinkedIn oder besser. Für SaaS-native Sales-Engineering-Profile unter 35 Jahren tendenziell schwächer als LinkedIn.
-
Stepstone
Ab 995 € / 30 TageGrößter klassischer Stellenmarkt mit breitem Bewerber-Pool. Für Sales Engineer ergibt sich gutes Volumen, besonders aus Industrie und Mittelstand, mit vielen Profilen, die aus Engineering oder Service in die Pre-Sales-Rolle wechseln. Etwas weniger Signal als LinkedIn oder XING bei Senior-Profilen aus reinem B2B-SaaS, aber sinnvoll, wenn Sie überregional und ohne starkes Tech-Branding suchen. Erwarten Sie höheres Filtering im ersten Screening.
Evaluations-Playbook
Die Rolle der:des Sales Engineer zeigt sich über fünf Evaluations-Stufen. Die Live-Demo-Übung in Stufe 4 ist die prädiktivste; sie zeigt, ob die:der Kandidat:in technische Tiefe mit Discovery-Disziplin und Erzählkunst verbindet. Validierung erfolgt durch Kumulation der Signale, nicht durch eine einzelne Stufe.
-
Stufe 1: CV-Lektüre
Suchen Sie nach Konsistenz zwischen technischem Hintergrund und Vertriebs-Exposition: ein:e gute:r Sales Engineer hat entweder eine Engineering- oder Beratungs-Vorgeschichte plus 2-4 Jahre dokumentierte Pre-Sales-Praxis, oder 5+ Jahre AE-Praxis mit klarem technischem Schwerpunkt (Demo-Verantwortung, RFP-Bearbeitung, Proof-of-Concept-Begleitung). Mindestverweildauer 18 Monate pro Position; mehrere 12-Monats-Stationen sind ein Signal für Branchen- oder Stack-Mismatch. Die Tiefe der Demo- und Proof-of-Concept-Verantwortung zählt mehr als die Anzahl unterstützter Deals.
-
Stufe 2: Phone Screen (30 Min.)
Nur drei Fragen: (1) Beschreiben Sie den letzten technischen Deal, bei dem Ihre Demo oder Ihr POC ausschlaggebend war, (2) Welche technische Frage einer:eines Prospects haben Sie zuletzt nicht beantworten können, und wie sind Sie damit umgegangen?, (3) Warum jetzt ein Wechsel? Ergebnis: Go/No-Go in 5 Min. Debrief. Vermeiden Sie tiefe technische Gotcha-Fragen auf dieser Stufe.
-
Stufe 3: Strukturiertes Interview (90 Min.)
Folgen Sie den 15 Fragen unten, abwechselnd behavioral, situational, case, technical und values. Achten Sie besonders auf das Gleichgewicht zwischen technischer Präzision und Discovery-Disziplin: eine:r starke:r Sales Engineer kann eine komplexe Architektur erklären, ohne in einen Produkt-Monolog zu kippen. Mindestens 2 Interviewer:innen (eine:r aus Sales, eine:r aus Engineering), unabhängiges Scoring vor dem Debrief.
-
Stufe 4: Live-Demo und Proof-of-Concept-Übung (90 Min.)
Geben Sie der:dem Kandidat:in eine Woche vor dem Termin ein Briefing eines fiktiven Prospects (Branche, Use-Case, 3-4 technische Anforderungen, ein versteckter Showstopper). Im Termin: 15 Min. Live-Discovery mit einer:einem Teammitglied in der Prospect-Rolle, dann 30 Min. produktbezogene Demo (Ihr eigenes Produkt oder ein nahes Open-Source-Äquivalent), dann 30 Min. Q&A zur Architektur und zur POC-Strategie, dann 15 Min. Debrief. Das ist die prädiktivste Stufe: die Qualität der Discovery-Fragen vor der Demo-Vertiefung und der Umgang mit dem versteckten Showstopper bestimmen die spätere Win-Rate-Wirkung.
-
Stufe 5: Referenzen (strukturierte Überprüfung)
Rufen Sie zwei Referenzen an: eine:n ehemalige:n Account Executive, mit der:dem die:der Kandidat:in zusammengearbeitet hat, und eine:n ehemalige:n Engineering- oder Produkt-Kolleg:in. Stellen Sie beiden dieselben vier Fragen: Worin ist sie:er am stärksten? Worin würden Sie eine ergänzende Person einstellen? Würden Sie sie:ihn morgen wieder als Pre-Sales-Partner:in haben wollen, warum oder warum nicht? Ein konkretes Beispiel eines technischen Deals, in dem die:der Kandidat:in den Unterschied gemacht hat? Die vierte Frage liefert das meiste Signal.
Strukturierte Interviewfragen
-
Verhaltensbezogen Diagnose und Lernfähigkeit Beschreiben Sie den letzten technischen Deal, den Sie verloren haben, obwohl Ihr Produkt technisch geeignet war. Was ist passiert?
Worauf eine starke Antwort hinweistFähigkeit, einen verlorenen Deal über die rein technische Frage hinaus zu diagnostizieren: Stakeholder-Misalignment, fehlender wirtschaftlicher Sponsor, schlechtes Timing, Procurement-Blockade. Bonus: die:der Kandidat:in identifiziert ein Frühsignal, das sie:er heute anders aufnehmen würde (etwa Ich habe in der Discovery zu wenig zu den Build-vs-Buy-Diskussionen gefragt). Kandidat:innen, die alles auf Preis oder Konkurrenz-Feature schieben, zeigen schwache Discovery-Reife.
-
Verhaltensbezogen POC- und Demo-Strategie Erzählen Sie mir vom komplexesten technischen Proof-of-Concept, den Sie begleitet haben. Was war der Scope, wer war beteiligt, was war die größte Schwierigkeit?
Worauf eine starke Antwort hinweistFähigkeit, einen POC zu strukturieren: klare Erfolgskriterien vor dem Start, Zeitfenster begrenzt (typisch 2-4 Wochen, nicht 3 Monate), Stakeholder-Mapping (technischer Sponsor, wirtschaftlicher Sponsor, Anwender:innen). Konkrete Angaben zu Dauer und Etappen. Kandidat:innen, die einen POC ohne Erfolgskriterien beschreiben, haben in Wirklichkeit eine erweiterte Demo geführt, keinen echten POC.
-
Verhaltensbezogen Technische Qualifizierung Beschreiben Sie eine Situation, in der Sie eine:m Account Executive sagen mussten, dass ein Deal technisch nicht qualifiziert ist. Warum, und wie haben Sie das kommuniziert?
Worauf eine starke Antwort hinweistReife in der Sales-Engineering-AE-Partnerschaft: Fähigkeit, einen Deal zu disqualifizieren oder zu re-scopen, ohne die Beziehung zur:zum AE zu beschädigen. Konkretes Beispiel mit Auftragswert, Begründung und Reaktion der:des AE. Kandidat:innen, die nie disqualifiziert haben, sind entweder zu defensiv (nicht trauen, gegenzuhalten) oder hatten keine Verantwortung für die technische Qualifizierung.
-
Situativ Pragmatismus und Ehrlichkeit Ein:e Account Executive bittet Sie 24 Stunden vor einer Vorstands-Demo um eine Spezial-Anpassung, die das Produkt eigentlich nicht abdeckt. Wie reagieren Sie?
Worauf eine starke Antwort hinweistSauberes Abwägen: Diagnose des wahren Bedarfs (ist die Anpassung wirklich nötig oder will die:der AE den Deal nur retten?), Optionen anbieten (Workaround in der Demo, expliziter Hinweis im Vorstands-Termin, ehrlicher Zeitplan zur künftigen Lieferung), Beteiligung von Engineering oder Produkt, wenn nötig. Antworten der Marke ich baue das schnell zusammen oder ich blocke die Demo sind beide rote Flaggen.
-
Situativ Glaubwürdigkeit Während einer Live-Demo stellt die:der technische Sponsor:in eine Frage, deren Antwort Sie nicht kennen. Wie gehen Sie damit um?
Worauf eine starke Antwort hinweistSouveränität im Nicht-Wissen: explizite Anerkennung (Das ist eine gute Frage, da bin ich nicht sicher, ich kläre das bis morgen und melde mich), konkrete Nachverfolgung mit Termin, kein Bluffen. Bonus: die:der Kandidat:in nennt einen realen Fall, in dem dieser ehrliche Umgang Vertrauen geschaffen hat. Kandidat:innen, die antworten ich erfinde nie etwas, ohne ein konkretes Beispiel zu nennen, sind vorsichtig zu gewichten.
-
Situativ POC- und Demo-Strategie Sie haben drei parallele POCs in unterschiedlichen Phasen. POC A (3 Wochen alt, Erfolgskriterien klar, technischer Sponsor engagiert), POC B (5 Wochen alt, Erfolgskriterien diffus, wechselnder Sponsor), POC C (1 Woche alt, klar, sehr engagiertes Team). Wie priorisieren Sie?
Worauf eine starke Antwort hinweistPriorisierung nach Wahrscheinlichkeit und Aufwand, nicht nach Alter: POC A und C sollten Priorität haben (klare Kriterien, engagierte Stakeholder); POC B braucht Klärung oder Cut. Antworten der Marke ich arbeite an dem POC, der am ältesten ist sind ein Bias zu Sunk Cost; Antworten der Marke ich arbeite parallel an allen drei zeigen mangelnde Priorisierung.
-
Case Cross-funktionale Zusammenarbeit Ein Prospect fordert eine native Integration mit einem System, das wir aktuell nur über CSV-Import unterstützen. Roadmap-Plan dafür: 9 Monate. Der Deal hat einen Auftragswert von 120 k€ pro Jahr. Wie gehen Sie vor?
Worauf eine starke Antwort hinweistStrukturiertes Vorgehen: (1) Klärung des wahren Bedarfs (Echtzeit-Sync oder Tages-Sync?, welches konkrete Volumen?), (2) Workaround-Optionen prüfen (CSV-Import mit Automatisierung, Drittanbieter-Integrationen wie Zapier oder Workato, kundenspezifische Lösung), (3) Eskalation an Produkt zur Roadmap-Prüfung mit klarer Business-Begründung, (4) ehrliche Kommunikation der Zeitleiste an die:den Prospect. Kandidat:innen, die einfach eine Roadmap-Zusage in 3 Monaten machen, ohne mit Produkt zu sprechen, sind eine rote Flagge.
-
Case Demo-Erzählung Bereiten Sie eine 10-minütige Discovery-Demo unseres Produkts (oder eines vergleichbaren Tools) für einen fiktiven Prospect vor: ein Logistik-KMU mit 80 Mitarbeitenden, das aktuell Excel und einen Eigenbau zur Auftragsverfolgung nutzt. Wie strukturieren Sie?
Worauf eine starke Antwort hinweistDemo als Erzählung, nicht als Feature-Tour: Einstieg über den Schmerz des Prospects (Excel-Chaos, fehlende Sichtbarkeit, manuelle Übergaben), dann gezielte Features, die genau diesen Schmerz lösen, mit konkreten Vorher-Nachher-Szenarien. Nicht mehr als 3-4 Features in 10 Min. Bonus: die:der Kandidat:in stellt vor Beginn 2-3 Klärungsfragen (welche:r konkrete:r Anwender:in im Termin, welcher Schmerz hat den Termin ausgelöst, welche Konkurrenz-Tools sind im Spiel).
-
Case Glaubwürdigkeit Architektur: ein Prospect fragt, wie unser Produkt mit 500 gleichzeitigen Nutzer:innen und 2 Millionen Datensätzen pro Tag umgeht. Sie kennen die genauen Zahlen unseres aktuellen Setups nicht im Kopf. Wie antworten Sie?
Worauf eine starke Antwort hinweistMethodisches Vorgehen: (1) klärende Rückfragen (handelt es sich um Lese- oder Schreiblast, welche Latenz-Anforderungen, welcher zeitliche Verlauf), (2) ehrliche Aussage zu dem, was Sie wissen vs. nicht wissen, (3) Bezug auf bekannte Referenzkund:innen oder veröffentlichte Benchmarks, (4) Vorschlag eines Performance-POCs mit dem realen Datenprofil. Antworten der Marke ja, das schafft das System locker ohne Datenbasis sind eine rote Flagge; Antworten der Marke ich weiß es nicht, frage Engineering und melde mich bis morgen sind reif.
-
Fachlich Technische Tiefe Erklären Sie mir, wie eine REST-API technisch von einer GraphQL-API unterscheidet. Wann würden Sie einer:m Prospect das eine, wann das andere empfehlen?
Worauf eine starke Antwort hinweistSicheres technisches Vokabular: REST als ressourcenorientiert mit festen Endpoints und HTTP-Verben, GraphQL als abfragebasiert mit einem Endpoint und flexibler Datenrückgabe. Anwendungsfälle: REST für einfache Server-zu-Server-Integrationen, GraphQL für komplexe Frontends mit variablen Anforderungen. Kandidat:innen, die nicht über buzzword-Niveau hinauskommen (REST ist alt, GraphQL ist modern), haben ein Glaubwürdigkeitsdefizit gegenüber technischen Prospects.
-
Fachlich Compliance- und Security-Tiefe Ein Prospect aus dem Gesundheitswesen fragt, wie Ihr Produkt mit DSGVO und einer geplanten ISO-27001-Zertifizierung umgeht. Welche Fragen stellen Sie zurück, und wie strukturieren Sie die Antwort?
Worauf eine starke Antwort hinweistVertrautheit mit Compliance-Vokabular ohne Anwaltston: Datenresidenz (EU oder nicht), Auftragsverarbeitungsvertrag, Subunternehmer-Listen, technische Maßnahmen (Verschlüsselung in Ruhe und in Bewegung, Audit-Logs), organisatorische Maßnahmen (Berechtigungskonzept, Schulungen), Zertifizierungsstatus. Bonus: die:der Kandidat:in benennt klar, was sie:er nicht beantworten kann, und verweist auf die Security- oder Legal-Ansprechperson. Wer ohne nachzufragen ja, sind wir komplett konform sagt, ist eine rote Flagge.
-
Fachlich Lerntempo Sie sollen ein neues Produktmodul lernen, das Engineering gerade ausliefert. Wie gehen Sie methodisch vor, um in 2 Wochen demo-fähig zu sein?
Worauf eine starke Antwort hinweistStrukturierte Lernmethode: (1) Roadmap und Release-Notes lesen, (2) Hands-on-Setup in einer Testumgebung, (3) zwei bis drei konkrete Anwender-Szenarien durchspielen, (4) Klärungssession mit Produkt-Owner oder Lead-Engineer, (5) Dry-Run der Demo mit einer:einem AE oder Kolleg:in vor dem ersten Kunden-Termin. Kandidat:innen, die nur die Dokumentation lesen, ohne hands-on zu üben, sind oft zu theoretisch in Demos.
-
Werte Coachbarkeit Wie nehmen Sie Feedback einer:eines Account Executive auf, wenn sie:er sagt, Ihre Demo war zu technisch und hat den Deal gefährdet?
Worauf eine starke Antwort hinweistOffenheit: Fähigkeit, das Feedback vom persönlichen Urteil zu trennen. Bonus: die:der Kandidat:in nennt ein konkretes Beispiel einer Verhaltensänderung nach unangenehmem AE-Feedback (etwa Discovery-First-Disziplin nach einer überladenen Demo). Kandidat:innen, die in der Antwort beschreiben, dem:der AE die technische Notwendigkeit erklärt zu haben statt zuzuhören, sind vorsichtig zu gewichten.
-
Werte Teamspiel Wie arbeiten Sie mit Engineering und Produkt zusammen, wenn ein:e Prospect ein Feature anfordert, das nicht auf der Roadmap steht?
Worauf eine starke Antwort hinweistPartnerschaftliche Haltung: strukturierte Übergabe an Produkt mit Business-Begründung (Auftragswert, Branche, Wettbewerbskontext), keine Aktivitäten hinter dem Rücken von Engineering, klare Erwartungssteuerung gegenüber dem:der Prospect. Kandidat:innen, die Engineering als Bremse oder Produkt als langsam beschreiben, zeigen eine Teamspiel-Schwäche, die in DACH-KMU-Strukturen schnell zu Reibung führt.
-
Werte Technische Integrität Beschreiben Sie eine Entscheidung, in der Sie die langfristige technische Gesundheit eines Accounts höher gewichtet haben als ein kurzfristiges Closing.
Worauf eine starke Antwort hinweistVertriebsreife mit technischem Gewissen: Fähigkeit, einen Scope-Downgrade oder ein verschobenes Closing zu empfehlen, wenn die technische Eignung nicht passt. Konkret: die:der Kandidat:in nennt Auftragswert, Account und Langzeit-Wirkung (etwa weniger Churn im Folgejahr, kein technischer Eskalations-Fall, sauberer Upsell-Pfad). Kandidat:innen, die nie gegen ein kurzfristiges Closing entschieden haben, zeigen einen transaktionalen Bias.
Woran Sie eine:n exzellente:n Sales Manager:in erkennen
| Kompetenz | Unter Anforderung | Auf Niveau | Über Anforderung |
|---|---|---|---|
| Technische Tiefe | Bleibt in der Demo auf Buzzword-Niveau (modern, skalierbar, sicher) ohne präzise Mechanismen. Stolpert bei Architektur- oder API-Fragen, sucht Lösungen durch Versuch und Irrtum ohne klares mentales Modell. | Beherrscht den aktuellen Stack und das eigene Produkt eigenständig. Kann eine neue Produktfeature in 1-2 Wochen demo-fähig lernen. Versteht die Fundamente gut genug, um bei Bedarf in Architektur-Diskussionen einzusteigen. | Referenzperson im Team für technische Tiefe; kann mit Engineering, Architektur-Teams der:des Kund:in und Produkt auf Augenhöhe diskutieren. Antizipiert klassische technische Einwände (Performance, Sicherheit, Integration) und hat dokumentierte Standardantworten. |
| Discovery und Demo-Erzählung | Startet die Demo ohne Klärungsfragen, geht durch die Feature-Liste in Reihenfolge. Demo dauert 45 Min., dabei 80 % der Zeit Monolog. Keine konkreten Vorher-Nachher-Szenarien. | Stellt 5-8 Discovery-Fragen vor der Demo, passt die Reihenfolge der gezeigten Features an die genannten Schmerzpunkte an. Demo dauert 20-30 Min., lässt die:den Prospect 30-40 % der Zeit sprechen. | Führt die Discovery wie eine Untersuchung: 10-15 strukturierte Fragen, identifiziert 2-3 Stakeholder mit unterschiedlichen Prioritäten. Demo wird zur Erzählung: 3-4 Features in einer logischen Reihenfolge, jede an einen konkreten Schmerz der:des Prospects gekoppelt, mit aktivem Pausieren für Fragen. |
| POC- und Demo-Strategie | POC startet ohne klare Erfolgskriterien, zieht sich über 8-12 Wochen, mit wechselnden Stakeholdern. Verlängert POCs aus Hoffnung statt aus Disziplin. Demo-Setup ist generisch und nicht prospekt-spezifisch. | Definiert Erfolgskriterien vor dem POC-Start (typisch 3-5 messbare Punkte), hält das Zeitfenster auf 3-4 Wochen, eskaliert bei diffusen Sponsorinnen. Demo-Setup wird vor jeder Demo angepasst (Branche, Use-Case, Stakeholder). | Pilotiert das POC-Portfolio wie ein eigenes Pipeline-Modell: kennt eigene Win-Rate pro POC-Phase, disqualifiziert souverän bei diffusen Kriterien, dokumentiert POC-Templates pro Branchen-Use-Case. Demo-Setups sind hochgradig prospekt-spezifisch und versionsgesteuert. |
| Glaubwürdigkeit und Ehrlichkeit | Antwortet auf technische Unbekannte mit Bluff oder generischer Beruhigung. Versucht, jede Frage in Echtzeit zu beantworten, auch wenn die Information nicht verfügbar ist. | Sagt klar, wenn sie:er etwas nicht weiß; klärt mit Engineering oder Produkt und meldet sich nach. Trennt klar zwischen Was wir heute können und Was wir planen. | Wird im Team und bei Kund:innen für radikale Ehrlichkeit zitiert. Bringt aktiv Showstopper ein, bevor die:der Prospect sie findet (Wir sind heute schwächer in X, wenn das ein Muss ist, sollten Sie das wissen). Diese Haltung wird zur Win-Rate-Wirkung im Lower-Funnel. |
| Cross-funktionale Zusammenarbeit | Eskaliert Feature-Requests ohne Business-Begründung an Produkt, beschwert sich öffentlich über Engineering-Velocity, übergibt POC-Ergebnisse nicht sauber an Customer Success. | Strukturiert Feature-Requests mit Business-Daten an Produkt, hält saubere Übergaben an Engineering bei Eskalationen, dokumentiert POC-Ergebnisse für Customer Success. | Wird in Engineering und Produkt als verlässlicher Partner zitiert; bringt strukturierte Markt-Signale, ohne als reine Sales-Stimme zu lobbyieren. Ist die Brücke zwischen Sales und Engineering und reduziert Reibung in beide Richtungen. |
| Coachbarkeit und AE-Partnerschaft | Hört AE-Feedback und kehrt zum gleichen Verhalten zurück. Arbeitet im Silo, sieht AEs als Verteiler der eigenen Demos. Verteidigt jede technische Entscheidung gegenüber AEs als Engineering-Realität. | Integriert AE-Feedback innerhalb weniger Wochen. Hält wöchentliche Pipeline-Reviews mit den 2-4 zugewiesenen AEs, dokumentiert gemeinsame Erkenntnisse aus verlorenen Deals. | Fordert AE-Feedback aktiv ein (beobachtete Demos, debriefte Deals), strukturiert die AE-Partnerschaft als dokumentiertes Ritual (Discovery-Briefing vor Demo, Debrief nach Demo, Pipeline-Review wöchentlich). Wirkt als technischer Coach für Junior-AEs. |
30/60/90-Tage-Plan
Bis Tag 30
- Vollständiges Produkt-Onboarding und interne Demo-Zertifizierung bestanden; eigenständige Standard-Demo möglich
- Shadowing von 5-8 Calls (Discovery, Demo, POC-Kickoff, technische Vertiefung) mit verschiedenen AEs
- Kartierung der 2-4 zugewiesenen Account Executives mit dokumentierten Erwartungen pro AE-Partnerschaft
- Erste 2-3 eigenständige Discovery-Calls und 1-2 Standard-Demos geführt, mit Post-Call-Begleitung durch die:den Manager:in
Bis Tag 60
- Erste eigenständige Custom-Demo für eine:n Mid-Market-Prospect, ohne Begleitung der:des Manager:in
- Erster eigenständig betreuter POC mit dokumentierten Erfolgskriterien und sauberer Übergabe an Customer Success
- Wöchentliches Pipeline-Review mit den zugewiesenen AEs gehalten, erste strukturierte technische Qualifizierungs-Disqualifikation dokumentiert
- Erste Feature-Request-Übergabe an Produkt mit strukturierter Business-Begründung
Bis Tag 90
- Mindestens 2 vollständige POCs erfolgreich begleitet (Start, Erfolgskriterien, Closing) mit dokumentierter Win-Rate-Wirkung
- Stabile operative Kadenz: Discovery-Briefings vor Demos, Demo-Debriefs, wöchentliche AE-Reviews konsequent gehalten
- Erste informelle Coaching-Beziehung mit einer:einem Junior-AE oder neuer:m Kolleg:in im Team
- Formales Review mit der:dem Manager:in: Ramp validiert, Verbesserungsplan auf 1-2 Achsen für das nächste Quartal
Häufige Fehler bei der Besetzung dieser Rolle
-
Sales Engineer und Account Executive in einer Anzeige vermischen
Beide Rollen brauchen Vertriebsexposition, aber die:der Sales Engineer trägt kein eigenes individuelles Quota; sie:er unterstützt 2-5 Account Executives mit technischer Tiefe, POC-Begleitung und maßgeschneiderten Demos. Beide Profile in einer Anzeige zu vermischen führt zu zwei klassischen Ergebnissen: entweder zahlen Sie ein AE-Gehalt für eine:n Sales Engineer, die:der dann nicht genug Closing-Verantwortung sieht und nach 9 Monaten geht, oder Sie stellen eine:n AE als Sales Engineer ein und merken in Monat 3, dass ihr:ihm die technische Tiefe für Architektur-Diskussionen fehlt. Beschreiben Sie die Quota-Struktur und den erwarteten technischen Tiefen-Level explizit.
-
Auf rein technische Tiefe ohne Discovery-Reife einstellen
Ein:e Solutions Architect aus einem Konzern hat oft beeindruckende technische Tiefe, aber wenig Übung im Discovery-First-Ansatz. In Mittelstands-Deals führt das zu Architektur-Vorträgen statt zu Schmerzpunkt-bezogenen Demos und senkt die Win-Rate. Bewerten Sie die Discovery-Disziplin im Interview (Stufe 4, Live-Demo-Übung) genauso hart wie die technische Tiefe. Ein:e gute:r Sales Engineer im KMU hat 70 % der Tiefe einer:eines Solutions Architect und 200 % der Discovery-Reife.
-
Die AE-Partnerschaft nicht im Interview prüfen
Sales Engineers arbeiten zu 60-80 % mit Account Executives, nicht direkt mit Kund:innen. Wer im Interview keine konkreten Beispiele einer AE-Partnerschaft liefern kann (gemeinsame Pipeline-Reviews, gegenseitiges Feedback, geteilte Disqualifikations-Entscheidungen), wird im Team Reibung erzeugen. Stellen Sie mindestens eine values-Frage explizit zur AE-Beziehung; lassen Sie eine:n AE aus dem Team mit der:dem Kandidat:in sprechen.
-
POC-Erfahrung mit Demo-Erfahrung verwechseln
Viele Profile mit Pre-Sales-Erfahrung in transaktionalen SaaS-Umfeldern haben hunderte Demos gehalten, aber selten einen echten Proof-of-Concept mit Erfolgskriterien und Engineering-Beteiligung begleitet. Im DACH-Mittelstand und in technischen B2B-Branchen ist der POC oft der zentrale Win-Hebel. Fragen Sie konkret nach Anzahl und Tiefe der begleiteten POCs (nicht der Demos) und nach der Methodik zur Definition der Erfolgskriterien.
-
Den technischen Compliance- und Security-Anteil unterschätzen
Ein:e Sales Engineer im deutschen B2B-Mittelstand verbringt 15-25 % der Zeit mit Security- und Compliance-Fragen: DSGVO-Auftragsverarbeitung, ISO-27001, BSI-Grundschutz, branchenspezifische Anforderungen (KRITIS, BAFIN, Medizinprodukteverordnung). Wer aus reinem Hyperscale-SaaS kommt, hat oft keine Tiefe in deutschen Compliance-Patterns. Bewerten Sie das im Interview (technical question 11) und kalibrieren Sie die Anforderungen je nach Ihrer Branche.
Häufige Fragen
-
Was verdient ein:e Sales Engineer im KMU in Deutschland?
Die Referenzspanne für eine:n Sales Engineer auf Mid-Level (4 bis 8 Jahre, davon mindestens 2 in Pre-Sales oder technischer Beratung) im deutschen B2B-SaaS-KMU liegt bei 58-88 k€ Fixgehalt pro Jahr (Median um 70 k€), ergänzt um eine variable Komponente von 10-20 k€ bei OTE (typisches 80/20-Modell). SaaS-Profile in Berlin oder München tendieren zur Obergrenze; klassische Mittelstand- und Industrie-Software-Profile liegen meist im unteren Drittel. Für eine:n soliden Mid bei 100 % OTE rechnen Sie mit 70-105 k€ Gesamt-Zielvergütung.
-
Was ist der Unterschied zwischen Sales Engineer und Account Executive?
Die:der Account Executive trägt ein individuelles Quota und ist der:die primäre kommerzielle Ansprechpartner:in. Die:der Sales Engineer ist die technische Verstärkung: sie:er unterstützt 2-5 AEs mit maßgeschneiderten Demos, Proof-of-Concept-Begleitung, Architektur-Diskussionen und Compliance-Antworten. Sales Engineers haben in der Regel kein individuelles Quota; die Variable koppelt häufig an Team-Ziele oder an AE-Quotas. Die beiden Rollen in einer Anzeige zu vermischen, ist einer der häufigsten Einstellungsfehler im DACH-B2B-SaaS.
-
Was ist der Unterschied zwischen Sales Engineer und Solutions Architect?
Die:der Sales Engineer wirkt im Pre-Sales: Demo, POC, technische Qualifizierung, Architektur-Diskussion vor dem Closing. Die:der Solutions Architect wirkt im Post-Sales und in tiefen Implementierungs-Projekten: detaillierte Architektur-Entwürfe, Migration, Customizing, manchmal Code. Im KMU sind die Rollen oft fließend, aber die Schwerpunkte sind unterschiedlich: ein:e Sales Engineer braucht mehr Discovery-Reife und Demo-Erzählkunst, ein:e Solutions Architect mehr technische Tiefe und Implementierungs-Erfahrung. Wer eine:n SE einstellt, sollte die 70/30-Gewichtung Sales/Engineering ehrlich kommunizieren.
-
Wie lange dauert die Einstellung eines:einer Sales Engineer in Deutschland?
Rechnen Sie mit 50-80 Tagen zwischen Ausschreibung und Vertragsunterzeichnung für eine Mid-Level-Position im deutschen B2B-SaaS-KMU. Etwas länger als bei reinen Account Executives, weil das Profil seltener ist und die Live-Demo-Übung (Stufe 4) ein zusätzliches Zeitfenster braucht. Im klassischen Mittelstand verlängert sich die Frist tendenziell, weil Entscheidungsprozesse mehr Stakeholder durchlaufen und technische Referenzen mehr Gewicht bekommen. Eine Verkürzung unter 50 Tage geht meist auf Kosten der Live-Demo-Übung und reduziert die Einstellungsqualität deutlich.
-
Welche technische Tiefe sollte ein:e Sales Engineer mitbringen?
Eine:e gute:r Sales Engineer im DACH-Mittelstand muss API-Konzepte (REST, GraphQL, Webhooks), Datenbank-Grundlagen, Authentifizierung (SSO, SAML, OAuth), Sicherheitsmechanismen (Verschlüsselung in Ruhe und in Bewegung, Audit-Logs) und Compliance-Vokabular (DSGVO, ISO-27001, branchenspezifische Anforderungen) auf einem Niveau beherrschen, das in Architektur-Diskussionen mit der:dem technischen Sponsor:in der:des Prospects auf Augenhöhe wirkt. Sie:er muss nicht selbst Produktionscode schreiben, aber Skript-Niveau (Python, JavaScript, SQL) ist ein klarer Vorteil. Hands-on-Erfahrung in einer früheren Engineering-, Beratungs- oder Implementierungs-Rolle ist das stärkste Signal.
-
Welche rechtlichen Vorgaben gelten für Sales-Engineer-Stellenausschreibungen in Deutschland?
Drei zentrale Vorgaben: (1) geschlechtsneutrale Stellenbezeichnung mit (m/w/d) oder Doppelpunkt-Schreibweise (§ 11 AGG), (2) Pflicht zur Gehaltstransparenz in der Anzeige oder vor dem ersten Interview (EU-Entgelttransparenzrichtlinie 2023/970, Umsetzung bis 7. Juni 2026), (3) Transparenz beim Einsatz von KI-Tools zur Vorauswahl und garantierte menschliche Aufsicht (EU AI Act, ab 2. August 2026). Im Interview selbst sind Fragen zu Alter, Herkunft, Familienstand oder Religion nach § 7 AGG unzulässig. Bei tarifgebundenen Branchen (z. B. Maschinenbau, Versicherungen) gelten zusätzlich die einschlägigen Tarifverträge.