Case study · Automation · In build

Inbound Lead Conversion: every lead booked once, none lost.

The deterministic core of an AI lead-conversion system for service businesses. A lead comes in, is deduplicated, qualified against the business’s own rules, checked against its service area and calendar, booked exactly once, synced to the CRM and queued for a confirmation text, with every step on an audit trail.

Stage: Phase 1 of 10
Test scenarios: 9
Built with: TypeScript · Postgres
Vendors: Mocked, on purpose

lead · trace_id 7f3c…

Webhook: HVAC repair, 78701

✓ event.dedup a UNIQUE key on the event, not a guess

✓ lead.upsert one person, matched by phone or email

✓ crm.contact synced, or queued for retry

✓ lead.qualified the business’s own rules

✓ slot.recheck availability checked again before booking

✓ booking exactly once, by idempotency key

✓ sms.queued only after suppression and consent checks

Booked. Confirmation queued.

The engineFastify · Postgres 16 · Zod

One lead, seven steps, one trace

Phase 1 proves the part that has to be right before any AI voice or vendor is plugged in: that a lead is never lost, never double-booked and never contacted against its consent. Every step writes an audit record under the lead’s trace ID, so one query shows exactly what happened and why.

Canonical lead events arriving by webhook from any channel
20 tables: leads, identities, consent, appointments, outbox, dead letters, callbacks, audit
Adapters for the CRM and the calendar, so vendors swap in without touching the core
Multi-tenant: each business brings its own services, area and rules

View the source on GitHub ↗

Built for the bad days

Nine tests, mostly for things going wrong

The happy path is one test. The rest check what happens when a webhook repeats, a vendor is down or a lead should not be booked at all.

Duplicate webhookBooked exactly once
The same event sent twice returns DUPLICATE, and a repeated booking under a new event id still makes one appointment.
Calendar outageNo invented slots
If the calendar cannot answer, a callback task is created. Availability is never made up.
CRM outageThe lead is kept
The booking still goes through; the CRM write waits in the outbox until the CRM is back.
Unsupported serviceA person decides
Anything the rules do not cover is escalated to a human instead of guessed at.
Outside the areaDeclined, not booked
A lead outside the service area gets an approved decline, never an appointment the team cannot keep.
Suppressed numberNo message queued
Suppression is checked before any text is written, so an opted-out number is never contacted.

Honest status

What is real, and what comes next

Qualification is rules for now, in the same structured shape a model will return: the model will suggest, and the engine still decides. When voice arrives, nothing downstream changes.

Part	Status	How
Lead event schema and validation	Real	Zod
Event and person de-duplication	Real	Postgres UNIQUE constraints
Exactly-once booking	Real	idempotency key plus a recheck
Consent ledger and suppression	Real	checked before any outbound message
Outbox and dead letters	Real tables	the delivery worker comes next
Qualification	Real, rule-based	the slot a model’s structured output will fill
CRM and calendar	Mocked	adapters for HubSpot / GoHighLevel and Google Calendar
Voice (Retell), SMS and email (Twilio, Resend)	Next phases	confirmations are queued, not sent
Human transfer	Phase 6

Work with us

Want something like this built?

Automate your lead intake → See all work

This system is offered as a product: Lead Responder. Meet who builds it.