Sales Qualified Lead (SQL)

Was ist ein Sales Qualified Lead (SQL)?

Sales Qualified Lead (SQL) bezeichnet einen Lead, der die Qualifizierungsschwelle vom Marketing zum Vertrieb überschritten hat. Im Gegensatz zum Marketing Qualified Lead (MQL), der Interesse gezeigt hat, erfüllt ein SQL konkrete Kriterien wie Budget, Authority, Need und Timeline (BANT) und ist bereit für direkte Verkaufsgespräche.

— Vertriebswikinger Glossar

Ein SQL ist nicht einfach "irgendein interessierter Lead", sondern ein strategisch qualifizierter Kontakt, bei dem die Wahrscheinlichkeit eines Abschlusses hoch genug ist, um wertvolle Vertriebsressourcen zu investieren. Die SQL-Definition ist eine der wichtigsten Vereinbarungen zwischen Marketing und Sales – und gleichzeitig eine der häufigsten Konfliktquellen.

Dein Marketing und Sales streiten über Lead-Qualität? Wir etablieren klare SQL-Definitionen →

SQL auf einen Blick

Eigenschaft	Wert
Definition	Lead bereit für persönlichen Verkaufskontakt
Vorherige Phase	MQL (Marketing Qualified Lead)
Nächste Phase	Opportunity/Deal
Typische Kriterien	BANT erfüllt, aktives Kaufinteresse
Conversion Rate	10-25% von MQL zu SQL (B2B Durchschnitt)
SQL → Customer	20-40% (je nach Industrie)
Übergabe-Methode	CRM-Zuweisung + Notification
Verantwortung	Sales Development (SDR/BDR) → Account Executive (AE)

Die Lead-Hierarchie: Von Contact zu Customer

```
Raw Contact (jeder Kontakt)
↓
Marketing Qualified Lead (MQL) – zeigt Interesse
↓
Sales Accepted Lead (SAL) – Sales akzeptiert Lead
↓
Sales Qualified Lead (SQL) – erfüllt Kriterien
↓
Opportunity – aktiver Deal
↓
Customer – Abschluss
```

Wichtig: Nicht jede Organisation nutzt alle Stufen. Viele vereinfachen zu: MQL → SQL → Opportunity

MQL vs. SQL vs. SAL – Die Unterschiede

Marketing Qualified Lead (MQL)

Definition:
Lead hat genug Interesse/Engagement gezeigt, um an Sales übergeben zu werden

Typische Kriterien: Behavioral Scoring:

• Website-Besuche: 5+ Seiten
• Content-Downloads: 2+ Assets (Whitepaper, E-Book)
• Email-Engagement: 3+ Klicks
• Webinar-Teilnahme: 1x
• Pricing-Page-Besuch: 1x

Demographic Scoring:

• Job Title: Decision Maker oder Influencer
• Company Size: >50 Mitarbeiter (je nach ICP)
• Industry: Target-Branchen
• Region: Bedienbare Märkte

Qualifizierung durch: Marketing (oft automatisiert via Marketing Automation)

Beispiel:
Sarah (Marketing Manager bei 200-MA-Firma) hat:

• Dein E-Book zu "B2B Lead Generation" heruntergeladen
• 3 Blog-Artikel gelesen
• Pricing-Page besucht

→ MQL

Realität: Könnte echtes Interesse haben ODER nur recherchieren

Sales Accepted Lead (SAL)

Definition:
MQL, den Sales gesehen und als "worthy of pursuit" akzeptiert hat

Prozess:

1. Marketing übergibt MQL
2. Sales (SDR/BDR) reviewed Lead
3. Schnell-Check: "Lohnt sich weiteres Qualifying?"
4. → Ja: SAL | → Nein: Disqualify/Recycle

Warum diese Stufe?
Verhindert, dass Sales Zeit mit offensichtlich schlechten Leads verschwendet

Akzeptanz-Kriterien:

• Richtiges Unternehmen (ICP-Match)
• Richtiger Ansprechpartner (keine Students, Competitors)
• Erreichbar (Email/Phone valide)

Nicht alle Orgs nutzen SAL – viele gehen direkt von MQL zu SQL

Sales Qualified Lead (SQL)

Definition:
Lead wurde vom Sales persönlich qualifiziert und erfüllt alle Kriterien für Opportunity-Creation

Typische Kriterien: BANT-Framework:

• Budget: Hat Budget oder kann es beschaffen
• Authority: Ist Decision Maker oder hat direkten Access
• Need: Hat konkretes, dringendes Problem
• Timeline: Will in absehbarer Zeit kaufen (z.B. <6 Monate)

Qualifizierung durch: Sales Development Rep (SDR) oder Business Development Rep (BDR) in Discovery Call

Beispiel:
Sarah (MQL von oben) hat im Call bestätigt:

• Budget: 50k € für Q1 approved
• Authority: Sie entscheidet gemeinsam mit VP Sales
• Need: Wollen Lead Gen um 40% steigern
• Timeline: Start bis März

→ SQL

Nächster Schritt: Übergabe an Account Executive (AE) für Demo/Proposal

Die kritische Unterscheidung

Kriterium	MQL	SAL	SQL
Qualifiziert von	Marketing (Auto)	SDR (Schnell-Check)	SDR (Deep-Dive)
Zeit investiert	0 Min (automatisch)	2-5 Min	15-30 Min
Kriterien	Behavioral + Demo	ICP-Match	BANT erfüllt
Kaufinteresse	Vermutlich	Möglich	Bestätigt
Nächster Schritt	SDR Outreach	Qualifying Call	AE Demo
Conversion zu Customer	1-3%	5-10%	20-40%

Das Problem: Marketing sieht jeden Download als "SQL" Sales will nur Leads mit Kaufvertrag in der Tasche

Die Lösung: Gemeinsame, schriftliche SQL-Definition (mehr dazu unten)

Die 7 SQL-Qualifizierungskriterien

1. Budget (Kaufkraft)

Die Frage:
"Kann der Lead sich unser Produkt leisten?"

Was qualifiziert:

Explizit:
"Wir haben 50k € Budget für Q1"

Implizit:
"Wir nutzen aktuell [teuren Competitor]"
→ Können sich ähnliches Budget leisten

Budget-Access:
"Ich muss das mit CFO besprechen" + Timeline
→ Kein Budget jetzt, aber beschaffbar

Disqualifiziert:
"Wir haben kein Budget" (ohne Timeline)
"Das ist viel zu teuer" (bei Minimum-Pricing)

Best Practice:
Frage nicht nach exaktem Budget-Betrag (macht Leute unkomfortabel)
Frage nach Budget-Range oder Budget-Prozess

Beispiel-Fragen:
"Haben Sie für dieses Jahr Budget allokiert?"
"In welchem Rahmen denken Sie?"
"Was nutzen Sie aktuell und was kostet das?"

2. Authority (Entscheidungsmacht)

Die Frage:
"Kann der Lead die Kaufentscheidung treffen oder beeinflussen?"

Decision Maker:

• C-Level (CEO, CTO, CFO, CMO)
• VP/Director in relevanter Funktion
• Budget-Verantwortlicher

Influencer:

• Team Lead, der an Decision Maker reportet
• User, die Produkt testen
• IT, die Technical Fit prüfen

Gatekeeper:

• Assistant, der nur weiterleitet
• Junior Researcher ohne Einfluss

Qualifiziert als SQL:
Decision Maker ODER Influencer mit Access zu Decision Maker

Disqualifiziert:
Gatekeeper ohne Weiterleitung
Student, der Research macht
Competitor, der spioniert

Beispiel-Fragen:
"Wer ist außer Ihnen in die Entscheidung involviert?"
"Wie sieht Ihr Buying-Prozess aus?"
"Wer muss final unterschreiben?"

Multi-Threading:
Selbst wenn initialer Contact kein Decision Maker ist – qualifiziert, wenn er dich connecten kann

3. Need (Konkretes Problem)

Die Frage:
"Hat der Lead ein Problem, das unser Produkt löst?"

Echtes Need:

• Quantifizierbares Problem ("Wir verlieren 30% Leads")
• Aktuell schmerzhaft (nicht theoretisch)
• Unsere Lösung passt

Kein echtes Need:
"Wir schauen uns um" (keine Urgency)
"Vielleicht später" (kein aktueller Pain)
"Nice to have" (nicht kritisch)

Need-Discovery:
Use SPIN-Questions im Discovery Call:

• Situation: "Wie managst du Leads aktuell?"
• Problem: "Was funktioniert nicht?"
• Implication: "Was kostet dich das?"
• Need-Payoff: "Wenn du das löst, was bedeutet das?"

Qualifiziert:
Problem + Impact + Unsere Lösung = Fit

Beispiel:
"Wir verlieren 40% unserer Inbound-Leads, weil Response-Time zu lang ist. Das kostet uns 500k € Revenue jährlich. Eine automatisierte Lead-Routing-Lösung würde das sofort fixen."
→ Perfect SQL

4. Timeline (Kaufzeitpunkt)

Die Frage:
"Wann will der Lead kaufen?"

Qualifizierte Timelines:

Urgent (SQL Tier 1):
"Wir müssen das noch dieses Quartal lösen"
→ Hot SQL, hohe Priorität

Near-Term (SQL Tier 2):
"Wir wollen in den nächsten 6 Monaten starten"
→ Standard SQL, normale Pipeline

Long-Term (SQL Tier 3):
"Vielleicht Ende Jahr"
→ Nurture-SQL, low priority

Disqualifiziert:
"Irgendwann mal"
"Kein konkreter Zeitplan"
"Nur mal schauen"
→ Zurück zu Marketing für Nurturing

Timeline-Driver verstehen:

• Business-Event: "Unser aktueller Contract läuft Q2 aus"
• Deadline: "Q1 Budget muss ausgegeben werden"
• Pain: "Wir können so nicht weitermachen"

Ohne Timeline = kein SQL

5. Fit (ICP-Match)

Die Frage:
"Passt der Lead zu unserem Ideal Customer Profile?"

ICP-Kriterien (B2B-Beispiel): Firmographic:

• Company Size: 50-500 Mitarbeiter
• Industry: SaaS, Tech, Professional Services
• Revenue: >5M € jährlich
• Region: DACH + EU

Technographic:

• Nutzt Salesforce/HubSpot
• Hat Marketing-Team >5 Personen
• Tech-affin (Cloud-ready)

Behavioral:

• Kauft ähnliche Tools
• Wachstumsfokussiert
• Innovationsbereit

Qualifiziert:
Erfüllt 70%+ der ICP-Kriterien

Red Flags:

• Zu klein (keine Buying Power)
• Zu groß (brauchen Enterprise-Lösung, die wir nicht haben)
• Falsche Industrie (unsere Lösung passt nicht)
• Falsche Region (können wir nicht bedienen)

Beispiel:
Lead ist 20-MA-Startup ohne Budget
→ Disqualify als SQL (außer hohe Wachstumspotenzial)

6. Pain Level (Dringlichkeit)

Die Frage:
"Wie dringend ist das Problem?"

Pain-Skala:

Critical (10/10):
"Wenn wir das nicht lösen, verlieren wir Kunden"
→ Höchste SQL-Priorität

High (7-9/10):
"Das kostet uns signifikant Zeit/Geld"
→ Standard SQL

Medium (4-6/10):
"Wäre nice, aber nicht dringend"
→ Low-Priority SQL oder Nurture

Low (1-3/10):
"Nur am Schauen"
→ Kein SQL

Pain-Indication:

• Häufigkeit: "Wir haben das Problem täglich"
• Impact: "Das kostet uns X €"
• Workarounds: "Wir kompensieren mit [aufwendiger Hack]"
• Frustration: "Das nervt unser Team massiv"

Ohne Pain = kein echtes Need = kein SQL

7. Engagement (Kaufinteresse-Signale)

Die Frage:
"Zeigt der Lead aktives Kaufinteresse?"

Positive Signale: Behavioral:

• Antwortet schnell auf Emails
• Nimmt Calls entgegen
• Fragt nach Details (Pricing, Implementierung, Support)
• Teilt Calendar für Follow-ups
• Involviert Team/Stakeholder

Verbal:
"Können Sie morgen meinem Chef präsentieren?"
"Wann könnten wir starten?"
"Was brauchen Sie von uns?"

Documented:

• Hat Demo angefordert
• Will Proposal sehen
• Fragt nach Case Studies
• Requested Trial

Negative Signale:

• Ghostet nach Initial Contact
• "Melde mich" (tut es nie)
• Cancelled Meetings mehrfach
• Antwortet einsilbig

Engagement-Score:
3+ positive Signale = SQL
1-2 positive Signale = Nurture
0 positive Signale = Disqualify

SQL-Scoring: Quantitative Qualifizierung

Einfaches SQL-Scoring (Binary)

Methode: Lead ist SQL, wenn alle Kriterien erfüllt sind

Beispiel:

✅ Budget: Ja
✅ Authority: Ja
✅ Need: Ja
✅ Timeline: Ja
→ SQL

✅ Budget: Ja
❌ Authority: Nein
✅ Need: Ja
✅ Timeline: Ja
→ Kein SQL (auch wenn 75% erfüllt)

Vorteil: Einfach, klare Linie
Nachteil: Zu strikt, viele Leads fallen durch

Weighted SQL-Scoring

Methode: Jedes Kriterium hat Punkte, ab Score X = SQL

Beispiel-System:

Kriterium	Punkte möglich	Gewichtung
Budget	25	25%
Authority	20	20%
Need	30	30%
Timeline	20	20%
Engagement	5	5%
Total	100	100%

SQL-Threshold: ≥70 Punkte Beispiel-Lead:

Budget: 20/25 (hat Budget-Range genannt, aber nicht final approved)
Authority: 15/20 (Influencer mit C-Level Access)
Need: 30/30 (kritisches, quantifiziertes Problem)
Timeline: 10/20 (6-9 Monate Timeline)
Engagement: 4/5 (mehrere positive Signale)

Total: 79/100 → SQL ✅

Vorteil: Flexibler, erfasst Nuancen
Nachteil: Komplexer zu managen

Tiered SQL-Kategorisierung

Methode: SQLs in Prioritäts-Tiers einteilen

Tier 1 SQL (Hot):

• BANT vollständig erfüllt
• Urgent Timeline (<3 Monate)
• High Pain Level
• C-Level involviert

→ Immediate AE-Übergabe, höchste Priorität Tier 2 SQL (Warm):

• BANT mehrheitlich erfüllt
• Normal Timeline (3-6 Monate)
• Medium Pain
• Decision Maker accessible

→ Standard Sales-Prozess Tier 3 SQL (Cool):

• BANT minimal erfüllt
• Long Timeline (6-12 Monate)
• Low-Medium Pain
• Influencer-Level Contact

→ Extended Nurturing, low-touch

Nutzen:
Sales kann Ressourcen priorisieren – fokussiere auf Tier 1, bearbeite Tier 2 parallel, nurture Tier 3

Der Marketing-Sales-Handoff

Das klassische Problem

Marketing-Perspektive:
"Wir generieren 500 MQLs pro Monat – Sales contacted nur 100!"

Sales-Perspektive:
"Marketing schickt uns Müll-Leads – 80% sind nicht erreichbar oder nicht interessiert!"

Die Realität:
Beide haben Recht. Problem ist mangelnde SQL-Definition-Alignment.

Die Lösung: Service Level Agreement (SLA)

Was ist ein SLA?
Schriftliche Vereinbarung zwischen Marketing und Sales über:

1. Was ist ein SQL? (Definition)
2. Wie viele SQLs liefert Marketing? (Quantität)
3. Wie schnell kontaktiert Sales SQLs? (Response Time)
4. Was passiert bei Disqualifikation? (Prozess)

Beispiel-SLA:

SQL-Definition:
Lead erfüllt:

• ICP-Match (50-500 MA, SaaS/Tech)
• Behavioral Score >50 (Pricing-Visit + 2 Content-Downloads)
• Job Title: VP+ oder Director in Sales/Marketing
• Region: DACH

Marketing committet:

• 100 SQLs pro Monat
• 70%+ davon erreichbar (valide Email/Phone)
• Übergabe via CRM mit Kontext (welche Assets downloaded, etc.)

Sales committet:

• Kontakt innerhalb 24h (Business Hours)
• Minimum 3 Kontaktversuche (Email, Phone, LinkedIn)
• Feedback bei Disqualifikation (Grund dokumentieren)
• SQL-zu-Opportunity Conversion >15%

Review:
Monatliches Meeting – Was funktioniert? Was muss angepasst werden?

Übergabe-Prozess optimieren

Step 1: Automatisierte Zuweisung

Lead wird SQL → CRM-Workflow triggered:

1. Lead-Status update: MQL → SQL
2. Assignment an zuständigen SDR/BDR (Round-Robin oder Territory-based)
3. Slack/Email-Notification: "Neuer SQL: [Name, Company, Context]"
4. Task creation: "Contact SQL within 24h"

Step 2: Context-Übergabe

Marketing übergibt nicht nur Lead, sondern Kontext:

• Welche Content-Pieces konsumiert?
• Welche Seiten besucht?
• Welche Emails geklickt?
• Campaign-Source?
• Behavioral Score?

Beispiel:
"Sarah Müller, Marketing Manager bei Acme Corp (200 MA)

• Downloaded: E-Book 'B2B Lead Gen'
• Attended: Webinar 'Sales & Marketing Alignment'
• Visited: Pricing Page (3x)
• Score: 68/100
• Source: LinkedIn Ad Campaign"

→ SDR weiß SOFORT, wie Gespräch zu führen ist

Step 3: SDR Qualifying Call

SDR kontaktiert SQL für Discovery Call:

• BANT verifizieren
• Pain deep-diven
• Next Steps klären

Outcome:

• Confirmed SQL: Übergabe an AE
• Not Ready: Zurück zu Marketing für Nurturing
• Disqualified: Lost + Reason dokumentieren

Step 4: AE-Übergabe

Wenn SQL bestätigt:

1. SDR scheduled Meeting mit AE + SQL
2. SDR übergibt internen Context (BANT-Notes, Pain-Points, Stakeholder)
3. AE führt Demo/Deep-Dive
4. Opportunity Creation

Feedback-Loop schließen

Problem ohne Feedback:
Marketing weiß nicht, was aus SQLs wird → kann nicht optimieren

Lösung: Sales dokumentiert in CRM:

• SQL accepted/rejected?
• Reason für Rejection (Wrong ICP, No Budget, No Response, etc.)
• Outcome (Opportunity Created, Won, Lost)

Marketing analysiert:

• Welche Channels generieren beste SQLs?
• Welche Content-Pieces korrelieren mit Conversion?
• Welche Kampagnen produzieren Müll-Leads?

Monatlicher Review:
Marketing + Sales sitzen zusammen:

• SQL-Volumen: Target erreicht?
• SQL-Qualität: Acceptance Rate? Conversion Rate?
• Process: Was läuft gut? Was muss geändert werden?

Kontinuierliche Iteration:
SQL-Definition ist nicht in Stein gemeißelt – passe an basierend auf Learnings

SQL-Conversion: Die Metrik, die zählt

Die 3 kritischen Conversion-Raten

1. MQL → SQL Conversion

Formel:
(Anzahl SQLs / Anzahl MQLs) × 100

Benchmark:

• Gut: 10-25%
• Durchschnitt: 5-15%
• Schlecht: <5%

Was beeinflusst:

• MQL-Qualität (besseres Scoring = höhere Conversion)
• SDR-Qualität (besseres Qualifying = mehr SQLs identifiziert)
• SQL-Definition (striktere Definition = niedrigere Rate)

Zu niedrig (<5%):
Marketing sendet schlechte MQLs ODER SQL-Definition zu strikt

Zu hoch (>30%):
SQL-Definition zu locker ODER MQL-Bar zu hoch

2. SQL → Opportunity Conversion

Formel:
(Anzahl Opportunities / Anzahl SQLs) × 100

Benchmark:

• Gut: 40-60%
• Durchschnitt: 25-40%
• Schlecht: <25%

Was beeinflusst:

• SQL-Qualität (besser qualifiziert = höhere Conversion)
• AE-Skills (bessere Discovery/Demo = mehr Opportunities)
• Product-Market-Fit

Zu niedrig (<25%):
SQLs sind nicht wirklich qualifiziert ODER AEs verkaufen schlecht

3. SQL → Customer Conversion

Formel:
(Anzahl Customers / Anzahl SQLs) × 100

Benchmark:

• Gut: 20-40%
• Durchschnitt: 10-25%
• Schlecht: <10%

Was beeinflusst:

• Gesamte Sales-Performance
• Product-Market-Fit
• Pricing
• Competition

End-to-End-Beispiel:

1000 MQLs
→ 150 SQLs (15% Conversion)
→ 60 Opportunities (40% von SQLs)
→ 20 Customers (33% von SQLs, 13% von Opportunities)

Bedeutet:
Du brauchst 50 MQLs für 1 Customer (2% Overall Conversion)

SQL-Velocity: Geschwindigkeit zählt

Was ist SQL-Velocity?
Zeit von SQL-Creation bis zur ersten Sales-Aktivität

Benchmark:

• Exzellent: <1h
• Gut: 1-4h
• Akzeptabel: 4-24h
• Schlecht: >24h

Warum wichtig? Lead Response Time Impact:

Response Time	Qualifizierungs-Wahrscheinlichkeit
<5 Min	100x höher als nach 30 Min
<1h	7x höher als nach 2h
<24h	60x höher als nach 48h

Realität: Der erste Vendor, der antwortet, hat 30-50% höhere Chance zu gewinnen Wie optimieren: Automation:

• Instant-Notification bei SQL-Creation
• Auto-assigned to available SDR
• First-Response-Email automatisch

Process:

• SDRs checken Queue alle 30 Min
• Priorisiere Inbound SQLs über Outbound
• Klare Response-Time-Targets (z.B. <2h)

SQL-Best-Practices

1. Co-Create SQL-Definition

Nicht: Marketing definiert alleine
Nicht: Sales definiert alleine

Sondern: Gemeinsamer Workshop

Agenda:

1. ICP definieren (gemeinsam)
2. BANT-Kriterien festlegen (was ist "Budget approved"?)
3. Scoring-System entwickeln (welche Punkte wofür?)
4. Pilot testen (100 Leads als Test)
5. Review & Adjust (nach 30 Tagen)

Output: Schriftliches Dokument, von beiden Teams unterschrieben

2. Start strikt, locker später

Phase 1 (Monat 1-3): Strikt SQL-Definition

• Nur Leads, die 100% Kriterien erfüllen
• Ziel: Beweise, dass Konzept funktioniert

Phase 2 (Monat 4-6): Locker einige Kriterien

• Teste, ob 80%-Match auch konvertiert
• Optimize basierend auf Data

Warum?
Besser, mit wenigen, guten SQLs zu starten als mit vielen schlechten

3. Multi-Thread SQLs

Problem:
Du qualifizierst Junior Manager als SQL → er kann nicht entscheiden

Lösung:
Frage im Qualifying Call:
"Wer ist außer Ihnen involviert?"

Wenn Decision Maker woanders:
"Macht es Sinn, dass ich [Decision Maker] auch involviere?"

Multi-Threading:

• Erhöht Gewinn-Chance
• Reduziert Single-Point-of-Failure
• Zeigt komplettes Buying Committee

SQL-Definition anpassen:
"SQL = Influencer mit Commitment, Decision Maker zu connecten"

4. Disqualify schnell

Problem:
SDRs halten an schlechten Leads fest (hoffen auf Miracle)

Realität:
Zeit mit schlechtem Lead = verpasste Opportunity mit gutem Lead

Regel:
Nach 3 Kontaktversuchen ohne Response → Disqualify
Nach Discovery Call, wenn BANT nicht erfüllt → Disqualify

Disqualify ≠ Delete:

• Send zurück zu Marketing für Nurturing
• Tag als "Not Now" (vielleicht später)
• Document Reason (für Learnings)

Kosten eines schlechten SQLs:
30 Min SDR-Zeit = 25-50 € Kosten
→ Bei 100 schlechten SQLs = 2500-5000 € verschwendet

5. Dokumentiere alles

In CRM festhalten: Bei SQL-Creation:

• Source (welche Kampagne?)
• Score (wie qualifiziert?)
• Context (was hat Lead gemacht?)

Nach Qualifying Call:

• BANT-Status (jedes Kriterium einzeln)
• Pain-Level (1-10)
• Stakeholder (wer ist involviert?)
• Next Steps (konkret)
• Timeline (wann nächster Call?)

Bei Outcome:

• SQL → Opportunity? Warum/Warum nicht?
• Opportunity → Won/Lost? Warum?
• Learnings (was hätten wir besser machen können?)

Warum wichtig:
Data ermöglicht Optimierung. Ohne Data = nur guessing.

6. Review SQL-Definition quartalsweise

Warum? Markt ändert sich:

• Neue Competitors
• Neue Buyer-Behaviors
• Neue Channels

Dein Produkt ändert sich:

• Neue Features → neue ICP-Segmente
• Pricing-Changes → andere Budget-Kriterien

Review-Fragen:

• Konvertieren unsere SQLs gut?
• Gibt es Muster bei Won/Lost?
• Ist Definition zu strikt/locker?
• Neue Qualifizierungs-Kriterien hinzufügen?

Adjust & Communicate:
Wenn Definition ändert → beide Teams informieren + dokumentieren

Häufige SQL-Fehler

Fehler 1: Keine gemeinsame Definition

Problem:
Marketing und Sales haben unterschiedliche Vorstellungen von "SQL"

Beispiel:
Marketing: "Hat Formular ausgefüllt" = SQL
Sales: "Hat Budget confirmed + Timeline" = SQL

Resultat:

• Sales accepts nur 20% der "SQLs"
• Marketing frustriert ("Sales macht nichts mit unseren Leads!")
• Sales frustriert ("Marketing schickt Müll!")

Lösung:
Schriftliche, gemeinsame SQL-Definition + SLA

Fehler 2: Zu fokussiert auf Volume

Problem:
Marketing-Ziel: "Generiere 500 SQLs pro Monat"
→ Definition wird verwässert, um Target zu erreichen

Resultat:
Viele "SQLs", aber niedrige Conversion

Beispiel:
500 SQLs → 50 Opportunities (10% Conversion) → 10 Customers
vs.
100 SQLs → 40 Opportunities (40% Conversion) → 15 Customers

Besser: Weniger, bessere SQLs

Lösung:
Incentivize auf SQL-to-Customer-Conversion, nicht nur SQL-Volume

Fehler 3: Langsame Response Time

Problem:
SQL kommt rein → SDR contacted erst nach 48h
→ Lead ist kalt, Konkurrenz war schneller

Impact:
Response nach 48h = 50% weniger Conversion als nach <1h

Lösung:

• Instant-Notifications
• Clear Response-Time-Targets (z.B. <4h)
• Dedicated SDR "on duty" für Inbound SQLs

Fehler 4: Kein Feedback-Loop

Problem:
Sales disqualifiziert SQLs, aber sagt Marketing nicht warum

Resultat:
Marketing macht weiter mit schlechten Kampagnen

Beispiel:
Marketing launched LinkedIn-Ad-Campaign
→ Generiert 100 MQLs, 20 SQLs
→ Sales rejects 18 von 20 (Reason: "No Budget")
→ Aber Marketing weiß das nicht
→ Campaign läuft weiter, verschwendet Budget

Lösung:
CRM-Pflicht: Bei Disqualifikation → Reason dokumentieren
Marketing reviewed monatlich Disqualification-Reasons

Fehler 5: SQL = MQL (zu niedrige Bar)

Problem:
Jeder MQL wird automatisch SQL (keine echte Qualifizierung)

Resultat:
SDRs überflutet mit unqualifizierten Leads
→ Frustration, niedrige Conversion, verschwendete Zeit

Lösung:
SQL muss echte Qualifizierung durch Sales bedeuten
→ Discovery Call durchgeführt, BANT verifiziert

Fehler 6: Über-Scoring (alles wird SQL)

Problem:
Scoring-System zu generös
→ 80% der MQLs werden SQLs

Realität:
Wenn 80% SQL werden, ist Definition zu locker

Healthy Benchmark:
10-30% MQL-zu-SQL-Conversion

Wenn >30%:
Entweder MQL-Bar zu hoch (zu wenig MQLs) ODER SQL-Bar zu niedrig

Lösung:
Recalibrate Scoring-System
Teste mit historischen Daten: "Welche SQLs haben tatsächlich gekauft?"

SQL-Tools & Automation

CRM-Systeme

Salesforce:

• Lead-Status-Management (MQL → SQL → Opportunity)
• Lead-Scoring (Einstein Lead Scoring)
• Assignment-Rules (Auto-assign SQLs)
• Dashboards (SQL-Conversion-Tracking)

HubSpot:

• Lifecycle Stages (Subscriber → MQL → SQL → Opportunity → Customer)
• Lead-Scoring (Behavioral + Demographic)
• Workflows (Auto-SQL-Creation bei Score-Threshold)
• Reporting (Funnel-Analytics)

Pipedrive:

• Custom Lead Stages
• Lead-Inbox mit Priorisierung
• Activity-Automation (Auto-task bei SQL-Creation)

Lead-Scoring-Tools

Leadfeeder:
Identifiziert Website-Besucher → Behavioral Scoring

6sense:
AI-basiertes Intent-Scoring (wer ist in Buying-Mode?)

Clearbit:
Enrichment (Firmographic Data) für ICP-Matching

Sales Engagement-Plattformen

Outreach / SalesLoft:

• Automatisierte Sequenzen für SQL-Follow-up
• Response-Tracking
• A/B-Testing von Messaging

Apollo:

• Prospecting + Enrichment
• Automated Outreach
• SQL-Pipeline-Tracking

Zusammenfassung

Ein Sales Qualified Lead (SQL) ist nicht einfach "irgendein Lead" – es ist ein strategisch qualifizierter Kontakt, bei dem Budget, Authority, Need und Timeline verifiziert wurden. Die SQL-Definition ist die kritischste Vereinbarung zwischen Marketing und Sales und entscheidet über Erfolg oder Misserfolg der gesamten Revenue-Engine.

Die 7 SQL-Prinzipien:

1. Co-Create Definition – Marketing & Sales gemeinsam, schriftlich
2. Strict BANT-Verification – Nicht guessing, sondern asking
3. Fast Response – <24h Kontakt, idealerweise <4h
4. Continuous Feedback – Closed-Loop zwischen Marketing & Sales
5. Quality > Quantity – 100 gute SQLs > 500 schlechte
6. Document Everything – Data ermöglicht Optimierung
7. Iterate Quarterly – SQL-Definition ist nicht statisch

Die Wahrheit über SQLs:
Eine perfekte SQL-Definition gibt es nicht. Was zählt: Gemeinsame Vereinbarung, kontinuierliche Messung, ständige Iteration. Teams, die das beherrschen, haben 40-60% höhere Conversion-Raten als solche, die Marketing und Sales im Silo operieren lassen.

Nächster Schritt: Plane ein SQL-Definition-Workshop mit Marketing & Sales. Agenda: ICP, BANT-Kriterien, Scoring-System, SLA. Dokumentiere alles, teste 30 Tage, reviewe und adjustiere.