Bookings, ad leads and form sign-ups into the right CRM, with conversions sent back to Meta
Four Make scenarios, each delivering one kind of funnel event to where it is worked: booked calls upserted into Close and into Pipedrive with a meeting activity, lead-ad submissions posted to a client's own CRM, and website sign-ups emailed, logged and sent back to Meta as server-side conversions.
Where this applies
Marketing agencies running funnels for several clients, and any business that takes leads from ad forms, landing pages and a booking calendar into more than one CRM.
- lead-ad runs in two weeks, one error
- 900+
- destinations per sign-up: email, sheet, Meta
- 3
- between booking checks for Pipedrive
- 15 min
The problem
A funnel agency's leads come from everywhere (ad lead forms, landing pages, a booking calendar) and have to reach whichever CRM the brand behind the funnel uses. Copying by hand loses the lead that arrived at the weekend, and a person who books twice becomes two records.
The ad platform needs to hear back as well. Meta optimises on what it is told, and a browser pixel misses sign-ups that a server-side event would catch, so a lead flow that stops at the CRM leaves the campaigns guessing.
What we built
A booked call is an upsert
When a call is booked in Calendly, one scenario searches Close for the lead. A router updates the lead if it exists, or creates the lead and its contact if not, so a second booking from the same person updates one record instead of making another.
Route by event type, then log the meeting
A second scenario, for a team that works in Pipedrive, checks Calendly every fifteen minutes, reads each new event and routes it by event type. Each route searches Pipedrive for the person, creates them if they are new, and adds an activity for the meeting either way.
Hand the lead to the client's own system
For a client with its own CRM, each Meta lead-form submission is posted straight to that CRM's intake API, which stores the lead and sends the double-opt-in email. The scenario is two modules and an ignore handler on purpose: the client's system owns the lead, and Make only delivers it.
One sign-up, three destinations
For a business-networking group's visitor sign-ups, each website form submission is emailed to the organiser, sent to Meta's Conversions API as a server-side event and added to a Google Sheet, all in one run.
The outcome
All four are live. The lead-ad hand-off ran at least 900 times between 30 September and 13 October 2026, with one error. The networking sign-up flow, live since February 2025, ran 27 times from 19 September to 21 October, and the Close upsert 25 times from 25 September to 19 October; neither recorded an error.
The Pipedrive scenario's fifteen-minute checks used 2,881 credits in the current billing period, almost all of them on checks that found no new booking.
Where it stops
Each scenario does one hand-off and no more: none of them reconciles the CRMs with each other, and the lead-ad flow leaves duplicates and consent to the client's own system. The Pipedrive scenario checks on a schedule rather than listening for bookings, which is where most of its credits go. This is a small part of a large account, and the rest of it is not described.
Built with
- Make.com
- Calendly
- Close
- Pipedrive
- Facebook Lead Ads
- Facebook Conversions API
- Elementor
- Google Sheets
- HTTP
Patterns used
- Search then create
- Route by event type
- Deliver, don't own
- Server-side conversion
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no