A useful Smartlead + Make integration moves a qualified reply into a CRM with a named owner and a recoverable failure path. For the example below, a person reviews a Smartlead reply and marks its lead category Interested. Smartlead sends a Lead Category Updated webhook to Make. Make checks the event, finds or creates the person in Pipedrive, creates or updates one deal, and assigns a follow-up activity to the sales owner. The team still reads and answers the reply; this scenario does not auto-send a sales message.
This is a documented design to build and test, not a scenario we ran in a private account. Smartlead's webhook setup, event and failure reference, Make's webhook documentation and Pipedrive module list were checked on October 1, 2026. Product labels and event fields can change; inspect a sample from your own account before mapping it.
Jan van Musscher demonstrated this specific Smartlead category-to-Make trigger in an August 2024 tutorial. He selected Lead Category Updated → Interested, sent a test event and showed Make detecting the payload. That is historical implementation context, not evidence that today's Make or Smartlead screen is identical. His 2023 CRM walkthrough also explains the operating distinction used here: a positive reply becomes a sales opportunity with a responsible person, while an unsubscribe needs suppression rather than a deal. The exact stages and team he described then are not assumed to be current.
Choose the trigger before building the scenario
| Trigger | What it means | Use it for |
|---|---|---|
| Email Reply | Someone replied; intent is still unknown. | Logging, triage or a review queue. Do not automatically create an interested deal from every reply. |
| Lead Category Updated → Interested | A lead was put into an interest category. | The reviewed handoff in this guide. Confirm whether a person or Smartlead's optional AI categorization made the change. |
| Lead Unsubscribed | The lead opted out. | A separate suppression/reconciliation route, never the interested-deal route. |
Smartlead documents reply categories in its Master Inbox and says they can be set there; its current campaign setup offers AI auto-categorization or manual-only categorization. For the first rollout, use manual review so the CRM handoff has an accountable decision. If you later use automatic categorization, sample false positives and ambiguous replies before treating that label as authority to open a deal.
Prerequisites and ownership
- A Smartlead campaign with replies visible to the person who will classify them, plus permission to configure webhooks at the intended campaign or client level.
- A Make scenario owner who can view failed executions and change mappings; a secret Make webhook URL must not be posted in a public document.
- A Pipedrive connection in Make with permission to search and create/update Persons, Deals, and Activities. Make's current Pipedrive CRM app lists those modules. Its older API v1 modules are deprecated, so use the current modules and review mappings if a scenario was built years ago.
- A small source-to-owner table: Smartlead client/campaign ID → Pipedrive pipeline/stage → accountable Pipedrive user. Decide what happens if the campaign is unknown. Do not silently assign every client's reply to one shared owner.
- An agreed contact rule: an interested reply may create a deal; an opt-out or a negative reply follows your suppression process and does not enter this route.
For multi-client work, choose an explicit boundary per client. Smartlead's client-access guide describes assigning campaigns and email accounts to clients. The Make mapping should preserve that client identity; matching by email alone could route the same address into the wrong client's CRM workspace.
Build the Smartlead → Make → Pipedrive path
1. Create the receiving webhook in Make
Create a scenario with Webhooks → Custom webhook as its first module. Give it a clear name, such as Smartlead interested to Pipedrive, and copy the unique HTTPS URL. Make documents that a custom webhook receives third-party requests and triggers its scenario. Keep the URL private. Make supports optional API-key authentication for custom webhooks, but use it only if the sender can provide the required header; do not turn it on and then wonder why Smartlead events are rejected.
Leave the scenario in Run once while collecting a sample. The fields available in Make's mapper come from a received payload, so do not guess field names from an old screenshot or paste a fabricated event into a production scenario.
2. Configure the matching Smartlead event
In Smartlead, go to Settings → Webhooks, choose Add Webhook, name it and paste the Make URL. Select the target campaign or client and the Lead Category Updated event. If the UI offers a category filter, select the account's Interested category. Smartlead's webhook guide documents the Settings/Webhook path and campaign/event selection; its failure guide lists category updates among the supported events.
Check existing webhooks first. Smartlead says user-level webhooks take priority over client- or campaign-level hooks, and its trigger troubleshooting guide warns that multiple hooks at the same level can result in only the latest updated one receiving notifications. If another integration already owns those events, plan one receiving route that fans them out rather than adding a competing hook and assuming both will fire.
3. Capture a real sample and filter it
Use Smartlead's test-event option if it appears in your account, or change a safe test lead to Interested, then inspect the bundle received in Make. Jan's older walkthrough shows the test-event path; current Smartlead documentation recommends triggering real test events and inspecting the payload. Record the observed event type, category, campaign and client identifiers, lead identifier, email, and any event/request identifier. Some fields may be absent; mark them unknown instead of building a brittle mapping.
Add a filter that continues only for Lead Category Updated events whose new category is Interested. Require a known campaign/client and a usable lead email or ID. Send unknown categories, missing IDs and unmapped clients to a review queue or a visible failed execution; do not create a generic sales deal. If a webhook includes both old and new state, compare the new state. A repeat notification must not produce another deal.
4. Map one person, one opportunity, one owner
In Make, use Pipedrive's current Search Persons module to look up the email in the intended CRM account. Create a Person only if no suitable match exists. Build a stable source key from Smartlead client ID + campaign ID + lead ID, then use Make's Data Store → Check the existence of a record and Get a record when present to see whether this handoff already has a Pipedrive deal ID. If it does, update that Deal; if it does not, inspect existing Deals for the Person before creating one in the intended pipeline and stage. Create a follow-up Activity for the mapped owner only when there is no existing activity for that handoff, with a due date the team has agreed to honor. Store the resulting CRM IDs under the source key only after the CRM writes succeed. Make lists the relevant Pipedrive modules and documents Data Store record keys and lookups.
An example mapping to agree before turning the scenario on:
| Source in Smartlead | Destination in Pipedrive | Owner of correction |
|---|---|---|
| Lead email and name from the observed payload | Person email/name | Sales operations reviews duplicates and spelling. |
| Client ID + campaign ID + lead ID | Stable source reference on the deal or in a Make ledger | Automation owner reconciles replays. |
| Category changed to Interested | Deal enters an agreed New interested reply stage | Human reviewer can correct a mistaken category. |
| Campaign-to-owner table | Deal owner and follow-up Activity owner | Sales manager maintains the routing table. |
| Link back to the Smartlead conversation, if the real payload provides one | Deal context or activity note | Rep reads the actual message before responding. |
Those fields are an example contract, not a claim about the exact payload or a default Pipedrive schema. Keep the Make ledger with the source key, CRM Person ID, Deal ID, Activity ID and processing state; store no more personal data there than necessary. A simple “search then create” can still race when two events arrive together, and a ledger write can fail after the CRM succeeds. Check both systems before replaying a failed run. Do not map full reply text into fields visible to everyone unless your organization's data policy permits it.
5. Turn on recovery before live replies
In Make Scenario settings, enable Store incomplete executions. Make says this is off by default and stores a failed run for retry or manual resolution. Add a Retry error handler to transient CRM/API failures where a repeat is safe. If creating the Person succeeds but creating the Deal fails, resume from the stored failure after inspecting the CRM; a blind restart may create a duplicate Person. Keep a stable event/request ID or source key and mark a delivery processed only after the CRM writes you require have succeeded.
Smartlead's webhook failure guide treats a non-2xx response, timeout, or an accepted event later dropped during processing as a failure. A Make webhook's acceptance is therefore not proof that the Pipedrive deal exists. Monitor Smartlead delivery logs, Make scenario runs and incomplete executions, and reconcile both against actual CRM records. For bursty traffic, a queue or durable intermediary may be needed; neither Make nor a webhook URL alone guarantees an exactly-once CRM handoff.
Test four cases before enabling the scenario
- Interested: change a test lead's category and verify one Person, one Deal, the right client pipeline, a named owner and one follow-up Activity.
- Other reply: send or classify a negative, referral, out-of-office or unsubscribe event. Verify it does not become an interested Deal. Handle suppression separately.
- Duplicate delivery: replay the same event or repeat the category action. Verify the existing opportunity is updated or left alone rather than duplicated.
- Partial failure: temporarily use a harmless test mapping that fails the CRM step. Confirm an incomplete execution or alert is visible, fix it, replay it and compare the final CRM state.
After those checks, activate the scenario and review the first real handoffs with the sales owner. Retain only the lead data needed to work the reply, protect webhook URLs and app connections, and keep a manual escalation for ambiguous responses. The Smartlead review covers the sender itself; our sales development tools guide compares broader handoff and agent options. If your sending account is still being connected, start with the Google Workspace OAuth setup.
Native Make app or custom webhook?
Make now has a Smart Lead AI app with a Watch Campaigns trigger and lead/campaign modules. Its docs say the connection needs Smartlead API access and an API key, and the integration is supported by a Make partner. Make labels that app documentation AI-generated and asks users to verify important details. The native app is another path to evaluate. We use the custom webhook here because the category-update event and receiving endpoint are explicit in Smartlead's own documentation, and because a team can inspect the raw event before deciding what qualifies for CRM creation. If your account's native Watch Campaigns trigger exposes the exact event and fields you need, compare its setup, permissions and failure behavior in a test scenario. Do not maintain two active triggers for the same event without deduplication.
Disclosure: OutboundXYZ has a Smartlead affiliate relationship. This article documents a proposed workflow using current public sources and Jan's dated historical videos; it does not claim a live test or a measured conversion lift.
