Building a Real-Time Lead Processor: My Playbook from the AI Engineer World's Fair

The Core Stack: Ingest, Process, Decide, Act

Every solid automation has a logical flow. Don’t just wire up an API call to ChatGPT and hope for the best. For this lead processor, the workflow has four distinct stages. Thinking in these stages keeps the build clean and makes it way easier to fix when something inevitably breaks.

1. Ingest: Get the raw data. In this case, it’s emails from a dedicated inbox where all the badge scans and contact forms are sent. The goal is to grab the body of every new email as it arrives.

2. Process: This is the AI’s job. Turn the unstructured block of email text into structured data. Who is this person? What company? What did they ask? Then, qualify them. Are they a potential customer, a student, or someone trying to sell me something?

3. Decide: Based on the processed data, what happens next? This is simple if/then logic. If the lead is ‘Hot’, do X. If ‘Vendor’, do Y.

4. Act: Execute the decision. Send a Slack message, draft an email, add a row to a CRM, or all three.

This isn’t just theory. It’s a mental model. If a lead doesn’t get a response, I can immediately ask: Did it fail to ingest? Did the AI process it incorrectly? Did the decision logic route it to the wrong place? Was the final action blocked?

Ingestion: Getting Data Out of Messy Emails

The first step is always the least glamorous. You need a trigger. I use Make (formerly Integromat) for this kind of workflow, but Zapier automations or others work too. I set up a simple module that watches a specific Gmail folder. When a new email lands there, the automation kicks off.

This is where you hit your first problem: email formatting is a disaster. You’ll get plain text, fancy HTML signatures, weird disclaimers, and quoted replies from previous conversations. Your job isn’t to parse it perfectly here. Your only job is to extract the main body of text from the newest message in the thread.

My concrete gripe with many no-code tools is how they handle this. Their built-in text parsers are often too basic. They might grab the entire email thread, including signatures and legal boilerplate from the last five replies. You end up feeding a ton of irrelevant garbage to your LLM, which costs more money and, worse, confuses the model. I had to add an extra step using a bit of regex to strip out common reply patterns (like ‘On Tue, Jan 5, 2026 at 2:15 PM John Doe wrote:’) before sending the content to the next stage. It’s an annoying but necessary cleanup step.

What Most Guides Get Wrong About Lead Qualification

Here’s the biggest mistake I see. People take that messy email body and throw it at a single, complex prompt asking the AI to do everything at once: extract the name, find the company, guess their title, summarize their request, and assign a lead score.

This is lazy and it’s fragile. It fails often.

A much better approach is a two-step prompt chain. It’s more reliable, cheaper to run, and a thousand times easier to debug.

Step 1: Extraction. The first LLM call has one job: convert the unstructured email blob into a clean, structured JSON object. That’s it. It doesn’t judge, it doesn’t analyze, it just extracts facts.

Step 2: Qualification. The second LLM call takes the clean JSON from the first step as its input. Its job is to make a decision. Using the structured data, it determines the lead’s category. This separation of concerns is fundamental. The extraction model can be dumber and faster (like GPT-3.5-Turbo), while the qualification model can be smarter if needed (like GPT-4o), saving you money on most calls.

The Prompt Chain: A Concrete Example

Let’s make this real. Here are the prompts I actually use, simplified a bit for clarity. I run these using the OpenAI module in Make.com.

First, the extraction prompt. It’s very specific and tells the model to output only JSON. This is key.

The output of this is clean data. Now, I feed that clean data into the second prompt for qualification.

My concrete love: This two-step process. When a lead is miscategorized, I can look at my logs (I use Airtable for this) and see exactly where it went wrong. Was the initial data extraction bad? Or was the qualification logic flawed? With a single prompt, you’d just be guessing.

Is a Full AI Agent Framework Overkill for This?

With all the hype around agentic workflows, a common question is whether you need a complex ai agent framework like LangChain or CrewAI for something like this. Honestly, for a defined, linear process like lead qualification, it’s like using a sledgehammer to hang a picture. Those frameworks are powerful when you need an AI to reason, plan, and use multiple tools to accomplish a complex goal with an unknown path.

This isn’t that. This is a production line. Email in, decision out. The path is known. Using a simpler tool like Make or Zapier gives you a visual canvas, is faster to build, and is far easier for anyone on your team to understand and maintain. This is an operator playbook, not a science experiment. You want reliability and simplicity for core business processes. Save the complex agent frameworks for tasks that actually require dynamic planning, not just a sequence of API calls.

How to Debug When Your AI Starts Hallucinating

It will break. Be ready for it. An LLM will eventually give you a weird output that crashes your workflow. Here’s how you handle it.

First, log everything. Every single run of your automation should write to a log. I use a simple Google Sheet or an Airtable base. It records the input email, the output of the extraction prompt, and the final qualification category. Without logs, you’re flying blind. When a user says “I never got a response,” you need to be able to look it up and see what happened.

Second, check your model’s ‘temperature’ setting. This controls randomness. For data extraction, you want zero randomness. Set the temperature to 0 or 0.1. You want the most deterministic, boring output possible. For the qualification step, a little creativity might be okay, but I still keep it low, around 0.3.

Third, remember: garbage in, garbage out. The most common point of failure is the initial data. A lead from the ai engineer world’s fair once had a crazy HTML signature with five different addresses and phone numbers. The extraction prompt got confused and merged them all into a single garbage string. The fix wasn’t a better prompt; it was better pre-processing to clean the input text before the AI ever saw it.

The Final Step: Routing and Response Automation

Once the AI has made its decision (‘Hot’, ‘Warm’, etc.), the final step is easy. Using a simple router or switch module in Make.com, I define the path for each category.

• Hot: Immediately sends a message to our internal Slack channel with the lead’s details and a link to the email. This creates immediate visibility for a human to take over.
• Warm: Adds the lead to our CRM (we just use an Airtable base) and sends an automated, but slightly personalized, email reply. The email template pulls the person’s name from the extracted data. It’s not perfect, but it’s a fast and relevant first touch.
• Cold/Vendor: Automatically archives the email and adds a tag in Gmail. No notification needed. This keeps the inbox clean and focused on real opportunities.

I run this entire system on a Make.com Core plan, which is about $19/month. For the amount of manual triage and response time it saves, that price is a steal. The OpenAI API costs are literally pennies per lead. This is the kind of profitable automation that defines a modern operator. It’s not a flashy demo; it’s a quiet, reliable workhorse.

If you want the deep cut on this, deeper coverage of AI agent platforms.

You can build this entire system following the steps above. It will take some trial and error, especially with the prompts. If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this entire workflow as a ready-to-deploy ai automation blueprint. You can find it at deepusecase.com/vault.