Die direkte Antwort
Claude Code oder Codex kann einen B2B-Telefon-Lookup steuern. Das Modell sollte aber keine Nummer raten und Profile nicht wahllos scrapen. Beginne mit einem akzeptierten Unternehmen, einer geprüften Rollenhypothese, dem Namen der Person und einer kanonischen LinkedIn-Profil-URL, die nur als Identitätsschlüssel dient. Verbinde den freigegebenen MCP-Server von Leadbase, übergib einen kleinen Batch, wenn Telefon-Lookup für den Workspace aktiviert ist, und erhalte jeden Status: found, not_found, pending oder failed.
Prüfe danach drei getrennte Fragen: Ist das die gemeinte Person? Welche Art Nummer wurde geliefert? Darf dein Team sie im geplanten Land und Kanal verwenden? found bedeutet Verfügbarkeit, nicht aktuelle Inhaberschaft, Rollenrelevanz, Einwilligung oder Anruferlaubnis. Miss Returned Coverage, bestätigte Accuracy, Call-ready Yield, Verbindungen zur richtigen Person, Credits und Review-Zeit, bevor du den Workflow ausweitest.
1. Definiere die Aufgabe präzise
Dieser Guide behandelt genau eine Aufgabe: Nutze Claude Code oder Codex, um Direct-Phone-Daten für bereits qualifizierte B2B-Personen anzufragen, prüfe die Ergebnisse und entscheide, welche Datensätze in eine separate Prüfung der Anrufberechtigung gehen dürfen. Der Ablauf beginnt nach Account-Discovery und Rollenrecherche. Musst du zuerst passende Unternehmen bestimmen, starte mit dem Guide zur ICP-Account-Liste. Ist noch unklar, welche Rolle relevant ist, nutze den Guide zur Buying-Committee-Hypothese.
Vier Begriffe müssen getrennt bleiben:
Der Agent ist nützlich, weil er einen Vertrag konsistent anwenden, ein Tool aufrufen, strukturierte Statuswerte erhalten und Ausnahmen für ein Review vorbereiten kann. Er ist nicht die Quelle der Telefondaten und darf fehlende Werte nicht erfinden. Sowohl Claude Code als auch Codex dokumentieren MCP-Verbindungen zu externen Tools und Daten. MCP stellt dem Agenten die Operation bereit; es macht das Ergebnis nicht automatisch wahr.
2. Beginne mit einem Eligibility-Paket statt einer Namensliste
Eine Person sollte erst in die Lookup-Queue gelangen, wenn dein Team erklären kann, warum es genau diese Person recherchiert. Erstelle vor jedem Telefon-Tool-Aufruf ein kompaktes Eligibility-Paket:
- stabile Zeilen-ID sowie aktuelle Pilot- oder Batch-ID;
- akzeptierter Unternehmensname, kanonische Domain und Version der Account-Entscheidung;
- Rollenhypothese, Review-Status und Evidenz für ihre Relevanz;
- Name der Person und kanonische
linkedin.com/in/...-Profil-URL; - ergänzende Angaben wie Unternehmen, Domain, Titel und Land, soweit bekannt;
- geplanter Kanal und zuständige Person für die nächste Entscheidung;
- frischer Idempotency Key für einen neuen Lookup-Batch.
Die kanonische Profil-URL ist ein Identitätsschlüssel für den Datenservice. Sie ist kein Auftrag, LinkedIn zu crawlen. Die aktuellen LinkedIn-Regeln zum Crawling untersagen automatisiertes Crawling ohne ausdrückliche Erlaubnis und verlangen von autorisierten Crawlern, Zugriffs- und Robots-Vorgaben einzuhalten. Gib einem Agenten keine Session-Cookies, beauftrage ihn nicht mit dem Umgehen von Zugriffsbeschränkungen und behandle ein sichtbares Profil nicht als Erlaubnis, jedes verfügbare Feld zu sammeln.
Lehne eine Zeile vor dem Lookup ab oder halte sie zurück, wenn die Unternehmensentscheidung veraltet ist, die Rolle nur aus Seniorität geraten wurde, das Profil mehrere Personen meinen könnte, die Person offenbar nicht mehr im Unternehmen arbeitet oder der geplante Verwendungszweck keinen Owner hat. Diese Fehler sind vor dem Kauf von Kontaktdaten günstiger zu lösen.
3. Wähle den passenden Beschaffungsweg
Ein agentengesteuerter strukturierter Lookup ist nicht immer die beste Route. Entscheide danach, welchen teuren Fehler du vermeiden musst.
Mache aus dieser Tabelle kein universelles Ranking. Eine Zentrale kann eine Direct-Dial-Datenbank in einem Markt mit schwacher Mobile-Coverage übertreffen. Eine menschlich verifizierte Teilmenge kann sinnvoller sein, wenn eine Telefonbestätigung Pflicht ist. Eine große Suite kann passen, wenn Telefon-Lookup nur ein Teil eines Enterprise-Betriebsmodells ist.
Leadbase passt gut zum engeren Fall dieses Guides, weil das Telefon-Tool nicht isoliert vom List Building arbeitet. Dasselbe System hilft, den Markt zu definieren, Account und Rolle zu qualifizieren und anschließend Claude Code oder Codex den Direct-Phone-Lookup über der Personenliste ausführen zu lassen. Die begrenzte, gemessene Capability und ihre expliziten Status halten diesen End-to-End-Ablauf kontrolliert.
4. Verbinde Claude Code oder Codex über MCP
MCP ist die Verbindungsschicht zwischen dem AI-Client und dem Tool-Katalog von Leadbase. Richte sie einmal anhand der aktuellen Leadbase-MCP-Anleitung ein und prüfe die Verbindung im Client, bevor du Kundendaten verwendest. Die Setup-Seite enthält die aktuellen Befehle für Claude Code und Codex. Nutze sie statt einer möglicherweise veralteten Drittanbieter-Konfiguration.
Lass dir nach der Verbindung die verfügbaren Tools anzeigen und bestätige, dass prospects.find_phone vorhanden ist. Der Kontakt-Lookup benötigt mcp:write; eine reine Leseberechtigung kann ihn ausblenden. Starte keinen Batch, nur weil der MCP-Server antwortet. Prüfe im gleichen System, in dem du testest, Funktionsname, Input-Anforderungen, aktuelle Batch-Grenze, Output-Status und Credit-Regel.
Laut Dokumentation vom 9. August 2026 akzeptiert das MCP-Schema eine bis fünfzig Identitäten pro Anfrage. Das ist die maximale Nutzlast eines einzelnen Low-Level-Aufrufs und nicht die maximale Größe eines Sheets oder kompletten Laufs. Bei 5.000 berechtigten Personen kann der Orchestrator das Sheet seitenweise lesen und mindestens 100 Aufrufe mit je 50 Personen senden; ein niedrigeres aktuelles Limit erzeugt mehr Aufrufe. Aktivierungsstatus, aktive Telefonroute, verfügbare Credits, Rate Limits und das konfigurierte Credit-Limit für Agenten-Batches können eine niedrigere ausführbare Grenze setzen. Ein Owner oder Admin muss direkte Telefonnummern aktivieren, die rechtmäßige geschäftliche Nutzung bestätigen, das Limit setzen und die Verfügbarkeit vor dem Lauf prüfen. Ein gelistetes Tool beweist nicht, dass eine Anfrage ausgeführt werden kann.
Vom Test mit zehn Personen auf 5.000 Sheet-Zeilen skalieren
Der Test mit zehn Personen im CTA dieses Guides ist ein Beweisschritt und kein Volumenlimit. Sobald Identitäts-, Policy-, Status- und Kostenregeln diesen Test bestehen, behältst du denselben Vertrag bei und änderst nur die Queue-Größe. Ein zuverlässiger großer Lauf hat fünf Ebenen:
- Lies das Sheet in einer deterministischen Reihenfolge und wähle nur Zeilen aus, die die schriftliche Eligibility-Regel bestehen.
- Schreibe den Input-Snapshot für die nächste Gruppe mit höchstens 50 Personen oder dem niedrigeren aktuellen Limit fest.
- Erzeuge einen frischen Idempotency Key, sende den Aufruf und halte Request sowie Batch-Reihenfolge fest.
- Schreibe
found,not_found,pendingoderfailedin jede ursprüngliche Zeile zurück, ohne Fehler zu löschen. - Frage nur ausstehende Ergebnisse mit identischem Input und Key erneut ab und fahre danach bei der nächsten unverarbeiteten Zeile fort.
Nenne das nicht eine Anfrage. Bei einer Nutzlast von 50 Personen erzeugen 5.000 berechtigte Zeilen mindestens 100 Capability-Aufrufe. Dubletten und nicht berechtigte Zeilen müssen vorher aus diesem Nenner entfernt werden. Retries und ein niedrigeres aktuelles Limit können die tatsächliche Zahl der Aufrufe erhöhen. Das Zeilen-Ledger und nicht die Aufrufzahl ist die geschäftliche Review-Einheit: Jede berechtigte Person muss am Ende einen sichtbaren endgültigen Status oder zum Stichtag einen ausdrücklich berichteten Pending-Status haben.
Jede Identität benötigt eine kanonische LinkedIn-Profil-URL. Die Antwort behält die Input-Reihenfolge bei und kann found, not_found, pending oder failed liefern. Eine gefundene Telefonnummer verbraucht derzeit fünf Leadbase-Credits. Exakte Wiederholung, No-Result, Pending und Failed verbrauchen nach dem aktuellen Capability-Vertrag keine Credits. Behandle Preise und Verträge als versionierte Produktfakten und prüfe Dokumentation sowie Workspace-Regeln vor jedem formalen Vergleich erneut.
Erstelle für einen neuen Batch einen frischen UUID- oder ULID-Idempotency-Key. Ist ein Ergebnis pending, frage mit exakt gleichem Input und gleichem Key erneut ab. Erzeuge nicht für jeden Poll einen neuen Key: Aus einer Operation können sonst mehrere werden und dein Audit-Trail geht verloren. Verwende den Key ebenso wenig für andere Identitäten.
5. Gib dem Agenten eine Non-Guessing-Anweisung
Der Prompt muss Eligibility, Tool-Auswahl, Batching, Idempotenz, Output-Felder und Stop-Regeln definieren. Ebenso wichtig ist, was der Agent nicht ableiten darf. Der folgende Prompt ist bewusst streng. Passe Feldnamen an dein Sheet oder Ledger an.
Dieser Prompt beauftragt das Modell nicht zu entscheiden, ob eine Telefonnummer rechtlich genutzt werden darf. Er beauftragt es mit einer definierten Abrufoperation und der Vorbereitung einer strukturierten Review-Queue. Halte Eligibility-Regeln in Datenfeldern und nicht nur in Prosa fest, damit das Review erkennen kann, warum eine Zeile in den Batch kam oder ausgeschlossen wurde.
Bitte den Agenten beim ersten Lauf, vor dem Tool-Aufruf die geplante Zeilenanzahl und eine redigierte Input-Zusammenfassung zu zeigen. So kannst du eine versehentlich zu breite Auswahl, fehlenden Länderkontext oder wiederholte Identitäten zuletzt prüfen. Ein vollständig autonomer Bulk-Run ist kein guter erster Test, weil ein technisch valider Aufruf dennoch die falsche Queue verarbeiten kann.
6. Plane vor dem Lookup einen begrenzten Pilot
Nutze für den ersten operativen Pilot fünf bis vierzig akzeptierte Identitäten nur dann, wenn diese Zahl in das bestätigte Workspace-Credit-Limit und die übrigen aktuellen Grenzen passt. Nutze sonst den niedrigeren zulässigen Batch. Beginne nicht mit einem beliebigen Export aller gefundenen Personen. Mische Zielländer und Rollentypen nur, wenn du sie getrennt auswertest. Veröffentlichst du bei gemischten Märkten nur eine Gesamtrate, kann ein starkes Segment ein schwaches verdecken.
Das folgende Planungsmodell vergleicht zwei von dir definierte Szenarien: Lookup aller Kandidaten oder vorherige Qualifizierung von Account und Rolle. Die Found-Rate ist eine Annahme und kein Leadbase-Benchmark. Die Credit-Berechnung nutzt standardmäßig die derzeitigen fünf Credits pro gefundener Nummer. Ändere den Wert, wenn sich der Produktvertrag ändert.
Qualifikationsbasierte Telefon-Lookup-Arbeitslast planen
Schätze Lookup-Volumen und Credit-Bedarf, wenn ein Agent alle Kandidaten oder nur Personen nach bestandener Account- und Rollenprüfung einreicht.
Die Fundrate ist eine Annahme und kein Leadbase-Benchmark. Qualifikation kann die tatsächliche Fundrate verändern, und ein gefundenes Ergebnis kann trotzdem irrelevant, falsch oder für den geplanten Anruf unbrauchbar sein.
Unter diesen Annahmen gelangen 2.000 Personen in den Telefon-Lookup und ungefähr 1.200 Ergebnisse werden gefunden. Gegenüber dem Einreichen aller Kandidaten vermeidet das Szenario 9.000 Credits.
| Metrik | Jeden Kandidaten nachschlagen | Vor dem Lookup qualifizieren |
|---|---|---|
| Erwartete eingereichte Telefon-Lookups | 5.000 | 2.000 |
| Geschätzte gefundene Ergebnisse | 3.000 | 1.200 |
| Geschätzte Credits | 15.000 | 6.000 |
Beide Szenarien nutzen dieselbe angenommene Fundrate und dieselben Credits pro gefundenem Ergebnis. Nur die Zahl der eingereichten Personen ändert sich.
Beim Lookup zuerst wird jede Kandidaten-Person berücksichtigt. Bei vorheriger Qualifikation wird die Kandidatenzahl mit der Account- und Rollen-Akzeptanzrate multipliziert. Erwartete Einreichungen, Funde und Credits behalten eine Nachkommastelle. Ein Capability-Aufruf enthält höchstens 50 ganze Personen, doch der Sheet-Workflow kann begrenzte Aufrufe über die vollständige Queue wiederholen. Bei 50 pro Aufruf benötigen 5.000 berechtigte Personen mindestens 100 Aufrufe.
Das ist Planungsrechnung, keine gemessene Abdeckung, Genauigkeit, Ersparnis oder Anruferlaubnis. Nutze einen festgeschriebenen Pilot und die Scorecard nach dem Lauf, um jede Annahme durch beobachtete Zahlen zu ersetzen.
Der Planner schätzt Arbeitslast. Er kann Datenrichtigkeit, Anrufberechtigung oder Verbindungen nicht vorhersagen. Nutze ihn zur Dimensionierung von Queue und Review-Kapazität. Veröffentliche die geschätzte Found-Zahl nicht als Produktergebnis.
Friere vor der Ausführung diese Pilotentscheidungen ein:
- berechtigte Länder, Unternehmenssegmente und Rollenfamilien;
- exakt erforderliche Felder der Personenidentität;
- Start- und Enddatum des Lookups;
- zuständige Person und zulässige Evidenz für die Identitätsprüfung;
- Owner der Call-Eligibility- und Sperrlistenprüfung;
- maximale Credits und Review-Stunden;
- minimale Stichprobe vor einer Entscheidung;
- Retest-Trigger und Termin.
Ein Pilot ohne festen Nenner lässt sich leicht schönrechnen. Erhalte jede übergebene Identität einschließlich No-Results und Fehler. Entfernst du sie nachträglich, steigen Coverage und sinken Kosten pro nutzbarem Datensatz künstlich.
7. Interpretiere die vier Lookup-Status korrekt
Der Antwortstatus sagt, was die Operation geliefert hat, nicht was in der Welt existiert.
Fasse not_found und failed niemals zusammen. Sie beantworten verschiedene Fragen und erzeugen andere Reparaturarbeit. Zähle ein Pending in einem zeitlich begrenzten Pilot ebenso wenig als gefunden. Weise es zum Entscheidungsstichtag als ungelöst aus.
Enthält ein Batch sowohl finale als auch ausstehende Ergebnisse, erhalte die Statuswerte auf Item-Ebene. Blockiere die Prüfung valider Found-Ergebnisse nicht endlos wegen der übrigen Zeilen. Schließe Pending-Zeilen aber auch nicht nur, damit die Tabelle aufgeht. Nenne das Beobachtungsfenster im Pilotbericht.
8. Prüfe Identität, Nummerntyp und Qualität getrennt
Das öffentliche Leadbase-Ergebnisschema unterstützt eine E.164-formatierte Nummer, einen Typ mobile, direct, work oder unknown und ein Qualitätslabel verified, likely oder unknown. Prüfe die Werte, die die aktive Route tatsächlich liefert. Vom Schema unterstützte Vielfalt bedeutet nicht, dass jede Route oder jeder Pilot jeden Typ enthält. Diese Felder sind hilfreich, aber nicht austauschbar.
Prüfe zuerst die Identität: Entspricht der zurückgegebene Datensatz der gemeinten Person im akzeptierten Unternehmen und in der relevanten Rolle? Nutze die übergebene Profil-URL und aktuelle ergänzende Angaben. Eine korrekte Nummer einer ehemaligen Person im Unternehmen ist für diesen Workflow kein korrektes Ergebnis.
Prüfe danach den Nummerntyp: Mobilnummer, direkte geschäftliche Durchwahl, allgemeine geschäftliche Nummer und unbekannter Typ schaffen unterschiedliche Erwartungen und können unter unterschiedliche interne Regeln fallen. Beschrifte eine unbekannte Nummer nicht still als mobil, nur weil die Vorwahl so wirkt. Nummernpläne und Portierung machen diese Ableitung unsicher.
Prüfe zuletzt die Qualität: Behandle das gelieferte Label als Input für die Bewertung und nicht als Garantie. Frage, was das Label abdeckt und wann die zugrunde liegende Prüfung stattfand. verified beweist allein weder aktuelle Inhaberschaft noch aktuelle Rolle, Anruferlaubnis oder Verbindung zur richtigen Person.
Nutze mindestens vier Review-Ergebnisse für Found-Datensätze:
- bestätigt korrekt: Evidenz stützt die Beziehung zwischen gemeinter Identität und Nummer nach der Testdefinition;
- bestätigt falsch: Evidenz belegt falsche Person, falsches Unternehmen oder falsche Nummernbeziehung;
- unklar: Das Review kann den Fund innerhalb der zulässigen Methode weder bestätigen noch widerlegen;
- nicht geprüft: Ein Found-Ergebnis ist noch nicht bewertet und darf nicht als korrekt zählen.
Bestätigte Accuracy berechnet sich aus bestätigt korrekt geteilt durch bestätigt korrekt plus bestätigt falsch. Zeige unklare Ergebnisse separat. Wer jeden nicht widerlegten Fund als korrekt zählt, belohnt ein schwaches Review.
9. Führe einen fiktiven Batch vom Input bis zur Entscheidung durch
Das folgende Beispiel ist fiktiv. Es zeigt Statuswerte und Entscheidungen, keine Leadbase-Performance.
Angenommen, ein Team hat vierzig plausible Personen aus zwanzig akzeptierten Accounts. Account- und Rollenreview lassen vierundzwanzig Personen zum Telefon-Lookup zu. Der Agent übergibt sie mit einem frischen Idempotency Key in einem begrenzten Batch. Vierzehn kommen als Found zurück, sechs als Not Found, zwei bleiben zum Review-Stichtag Pending und zwei schlagen fehl.
Das Review bestätigt neun richtige Identitäten und zwei falsche. Drei Found-Ergebnisse bleiben unklar. Sieben der neun korrekten Datensätze bestehen die separate Länder-, Kanal-, Zweck- und Sperrlistenprüfung. Das Team versucht sechs Anrufe und erreicht zweimal die gemeinte Person.
Der richtige Bericht sagt nicht „58 Prozent genau“, weil vierzehn von vierundzwanzig eine Nummer geliefert haben. Das ist die Returned Coverage: 14 / 24. Bestätigte Accuracy ist 9 / (9 + 2). Der Anteil unklarer Fund-Ergebnisse ist 3 / 14. Call-ready Yield ist 7 / 24. Die Right-Person-Connection-Rate unter Versuchen ist 2 / 6. Jede Kennzahl beantwortet eine andere operative Frage. Operativ ungelöste Arbeit ist breiter: Dazu gehören auch Pending und noch nicht geprüfte Datensätze.
Die zwei fehlerhaften Datensätze bleiben Failed. Pending bleibt zum Stichtag Pending. Die drei unklaren Found-Datensätze bleiben ungelöst. Das sieht weniger glatt aus als eine einzige „Erfolgsrate“, zeigt aber, welcher Teil des Workflows repariert werden muss.
10. Eine gefundene B2B-Nummer ist nicht automatisch anrufbar
Telefonverfügbarkeit und erlaubte Nutzung sind getrennte Entscheidungen. Dieser Guide kann deine Rechtsgrundlage, Einwilligungslage, lokalen Werberegeln, Sperrpflichten oder die Angemessenheit eines konkreten Anrufs nicht bestimmen. Deine zuständige Rechts- oder Datenschutzfunktion muss Regeln für Land, Empfänger, Zweck und Kanal festlegen.
Halte mindestens Zweck, Datenquellenkategorie, Land, geplanten Kanal, Sperrlistenergebnis, Owner und Entscheidungsdatum fest. Art. 5 DSGVO verlangt unter anderem Rechtmäßigkeit, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung und Rechenschaftspflicht bei der Verarbeitung personenbezogener Daten. Der offizielle Text von Art. 5 DSGVO ist eine Quelle zu Grundsätzen und keine Erlaubnis für einen konkreten Anruf.
Länderregeln können engere Gates hinzufügen. In Deutschland behandelt § 7 UWG Telefonwerbung gegenüber sonstigen Marktteilnehmern ohne zumindest mutmaßliche Einwilligung als unzumutbare Belästigung. Eine gefundene Geschäftsnummer belegt diese einzelfallabhängige Vermutung nicht. Im Vereinigten Königreich erläutert die B2B-Marketing-Anleitung des ICO Prüfpflichten für Live-Calls, darunter TPS/CTPS und die eigene Do-not-call-Liste sowie Identifikations- und Kontaktdatenpflichten.
Diese Beispiele zeigen, warum eine globale Regel callable=true unsicher ist. Ein gutes System übergibt einen Fund in einen länderbezogenen Entscheidungsprozess. Es leitet Erlaubnis nicht aus Verfügbarkeit ab. Nutze den Guide zu DSGVO-bewusstem Outbound für das umfassendere Betriebsmodell und lass erhebliche Unsicherheit fachlich prüfen.
11. „Leads mit Claude Code scrapen“ ist der falsche Betriebsvertrag
Menschen suchen nach Formulierungen wie „Leads mit Claude Code scrapen“ oder „LinkedIn-Leads mit Codex scrapen“. Der Satz vermischt jedoch mehrere Aufgaben: Accounts entdecken, Rollen identifizieren, Kontaktdaten abrufen und Outreach aktivieren. Ein verlässlicher Workflow trennt sie.
Claude Code und Codex können freigegebene Tools aufrufen, autorisierte Dateien transformieren und Review-Queues vorbereiten. Das erlaubt dem Agenten nicht, Zugriffskontrollen einer Website zu umgehen, eine authentifizierte Session zu automatisieren, Quellenbedingungen zu ignorieren oder mehr personenbezogene Daten als für den Zweck nötig zu sammeln. Erlaubt eine Quelle keine automatisierte Erhebung, ändert ein AI-Agent diese Grenze nicht.
Der sicherere Prompt lautet nicht „Scrape alle Entscheider und Mobilnummern“. Er lautet: „Nutze für diese akzeptierten Zeilen diese freigegebene Telefon-Lookup-Funktion, erhalte explizite Statuswerte und stoppe vor der Aktivierung.“ Das ist auch technisch besser: Der strukturierte Vertrag produziert reproduzierbare Inputs, begrenzte Batches, maschinenlesbare Ausnahmen und messbare Kosten.
12. Halte ein Ledger, das ein Review übersteht
Lade das B2B-Agent-Telefon-Lookup-Ledger herunter. Es enthält fiktive Zeilen für Found, Not Found, Pending, Failed, falsche Person und unklare Fälle. Ersetze sie durch deine Testdaten und erhalte den ursprünglichen Nenner.
Das Ledger trennt bewusst:
- Account- und Rollenberechtigung von Telefonverfügbarkeit;
- übergebene Identität von zurückgegebenen Telefonfeldern;
- Lookup-Status von menschlicher Identitäts- und Nummernprüfung;
- ein kontrolliertes
adjudication_outcome– bestätigt korrekt, bestätigt falsch, unklar, nicht geprüft oder nicht anwendbar – aus den getrennten Identitäts- und Nummernprüfungen; - gefundene Daten von Call Eligibility und Sperrlistenstatus;
- Lookup-Credits von Review-Minuten;
- Anrufversuch von der Verbindung zur richtigen Person.
Nutze eine Zeile je übergebener Identität und halte die stabile Zeilen-ID über den Workflow hinweg. Der Idempotency Key gehört zum exakten Lookup-Batch und ist keine dauerhafte Personen-ID. Beschränke den Zugriff auf zurückgegebene Telefonnummern und lege reale personenbezogene Daten nicht in öffentliche Beispiele, Tickets oder Prompts für nicht freigegebene Systeme.
Ergänze für einen formalen Vergleich Anbieter, Produkt, Tarif, Testdatum und eingefrorene Akzeptanzdefinition in einer eigenen Pilot-Zusammenfassung. Vergleiche nicht die rohe Found-Rate eines Tools mit der bestätigten Accuracy eines anderen. Nutze dieselben Identitäten, dieselbe Review-Methode, dasselbe Beobachtungsfenster und dasselbe Kostenmodell.
13. Bewerte das Ergebnis, das Sales tatsächlich nutzen kann
Die folgende interaktive Scorecard verwendet deine beobachteten Zahlen. Sie prüft, dass Found, Not Found, Pending und Failed zusammen Submitted ergeben, dass Found gleich korrekt plus falsch plus unklar plus nicht geprüft ist, dass Call-eligible nicht größer als bestätigt korrekt wird und dass Verbindungen nicht größer als Versuche sind. Nutze ausschließlich das zusammengesetzte adjudication_outcome im Ledger für diese vier Found-Zahlen. Die Kostenmetrik enthält Lookup-Credits und Review-Zeit, aber keinen nachgelagerten Anrufbetrieb.
Pilot für direkte Telefonnummern auswerten
Trage beobachtete Pilotzahlen ein, um gelieferte Abdeckung, Genauigkeit der Personenzuordnung, ungeklärte Ergebnisse, Anruffreigabe, Verbindungsergebnisse und Lookup-und-Review-Kosten zu trennen.
Den rechnerischen Wert pro Credit legst du fest. Enthaltene Plan-Credits, marginale Overage-Credits, Prüfzeit und nachgelagerte Anrufkosten sind unterschiedliche Kostenarten.
Die gelieferte Abdeckung beträgt 62,5%; die bestätigte Genauigkeit der Personenzuordnung beträgt 85,7%. 15 Datensätze bestanden die getrennte Prüfung zur Anruffreigabe, und 7 Versuche erreichten die richtige Person.
| Metrik | Ergebnis | Definition |
|---|---|---|
| Gelieferte Abdeckung | 62,5% | Gefundene Ergebnisse ÷ eingereichte Lookups |
| Bestätigte Genauigkeit der Personenzuordnung | 85,7% | Bestätigt richtige Person ÷ (bestätigt richtige Person + bestätigt falsch) |
| Anteil unklarer Fund-Ergebnisse | 16% | Unklare Fund-Ergebnisse ÷ gefundene Ergebnisse |
| Für Anruf nutzbare Ausbeute | 37,5% | Für Anruf freigegeben ÷ eingereichte Lookups |
| Rate erreichter richtiger Personen | 58,3% | Erreichte richtige Personen ÷ Anrufversuche |
| Kosten des Lookup-und-Review-Piloten | 98,75 € | Credits × Credit-Wert + Prüfminuten ÷ 60 × Stundensatz |
| Lookup-und-Review-Kosten pro für Anruf freigegebenem Datensatz | 6,58 € | Kosten des Lookup-und-Review-Piloten ÷ für Anruf freigegebene Datensätze |
| Lookup-und-Review-Kosten pro erreichter richtiger Person | 14,11 € | Kosten des Lookup-und-Review-Piloten ÷ erreichte richtige Personen |
Jeder eingereichte Lookup bleibt als gefunden und geprüft, gefunden aber nicht geprüft, nicht gefunden, ausstehend oder fehlgeschlagen sichtbar. Ein gefundenes Ergebnis gilt erst als korrekt, wenn die Identitätsprüfung es bestätigt.
Die Abdeckung nutzt eingereichte Lookups. Die bestätigte Genauigkeit schließt unklare und nicht geprüfte Ergebnisse aus, weist beide aber getrennt aus. Die für Anruf nutzbare Ausbeute nutzt jeden eingereichten Lookup. Die Verbindungsrate nutzt tatsächliche Anrufversuche. Kosten des Lookup-und-Review-Piloten sind Credits mal eingetragener Credit-Wert plus Prüfminuten mal Stundensatz geteilt durch 60; Anrufbetrieb und andere nachgelagerte Kosten sind ausgeschlossen.
Die Scorecard belegt weder statistische Signifikanz noch Aktualität, rechtliche Zulässigkeit, Einwilligung, mutmaßliche Einwilligung oder die Überlegenheit eines Anbieters. Bewahre zeilenbezogene Evidenz auf und berichte Segment, Daten, Definitionen und ungeklärte Fälle neben den Metriken.
Nutze diese Formeln im schriftlichen Pilotbericht:
- Returned Coverage = Found / Submitted;
- bestätigte Accuracy = bestätigt korrekt / (bestätigt korrekt + bestätigt falsch);
- Anteil unklarer Fund-Ergebnisse = unklar / Found;
- Call-ready Yield = Call-eligible / Submitted;
- Right-Person-Connection-Rate = Connected / Attempted;
- Kosten des Lookup-und-Review-Piloten = verbrauchte Credits × interner Credit-Wert + Review-Stunden × Vollkostenstundensatz;
- Lookup-und-Review-Kosten je Call-eligible-Datensatz = Kosten des Lookup-und-Review-Piloten / Call-eligible;
- Lookup-und-Review-Kosten je Verbindung zur richtigen Person = Kosten des Lookup-und-Review-Piloten / Connected.
Ist ein Nenner null, gib „nicht verfügbar“ und nicht null Prozent aus. Eine Kampagne ohne Anrufversuche hat keine beobachtete Connection-Rate. Ein Pilot ohne bestätigt korrekte oder bestätigt falsche Datensätze hat keine bestätigte Accuracy. Diese Trennung verhindert, dass fehlende Evidenz wie schlechte oder perfekte Performance aussieht.
Brich Ergebnisse nur dann nach Land, Rollenfamilie und Nummerntyp herunter, wenn jedes Segment genug Beobachtungen für eine sinnvolle Aussage hat. Beschrifte die Ansicht sonst als explorativ. Behaupte nicht, dass ein kleiner Pilot spätere Kampagnenergebnisse vorhersagt.
14. Nutze Fehleranalyse für den nächsten Batch
Jedes schwache Ergebnis braucht eine andere Reparatur:
„Repariere“ einen enttäuschenden Pilot nicht, indem du schwierige Zeilen löschst oder die Definition von korrekt erweiterst. Dokumentiere den Fehler, ändere eine materielle Variable und führe einen neuen versionierten Batch aus. Erhalte das alte Ergebnis, damit dein Team die Wirkung sehen kann.
Definiere einen Retest-Trigger statt einer universellen Ablaufzusage. Ein neues Land, eine veränderte Rollenfamilie, eine wesentliche Produktvertragsänderung, eine veraltete Personenidentität oder wiederholt falsche Personen sollten einen neuen Test auslösen. Das passende Intervall hängt von Volatilität und Entscheidungskosten ab.
Gib dem Agent einen Tool-Vertrag, keinen Blankoscheck
„Finde Telefonnummern im Web“ ist ein unsicherer und nicht reproduzierbarer Agent-Auftrag. Leadbase verändert die Aufgabe. Claude Code oder Codex erhält eine enge MCP-Funktion für identifizierte Personen, einen begrenzten Batch, explizite Ergebniszustände, Wiederholungsregeln und gemessene Found-Ergebnisse. Der AI-Client koordiniert die Operation; er erhält weder die Erlaubnis, Identitäten zu erfinden, noch aus einer plausiblen Nummer eine Outbound-Aktion zu machen.
Die Kontrollschicht: Leadbase macht Direct-Phone-Lookup zu einer typisierten Operation, die dein Agent ausführen und dein Team prüfen kann – nicht zu einem offenen Scraping-Auftrag.
Der kommerzielle Vorteil ist kein unbelegtes Versprechen, Leadbase habe immer die meisten Telefonnummern. Dein Agent kann den vollständigen Weg von einer qualifizierten Personen-Queue zu Direct-Phone-Ergebnissen über tausende Zeilen ausführen, statt den Prozess nur zu erklären oder dich an einen weiteren Anbieter-Workflow zu verweisen. Bekannte Identität hinein, ein expliziter Status pro Person heraus und Kosten nur für Found-Ergebnisse sind die Kontrollen unter diesem Resultat. Deine Queue-Regel und das menschliche Review entscheiden weiterhin über den nächsten Schritt; Leadbase hat in diesem Workflow keine Outbound-Call-Aktion.
Erstelle einen Workspace und bestätige die Verfügbarkeit des Telefon-Lookups, wenn diese Grenze zu deinem Workflow passt. Sprich mit Sales, bevor du einen Batch zusagst, wenn du Aktivierung, aktuelle Limits, länderspezifische Review-Felder oder eine Übergabe für dein bestehendes System of Record klären musst.
Wann Leadbase nicht besser passt
Wähle einen anderen Weg, wenn deine eigentliche Anforderung außerhalb dieses Workflows liegt:
- Wähle einen Service mit menschlicher Telefonverifikation, wenn vor der Lieferung zwingend ein dokumentierter Right-Person-Call-Check nötig ist.
- Wähle eine ausgereifte Enterprise-GTM-Suite, wenn native CRM-Governance, proprietärer Intent, breite Integrationen, Procurement-Nachweise und zentrale Administration wichtiger als ein fokussierter MCP-Workflow sind.
- Wähle eine Browser-Erweiterung, wenn eine Person nur gelegentlich einen einzelnen Datensatz im Browser aufdecken muss und kein wiederholbares Agent-Ledger braucht.
- Nutze eine offizielle Unternehmenszentrale oder lokale Recherche, wenn Direct-Phone-Coverage gering oder der Unternehmensweg angemessener ist.
- Führe gar keinen Telefon-Lookup aus, wenn Account, Rolle, Zweck oder Entscheidung zur erlaubten Nutzung nicht bereit sind.
Dieser Contrary-Fit-Test gehört zur Kaufentscheidung. Ein fokussiertes Tool ist nur dann wertvoll, wenn die fokussierte Aufgabe tatsächlich der Engpass ist.
Was dieser Guide nicht behauptet
Dieser Guide behauptet nicht, dass Leadbase die größte Datenbank, höchste Coverage, beste Accuracy, niedrigsten Gesamtkosten oder exklusiven Zugriff auf MCP oder Direct Phones hat. Er behauptet nicht, dass jede gelieferte Nummer eine Mobilnummer, menschlich verifiziert, aktuell im Besitz der gemeinten Person oder rechtmäßig anrufbar ist. Die fiktiven Beispiele sind keine Performance-Evidenz.
Ebenso wenig wird behauptet, Claude Code oder Codex entdecke selbstständig private Telefondaten. Der AI-Client koordiniert ein dokumentiertes externes Tool. Die Ergebnisqualität hängt von übergebener Identität, Anbieter-Coverage, aktuellem Produktvertrag, Review-Definition, Beobachtungsdatum und Aktivierungsregeln ab.
Fakten und Links in diesem Guide wurden am 9. August 2026 geprüft. Prüfe MCP-Setup, Vertrag von prospects.find_phone, Credit-Regel, Plattformbedingungen und Länderanleitungen vor einem wesentlichen Rollout erneut.
Abschluss-Checkliste
- Der Account ist nach einer schriftlichen und aktuellen Regel akzeptiert.
- Die Rolle ist durch account-spezifische Evidenz belegt.
- Das kanonische Profil identifiziert die gemeinte Person.
- Für jeden neuen Batch wird ein frischer UUID oder ULID verwendet.
- Pending wird nur mit identischem Input und Key gepollt.
- Found, Not Found, Pending und Failed bleiben getrennt.
- Identität, Nummerntyp und Qualität werden separat geprüft.
- Eine gefundene Nummer wird nie automatisch Call-eligible.
- Länder-, Kanal-, Zweck- und Sperrlistenprüfung haben einen Owner.
- Coverage, bestätigte Accuracy, Anteil unklarer Fund-Ergebnisse, Pending und nicht geprüfte Datensätze, Call-ready Yield, Verbindungen, Credits und Review-Zeit werden getrennt berichtet.
- Abgelehnte und ungelöste Zeilen bleiben in Nenner und Ledger.
- Der nächste Batch ändert eine dokumentierte Variable und erhält das vorige Ergebnis.
