Roofing Lead Routing

How a roofing enquiry finds the correct contracted service territory

Every enquiry is checked against two pieces of information — the property's ZIP code and the service requested — and those two together determine which territory it belongs to. A territory is a defined set of ZIP codes tied to a written agreement with one roofer, not a city name or a radius drawn loosely around a map pin.

The lookup, step by step

1. The homeowner's ZIP or town is captured from the call, form or chat.
2. The ZIP is checked against the set of ZIPs assigned to a territory.
3. If the ZIP matches a territory, the requested service is checked against that territory's assigned roofer's accepted service list.
4. If both match and the territory is active (not paused), the enquiry is routed to that roofer's assigned delivery channel.
5. If the ZIP doesn't resolve to any active territory, or the territory exists but is paused, the enquiry is held or routed to a waitlist rather than sent nowhere.

A ZIP that's never been captured for a prior enquiry doesn't block the process — the enquiry is still saved, and the ZIP match is attempted with whatever was reported. If the homeowner reports a ZIP that's clearly wrong or a town name instead of a code, that's noted in the record rather than silently guessed into the nearest territory.

Matching repair, replacement and specialist work to eligible partners

A ZIP match alone doesn't route an enquiry — the service requested also has to match what the assigned roofer in that territory has agreed to accept. A roofer who accepts repair and replacement work but not commercial coating, for example, won't receive a coating enquiry even if the ZIP is squarely inside their territory.

Why the service match matters

• It keeps enquiries aligned with the work your team actually wants and is set up to perform.
• It prevents a specialist request — multifamily, industrial, HOA, coating — from landing with a roofer who only does residential repair and replacement.
• It gives the network an honest answer when a service in a territory has no eligible partner yet, rather than forcing a mismatch.

Your accepted-service list is something you set and can review — it isn't inferred from past jobs or guessed from your company name. If a service category isn't on your list, an enquiry for that service in your territory either waits for a different eligible partner to be assigned, or doesn't route at all, depending on how the territory is configured.

If your team adds a new accepted service mid-agreement — taking on multifamily work for the first time, for example — that update is applied going forward, not retroactively to enquiries already captured before the change. Confirm the effective date of any service-list update with your account contact so expectations line up with what actually starts routing.

Using estimator availability without breaking exclusivity commitments

Routing checks your territory and service eligibility — it does not check your estimator's personal calendar or manage crew scheduling. Appointment booking is a separate layer: the public booking page shows the homeowner three to six real open times pulled live from the assigned roofer's calendar, with a live check against Google Calendar so already-booked slots never appear, and the reservation itself is atomic so two homeowners can't claim the same slot.

Where routing and booking meet

Once an enquiry routes to your territory, the homeowner is shown booking options tied to your calendar, not a shared pool across multiple roofers. This keeps the exclusivity commitment intact: the territory routing decision and the calendar availability both resolve to the one assigned roofer, never a mix of partners competing for the same slot.

If your calendar has no open slots visible for the requested window, the homeowner either sees the next available real slot or is offered a callback request instead of a booking. The AI receptionist can record an appointment request without promising a specific slot — it does not fabricate availability to avoid a dead end in the conversation.

• Routing decides which roofer an enquiry belongs to, based on ZIP and service.
• Calendar OS decides which times are actually open for that roofer, checked live against Google Calendar.
• Neither system claims to handle crew dispatch, job scheduling, or ERP functions — those stay outside this platform.

Because booking depends on your calendar being accurate, a stale or disconnected calendar is one of the more common reasons a homeowner sees fewer open slots than you expect, or none at all. Checking that the connected calendar reflects your real availability is a simple step worth confirming whenever booking volume looks unusually low for a territory that should be active.

What happens when a call or lead delivery fails

A failed delivery is treated as an event to recover from, not a lost lead. Every push to your CRM — whether by webhook, Zapier, a native connection, or email/SMS fallback — carries a status: queued, sent, delivered, or failed, and a failed status triggers a retry with backoff rather than silently dropping the record.

The delivery fallback sequence

1. The lead attempts delivery through your primary configured channel (CRM integration, webhook, or native connection).
2. If that attempt fails, the system retries with backoff rather than immediately giving up.
3. If retries don't succeed, an email or SMS fallback delivers the lead details directly so the record reaches a person even if the integration is down.
4. A fallback alert notifies your team that the primary delivery path failed, so the integration issue itself can be fixed.

A similar logic applies to calls: if the AI receptionist or ring-first forwarding can't reach a live person for an urgent issue, the system gives the caller an honest message about the failed transfer rather than pretending someone is available, and alerts your team so a next-day or manual handoff can happen through the lead record's timeline.

Delivery failures are logged with enough detail — which channel failed, at what time, and how many retries ran — that a pattern of repeated failures on one integration is easy to spot and escalate, rather than looking like a series of unrelated one-off incidents.

Handling overlapping ZIP codes, repeat callers and reassignment

Overlapping ZIP codes and repeat callers are handled by the same underlying mechanics as a first-time enquiry: a ZIP and service match to resolve the territory, and a duplicate check against existing opportunities before a new record is created.

Overlapping or boundary ZIPs

Where a ZIP sits near a boundary between two territories, the assignment follows the territory definition on file, not an estimate of which roofer is "closer." If a ZIP genuinely isn't assigned to any territory yet, the enquiry is still captured and flagged rather than forced into the nearest available match.

Repeat callers and existing opportunities

A homeowner who calls twice about the same roof problem is matched against the existing opportunity by phone number, and the system flags the second contact as a duplicate rather than creating a second lead record and billing event. This protects both the territory's lead count and your pay-per-call credits from being charged twice for one job.

Capacity pauses and waitlists

If a territory's assigned roofer pauses intake — for example, because they're at capacity — new enquiries for that territory don't simply vanish. They're held on a waitlist rather than routed to a different, non-contracted roofer, preserving the exclusivity the agreement is built on.

Admin reassignment

Lead caps, the maximum number of roofers routed per market, and reassignment of a territory when an agreement ends are managed through the network's internal admin controls. Those internal mechanics aren't exposed publicly here — what matters to your team is that a territory pause routes to a waitlist, not to a competitor, and that reassignment only happens under the written agreement's terms.

In practice, most reassignment questions come up around contract renewal or when a roofer's capacity changes significantly — expanding into a new crew, or scaling back after a slow season. Those conversations happen through your account relationship, not through an automated rule the platform applies without notice.

Proving a routing rule works before accepting live enquiries

Before a territory goes live for your account, the routing setup for it can be tested the same way any new integration should be: with a scenario test that confirms ZIP and service matches resolve correctly, the right person receives the delivery, and the fallback actually fires when it's supposed to.

What a scenario test covers

1. Submit a test enquiry for a ZIP and service inside your territory and confirm it routes to your CRM with a delivered status.
2. Submit a test enquiry for a service outside your accepted list and confirm it does not route to you.
3. Simulate a failed primary delivery and confirm the retry and fallback alert both fire.
4. Submit a duplicate test contact and confirm it's flagged rather than creating a second billable record.
5. Confirm your calendar correctly shows (or correctly hides) availability for a test booking request.

Use the routing acceptance worksheet below to document each test and its outcome before a territory is treated as fully live for your account. This is the same kind of verification you'd want from any integration partner — proof the rule behaves as described, not just a verbal assurance.

Documenting these tests also gives both sides a shared reference if a dispute comes up later — for example, if a lead you expected never arrived. Instead of relying on memory of how the integration was supposed to work, you can point to the recorded test outcome and compare it against what actually happened on the live enquiry.