Roofing CRM lead delivery: what's actually connected

Receiving network-generated roofing enquiries in the CRM you already use

The leads originate on sites and numbers the network owns and operates, separate from your own website. When someone calls, fills out a form, or chats on one of those sites, the network captures the enquiry, matches it to your territory, and pushes it toward your CRM using whichever connection method is available and confirmed for your provider.

The provider you use determines how that delivery happens — not whether it happens. A generic webhook and a private Zapier app work today for essentially any CRM capable of receiving one. Where a deeper native connection exists, it adds structured field mapping and status feedback beyond a raw webhook payload.

Current provider connection status

If your CRM isn't on this list at all, the webhook and Zapier routes still apply as long as your CRM (or an integration platform sitting in front of it) can accept an inbound webhook or a Zap trigger. Email and SMS fallback exist as a backstop for any provider, including ones with no API access at all.

Which contact, property, roof-problem and attribution fields matter

A lead record is only useful if the fields your estimator actually needs make it into your CRM in a usable shape. The network captures what the caller or form-filler provides — it cannot invent a property address or a problem description nobody gave it — and passes along whatever was collected.

Fields available when provided

• Name, phone, email
• Property address or ZIP
• Service requested and problem notes (leak, storm damage, tear-off, re-roof, etc.)
• Urgency
• Source site/domain and source page
• Territory and assigned roofing company
• Timestamp and a qualification summary
• Call recording link and transcript/AI summary, where permitted
• UTM/campaign metadata
• Appointment details, if one was booked

Not every lead will have every field populated — a quick call that drops before the caller gives an address will arrive without one. Fields that weren't provided are left blank rather than guessed, and your CRM mapping should treat a blank field as genuinely unknown, not as a data error.

Attribution fields (source site, source page, UTM/campaign metadata) travel with the lead so your team can see where it originated, but they describe the site and page the enquiry came from — not a guarantee of keyword-level marketing attribution, which isn't part of this delivery.

Separating contact creation from a confirmed lead delivery

Creating a contact record in your CRM and confirming that a lead was actually delivered are two different events, and conflating them hides failures. A delivery can create a contact and still fail to attach the opportunity details, or it can be accepted by your CRM's API but rejected for a validation reason you only see in the status log.

The delivery lifecycle

1. Queued — the lead has been captured and is waiting to be sent
2. Sent — the delivery attempt has gone out to your CRM or connection method
3. Delivered — your CRM has acknowledged receipt (provider response or external record ID is logged)
4. Failed — the attempt did not succeed, and the system moves to retry logic

Every delivery attempt is timestamped and carries the provider's response or an external record ID when one is returned, so you can trace a specific lead back to the exact CRM record it created, not just confirm something was sent.

Your portal shows simple connection health — essentially whether your CRM connection is working — so a non-technical user can see at a glance if something needs attention, without reading raw status logs. If you want the detail, the full queued/sent/delivered/failed history for each lead is there too.

This separation matters most when something goes wrong partway through: a contact might get created by your CRM's own matching logic even while the opportunity or job details fail to attach, and without a distinct delivery status you'd have no way to know the record is incomplete.

Avoiding duplicate customers while preserving separate roofing projects

A returning homeowner — someone who called about a repair last year and is calling again now about a full replacement — creates a real tension: you don't want two duplicate contact records for the same person, but you also don't want their second, separate project buried inside the first one as if nothing new happened.

The network de-duplicates enquiries before they're delivered, matching on details like name, phone, and address where available, so the same enquiry isn't delivered twice because of a double form submission or a repeat call within a short window. That de-duplication happens on the network side, before delivery.

What de-duplication is and isn't

• It prevents the same single enquiry from being delivered more than once (e.g., a form double-submit)
• It does not merge two genuinely separate enquiries from the same person into one project
• Your CRM's own contact-matching logic still applies on top of this — most CRMs will match an existing contact by phone or email automatically
• A new project for an existing contact should create a new opportunity/job record, not overwrite the old one

If you ever see what looks like a true duplicate — the same enquiry delivered twice with no new information — that's worth flagging, since it points to either a de-duplication gap or a retry that should have been caught by the idempotency key described in the next section.

Recovering from expired connections, rejected fields and outages

CRM connections break for mundane reasons: an API key expires, a field a lead delivery tries to populate gets renamed in your CRM, or your CRM has an outage on its end. None of those should mean a lead simply vanishes, and the delivery system is built around that assumption.

How failure recovery works

• Retries with exponential backoff — a failed attempt is retried automatically, with increasing delay between attempts, rather than hammering a down endpoint
• Idempotency keys — each delivery attempt carries a unique key so a retry can't accidentally create a duplicate record if the original attempt actually succeeded silently
• Dead-letter queue — a lead that exhausts its retries lands in a dead-letter queue for manual review and retry, instead of being dropped
• Fallback alert — if the CRM push keeps failing, an email or SMS alert goes out so a human knows to act, and the lead details are available through that fallback channel

A rejected field — say, your CRM requires a value in a field the lead didn't supply — triggers a failed status with the provider's rejection reason attached where the provider returns one. That's diagnostic information you or your onboarding contact can use to fix the mapping, not a dead end.

Your portal's connection-health indicator is the fastest way to notice a problem before it accumulates. Checking it periodically, rather than only after a customer mentions a lead you never saw, catches most of these issues early.

Running a roofer-side acceptance test before going live

Before you let leads start flowing into a live CRM workflow your team depends on, run a short acceptance test. It takes a connection from "should work" to "confirmed working with your specific setup," and it's the single best way to catch a field-mapping or status issue before it affects a real customer enquiry.

Acceptance test steps

1. Confirm which connection method applies to your CRM (webhook, Zapier, native connection, or fallback) and its current status
2. Submit a clearly-marked test enquiry (form or call) through the relevant site, so it doesn't get mistaken for a real customer
3. Check your portal for the delivery status: queued, sent, delivered, or failed
4. Confirm the test record arrived in your CRM, and check that the fields mapped where you expect
5. Intentionally submit a second test with the same name/phone to confirm your contact-matching behaves as expected
6. Confirm who on your team receives the fallback alert if a delivery fails, and that they know what to do with it
7. Document the test result and date, so you have a record of when the connection was last verified

Re-run the acceptance test any time you change CRM providers, update field mappings, or get an alert that a connection has failed repeatedly. A connection that worked at onboarding can still break later if your CRM changes its API or your team edits a required field on their end.

If a provider is listed as in testing in the status table above, ask explicitly whether it's ready for your go-live date, and have a fallback (webhook, Zapier, or email/SMS) ready as backup regardless of the answer.