Workflow Make.com di lead generation locale

Se stai costruendo un workflow Make.com di lead generation per la prospezione locale, il passaggio di acquisizione dati è dove la maggior parte degli scenari si complica. Trovare attività locali, i loro siti web, numeri di telefono ed email di contatto significa di solito mantenere scraper del browser e selettori che si rompono. biz collect offre a Make una via più pulita: un modulo HTTP invia una località e parole chiave a /v1/search, ricevi un job_id asincrono, poi un ciclo di polling controlla /v1/jobs/:id finché il JSON strutturato è pronto. Questa guida costruisce uno scenario Make completo che trova attività locali, estrae email deduplicate dai loro siti web e scrive i risultati su Google Sheets, un CRM o qualsiasi app a valle.

Perché usare un'API per la lead generation in Make?

Make (già Integromat) è eccellente nel collegare app: trigger, chiamate HTTP, router, iterator, aggregatori, data store e scenari pianificati. Ma la lead generation locale ha un passaggio di acquisizione dati che diventa fragile se provi ad automatizzarlo con lo scraping del browser dentro Make.

Un tipico setup "Make Google Maps scraper" parte da un servizio di browser headless, un URL di ricerca, selettori per le schede dei risultati e una logica separata per visitare ogni sito web e trovare le email. Può funzionare per una demo, ma crea manutenzione continua. I layout cambiano, le sessioni falliscono, i selettori si rompono e l'estrazione email diventa un secondo scraper da sorvegliare. Se stai valutando questo contro un'API di dati, il compromesso tra la Google Places API, gli scraper e le API di dati aziendali espone le differenze.

biz collect è progettato per la forma opposta. È un'API di contatti aziendali nativa per gli LLM, costruita per agenti, strumenti di workflow, script e arricchimento CRM. Chiami /api/v1/search con parametri come location, keywords, radius_km e scrape_emails. L'API restituisce un job in coda. Fai polling su /api/v1/jobs/:id finché è completo, poi usi i record JSON restituiti nel resto del tuo scenario.

Questo lascia il tuo scenario Make concentrarsi sul routing:

• Eseguire ricerche su pianificazione o da un webhook.
• Richiedere dati aziendali locali strutturati a biz collect.
• Attendere e fare polling finché il job asincrono è completo.
• Suddividere le attività restituite in bundle singoli.
• Filtrare, deduplicare o valutare i record.
• Inviare i lead qualificati a Google Sheets, HubSpot, Pipedrive, Airtable, Notion o un'altra app.

Per i dettagli dell'API, parti dai docs API, dagli esempi di integrazione in integrazioni e dai limiti di piano in prezzi. Se vuoi vedere il modello ricerca-e-polling asincrono prima di costruire, la pagina come funziona biz collect percorre lo stesso ciclo che questo scenario automatizza. La documentazione di Make è utile per i moduli standard usati qui, in particolare il modulo HTTP, lo strumento Sleep, l'Iterator e il modulo Google Sheets.

Cosa costruisce questo scenario

Lo scenario di questo tutorial automatizza i lead locali dalla richiesta di ricerca all'output verso la destinazione. Usa moduli Make standard, con biz collect che gestisce la ricerca aziendale e Make l'orchestrazione.

Lo scenario finale ha questo aspetto:

1. Un trigger avvia lo scenario manualmente, su pianificazione o da un webhook.
2. Un modulo HTTP invia una richiesta POST a /api/v1/search di biz collect.
3. La risposta restituisce un job_id e lo stato del job.
4. Un modulo Sleep mette in pausa brevemente prima del polling.
5. Un secondo modulo HTTP chiama /api/v1/jobs/:id.
6. Un router o repeater verifica se lo stato del job è completed.
7. Se non è completo, lo scenario attende e fa polling di nuovo, con un limite di tentativi.
8. Una volta completo, un Iterator trasforma le attività restituite in bundle singoli.
9. I moduli di destinazione inviano i lead a Google Sheets, un CRM o un'altra app.
10. Le route di errore gestiscono job falliti, timeout e set di risultati vuoti.

Puoi adattare lo stesso schema per prospezione occasionale, scansioni di mercato ricorrenti, liste di lead per agenzie, arricchimento CRM o workflow di agenti IA che necessitano di dati di contatto di attività locali verificati.

Prerequisiti

Prima di costruire lo scenario, ti serve:

• Un account Make, su qualsiasi piano che consenta i moduli HTTP.
• Una chiave API biz collect.
• Una destinazione per i lead, come Google Sheets, HubSpot o Pipedrive.
• Una definizione di ricerca chiara: località, parole chiave di categoria, raggio e se estrarre le email dai siti web.

biz collect è gratuito da iniziare con 200 crediti di iscrizione e senza carta di credito. È sufficiente per costruire, testare ed eseguire piccoli job di prospezione prima di mettere lo scenario su una pianificazione di produzione. Controlla prezzi per i limiti di piano attuali.

Flusso di dati e forma dell'API

biz collect usa un flusso di job asincrono perché la ricerca di attività locali e l'estrazione email dai siti web possono richiedere più tempo di una normale richiesta HTTP sincrona. Make gestisce bene questo perché gli scenari possono dormire, ramificarsi e ripetersi.

La richiesta base è un POST a:

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

Il body contiene gli input di ricerca locale:

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

La risposta contiene un identificatore di job. Lo scenario ha bisogno solo del job_id e dello stato:

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

Poi Make fa polling:

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

Una volta completo, il risultato contiene record aziendali strutturati:

{
  "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"]
    }
  ]
}

Il contratto è stabile: avviare una ricerca, ricevere un job_id, fare polling sul endpoint del job, poi elaborare JSON strutturato. Per lo schema autorevole, usa il riferimento OpenAPI nei docs di biz collect.

Passo 1: Creare il trigger

Inizia con il trigger che corrisponde al tuo caso d'uso:

• Run once per test e ricerche occasionali.
• Schedule per prospezione ricorrente, ad esempio ogni lunedì mattina.
• Custom webhook quando un altro sistema o agente deve avviare una ricerca dinamicamente.

Per una prima versione, esegui lo scenario manualmente e codifica in modo fisso una località e delle parole chiave nel primo modulo HTTP. Una volta stabile, sostituisci i valori fissi con dati da una pianificazione, un Google Sheet di territori o un payload di webhook.

Se vuoi che lo scenario accetti ricerche dinamiche, aggiungi un trigger Custom webhook e invia un body come:

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

Poi il modulo di richiesta biz collect può mappare i campi in arrivo del webhook. Mantieni semplice il primo scenario, conferma la forma della risposta, poi parametrizza.

Passo 2: Aggiungere il modulo HTTP per /api/v1/search

Aggiungi un modulo HTTP impostato su Make a request dopo il trigger. Chiamalo Start biz collect Search.

Configuralo:

• URL: https://bizcollect.dev/api/v1/search
• Method: POST
• Headers: un header di autorizzazione e un header content-type
• Body type: Raw, content type JSON
• Parse response: Yes, così Make espone i campi JSON

Usa questi header:

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY
Content-Type: application/json

Per una ricerca di test fissa, usa questo body JSON:

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

Per una versione webhook, mappa i campi della richiesta invece di codificarli in modo fisso, ad esempio {{1.location}} e {{1.keywords}}, dove 1 è il modulo webhook. Se il tuo trigger fornisce le parole chiave come stringa separata da virgole, suddividila prima in un array con una funzione split() o un modulo dedicato, perché l'API si aspetta un input di parole chiave chiaro e un array è il più facile da controllare.

Dopo l'esecuzione di questo modulo, hai un bundle con job_id, status e possibilmente poll_url. Se la richiesta fallisce, controlla la chiave API, il body e i limiti attuali in prezzi.

Passo 3: Attendere prima del primo poll

Aggiungi un modulo Sleep dopo la richiesta di ricerca. Chiamalo Wait Before Polling.

Imposta un breve ritardo, da 10 a 20 secondi. L'estrazione email richiede che l'API visiti i siti web delle attività, analizzi le pagine e deduplichi gli indirizzi candidati, quindi fare polling immediatamente dopo la richiesta di ricerca di solito aggiunge rumore senza migliorare il risultato.

Un punto di partenza pratico è 15 secondi. Il modulo Sleep di Make è limitato a 300 secondi per chiamata, il che è ampiamente sufficiente per una singola pausa; il ciclo di polling nei passaggi successivi ti dà il tempo di attesa totale più lungo. Per ricerche ampie, tendi verso l'alto; per piccoli job di arricchimento, abbassalo.

Passo 4: Fare polling su /api/v1/jobs/:id

Aggiungi un altro modulo HTTP chiamato Poll biz collect Job.

Configuralo:

• URL: https://bizcollect.dev/api/v1/jobs/{{job_id}}, mappando il job_id dalla risposta di ricerca
• Method: GET
• Headers: lo stesso header di autorizzazione
• Parse response: Yes

Header:

Authorization: Bearer YOUR_BIZCOLLECT_API_KEY

La risposta di polling include lo stato attuale del job. Ramifica su quello stato invece di presumere che il primo poll sia completo. Stati tipici da gestire:

• queued o running: attendere e fare polling di nuovo.
• completed: elaborare businesses.
• failed: fermare e avvisare qualcuno o registrare l'errore.

Usa i campi di stato reali dai docs API come fonte di verità.

Passo 5: Costruire il ciclo di polling

Make non ha un singolo modulo "cicla fino a condizione", quindi costruisci il ciclo da parti standard. Lo schema più manutenibile usa un Repeater con un numero limitato di iterazioni e un Router che esce quando il job è finito.

La struttura è:

1. Un Repeater impostato su un numero massimo di tentativi, ad esempio 20.
2. In ogni iterazione: un modulo Sleep, poi il modulo HTTP Poll biz collect Job.
3. Un Router dopo il poll con due route.
4. Route A, un filtro dove status è uguale a completed, continua verso l'elaborazione e usa uno "Stop" o un flag così le iterazioni successive vanno in cortocircuito.
5. Route B, un filtro dove status è uguale a failed, instrada verso un gestore di errore.

Un modo semplice per evitare iterazioni sprecate è memorizzare il risultato in un data store o una variabile di scenario al completamento e aggiungere un filtro in cima al repeater che salta il lavoro una volta impostato il flag. Con uno Sleep di 15 secondi e 20 tentativi, il ciclo attende circa cinque minuti prima di arrendersi, il che si adatta alla maggior parte dei job di estrazione email. Regola entrambi i numeri alla dimensione della tua ricerca:

• Test di prospezione rapidi: 10 tentativi a 10 secondi.
• Job di estrazione email: 20 tentativi a 15 secondi.
• Grandi ricerche ricorrenti: 30 tentativi a 20 secondi.

Il valore giusto è operativo, non teorico. Dai ai job normali il tempo di finire mentre fai emergere ritardi inattesi.

Passo 6: Suddividere le attività con un Iterator

Una volta che status è completed, la risposta contiene un array di attività. La maggior parte dei moduli di destinazione lavora un bundle alla volta, quindi aggiungi un Iterator chiamato Split Businesses e puntalo all'array businesses della risposta di poll.

Dopo l'Iterator, ogni attività è il proprio bundle con campi come name, address, phone, website ed emails. Per ottenere una singola email principale e un conteggio pulito, aggiungi un modulo Set Variable o usa funzioni inline:

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

Se lo scenario è specificamente per l'email in uscita, aggiungi un filtro dopo l'Iterator dove primary_email non è vuota. Questo mantiene il CRM o il foglio di calcolo concentrato sui lead su cui puoi agire. Se il tuo team chiama anche i prospect, mantieni i record con un numero di telefono anche quando non viene trovata alcuna email, poiché la copertura email è sempre parziale.

Passo 7: Inviare i lead a Google Sheets

Google Sheets è la destinazione più facile perché l'output è immediatamente visibile. Aggiungi un modulo Google Sheets "Add a row" dopo l'Iterator.

Colonne consigliate:

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

Mappa i valori:

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 }}

Per una strategia di deduplicazione leggera, usa il dominio del sito web o l'email principale come chiave univoca. Poiché il modulo "Add a row" aggiunge soltanto, aggiungi un controllo "Search rows" prima della scrittura, o usa un data store indicizzato sul dominio, se l'unicità rigorosa conta.

Passo 8: Inviare i lead qualificati a un CRM

Per un CRM come HubSpot o Pipedrive, il flusso comune è:

1. Cercare un'azienda esistente per dominio o sito web.
2. Se non esiste corrispondenza, creare l'azienda.
3. Se primary_email esiste, cercare un contatto esistente per email.
4. Se non esiste contatto, creare il contatto.
5. Associare il contatto all'azienda se il tuo CRM lo richiede.

Mantieni la prima versione conservativa. Non creare contatti duplicati solo perché un'attività ha diverse email. Inizia con primary_email, poi memorizza opzionalmente l'intera lista deduplicata in una proprietà personalizzata o una nota.

Un mapping azienda utile:

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

Se il tuo CRM ha regole sui dati rigorose, aggiungi una validazione prima dei moduli di creazione:

• Creare contatti solo quando primary_email non è vuota.
• Creare aziende solo quando website o phone è presente.
• Aggiungere un campo di origine come biz collect Make scenario.
• Aggiungere la località di ricerca e il set di parole chiave come contesto di campagna.

Questo rende facile fare reporting su quali ricerche locali hanno prodotto lead utili.

Passo 9: Aggiungere route di errore e notifica

Uno scenario di lead generation di solito gira su pianificazione, il che significa che i fallimenti silenziosi creano pipeline obsolete. Make gestisce gli errori con gestori di errori collegati ai moduli e con route dedicate per gli stati di errore noti.

Aggiungi la gestione per questi casi:

• Richiesta non autorizzata: chiave API mancante o non valida. Fermare e notificare il proprietario dello scenario.
• Richiesta errata: location mancante, keywords vuoto o radius_km non valido. Scrivere l'input fallito in un foglio di errori.
• Limite di rate o di piano: mettere in pausa lo scenario e inviare un alert con un link a prezzi.
• Job fallito: notificare via Slack o email e includere il job_id.
• Timeout del job: includere il conteggio dei tentativi e l'ultimo stato noto.
• Nessuna attività restituita: scrivere un risultato riuscito ma vuoto con i parametri di ricerca.

Per un riepilogo di esecuzione compatto, aggrega le attività prima dell'Iterator e pubblica un singolo messaggio:

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

Questo ti dà abbastanza visibilità per monitorare gli scenari ricorrenti senza aprire Make a ogni esecuzione.

Layout di scenario consigliato

Ecco la sequenza completa di moduli per una versione pratica:

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

Questo schema evita infrastruttura su misura pur gestendo le realtà delle API asincrone: il lavoro può essere messo in coda, i job possono durare un po', e i job falliti o di lunga durata hanno bisogno di un percorso adatto agli operatori. Se stai valutando Make contro altri strumenti, il workflow n8n di lead generation mostra lo stesso ciclo crea-attendi-poll come node visivi, e la guida ai migliori strumenti di lead generation locale nel 2026 colloca un workflow automazione-più-API tra scraper, strumenti no-code e CRM.

Iniziare a costruire

Lo scenario Make.com di lead generation più semplice ma utile è composto da pochi moduli: trigger, richiesta HTTP, sleep, poll, router, iterator e output. Il valore viene dall'usare un'API che restituisce dati aziendali strutturati ed email di siti web verificate invece di chiedere a Make di mantenere uno scraper.

biz collect è costruito esattamente per questo schema: un POST per avviare una ricerca locale, polling asincrono fino al completamento, campi JSON stabili, docs OpenAPI 3.1 ed email di contatto deduplicate estratte dai siti web delle attività. Si adatta a Make, n8n, Zapier, script, strumenti LLM e arricchimento CRM senza manutenzione del browser headless.

Puoi iniziare gratuitamente con 200 crediti di iscrizione e senza carta di credito. Apri i docs API, rivedi le integrazioni, controlla i prezzi e costruisci oggi il tuo primo scenario di lead locali automatizzati in Make.