You connect Lead to Speed to Make (formerly Integromat) with a webhook: Make watches for a new lead in any of its 2,000+ connected apps, then instantly passes that lead's phone number and details to Lead to Speed, which places an AI phone call in under 10 seconds. This matters because leads contacted within 5 minutes are far more likely to qualify — the MIT/Oldroyd Lead Response Management study is the common reference for the ~21x advantage over waiting 30 minutes. Every minute your automation shaves off response time is measurable pipeline. Make is the glue that turns "we got a lead" into "we're already on the phone."
Why route leads through Make instead of a direct integration
Make is worth the extra step when your leads arrive from more than one source. Most businesses collect inbound from a website form, a Facebook lead ad, a Calendly booking, a chatbot, and a CRM — and each speaks a different data format. Make normalizes all of them into one clean payload before it ever reaches Lead to Speed.
The core value is speed-to-lead consistency. It doesn't matter whether a lead comes from Typeform or a Shopify checkout — Make catches it and fires the same instant-call workflow. That reliability is the whole point, because average B2B lead response time is still measured in hours (studies put it around 29–47 hours depending on methodology), and roughly 78% of buyers purchase from the first company that responds.
Use Make instead of a point-to-point integration when you need:
- Multiple lead sources funneling into one call trigger
- Data enrichment or cleanup (formatting phone numbers to E.164, deduping) before the call
- Conditional routing — e.g., only call leads from certain campaigns or ZIP codes
- Fan-out actions — call the lead and log to your CRM and ping Slack, in parallel
If you have a single form and no logic, a direct webhook may be simpler. For anything multi-source, Make earns its keep.
What you need before you start
You need three things ready before building: a Lead to Speed account with API access, a Make account, and at least one live lead source. Gather these first so you're not context-switching mid-build.
- Lead to Speed credentials — your API key or account-specific webhook endpoint, found in your Lead to Speed settings. See how it works for where calls get triggered in the flow.
- A Make account — the free tier supports webhooks and works for testing; higher plans raise the operations limit and lower the minimum scenario interval.
- A lead source — the app producing your leads (Facebook Lead Ads, a web form, HubSpot, etc.).
- A test phone number you control, so you can verify a real call fires before going live.
One prerequisite people skip: confirm your lead source actually includes a phone number. Lead to Speed places a call, so a lead with no valid mobile number can't be dialed. Build a filter for that early rather than debugging silent failures later.
Step-by-step: build the Make scenario
The fastest path is a two-module scenario — a trigger that catches the lead and an HTTP/webhook module that sends it to Lead to Speed. Here's the build.
- Create a new scenario in Make and click the first module to add your trigger. Choose your lead source app (e.g., "Facebook Lead Ads → Watch Leads") or use Make's built-in "Custom Webhook" if your form posts a generic webhook.
- For a custom webhook: copy the webhook URL Make generates and paste it into your form tool's webhook/notification setting. Submit one test lead so Make can learn the data structure.
- Add a Router or Filter (optional but recommended). Set a filter condition like
Phone number: existsso leads without a callable number never trigger a wasted call. - Add the second module: "HTTP → Make a request." Set the method to POST and the URL to your Lead to Speed webhook endpoint.
- Map the payload. In the request body (JSON), map Make's incoming fields to Lead to Speed's expected fields — typically
phone,name,email, andsource. Include any campaign or context fields you want the AI to reference on the call. - Add your Lead to Speed API key in the request headers (as instructed in your account), then save.
Set the scenario to run immediately (webhooks are real-time by default). Turn scheduling on, and the workflow is live.
Mapping fields and formatting phone numbers correctly
The single most common failure point is phone number formatting, so fix it in Make before the call ever fires. Lead to Speed dials whatever number it receives, so garbage in means no call out.
Use a Make text function or the built-in phone number formatting to convert numbers into E.164 format (e.g., +14155551234). Strip spaces, dashes, and parentheses. If your leads are US-based and arrive as 10 digits, prepend +1.
A clean field map usually looks like this:
| Lead to Speed field | Maps from (Make) | Notes |
|---|---|---|
phone |
Lead phone, formatted E.164 | Required — call fails without it |
name |
First + last name | Used by the AI to greet the lead |
email |
Lead email | Stored in the CRM record |
source |
Trigger app or campaign name | Helps segment and script the call |
notes |
Form answers, ad name, page URL | Context the AI can reference live |
Field names above are illustrative — check your Lead to Speed account for the exact expected payload keys before mapping.
The richer the context you pass, the smarter the AI conversation. Passing the campaign name and the lead's stated interest lets the AI open with something relevant instead of a generic pitch — which matters when Velocify research shows contact within one minute drives dramatically higher conversion. Fast and relevant beats fast alone.
Testing, error handling, and going live
Always run a real test call to your own phone before pointing the scenario at live traffic. Make's "Run once" button executes the scenario a single time so you can watch the data flow module by module.
Verify these in order:
- The trigger fires and shows the correct lead data in the module bubble.
- Your filter passes valid leads and blocks number-less ones.
- The HTTP module returns a 2xx success status from Lead to Speed.
- Your test phone actually rings within seconds — the real proof.
For production reliability, add error handling. In Make, right-click the HTTP module and attach an error handler route (a "Resume" or "Break" directive) so one malformed lead doesn't halt the whole scenario. Route failed leads to a Slack alert or an email so a human can follow up manually.
Also plan for after-hours volume: 30–40% of inbound leads commonly arrive outside business hours, and Lead to Speed calls 24/7, so your Make scenario should stay active around the clock — don't schedule it to business hours only. Every recording, transcript, and AI summary lands in the Lead to Speed CRM regardless of when the call happens, so your reps have full context the next morning. For the strategic case behind all this automation, the complete guide to speed to lead covers why sub-minute response wins deals.
Make vs. Zapier vs. direct integration for triggering calls
Make is the strongest choice when your logic is complex or your lead volume is high, but it's not the only option. Here's an honest comparison of the three common ways to trigger a Lead to Speed call.
| Approach | Best for | Strengths | Limitations |
|---|---|---|---|
| Make (Integromat) | Multi-source, conditional routing, high volume | Visual scenario builder, powerful branching/filters, operations-based pricing that suits high throughput | Steeper learning curve; multi-step scenarios take time to build |
| Zapier | Teams already on Zapier wanting a quick single-path automation | Huge app library, simplest setup for linear flows | Complex branching is clunkier; task-based pricing can add up at volume |
| Direct webhook | A single form with no extra logic | Fewest moving parts, lowest latency, no third-party dependency | No enrichment, routing, or fan-out; you rebuild logic per source |
Pricing and feature sets for Make and Zapier change frequently — verify current plans and limits on each vendor's site before committing.
The tie-breaker is usually latency and logic. Any of the three can hit sub-10-second calls because the bottleneck is the call platform, not the automation layer. Choose Make when you value branching and want one scenario to handle every lead source; choose a direct webhook when simplicity and minimum latency matter more than flexibility.