Make.com Workflow zur Leadgenerierung (lokale Daten)

Wenn Sie einen Make.com-Workflow zur Leadgenerierung für lokales Prospecting bauen, ist der Datenbeschaffungs-Schritt der Punkt, an dem die meisten Szenarien unübersichtlich werden. Lokale Betriebe, ihre Websites, Telefonnummern und Kontakt-E-Mails zu finden, bedeutet üblicherweise, Browser-Scraper und Selektoren zu pflegen, die brechen. biz collect gibt Make einen saubereren Weg: Ein HTTP-Modul sendet einen Standort und Stichworte an /v1/search, Sie erhalten eine asynchrone job_id, dann prüft eine Poll-Schleife /v1/jobs/:id, bis das strukturierte JSON bereit ist. Dieser Guide baut ein komplettes Make-Szenario, das lokale Betriebe findet, deduplizierte E-Mails aus ihren Websites extrahiert und die Ergebnisse an Google Sheets, ein CRM oder eine beliebige nachgelagerte App schreibt.

Warum eine API für Leadgenerierung in Make nutzen?

Make (früher Integromat) ist hervorragend im Verbinden von Apps: Trigger, HTTP-Aufrufe, Router, Iteratoren, Aggregatoren, Data Stores und geplante Szenarien. Aber lokale Leadgenerierung hat einen Datenbeschaffungs-Schritt, der brüchig wird, wenn Sie ihn mit Browser-Scraping in Make automatisieren.

Ein typisches "Make Google Maps Scraper"-Setup startet mit einem Headless-Browser-Dienst, einer Such-URL, Selektoren für Listing-Karten und separater Logik, um jede Website zu besuchen und E-Mails zu finden. Das kann für eine Demo funktionieren, aber es erzeugt laufende Wartung. Seitenlayouts ändern sich, Sessions scheitern, Selektoren brechen, und Website-E-Mail-Extraktion wird zum zweiten Scraper, den man betreuen muss. Wägen Sie das gegen eine Daten-API ab, legt der Kompromiss zwischen Google Places API, Scrapern und Firmendaten-APIs die Unterschiede dar.

biz collect ist für die entgegengesetzte Form gebaut. Es ist eine LLM-native Business-Contacts-API, gebaut für Agenten, Workflow-Tools, Skripte und CRM-Anreicherung. Sie rufen /api/v1/search mit Parametern wie location, keywords, radius_km und scrape_emails auf. Die API gibt einen eingereihten Job zurück. Sie pollen /api/v1/jobs/:id, bis er fertig ist, und nutzen dann die zurückgegebenen JSON-Datensätze im Rest Ihres Szenarios.

Das lässt Ihr Make-Szenario sich auf das Routing konzentrieren:

• Suchen nach Zeitplan oder aus einem Webhook laufen lassen.
• Strukturierte lokale Firmendaten von biz collect anfordern.
• Warten und pollen, bis der Async-Job fertig ist.
• Zurückgegebene Betriebe in einzelne Bundles aufteilen.
• Datensätze filtern, deduplizieren oder scoren.
• Qualifizierte Leads an Google Sheets, HubSpot, Pipedrive, Airtable, Notion oder eine andere App senden.

Für API-Details starten Sie mit den API-Docs, Integrationsbeispielen unter Integrationen und Plan-Limits unter Preise. Wollen Sie das asynchrone Suchen-und-Pollen-Modell vor dem Bauen sehen, führt die Seite wie biz collect funktioniert durch denselben Lebenszyklus, den dieses Szenario automatisiert. Makes eigene Dokumentation ist nützlich für die verwendeten Standard-Module, besonders das HTTP-Modul, das Sleep-Tool, den Iterator und das Google Sheets Modul.

Was dieses Szenario baut

Das Szenario in diesem Tutorial automatisiert lokale Leads vom Such-Request bis zur Zielausgabe. Es nutzt Standard-Make-Module, wobei biz collect die Firmensuche und Make die Orchestrierung übernimmt.

Das finale Szenario sieht so aus:

1. Ein Trigger startet das Szenario manuell, nach Zeitplan oder aus einem Webhook.
2. Ein HTTP-Modul sendet einen POST-Request an biz collect /api/v1/search.
3. Die Antwort liefert eine job_id und den Job-Status.
4. Ein Sleep-Modul pausiert kurz vor dem Pollen.
5. Ein zweites HTTP-Modul ruft /api/v1/jobs/:id auf.
6. Ein Router oder Repeater prüft, ob der Job-Status completed ist.
7. Ist er nicht fertig, wartet und pollt das Szenario erneut, mit einem Retry-Limit.
8. Ist er fertig, verwandelt ein Iterator die zurückgegebenen Betriebe in einzelne Bundles.
9. Ziel-Module senden Leads an Google Sheets, ein CRM oder eine andere App.
10. Fehler-Routen handhaben fehlgeschlagene Jobs, Timeouts und leere Ergebnismengen.

Sie können dasselbe Muster für einmaliges Prospecting, wiederkehrende Marktscans, Agentur-Lead-Listen, CRM-Anreicherung oder KI-Agenten-Workflows anpassen, die verifizierte lokale Firmenkontaktdaten brauchen.

Voraussetzungen

Bevor Sie das Szenario bauen, brauchen Sie:

• Ein Make-Konto, auf einem beliebigen Plan, der HTTP-Module erlaubt.
• Einen biz collect API-Key.
• Ein Ziel für die Leads, etwa Google Sheets, HubSpot oder Pipedrive.
• Eine klare Suchdefinition: Standort, Kategorie-Stichworte, Radius und ob E-Mails von Websites extrahiert werden sollen.

biz collect ist gratis zu starten mit 200 Startguthaben und ohne Kreditkarte. Das reicht, um kleine Prospecting-Jobs zu bauen, zu testen und zu laufen, bevor Sie das Szenario auf einen Produktionszeitplan setzen. Prüfen Sie Preise für die aktuellen Plan-Limits.

Datenfluss und API-Form

biz collect nutzt einen Async-Job-Flow, weil lokale Firmensuche und Website-E-Mail-Extraktion länger dauern können als ein normaler synchroner HTTP-Request. Make handhabt das gut, weil Szenarien schlafen, verzweigen und wiederholen können.

Der Basis-Request ist ein POST an:

https://bizcollect.dev/api/v1/search

Der Body enthält die lokalen Sucheingaben:

{
  "location": "Manchester, UK",
  "keywords": ["letting agent", "estate agent"],
  "radius_km": 12,
  "scrape_emails": true
}

Die Antwort enthält einen Job-Identifikator. Das Szenario braucht nur die job_id und den Status:

{
  "job_id": "job_123456",
  "status": "queued",
  "poll_url": "/api/v1/jobs/job_123456"
}

Dann pollt Make:

GET https://bizcollect.dev/api/v1/jobs/job_123456

Ist er fertig, enthält das Ergebnis strukturierte Firmensätze:

{
  "job_id": "job_123456",
  "status": "completed",
  "businesses": [
    {
      "name": "Example Lettings",
      "address": "12 High St, Manchester M1 1AA",
      "phone": "+44 161 555 0101",
      "website": "https://examplelettings.co.uk",
      "emails": ["hello@examplelettings.co.uk", "info@examplelettings.co.uk"]
    }
  ]
}

Der Vertrag ist stabil: Suche starten, job_id erhalten, den Job-Endpunkt pollen, dann strukturiertes JSON verarbeiten. Für das massgebliche Schema nutzen Sie die OpenAPI-Referenz in den biz collect Docs.

Schritt 1: Den Trigger erstellen

Beginnen Sie mit dem Trigger, der zu Ihrem Anwendungsfall passt:

• Run once zum Testen und für einmalige Suchen.
• Schedule für wiederkehrendes Prospecting, etwa jeden Montagmorgen.
• Custom Webhook, wenn ein anderes System oder ein Agent eine Suche dynamisch starten soll.

Für eine erste Version laufen Sie das Szenario manuell und hardcodieren Standort und Stichworte im ersten HTTP-Modul. Ist es stabil, ersetzen Sie feste Werte durch Daten aus einem Zeitplan, einem Google Sheet mit Gebieten oder einem Webhook-Payload.

Soll das Szenario dynamische Suchen annehmen, fügen Sie einen Custom-Webhook-Trigger hinzu und senden Sie einen Body wie:

{
  "location": "Zurich, Switzerland",
  "keywords": ["law firm", "tax advisor"],
  "radius_km": 10,
  "scrape_emails": true
}

Dann kann der biz collect Request die eingehenden Webhook-Felder mappen. Halten Sie das erste Szenario einfach, bestätigen Sie die Antwortform, dann parametrisieren Sie.

Schritt 2: Das HTTP-Modul für /api/v1/search hinzufügen

Fügen Sie nach dem Trigger ein HTTP-Modul auf Make a request hinzu. Nennen Sie es Start biz collect Search.

Konfigurieren Sie es:

• URL: https://bizcollect.dev/api/v1/search
• Method: POST
• Headers: einen Autorisierungs-Header und einen Content-Type-Header
• Body type: Raw, Content Type JSON
• Parse response: Yes, damit Make die JSON-Felder freilegt

Nutzen Sie diese Header:

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY
Content-Type: application/json

Für eine feste Testsuche nutzen Sie diesen JSON-Body:

{
  "location": "Miami, FL",
  "keywords": ["med spa", "aesthetic clinic"],
  "radius_km": 20,
  "scrape_emails": true
}

Für eine Webhook-Version mappen Sie die Request-Felder, statt sie hart zu codieren, etwa {{1.location}} und {{1.keywords}}, wobei 1 das Webhook-Modul ist. Übergibt Ihr Trigger keywords als kommagetrennten String, teilen Sie ihn zuerst mit einer split()-Funktion oder einem dedizierten Modul in ein Array, weil die API klare Stichwort-Eingaben erwartet und ein Array am einfachsten zu kontrollieren ist.

Nachdem dieses Modul läuft, haben Sie ein Bundle mit job_id, status und möglicherweise poll_url. Scheitert der Request, prüfen Sie API-Key, Body und aktuelle Limits unter Preise.

Schritt 3: Vor dem ersten Poll warten

Fügen Sie nach dem Such-Request ein Sleep-Modul hinzu. Nennen Sie es Wait Before Polling.

Setzen Sie eine kurze Verzögerung von 10 bis 20 Sekunden. E-Mail-Extraktion verlangt, dass die API Firmenwebsites besucht, Seiten parst und Kandidatenadressen dedupliziert, also fügt Pollen unmittelbar nach dem Such-Request meist Rauschen hinzu, ohne das Ergebnis zu verbessern.

Ein praktischer Ausgangspunkt sind 15 Sekunden. Das Make-Sleep-Modul ist auf 300 Sekunden pro Aufruf begrenzt, was für eine einzelne Pause reichlich ist; die Poll-Schleife in den nächsten Schritten gibt Ihnen die längere Gesamtwartezeit. Für breite Suchen tendieren Sie zum oberen Ende; für kleine Anreicherungs-Jobs senken Sie sie.

Schritt 4: /api/v1/jobs/:id pollen

Fügen Sie ein weiteres HTTP-Modul namens Poll biz collect Job hinzu.

Konfigurieren Sie es:

• URL: https://bizcollect.dev/api/v1/jobs/{{job_id}}, wobei Sie die job_id aus der Suchantwort mappen
• Method: GET
• Headers: derselbe Autorisierungs-Header
• Parse response: Yes

Header:

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY

Die Poll-Antwort enthält den aktuellen Job-Status. Verzweigen Sie auf diesen Status, statt anzunehmen, der erste Poll sei fertig. Typische Status, die zu handhaben sind:

• queued oder running: warten und erneut pollen.
• completed: businesses verarbeiten.
• failed: stoppen und jemanden alarmieren oder den Fehler loggen.

Nutzen Sie die tatsächlichen Status-Felder aus den API-Docs als Quelle der Wahrheit.

Schritt 5: Die Poll-Schleife bauen

Make hat kein einzelnes "Schleife bis Bedingung"-Modul, also bauen Sie die Schleife aus Standardteilen. Das wartbarste Muster nutzt einen Repeater mit einer begrenzten Anzahl von Iterationen und einen Router, der ausbricht, wenn der Job fertig ist.

Die Struktur ist:

1. Ein Repeater, gesetzt auf eine maximale Anzahl von Versuchen, etwa 20.
2. In jeder Iteration: ein Sleep-Modul, dann das Poll biz collect Job HTTP-Modul.
3. Ein Router nach dem Poll mit zwei Routen.
4. Route A, ein Filter, bei dem status gleich completed ist, fährt mit der Verarbeitung fort und nutzt ein "Stop" oder ein Flag, sodass spätere Iterationen kurzschliessen.
5. Route B, ein Filter, bei dem status gleich failed ist, routet zu einem Fehler-Handler.

Ein einfacher Weg, verschwendete Iterationen zu vermeiden, ist, das Ergebnis bei Fertigstellung in einem Data Store oder einer Szenario-Variable zu speichern und oben im Repeater einen Filter hinzuzufügen, der Arbeit überspringt, sobald das Flag gesetzt ist. Mit einem 15-Sekunden-Sleep und 20 Versuchen wartet die Schleife etwa fünf Minuten vor dem Aufgeben, was den meisten E-Mail-Extraktions-Jobs entspricht. Tunen Sie beide Zahlen auf Ihre Suchgrösse:

• Schnelle Prospecting-Tests: 10 Versuche à 10 Sekunden.
• E-Mail-Extraktions-Jobs: 20 Versuche à 15 Sekunden.
• Grosse wiederkehrende Suchen: 30 Versuche à 20 Sekunden.

Der richtige Wert ist operativ, nicht theoretisch. Geben Sie normalen Jobs Zeit zum Fertigwerden, während Sie unerwartete Verzögerungen dennoch sichtbar machen.

Schritt 6: Betriebe mit einem Iterator aufteilen

Ist status completed, enthält die Antwort ein Array von Betrieben. Die meisten Ziel-Module arbeiten ein Bundle nach dem anderen, also fügen Sie einen Iterator namens Split Businesses hinzu und richten ihn auf das businesses-Array aus der Poll-Antwort.

Nach dem Iterator ist jeder Betrieb sein eigenes Bundle mit Feldern wie name, address, phone, website und emails. Um eine einzelne primäre E-Mail und eine saubere Zählung zu bekommen, fügen Sie ein Set-Variable-Modul hinzu oder nutzen Inline-Funktionen:

primary_email = {{ first(business.emails) }}
all_emails    = {{ join(business.emails; ", ") }}
email_count   = {{ length(business.emails) }}

Ist das Szenario speziell für Outbound-E-Mail, fügen Sie nach dem Iterator einen Filter hinzu, bei dem primary_email nicht leer ist. Das hält das CRM oder die Tabelle auf Leads fokussiert, auf die Sie reagieren können. Ruft Ihr Team auch Prospects an, behalten Sie Datensätze mit Telefonnummer, selbst wenn keine E-Mail gefunden wird, da die E-Mail-Abdeckung immer teilweise ist.

Schritt 7: Leads an Google Sheets senden

Google Sheets ist das einfachste erste Ziel, weil die Ausgabe sofort sichtbar ist. Fügen Sie nach dem Iterator ein Google Sheets "Add a row"-Modul hinzu.

Empfohlene Spalten:

• Search Job ID
• Business Name
• Address
• Phone
• Website
• Primary Email
• All Emails
• Email Count
• Created At

Mappen Sie die Werte:

Search Job ID  -> {{ job_id }}
Business Name  -> {{ business.name }}
Address        -> {{ business.address }}
Phone          -> {{ business.phone }}
Website        -> {{ business.website }}
Primary Email  -> {{ primary_email }}
All Emails     -> {{ all_emails }}
Email Count    -> {{ email_count }}
Created At      -> {{ now }}

Für eine leichte Dedupe-Strategie nutzen Sie die Website-Domain oder die primäre E-Mail als eindeutigen Schlüssel. Da das "Add a row"-Modul nur anhängt, fügen Sie vor dem Schreiben eine "Search rows"-Prüfung hinzu oder nutzen Sie einen Data Store mit Schlüssel auf der Domain, falls strenge Eindeutigkeit wichtig ist.

Schritt 8: Qualifizierte Leads an ein CRM senden

Für ein CRM wie HubSpot oder Pipedrive ist der häufige Ablauf:

1. Nach einer bestehenden Firma per Domain oder Website suchen.
2. Existiert keine Übereinstimmung, die Firma erstellen.
3. Existiert primary_email, nach einem bestehenden Kontakt per E-Mail suchen.
4. Existiert kein Kontakt, den Kontakt erstellen.
5. Den Kontakt mit der Firma verknüpfen, falls Ihr CRM es verlangt.

Halten Sie die erste Version konservativ. Erstellen Sie keine doppelten Kontakte nur, weil ein Betrieb mehrere E-Mails hat. Starten Sie mit primary_email, speichern Sie optional die ganze deduplizierte Liste in einer benutzerdefinierten Eigenschaft oder Notiz.

Ein nützliches Firmen-Mapping:

name    -> {{ business.name }}
domain  -> {{ replace(replace(business.website; "https://"; ""); "www."; "") }}
phone   -> {{ business.phone }}
website -> {{ business.website }}

Hat Ihr CRM strenge Datenregeln, fügen Sie vor den Erstellen-Modulen Validierung hinzu:

• Kontakte nur erstellen, wenn primary_email nicht leer ist.
• Firmen nur erstellen, wenn website oder phone vorhanden ist.
• Ein Quellenfeld wie biz collect Make scenario ergänzen.
• Suchstandort und Stichwortmenge als Kampagnenkontext ergänzen.

Das macht es einfach zu berichten, welche lokalen Suchen nützliche Leads erzeugt haben.

Schritt 9: Fehler- und Benachrichtigungs-Routen hinzufügen

Ein Szenario zur Leadgenerierung läuft meist nach Zeitplan, was heisst, dass stille Fehler zu veralteten Pipelines führen. Make handhabt Fehler mit an Module angehängten Fehler-Handlern und mit dedizierten Routen für bekannte Fehlerzustände.

Fügen Sie Behandlung für diese Fälle hinzu:

• Unautorisierter Request: API-Key fehlt oder ungültig. Stoppen und den Szenario-Eigentümer benachrichtigen.
• Fehlerhafter Request: fehlender location, leere keywords oder ungültiger radius_km. Die fehlgeschlagene Eingabe in ein Fehler-Sheet schreiben.
• Rate- oder Plan-Limit: das Szenario pausieren und einen Alert mit Link zu Preise senden.
• Job gescheitert: per Slack oder E-Mail benachrichtigen und die job_id einschliessen.
• Job-Timeout: die Versuchszahl und den letzten bekannten Status einschliessen.
• Keine Betriebe zurückgegeben: ein erfolgreiches, aber leeres Ergebnis mit den Suchparametern schreiben.

Für eine kompakte Lauf-Zusammenfassung aggregieren Sie die Betriebe vor dem Iterator und posten eine einzelne Nachricht:

biz collect job {{ job_id }} completed.
Businesses found: {{ length(businesses) }}
With email: {{ length(filter(businesses; length(item.emails) > 0)) }}

Das gibt Ihnen genug Sichtbarkeit, um wiederkehrende Szenarien zu überwachen, ohne für jeden Lauf Make zu öffnen.

Empfohlenes Szenario-Layout

Hier ist die komplette Modul-Sequenz für eine praktische Version:

Trigger (Run once / Schedule / Webhook)
  -> HTTP: Start biz collect Search
  -> Repeater (max 20)
       -> Sleep (15s)
       -> HTTP: Poll biz collect Job
       -> Router
            completed -> Iterator: Split Businesses
                           -> Filter: primary_email is not empty
                           -> Google Sheets / CRM
            failed    -> Notify error
  -> (timeout fallthrough) -> Notify timeout

Dieses Muster vermeidet massgeschneiderte Infrastruktur und handhabt die Realitäten asynchroner APIs: Arbeit kann eingereiht werden, Jobs können eine Weile laufen, und fehlgeschlagene oder langlaufende Jobs brauchen einen operator-freundlichen Weg. Wägen Sie Make gegen andere Tools ab, zeigt der n8n-Workflow zur Leadgenerierung dieselbe Erstellen-Warten-Pollen-Schleife als visuelle Nodes, und der Guide zu den besten Tools für lokale Leadgenerierung 2026 ordnet einen Automatisierung-plus-API-Workflow zwischen Scrapern, No-Code-Tools und CRMs ein.

Loslegen

Das einfachste nützliche Make.com-Szenario zur Leadgenerierung besteht aus nur wenigen Modulen: Trigger, HTTP-Request, Sleep, Poll, Router, Iterator und Ausgabe. Der Wert kommt daraus, eine API zu nutzen, die strukturierte Firmendaten und verifizierte Website-E-Mails liefert, statt Make zu bitten, einen Scraper zu pflegen.

biz collect ist für genau dieses Muster gebaut: ein POST, um eine lokale Suche zu starten, asynchrones Pollen auf Fertigstellung, stabile JSON-Felder, OpenAPI-3.1-Docs und deduplizierte Kontakt-E-Mails, extrahiert aus Firmenwebsites. Es passt zu Make, n8n, Zapier, Skripten, LLM-Tools und CRM-Anreicherung ohne Headless-Browser-Wartung.

Sie können gratis mit 200 Startguthaben und ohne Kreditkarte starten. Öffnen Sie die API-Docs, prüfen Sie die Integrationen, sehen Sie sich die Preise an und bauen Sie noch heute Ihr erstes automatisiertes Szenario für lokale Leads in Make.