SQL-Definition und Akzeptanz: Wozu sich der Vertrieb verpflichtet, wenn er einen Lead annimmt

Die Leads liegen in Salesforce. Status: SQL. Alter: 17 Tage. Erster Kontakt: nie.

Marketing sieht die Anzahl der akzeptierten Leads und denkt, der Handoff hat funktioniert. Der Vertrieb sagt, die Leads waren nicht gut. Technisch gesehen liegt niemand falsch — und genau das ist das Problem. Akzeptanz hat stattgefunden. Verantwortlichkeit nicht.

Ein SQL ohne Akzeptanz-SLA ist nur ein Label. Wenn der Vertrieb bei einem Lead auf „Annehmen" klickt, muss diese Aktion etwas Konkretes bedeuten: eine Verpflichtung, innerhalb eines definierten Zeitfensters mit definierten nächsten Schritten zu handeln — oder den Lead mit einem dokumentierten Grund zurückzugeben. Ohne diesen Vertrag ist Ihr MQL-zu-SQL-Handoff Theater. Zwei Teams, die Alignment performen, ohne es tatsächlich zu erreichen.

Dieser Artikel legt dar, was eine SQL-Definition enthalten sollte, wozu die Akzeptanz den Vertrieb tatsächlich verpflichtet und wie das Agreement so dokumentiert wird, dass beide Seiten daran festgehalten werden können.

Wichtige Fakten: SQL-Performance und Handoff-Qualität

• Laut MarketingSherpa-Forschung zu B2B-Lead-Follow-up-Raten werden nur 27 % der an den Vertrieb weitergeleiteten Leads jemals kontaktiert.
• Unternehmen mit formalen SLA-Agreements zwischen Marketing und Vertrieb haben eine 2,4-mal höhere Wahrscheinlichkeit, jährliches Umsatzwachstum zu berichten, laut HubSpots State of Marketing Report.
• Das durchschnittliche B2B-Unternehmen verliert 71 % seiner Internet-Leads, weil sie nicht schnell genug kontaktiert werden, so eine Studie von Drift und Heinz Marketing.
• Leads, die innerhalb von 5 Minuten nach der ersten Anfrage kontaktiert werden, qualifizieren sich mit 21-mal höherer Wahrscheinlichkeit als Leads, die erst nach 30 Minuten kontaktiert werden — laut einer gemeinsamen MIT- und InsideSales.com-Studie.
• 61 % der B2B-Marketer leiten alle Leads direkt an den Vertrieb weiter, aber nur 27 % dieser Leads sind tatsächlich qualifiziert, so MarketingSherpa.

Das Problem des Akzeptanz-Theaters

Die Gartner SQL-Definition behandelt den SQL-Status als bestätigte Eigentumsübertragung — aber Eigentümerschaft ohne Verantwortlichkeit ist die Lücke, die die meisten Teams nie schließen.

So entfaltet sich das Akzeptanz-Theater in den meisten B2B-Unternehmen:

Marketing übergibt am Ende der Woche einen Stapel MQLs an den Vertrieb. Der Vertrieb akzeptiert sie, weil der SLA besagt, dass er innerhalb von 48 Stunden antworten muss. Aber „Annehmen" bedeutet, einen CRM-Button zu klicken. Es bedeutet nicht, dass der Rep den Lead angesehen, das Unternehmen recherchiert oder plant, innerhalb eines vertretbaren Zeitfensters anzurufen.

Zwei Wochen später zieht Marketing den Bericht. Alle MQLs wurden „akzeptiert". Gut. Außer dass nur 3 von 20 jemals kontaktiert wurden. Die anderen 17 sind jetzt kalt.

Wenn Marketing dies im nächsten Alignment-Meeting anspricht, sagt der Vertrieb: „Diese Leads waren nicht gut." Marketing sagt: „Sie haben sie akzeptiert." Beide Seiten haben technisch Recht. Keine Seite trägt Verantwortung.

Die Ursache ist definitorisch. Die meisten Unternehmen definieren einen SQL nur hinsichtlich der Weiterleitungskriterien: welche Signale ein Lead haben muss, bevor der Vertrieb die Verantwortung übernimmt. Sie definieren nicht, was der Vertrieb im Gegenzug schuldet. Diese Asymmetrie lässt den Handoff scheitern.

SQL vs. MQL: Die Eigentümerschaftsverschiebung

Der MQL-zu-SQL-Übergang ist nicht nur eine Statusänderung. Er soll eine Eigentumsübertragung sein.

Wenn ein Lead ein MQL ist, gehört er Marketing. Marketing entscheidet, ob es ihn pflegt, beschleunigt oder disqualifiziert. Wenn ein Lead ein SQL wird, gehört er dem Vertrieb. Der Vertrieb entscheidet, ob er ihn vorantreibt, zurückgibt oder abschließt.

Aber Eigentümerschaft ohne Verantwortlichkeit ist leer. Der Vertrieb, der einen SQL „besitzt", muss operativ etwas bedeuten:

• Der Vertrieb ist für den ersten bedeutungsvollen Kontakt verantwortlich
• Der Vertrieb muss den Lead entweder vorantreiben oder innerhalb eines definierten Zeitfensters ablehnen
• Eine Ablehnung erfordert einen dokumentierten Grund, der zurück zu Marketing geleitet wird

Solange Sie nicht definieren, was Eigentümerschaft tatsächlich erfordert, verschiebt der Handoff lediglich einen Datensatz von der Ansicht eines Teams in die eines anderen. Am Schicksal des Leads ändert sich nichts.

Der MQL-zu-SQL-Handoff-Prozess behandelt die Mechanik dieser Übertragung. Dieser Artikel konzentriert sich darauf, was die Akzeptanzverpflichtung enthalten sollte. Den umfassenderen Funnel-Kontext, den beide Teams teilen, definiert das vereinbarte Funnel-Modell für jede Phase.

Die zweiteilige SQL-Definition

Das SQL-Zweiteiliges-Definitions-Framework

Eine vollständige SQL-Definition umfasst zwei gleichermaßen verbindliche Verpflichtungen — Qualifikationskriterien (was einen Lead SQL-fertig macht) und Akzeptanzverpflichtungen (was der Vertrieb nach der Annahme schuldet). Die meisten Teams schreiben Teil 1 und überspringen Teil 2. Diese Asymmetrie ist der Punkt, an dem Handoffs scheitern.

Teil 1: Qualifikationskriterien — die Signale, die einen Lead SQL-bereit machen. Umfasst Fit (ICP-Match, Kaufberechtigung), Intent (Demo-Anfrage, Preisbesuch) und Timing (aktives Projekt, Budgetzyklusabgleich).

Teil 2: Der Akzeptanz-SLA — wozu sich der Vertrieb beim Klicken auf Annehmen verpflichtet: erste bedeutungsvolle Kontaktaufnahme innerhalb von 24 Stunden, Discovery-Versuch innerhalb von 5 Werktagen, Disposition (vorantreiben oder mit Begründung zurückgeben) innerhalb von 10 Werktagen.

Beide Teile befinden sich im selben unterzeichneten Dokument. Eine Definition, die nur Teil 1 umfasst, ist ein Handoff ohne Verantwortlichkeit.

Eine funktionierende SQL-Definition hat zwei Teile, die die meisten Teams nur halb aufbauen:

Teil 1: Qualifikationskriterien: die Signale, die einen Lead SQL-bereit machen. Das ist es, was die meisten Teams schreiben.

Teil 2: Akzeptanzverpflichtungen: wozu sich der Vertrieb nach der Annahme verpflichtet. Das ist es, was die meisten Teams überspringen.

Beide Teile müssen im selben dokumentierten Agreement stehen. Eine Definition, die nur Teil 1 umfasst, sagt Ihnen, an wen Sie übergeben sollen. Sie sagt Ihnen nicht, was als nächstes zu tun ist. Und ohne Teil 2 bleibt die Akzeptanz eine Formalität.

Teil 1: Qualifikationskriterien

SQL-Kriterien sollten drei Signal-Kategorien umfassen: Fit, Intent und Timing.

Fit-Signale bestätigen, dass der Lead wirklich zu Ihrem Zielmarkt gehört:

• ICP-Match bei Unternehmensgröße, Branche, Geografie — das gemeinsame ICP-Framework dokumentiert, wie man sich teamübergreifend auf diese Dimensionen einigt
• Bestätigte oder wahrscheinliche Budgetberechtigung (Titel weist auf Kaufrolle hin oder direkte Budgetbestätigung aus Formular/Gespräch)
• Technologie-Stack-Kompatibilität (sie nutzen Systeme, mit denen Ihr Produkt integriert wird, oder ersetzen ein System, das Sie ablösen)

Intent-Signale bestätigen aktives Kaufinteresse:

• Hochwertige Seitenbesuche: Preise, Demo, Vergleich, ROI-Rechner
• Explizite Anfrage: Demo gebucht, Trial gestartet, direkte Anfrage
• Wettbewerbsrecherche-Verhalten: Besuch von Konkurrenzvergleichsinhalten

Timing-Signale bestätigen ein aktives Entscheidungsfenster:

• Formularfeld mit Projekt-Timeline („evaluieren jetzt", „Q2-Budget eingeplant")
• Event-Trigger: auslaufender Vertrag, Führungswechsel, Finanzierungsrunde
• Inbound-Kontaktaufnahme (sie haben Sie kontaktiert, was ein gewisses Maß an Dringlichkeit impliziert)

Kein einzelnes Signal sollte einen Lead automatisch zum SQL machen. Ein Lead, der einmal Ihre Preisseite besucht hat und Ihrem ICP entspricht, ist nicht unbedingt bereit für ein Verkaufsgespräch. Sie wollen eine Kombination — typischerweise Fit plus mindestens ein starkes Intent- oder Timing-Signal.

SQL-Kriterien-Checkliste

Mindestsignale, bevor der Vertrieb die Verantwortung übernimmt:

• Unternehmen entspricht ICP bei mindestens 2 von 3 firmografischen Kriterien (Größe, Branche, Tech-Stack)
• Kontakt hat wahrscheinliche Kaufberechtigung (VP oder höher, oder bestätigter Economic Buyer)
• Mindestens ein explizites Intent-Signal (Demo-Anfrage, Preisbesuch, direkte Anfrage)
• Keine aktiven Disqualifikatoren (Wettbewerber, Student, irrelevante Geografie)
• Lead-Quelle erfasst und verifiziert

Diese Checkliste ist ein Ausgangspunkt. Kalibrieren Sie sie anhand Ihrer Closed-Won-Daten. Wenn Leads, die alle fünf Kriterien erfüllen, zu einem wesentlich höheren Preis abschließen als solche, die drei erfüllen, sind Ihre Schwellenwerte ungefähr richtig. Wenn Fünf-Kriterien-Leads zum gleichen Preis wie Drei-Kriterien-Leads abschließen, gaten Sie zu stark.

Das MQL-Definitions-Framework behandelt die Qualifikationsentscheidungen in früheren Phasen, die in diesen Kriteriensatz einfließen.

Teil 2: Der Akzeptanz-SLA

Wenn der Vertrieb einen SQL akzeptiert, verpflichtet er sich zu bestimmten Maßnahmen innerhalb bestimmter Zeitrahmen. Der Akzeptanz-SLA definiert diese Verpflichtungen.

Der 24-Stunden-First-Touch-SLA ist derjenige, den die meisten Teams verpassen. HBR-Forschung zu Online-Sales-Leads ergab, dass Unternehmen, die potenzielle Kunden innerhalb einer Stunde nach einer Anfrage kontaktierten, fast siebenmal häufiger den Lead qualifizierten als solche, die noch eine Stunde länger warteten.

Zitierbar: B2B-Vertriebsteams, die auf Inbound-Leads innerhalb einer Stunde nach einer Anfrage reagieren, qualifizieren den Lead mit 7-fach höherer Wahrscheinlichkeit als Teams, die noch 60 Minuten länger warten — laut HBR-Forschung zu Online-Sales-Lead-Response-Raten. Der Unterschied zwischen 1 Stunde und 24 Stunden ist bereits erheblich. Wenn Ihr Akzeptanz-SLA 48 Stunden für den ersten Kontakt erlaubt, geben Sie Pipeline auf, bevor der Vertrieb überhaupt zum Telefon greift.

Für Teams, die Inbound-Demo-Anfragen bearbeiten, sollten Sie dies weiter verschärfen. Ein Fünf-Minuten-Response-SLA ist für hochintentionierte Inbound-Leads erreichbar und verändert Conversion-Raten spürbar.

SQL-Kriterien schreiben, die Ihr Team tatsächlich verwenden wird

Die Gartner MQL-Definition ist hier eine nützliche Upstream-Referenz — die SQL-Kriterien, die Sie Downstream schreiben, sollten genau widerspiegeln, wo die MQL-Definition endet und die Eigentümerschaft auf den Vertrieb übergeht.

SQL-Definitionen scheitern aus zwei Gründen: Entweder sind sie zu locker (jeder MQL gilt als SQL) oder zu starr (so viele Kriterien, dass kaum Leads jemals qualifizieren und der Vertrieb klagt, die Definition sei unrealistisch).

Eine funktionierende Definition ist spezifisch genug, um bedeutungsvoll zu sein, und flexibel genug, um die Vielfalt echter Leads zu berücksichtigen.

Vermeiden Sie binäre Definitionen. Statt „Budget muss bestätigt sein" schreiben Sie: „Budget-Bereich im Formular angegeben ODER Titel deutet auf Budgetkompetenz hin (VP oder höher)." Dies berücksichtigt die Realität, dass viele Käufer in der Awareness-Phase kein Budget offenbaren.

Bauen Sie explizite Disqualifikatoren ein. Negative Kriterien sind genauso wichtig wie positive. Ein Lead, der perfekt zu Ihrem ICP passt, aber von einem direkten Wettbewerber, einem Studenten oder aus einem Land stammt, in dem Sie nicht tätig sind, sollte die SQL-Kriterien unabhängig von seinen Intent-Signalen nicht erfüllen.

Verwenden Sie „wahrscheinlich"-Formulierungen sorgfältig. „Wahrscheinliche" Kaufberechtigung ist ein gültiges Kriterium für SQLs in vielen Situationen, insbesondere bei Inbound, wo Sie beim ersten Kontakt selten Budget bestätigen. Aber „wahrscheinlich" erfordert eine Definition. „Titel Director oder höher in der relevanten Funktion" ist wahrscheinliche Berechtigung. „Jeder mit einer geschäftlichen E-Mail" ist es nicht.

Legen Sie eine Mindestwertung oder Signalanzahl fest. Für Teams, die gemeinsames Lead Scoring verwenden, definieren Sie die erforderliche Mindestwertung für den SQL-Status. Für Teams ohne formales Scoring definieren Sie eine Mindestsignalanzahl (z. B. „mindestens 2 Fit-Signale und mindestens 1 Intent-Signal").

Die SAL-Stufe: Wann sie hilft, wann nicht

Einige Revenue-Teams fügen zwischen MQL und SQL eine Sales Accepted Lead (SAL)-Stufe ein. Die SAL-Stufe schafft ein kurzes Fenster (typischerweise 48-72 Stunden), in dem der Vertrieb den Lead überprüfen kann, bevor er sich vollständig zum SQL-SLA verpflichtet.

Wann SAL Klarheit schafft:

• Hohes Inbound-Volumen, bei dem der Vertrieb wirklich Überprüfungszeit benötigt, bevor er sich verpflichtet
• Teams, bei denen die Qualifikationskriterien komplex sind und CRM-Recherche vor der Akzeptanz erfordern
• Organisationen mit formalen SLA-Audits, bei denen eine Teilverpflichtung bedeutsam ist

Wann SAL nur Reibung erzeugt:

• Teams mit klaren ICP-Kriterien, bei denen die Überprüfung 2 Minuten dauert
• Niedrigvolumen-Umgebungen, bei denen jeder Lead sowieso eine vollständige Überprüfung wert ist
• Organisationen, bei denen die SAL-Stufe genutzt wird, um Verantwortlichkeit zu verzögern statt sie zu ermöglichen

Wenn Sie eine SAL-Stufe hinzufügen, definieren Sie ein strenges Fenster (maximal 48 Stunden) und eine Dispositionsanforderung am Ende dieses Fensters: zum SQL-Status akzeptieren oder mit Begründung zurückgeben. Ein SAL, der eine Woche liegen kann, bietet keinen Vorteil gegenüber einem MQL. Die Lead-Routing-Regeln, die Ihr Team anwendet, bestimmen, welcher Rep den Lead erhält, sobald er das SAL-Fenster überwunden hat.

Was passiert, wenn der Vertrieb einen SQL ablehnt

Ablehnung ist ein wertvolles Signal — aber nur, wenn sie korrekt dokumentiert wird.

Ablehnungsgrund-Taxonomie (strukturierte Codes, kein Freitext):

Unstrukturierte Ablehnungsgründe („kein Interesse", „schlechter Lead") sind für Marketing nutzlos. Sie sagen Ihnen nicht, ob die Definition aktualisiert werden muss, ob das Nurture-Programm versagt hat, oder ob der Vertrieb Ablehnungen nutzt, um schwieriger Arbeit aus dem Weg zu gehen.

Strukturierte Ablehnungscodes ermöglichen es Marketing, Muster zu identifizieren. Wenn 40 % der SQL-Ablehnungen als R2 zurückkommen (richtiges Unternehmen, falsches Timing), kann Marketing einen schnelleren Re-Engagement-Trigger aufbauen. Wenn 30 % als R3 zurückkommen (außerhalb ICP), hat die MQL-Definition ein Problem.

Der Prozess der Lead-Ablehnung und -Wiederverwertung beschreibt, was mit zurückgegebenen Leads passiert. Diese Taxonomie fließt direkt in diesen Workflow ein.

Den SQL-Vertrag dokumentieren

Die SQL-Definition und der Akzeptanz-SLA sollten ein einziges schriftliches Dokument sein, kein mündliches Verständnis. Sowohl VP Marketing als auch VP Sales unterzeichnen es. Beide Teams haben Zugang dazu. Es hat eine Versionsnummer und ein letztes Überprüfungsdatum.

Dokumentenstruktur:

SQL-Vertrag — [Unternehmensname]
Version: [X.X]
Inkrafttreten: [Datum]
Zuletzt überprüft: [Datum]
Verantwortliche: VP Marketing, VP Sales

Abschnitt 1: SQL-Qualifikationskriterien
- Erforderliche Mindest-Fit-Signale: [Liste]
- Erforderliche Mindest-Intent-Signale: [Liste]
- Disqualifikatoren: [Liste]
- Mindest-Gesamtwertung (falls zutreffend): [Wertung]

Abschnitt 2: Akzeptanzverpflichtungen
- SLA erste bedeutungsvolle Kontaktaufnahme: [Zeitrahmen]
- SLA Discovery-Versuch: [Zeitrahmen]
- Dispositionsanforderung: [Zeitrahmen und Optionen]

Abschnitt 3: Ablehnungsstandards
- Ablehnungscodes: [Taxonomie]
- Routing-Aktionen pro Code: [Tabelle]
- Ablehnungs-SLA (Feedback an Marketing): [Zeitrahmen]

Abschnitt 4: Überprüfungsplan
- Vierteljährliches Kalibrierungsmeeting: [Verantwortliche, Format]
- Auslöser für außerordentliche Überprüfung: [Bedingungen]

Versionskontrolle ist wichtig. Wenn sich die Definition ändert — weil sich Ihr ICP verschoben hat, ein neuer Kanal begonnen hat, Leads unterschiedlicher Qualität zu generieren, oder Kalibrierungsdaten zeigten, dass die Schwellenwerte falsch waren — brauchen Sie eine Aufzeichnung dessen, was sich geändert hat und warum. Ohne Versionskontrolle werden alte Definitionen befolgt, nachdem sie ersetzt wurden, und Sie können Leistungslücken nicht gegen die richtige Baseline diagnostizieren.

Rework-Analyse: Teams, die eine zweiteilige SQL-Definition formalisieren — mit dokumentierten Kriterien und Akzeptanz-SLAs — schließen die Lücke des Akzeptanz-Theaters typischerweise innerhalb eines Quartals. Der führende Indikator ist die Ablehnungsrate mit strukturierten Ablehnungscodes. Wenn R1–R6-Codes konsistent verwendet werden, stabilisiert sich die MQL-zu-SQL-Conversion innerhalb von 60 Tagen, weil Marketing zurückgegebene Leads korrekt weiterleiten kann, statt dieselben disqualifizierten Kontakte erneut weiterzuleiten. Beginnen Sie mit dem Akzeptanz-SLA, bevor Sie die Kriterien optimieren. Verhalten vor Scoring.

SQL-Qualität im Zeitverlauf messen

Drei Metriken zeigen Ihnen, ob Ihre SQL-Definition funktioniert:

SQL-zu-Opportunity-Conversion-Rate. Wenn weniger als 60-70 % der SQLs zu Opportunities werden, ist Ihre Definition zu locker. Sie leiten Leads weiter, die der Vertrieb nicht vorantreiben kann. Wenn die Conversion sehr hoch ist (>90 %) und das Volumen gering ist, könnte Ihre Definition zu streng sein und Sie verpassen Pipeline. Die Lead-zu-Opportunity-Conversion-Benchmarks aus der Pipeline-Seite geben Ihnen die Downstream-Sicht auf diese Rate.

SQL-zu-Closed-Won-Rate. Verfolgen Sie die Win-Rate ab der SQL-Phase, nicht nur ab Opportunity. Wenn Sie viele Opportunities aus SQLs erstellen, aber wenige abschließen, zeigt sich das Qualitätsproblem eine Phase später: Die SQL-Kriterien leiten Leads weiter, die der Vertrieb bearbeiten, aber nicht abschließen kann. Hier werden die Opportunity-Qualifikations-Kriterien entscheidend — was der Vertrieb als SQL akzeptiert, sollte mit dem übereinstimmen, was er tatsächlich vorantreiben kann.

Ablehnungsrate nach Ablehnungscode. Eine steigende R3-Rate (außerhalb ICP) bedeutet, dass Ihre Upstream-Qualifikation driftet. Eine steigende R2-Rate (richtiges Unternehmen, falsches Timing) könnte bedeuten, dass Marketing Leads zu schnell beschleunigt, oder sie signalisiert eine Chance für timing-basierte Nurture-Programme.

Überprüfen Sie diese Metriken vierteljährlich im Alignment-Meeting, das das Marketing-Sales-Alignment-Glossar und gemeinsame Definitionen behandelt. Wenn sich Zahlen bewegen, gehen Sie zur Definition zurück, nicht zum Team.

Das Fazit

Eine SQL-Definition ohne Akzeptanzverpflichtungen ist ein Handoff ohne Verantwortlichkeit. Marketing kann auf akzeptierte Zahlen verweisen. Der Vertrieb kann auf Lead-Qualität verweisen. Niemand ist für die Lücke dazwischen verantwortlich.

Das Schreiben der zweiteiligen Definition (Kriterien plus Verpflichtungen) schließt diese Lücke. Der Vertrieb weiß, was Akzeptieren bedeutet, bevor er den Button klickt. Marketing weiß, was nach dem Handoff zu erwarten ist. Wenn etwas schiefläuft, zeigt das Agreement, wo.

Beide Teams müssen das Dokument besitzen. Beide müssen die Daten überprüft haben, die die Schwellenwerte informiert haben. Und beide müssen das Gefühl haben, dass die Definition fair ist — keine Falle für eine der Seiten.

So wird Akzeptanz zu einer Verpflichtung statt einer Formalität.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem MQL und einem SQL?

Ein MQL (Marketing Qualified Lead) ist ein Lead, den Marketing als die Mindest-ICP- und Engagement-Kriterien erfüllend bestimmt hat, was ihn der Pflege in Richtung eines Verkaufsgesprächs würdig macht. Ein SQL (Sales Qualified Lead) ist ein Lead, der eine höhere Schwelle überschritten hat — bestätigter Fit, aktiver Intent und Timing-Signale — und den der Vertrieb akzeptiert hat, um ihn zu bearbeiten. Der Eigentumsunterschied ist die wichtigste Unterscheidung: Marketing besitzt den MQL, der Vertrieb besitzt den SQL.

Wozu verpflichtet die SQL-Akzeptanz den Vertrieb tatsächlich?

Wenn der Vertrieb einen SQL akzeptiert, verpflichtet er sich zu bestimmten Maßnahmen innerhalb definierter Zeitrahmen: eine erste bedeutungsvolle Kontaktaufnahme innerhalb von 24 Stunden, ein Discovery-Versuch innerhalb von 5 Werktagen und eine vollständige Disposition — zu einer Opportunity vorantreiben oder mit einem strukturierten Ablehnungsgrund zurückgeben — innerhalb von 10 Werktagen. Akzeptanz ohne diese Verpflichtungen ist Theater, keine Verantwortlichkeit.

Was sollte passieren, wenn der Vertrieb einen SQL ablehnt?

Der Vertrieb sollte den Lead mit einem strukturierten Ablehnungscode zurückgeben, nicht mit Freitext wie „kein Fit". Eine Ablehnungstaxonomie (z. B. R1 = falsche Persona, R2 = kein aktives Projekt, R3 = außerhalb ICP) sagt Marketing genau, wo der Breakdown stattgefunden hat, damit es die MQL-Definition korrigieren oder bessere Nurture-Programme aufbauen kann. Unstrukturierte Ablehnungsgründe sind für Upstream-Verbesserungen nutzlos.

Was wenn der Vertrieb einen akzeptierten SQL nie kontaktiert?

Das ist das Akzeptanz-Theater-Problem — Akzeptanz hat stattgefunden, Verantwortlichkeit nicht. Die Lösung ist operativ: Bauen Sie SLA-Reporting in Ihr CRM ein, das SQLs ohne First-Touch-Aktivität nach 24 Stunden markiert. Sowohl VP Marketing als auch VP Sales sollten diesen Bericht wöchentlich sehen. Wenn verpasste SLAs in einem gemeinsamen Dashboard auftauchen, sind beide Teams für die Lücke verantwortlich.

Wie oft sollte die SQL-Definition überprüft werden?

Mindestens vierteljährlich. Die SQL-Definition sollte immer dann erneut betrachtet werden, wenn die SQL-zu-Opportunity-Conversion um mehr als 10 Prozentpunkte gegenüber dem Vorquartal fällt, wenn ein neuer Kanal beginnt, Leads deutlich anderer Qualität zu generieren, oder wenn sich Ihr ICP verschiebt. Versionieren Sie das Dokument, damit Sie Leistungslücken gegen die richtige Baseline diagnostizieren können.

Was ist ein SAL (Sales Accepted Lead) und wann sollten wir diese Phase hinzufügen?

Ein SAL ist eine Zwischenphase zwischen MQL und SQL, die dem Vertrieb ein kurzes Überprüfungsfenster gibt — typischerweise 48–72 Stunden —, um zu bestätigen, dass ein Lead SQL-Kriterien erfüllt, bevor er sich vollständig zum Akzeptanz-SLA verpflichtet. SAL bietet einen Mehrwert, wenn Qualifikationskriterien komplex sind und der Vertrieb wirklich Recherche-Zeit vor der Verpflichtung benötigt. Er erzeugt Reibung, wenn er zu einem Puffer für langsames Follow-up wird. Wenn Ihre SAL-Phase konsistent älter als 72 Stunden wird, entfernen Sie sie.

Wie berechnen wir das richtige SQL-zu-Opportunity-Conversion-Ziel?

Ziehen Sie 3–6 Monate saubere CRM-Daten. Zählen Sie SQLs nach Eingangsdatum und Opportunities, die aus diesen SQLs erstellt wurden. Teilen Sie Opportunities durch SQLs, um Ihre Baseline-Rate zu erhalten. B2B-KMU-Benchmarks liegen bei 60–80 %; Mid-Market bei 55–75 %. Wenn Sie unter 55 % liegen, ist Ihre SQL-Definition zu locker. Wenn Sie über 90 % liegen, aber das Volumen gering ist, gaten Sie zu stark und verlieren Pipeline.

Mehr erfahren

• MQL-Definitions-Framework
• MQL-zu-SQL-Handoff-Prozess
• Vereinbartes Funnel-Modell
• Lead-Ablehnung und -Wiederverwertung
• Fünf-Minuten-Response-SLA
• Opportunity-Qualifikation
• Marketing-Sales-Alignment-Glossar