Contact Us

Work / AI Agents / Inbound Lead Intake

Inbound Lead Intake Every lead recorded, scored and delivered.

Takes every lead from your forms and email, cleans and de-duplicates it, scores it by rules you can read, and delivers it to your CRM without losing one. This page shows what it does and how it is built. Every real engagement is fitted to your documents, systems and rules.

Lead intakeSample data
LeadResultWhy
Business email, phoneDeliveredScored high, sent to the CRM
Free mail, short noteDeliveredScored low, sent with its score
Same person, same sourceDuplicateNot entered twice
Missing emailQuarantinedKept for review, not delivered
The pipeline

How one lead travels through it.

A lead is saved the moment it arrives, so nothing later can lose it. Each stage after that is a plain, testable step.

01ReceiveSigned request witha timestamp02Store rawSaved first, so any stepcan be run again03ValidateMalformed leads arequarantined, kept04NormaliseNames, emails andphones in one shape05De-duplicateSame person, samesource: entered once06ScoreRules you can read,stored with the lead07Record and queueLead and delivery jobin one transaction08DeliverTo your CRM; retried,then set asideNo language model in the pipeline · every stage is plain code
Fig. 1
  1. ReceiveA signed webhook with a timestamp, so a captured request cannot be replayed.
  2. Store the raw eventSaved before anything else, so any later step can be run again.
  3. Validate and normaliseMalformed leads are quarantined and kept. Names, emails and phone numbers are put in one shape.
  4. De-duplicateThe same person from the same source is recognised and not entered twice.
  5. ScoreA rule-based score from signals such as a business email, a phone number, a company and the length of the message.
  6. Record and queueThe lead and its delivery job are saved together in one transaction.
  7. DeliverA background worker sends it to the CRM, retrying with backoff and setting aside what keeps failing.
States

Where a lead can be, and where it can go next.

A lead ends in one of a few places, and none of them is "lost". Failures are kept with their reason so a person can look.

receivedvalidatedrecordedpendingdeliveredquarantinedduplicateretryingdead letterA dead delivery stays in the queue with its error, and can be requeuedretry
Fig. 2
The system

Intake, queue, and a worker that does not give up.

The lead and its delivery job are saved together, so a crash between them cannot lose a lead. The CRM sits behind one adapter, so changing it changes one file.

FORMS · EMAIL · WEBHOOKSLead sourcesSigned request witha timestampFASTIFYIntake APISignature, rate limit,validationCODEPipeline stagesNormalise, de-duplicate,score by rulesPOSTGRESDatabaseRaw events, leads,quarantine, delivery queueJOBRetention and erasureRedacts raw payloads;deletes on requestOPERATIONSHealth and metricsProtected endpoint; alertson stuck deliveriesDESTINATIONYour CRMHubSpot adapter orany HTTP endpointWORKERDelivery workerRetries with backoff;dead-letter listDashed: the worker takes jobs from the database
Fig. 3
What it does

The parts that do the work.

Transparent scoring

Rules a salesperson can read and change, not a black box. The score and its inputs are stored with the lead.

CRM delivery

A HubSpot adapter that finds the contact by email and updates it, or creates it, plus a generic HTTP destination for other systems.

Delivery that survives failure

At-least-once delivery with an idempotency key, retries with backoff and a dead-letter list you can inspect and requeue.

Operations

Rate limiting, health checks, a protected metrics endpoint and alerts on stuck deliveries.

Rules it keeps

Written down first, then enforced in code.

  • Email and forms only. No phone calling, which keeps calling-compliance questions out of scope.
  • Nothing is lost silently. A failed delivery is retried, then set aside with its error, never dropped.
  • Retention is a setting. Raw payloads are redacted after a set time and leads are deleted after a set period you choose.
  • Erasure is built in. One command removes a person from every local table. The CRM copy is removed in the CRM.
How it is built

Plain parts, chosen to be swapped.

TypeScript (strict) on Node · Fastify · PostgreSQL · Zod · Docker

Your data, your decision

Where your data lives, and which model ever sees it, is your decision. We design to it.

The pipeline has no language model in it, so no lead data goes to an AI provider. Raw events, leads and the delivery queue sit in your own PostgreSQL, in the region you pick. The only place data leaves is the CRM you choose.

  • In your own cloud account, in the region you name.
  • On your own servers, with nothing in our hands.
  • With a language model that runs on your hardware, so no data goes to an AI provider.
  • With a hosted model in a region you approve, under the terms you choose.

Australia

The Privacy Act 1988 and the Australian Privacy Principles. Principle 8 covers sending personal information overseas: the sender stays accountable for how it is handled there. Some sectors and government work require data to stay onshore.

New Zealand

The Privacy Act 2020. Information privacy principle 12 limits disclosing personal information to a body outside New Zealand unless it is protected to a comparable standard or the person has agreed.

European Union

The GDPR. Moving personal data outside the EEA needs a legal basis for the transfer. Hosting and model endpoints inside the EU avoid the question.

United States

No single federal privacy law. State laws such as California’s CCPA, and sector rules such as HIPAA for health and GLBA for finance, decide what applies. Contracts often require US-only processing.

This is a summary to explain how we work, not legal advice. Your own counsel confirms what applies to you, and we build to what they decide. More on the privacy page.