Skip to main content
Case study · CRM + operations

Inspection Revenue Engine

Production GoHighLevel and n8n system for a multi-inspector home-inspection company.

Live in production2026

GoHighLevel · n8n · Python · Supabase · Spectora

A
Live n8n production dashboard: 318 production executions, 0 failed, 0% failure rate, 0.7 second average run time, with the Spectora-to-GoHighLevel event workflows published.
  1. 1Every production run is logged here. Zero failed, at a 0 percent failure rate.
  2. 2Three event workflows: every booking, report, and payment writes into the CRM automatically.
  3. 3A separate alerting workflow emails me the moment any event fails.
The live n8n dashboard, June 2026. These are the real numbers the stats above are read from.
0
failed events, every audit
May 2026
in production since
318
production executions
0.7s
avg run time
~8,000
contacts migrated
6,500+
opportunities migrated
Context

A multi-inspector US home-inspection company ran everything on its inspection software, Spectora, with no CRM underneath. Years of client and agent history sat locked in one tool. No marketing attribution, lead generation by hand, follow-up by memory. Real revenue and real customers, and a history they couldn't market from or report on.

I built the production system around it. A GoHighLevel CRM from scratch, a custom integration bridging Spectora into it over self-hosted n8n, a full historical migration of their book of business, and a marketing-to-revenue attribution layer. It's run in production since May 2026 and carries every real booking, report-delivery, and payment event the business runs.

Constraints

The original scope assumed a two-way sync, data flowing back into the inspection software. Deep discovery killed that assumption. The platform is outbound-webhook-only, with no inbound API and no programmatic write path of any kind. The direction we'd promised was impossible.

Most builders either quote that two-way sync and miss at the deadline, or quietly drop it and hope nobody notices. I put the correction in writing as an explicit scope change while there was still time to act on it, then re-architected around the real constraint.

The data had to migrate clean on top of that. Years of records, with duplicate contacts and phone-number collisions that GoHighLevel rejects at the server. A migration that loses relationship history is worse than no migration.

Approach

Instead of a fake sync, I built forward-direction enrichment. When a booking fires, the bridge looks the agent up in GoHighLevel and creates or updates the contact, and a one-time historical backfill runs through the platform's CSV export path. The client got a complete, continuously updated CRM and no pretend two-way sync.

The integration runs on self-hosted n8n on a hardened Linux VPS. Three production event workflows, booking created, report delivered, and payment completed, route every inspection across a 50-service catalog. Every inbound event dedupes against a composite-keyed Postgres ledger, so vendor retry storms can't double-write the CRM. Phone-number collisions get caught, retried without the colliding field, and tagged for human review instead of failing silently. A separate workflow polls hourly and emails me the moment any event fails.

The attribution layer ties a marketing touch to the booking it eventually drives. Per-event QR codes feed a tagged capture form and a structured nurture sequence, and the booking webhook traces that touch back months later.

Exhibits
B
The Booking Created workflow canvas in n8n, showing the intake, dedup, collision-handling, and opportunity-creation nodes.
  1. 1Every booking enters on the left and dedupes against a keyed ledger, so vendor retries never double-write the CRM.
  2. 2Phone-number collisions get caught, retried without the colliding field, and tagged for review instead of failing silently.
  3. 3On the right the booking becomes an opportunity in the CRM, stamped with the agent who sent it.
Booking Created, one of three production event workflows. It routes every inspection across a 50-service catalog with dedup, retries, and idempotency.
C
The failure-alerting workflow canvas in n8n: a scheduled poll, a real-error filter, and an email step.
  1. 1A schedule kicks it off every hour.
  2. 2It filters for real failures, not routine noise.
  3. 3Then it emails me the moment a production event actually fails.
The failure-alerting workflow. It polls hourly, filters for real errors, and emails me the moment a production event fails.
Status
Status registry
Live
Spectora to GoHighLevel data bridge
Live
One-time historical backfill
Live
Agent and CE nurture intake
Live
Weekly automated health audit
Live
Lifecycle automations
Live
Team operations dashboard, behind auth
Results

Revenue results are the client's private data. I publish capability, not his numbers.

Result

Live in production since May 2026, carrying the business's real booking, report-delivery, and payment events. Real revenue data, not test traffic. A point-in-time read from the live n8n dashboard showed 318 production executions, 0 failed, a 0% failure rate, and a 0.7-second average run time. The residential pipeline alone holds 5,840 opportunities.

The historical migration moved roughly 8,000 contacts and 6,500-plus opportunities with clean deduplication and zero lost relationship history. The engagement is ongoing. The lifecycle-automation milestone is live, and a custom team-operations dashboard runs behind auth on the client's own subdomain.

Stack

GoHighLevel · Spectora (Advanced-tier webhooks) · n8n (self-hosted) · Python · Supabase / Postgres · Resend · Next.js · hardened Linux VPS behind Caddy with auto-TLS