Skip to content
01 / 06Own capability · in-house system

AI-Driven Outbound & Enrichment Pipeline

The headline

One SDR works 32 leads a day by hand. The same pipeline runs 1,920 — the output of about 60 SDRs — and the only thing it bills you for is API usage.

32/day = 15 minutes per lead × 8 hours. 1,920/day = 4 leads per minute × 60 × 8 hours. 1,920 ÷ 32 = 60.

What you are buying

You are not buying a pile of nodes. You are buying an outbound system that runs every day: each lead is deduplicated before any paid call touches it, a vision model picks the photo that is costing the restaurant orders, a RAG agent writes the diagnosis, the decision-maker’s direct address is resolved — and then the line stops and waits for a human to press [Approve].

What this replaces

  • It is 1am and the SDR is still pasting their sixtieth LinkedIn profile. Finding the lead, choosing a photo, writing the diagnosis, locating the executive’s address and sending takes about 15 minutes, which caps a day at 32. Scaling that means hiring, and a hire is $3,000 a month — sixty of them is $180,000 a month. The invoice arrives before the leads do.
  • The volume arrives and the flow breaks first. A single-threaded marketing workflow runs out of memory somewhere past a thousand records. One external API answers 429 and the whole run dies with no resume, so the only recovery is to start over and pay the API bill a second time.
  • The wrong photo means the email was wasted. A conventional scraper returns the first Google Maps image, which is usually the shopfront. The AI then writes a diagnosis about food photography it cannot see, and the message reads like a broadcast. Send it to info@ and the delivery status never comes back, so nobody learns who was worth following up.

Architecture

AI-Driven Outbound & Enrichment Pipeline — architecture wireframeBlock diagram in three stages, trigger to brain to action, marking the blocking gate and the reuse loop on the main line.01TRIGGERn8n Code Nodecity × category matrixApify crawler clustermulti-source captureTwenty CRM dedupeDomain / PlaceID key02BRAINAgent A · Gemini Flashpicks the weakest food shotAgent B · Dify RAGBauhaus guide + case libraryApollo.io enrichmentARR · headcount · direct email03ACTIONChefShot Render APIBefore / After comparisonPersonalised HTML emaildiagnosis + render attachedHITLhuman approve gateDelivery · /api/trackstatus written backWebhook → Dify intentCRM marked Hot Leadasync ·producer-consumer1.5s token bucket+ 429 backoffCACHE HITDEDUPE_HIT · skippedn8n · Dify · Apify · Apollo.io · Twenty CRM · PostgreSQL · FastAPI · Gemini Flash

Three decoupled stages. The deduplication barrier sits before any paid API call; the human approval gate sits on the main line between composition and delivery.

Guardrails

  • The AI is not allowed to send. High-value or low-scoring ICPs never go out automatically: n8n pushes an interactive card — original photo, diagnosis, redraw, executive details — to Slack or Feishu, and the pipeline releases delivery only after a human presses [Approve]. Unapproved leads wait in the state pool indefinitely.
  • A sliding-batch worker with a token bucket and resume. A scheduled workflow pulls 20 leads every 5 minutes, so the measured cadence is 4 per minute. Outbound calls pass through a 1.5-second token bucket and retry on 429 with exponential backoff, so rate limiting does not break the run. The worker resumes from the state pool after an interruption instead of restarting from zero.
  • Telemetry and cost limiting. Node duration, token spend and failure stacks are written back to the CRM, and a global alert fires when a day’s spend crosses its waterline. Deduplication runs on Domain and Place ID before anything reaches the AI stage.
  • Producer, Enricher and Consumer are three separate pipelines. When one is rate-limited or stuck, the other two keep working their own state pools — no single 429 takes the line down.

What you end up holding

  • Enterprise automation blueprint — the n8n workflow JSON matrix, importable into your own private cloud and split into Producer, Enricher and Consumer.
  • Agent logic configuration — the Dify DSL export, including system prompts, the output schema and the retrieval knowledge base.
  • CRM governance and tracking — the CRM object-model configuration plus the interface documentation for the self-hosted tracking gateway that writes delivery status back.

4 to 6 weeks, from core-path mapping and agent prompt tuning through the async concurrency architecture and tracking deployment. A planning range, not a contract commitment.

Stack

Orchestration
n8n · Dify
Data
Twenty CRM · PostgreSQL · Apify · Apollo.io · Firecrawl
Delivery
FastAPI tracking gateway · Slack / Feishu cards · HTML email

The figures, with their arithmetic

3 seconds per lead
Timestamps from the n8n execution log. The same chain takes a person 15 minutes.
15 minutes per lead — the manual baseline
Self-measured, single run: find, choose a photo, write the diagnosis, locate the executive, send. This is our own baseline, not a client measurement.
300×
900 seconds ÷ 3 seconds. Same lead, same work, 300 times faster.
4 leads per minute
20 leads ÷ 5 minutes, the sliding-batch cadence. A person manages one every 15 minutes.
1,920 leads a day
4 per minute × 60 × 8 hours. One SDR does 32.
32 leads a day
15 minutes per lead × 8 hours. That is the manual ceiling; the pipeline’s is 1,920.
≈ 60 SDRs, equivalent
1,920 ÷ 32 = 60. A whole outbound team’s throughput.
≈ $180,000 a month in payroll avoided
60 people × $3,000 a month, using the market rate for an SDR as the baseline. What you pay instead is API usage.
Designed for 100k+ records
A design capacity, not a measurement. The measured cadence is the 4 leads per minute above. Both statements belong together.

The same shape, three other problems

This is the part that matters if the featured use case is not yours: the same architecture pointed at three unrelated situations, none of them a variation on the case above, and none of them requiring a rebuild. These are transfer directions rather than delivered engagements — the system above is what we have run, and the three below are what its shape solves next. We label the difference rather than blur it.

  • B2B SaaS and cross-border DTC

    scrape merchants still running an old site builder, have the AI read the UX faults in their storefront, resolve the e-commerce director through Apollo, and send out a UX teardown with a Figma concept redesign.

  • Executive search and senior recruiting

    watch a target competitor for changes in core personnel, pull the candidate’s LinkedIn and compare it against the JD library, generate a tailored approach email, and write delivery status back to the CRM.

  • MCN and creator marketing

    scrape YouTube and TikTok creators in batches, have the AI read their recent content performance and audience profile, and send a sponsorship invitation written to fit that person’s persona.

Have a system that needs building?

Write down the situation. You get a written, specific response: no calendar, no discovery call, no fifteen minutes of introductions.

Status

Built in-house. This is a tool we built for ourselves to prove our own outbound orchestration, not a client engagement — no external organisation runs it. It is live and running in our own stack.

Built in-house. Running in our own stack.

Read the full architecture, and where it breaks at 100k

Ready to build a system?[ Send a Brief ]