Build it

Wiring marketing to dispatch: the ServiceTitan, FieldEdge, and Housecall Pro integration guide

Marketing systems and dispatch systems were designed in different decades by different people for different problems. Connecting them is where most home services platforms quietly lose 10 to 20 points of conversion. Here's the architecture that holds up in production.

By Chris SheppardJune 27, 202610 min read

A lead comes into a paid search campaign at 11:47 AM. The form submission fires. The marketing dashboard counts it as a conversion. The lead lands in HubSpot, which assigns it to a queue. A rep picks it up at 12:18 PM, books a service appointment, and types the booking into ServiceTitan. At 2:30 PM the dispatcher reviews the schedule and notices the new appointment was booked into the wrong service area. The truck won't arrive on time. The customer cancels at 3:15 PM.

Marketing reports a conversion. Operations reports a no-show. Finance reports zero revenue. The CRM reports a lead. The dispatch system reports a cancelled job. Five systems, five different stories about the same customer, and no one notices the disconnect until next month's CAC report shows leads going up and booked revenue going down.

The four wires that have to be live

Wiring marketing to dispatch isn't one integration. It's four. Each one is a distinct failure surface. Each one needs to be designed, tested, and monitored independently.

Lead in. Every paid form, every call, every chat captured to the CRM with the marketing source attached (UTM, GCLID, tracking number).
Booking out. Every booked appointment created in dispatch with the customer record, the service type, the time slot, and the original marketing source preserved.
Outcome back. Every job's completion status, ticket value, and disposition pushed back to the CRM and the attribution warehouse so the marketing P&L reflects what actually happened.
Customer record reconciled. The same customer across marketing, CRM, and dispatch has one identity, not three duplicates with slightly different phone numbers.

Most operators have wire 1 working, wire 2 partially working, wire 3 completely missing, and wire 4 broken in a way nobody has audited. That's the gap.

ServiceTitan

ServiceTitan is the dominant dispatch platform in residential HVAC and the major plumbing operations. Strong API, well-documented integration surfaces, and a marketplace of pre-built connectors that get most operators 70 percent of the way there. The challenges are not technical; they're operational.

Service-area validation is strict. Marketing campaigns running in zip codes outside the dispatch service area generate leads ServiceTitan can't book. The cleanest fix is geo-fencing the paid campaigns to the validated service area in the system.
Time-slot increments differ by service type. A maintenance visit gets a 2-hour window; a replacement quote gets a 4-hour window. The booking flow needs to know which is which before it offers a time.
Customer record matching matters. Same household, two phone numbers, two records is a common failure pattern. The deduplication logic needs to live in the integration layer, not be left to the dispatchers.
Marketing source preservation is manual by default. Custom field added to the customer or job record, populated by the integration, surfaced in reporting. Worth doing on day one; painful to retrofit.

FieldEdge

FieldEdge serves a similar audience to ServiceTitan with a slightly different feature set. API surface is solid but less polished. Same four wires apply. Two FieldEdge-specific notes:

Lead-source picklists are configurable per account. Standardize them at the platform level before any integration work starts; the marketing reporting downstream is only as clean as the picklist values.
Recurring service-agreement creation from a one-time job has well-defined API endpoints. Worth wiring as part of the lifecycle marketing flow: every completed job is an opportunity to enroll in a maintenance plan, and the prompt should fire at the right moment in the post-service customer journey.

Housecall Pro

Housecall Pro is the leader at the smaller-operator end of the market. Cleaner UX than the enterprise systems, lighter integration surface. Excellent for single-location operators up to mid-size multi-location. For platforms approaching 10+ locations, the integration limits start to bite and operators usually evaluate ServiceTitan or FieldEdge.

Webhook-driven integration is the cleanest pattern. Housecall Pro fires events on customer creation, job booking, and job completion. The integration listens and updates the attribution warehouse.
Reporting API is sufficient for marketing reconciliation but lacks the granularity ServiceTitan offers. Compensate by capturing more events at the dispatch boundary and reconciling in your own warehouse.

Service Fusion and the rest

Service Fusion, Jobber, Workiz, and a long tail of dispatch systems are present in the market. Same architecture applies; the integration work is proportional to the API surface quality. Sheppard has built integrations against all of these. The pattern below holds regardless of which system the operator is on.

The integration architecture that survives production

Production-grade integration between marketing and dispatch has three architectural decisions worth getting right up front.

Event-driven, not batch. Real-time webhook + queue-and-replay pattern, not nightly CSV pushes. The marketing operating system needs to know within minutes when a booked job is created or cancelled.
Idempotent writes. Every operation that writes to the dispatch system needs to be safe to retry. Dispatch APIs occasionally time out; the integration needs to recover without creating duplicate bookings.
Reconciliation job nightly. A sweep that compares the dispatch system's source of truth (what actually got booked) against the integration's record of what should have happened. Discrepancies get logged, alerted, and remediated. This is how you catch silent integration failures before they show up in a missed-revenue report three months later.

How Sheppard builds this

Sheppard's Build-it mode includes the dispatch integration layer as a standard capability. We've built event-driven integrations against ServiceTitan, FieldEdge, Housecall Pro, Service Fusion, and Salesforce/HubSpot as the upstream CRM layer. The integration runs inside the operator's perimeter (typically Vercel + Postgres + Supabase), is documented, and is transferable at exit. We monitor sync health continuously, alert on failure, and operate it as part of the marketing function rather than handing the operator a SaaS dependency.

How long does the integration take?

Four to eight weeks for a single dispatch system, end to end: the integration build, the field-mapping decisions, the test coverage, and the production deployment with reconciliation monitoring. For a multi-DMA platform that's standardizing on one dispatch system across all locations, 90 to 120 days because the work scales with the number of accounts and the operational decisions (lead source picklists, service area boundaries, time slot conventions) that need to be aligned platform-wide.

Should the integration be a SaaS we rent or something we own?

Own it. The integration sits at the boundary between two systems you depend on operationally. A SaaS dependency in that position creates a vendor with leverage over the operation. Build the integration once, document it, run it inside the operator's infrastructure, transfer it cleanly if the business sells. Sheppard builds and operates these integrations as part of the engagement; we don't license them.

What happens when the dispatch vendor pushes an API change?

Maintenance windows in the integration layer. The reconciliation job catches API contract changes within 24 hours by detecting unexpected field shapes or missing data. The fix is usually a one-day patch to the integration code. Sheppard treats integration maintenance as part of the ongoing engagement, not a separate billable line; the operator never has to think about it unless they choose to.

Can I use Zapier or a similar tool for this?

For very small operations with light volume, sometimes. For anything with real volume or any platform with multiple locations, no. Zapier is excellent for prototyping but the failure modes in production (silent timeouts, missing idempotency, no reconciliation) become real problems when the integration is load-bearing for revenue. Use Zapier to validate the workflow, build the production integration on infrastructure you control.

How does this connect to the AI call layer?

Tightly. The AI call layer needs the dispatch integration to check real availability and book real slots. If you're deploying both, build them together: the AI calls the integration layer to book; the integration calls the dispatch system. Sequencing them as separate projects usually means rebuilding the booking interface twice.