What we're building
This workshop is about a problem that looks simple until the volume arrives. You can pull thousands of businesses from search data. You can enrich those records. You can ask an AI model to score them. None of that automatically gives you a useful sales system.
The useful system begins when each layer has a job. Search data finds the market. Inspection tells you what is actually there. Enrichment adds context. Rules remove obvious bad fits. AI handles the gray area. A database preserves state. The CRM receives only records that have earned the right to become sales work.
That is the architecture we will build. It is not our private production workflow, and it does not expose client credentials, exact qualification thresholds, proprietary prompts, or production JSON. It is the public version of the thinking: enough to understand the system and build a responsible first version.
Why this matters
Most lead automation demos begin too late. A form arrives, an AI model assigns a score, and the workflow sends a notification. That can be useful, but it avoids the harder question: where did the business come from, what do we know about it, which facts are trustworthy, what should disqualify it before AI gets involved, and what has to survive if the workflow fails halfway through?
Those questions matter when you are dealing with a few hundred records. They matter much more when the source set grows into the tens of thousands. In one system pattern we designed, the discovery layer could start with roughly 15,000 to 25,000 local-business records. At that scale, a workflow is no longer a clever chain of nodes. It is a data and decision system.
The architecture
The public architecture has six stages: discover, inspect, enrich, qualify, persist, and route. The order matters because each stage should reduce uncertainty before the next stage becomes more expensive.
Discovery begins with search and local-business data. DataForSEO can supply SERP and Maps-related signals that help define the addressable market. We are not asking an AI model to imagine which businesses exist. We are starting with structured market evidence.
Inspection looks at the business behind the record. A website can exist and still be a poor fit. A site may be broken on mobile, slow, thin, outdated, missing obvious conversion paths, or built on a stack that tells us something about the likely project. Lighthouse-style quality signals and technology detection can turn a name and URL into a more useful picture.
Enrichment adds company context. This is where employee range, revenue range, industry, location, technology, and other verifiable business facts can help separate an interesting company from a company that actually matches the intended ICP.
Qualification then uses two different kinds of judgment. Hard rules handle facts that should not be subjective. If a company is outside the geography, outside the company-size range, in an excluded category, or missing a required attribute, a deterministic rule can make that decision. AI is more useful for the ambiguous layer: interpreting the company, summarizing why the fit is strong or weak, and explaining the reasoning in a structured format.
Persistence is what keeps the workflow from becoming fragile. The system needs to know what it has already seen, what stage each record reached, which enrichment succeeded, which step failed, what should retry, and what should never be processed twice. That is the point where a spreadsheet can stop being a convenient interface and start becoming the wrong source of truth.
Routing is last. A CRM should not be the junk drawer for every raw record the workflow can find. It should receive a business only when there is a reason for a person or downstream sequence to do something with it.
Start with discovery
The first build step is to define the market you actually want. The temptation is to begin with the biggest possible keyword list or geographic radius. Resist it. A discovery workflow is only as useful as the question it is answering.
If the commercial target is independent roofing companies in a defined size range, the system should encode that intention before the first API request. The locations, categories, query families, deduplication key, and exclusions should all reflect the market you mean to study. Pulling 25,000 records feels impressive. Pulling 4,000 records that are much closer to the real buyer can be far more valuable.
Inspect the business
A company record should not become a sales lead because its category name looks promising. The next layer inspects the actual digital property.
We can collect performance signals, confirm whether the site resolves correctly, inspect mobile behavior, identify obvious technical problems, and detect technology where that context matters. The point is not to turn Lighthouse into a lead score. A fast website can still be strategically weak. A slow website can still belong to a company that is completely wrong for the offer.
Inspection creates evidence. Qualification decides what the evidence means.
Add useful context
Enrichment should answer questions the source record cannot. How large is the company? Does it appear to operate in one location or many? What technologies does it use? Is the site running a platform we support? Does the business appear to sell the kind of service where our work has enough economic value to make outreach reasonable?
The important word is useful. More fields do not automatically create a better lead. Every enrichment step costs time, money, or both. If a field never changes a decision, remove it.
Separate the rules
This is where many AI qualification systems become needlessly risky. They give the model one giant prompt, hand it the record, and ask for a score from zero to one hundred. That produces something that looks precise without necessarily being controlled.
We prefer to separate deterministic rejection rules from contextual AI judgment. The rules handle the boundaries the business already knows. The model handles the parts where language and context are genuinely useful.
That means the workflow can explain why a lead disappeared. It also means a prompt change cannot silently override a hard commercial rule that was supposed to stay fixed.
Persist the state
Early versions of automation often use Google Sheets because it is visible, familiar, and fast to set up. There is nothing wrong with that. The problem begins when the sheet is being asked to behave like a queue, a database, an audit log, and a retry engine at the same time.
In our own system development, the write volume eventually exposed that problem. Too many queued pushes made the spreadsheet layer the bottleneck. Moving the durable state toward PostgreSQL created a better place to track processed records, retries, deduplication, statuses, and downstream delivery.
The lesson is not that Sheets is bad. The lesson is that a tool can be excellent at one stage of a system and become the wrong tool when the operating requirements change.
Route with purpose
Once a record has passed the evidence and qualification layers, it can move into the system where the next action belongs. That might be GoHighLevel, HubSpot, Salesforce, an Airtable review queue, or another operating layer.
The CRM record should arrive with context. The salesperson should be able to see why the company was qualified, what the system observed, which facts are verified, and what the next useful action might be. If the workflow only creates a contact and leaves the human to repeat all of the research, the automation stopped too early.
Where scale hurts
Scaling does not usually fail because one node is missing. It fails because volume exposes assumptions that were harmless when the workflow was small.
Rate limits matter. Retries matter. Duplicate records matter. API cost matters. Long-running executions matter. A record that fails after enrichment but before routing needs a known state. A record that reappears next week should not silently become a second opportunity. A provider outage should not erase the distinction between “not a fit” and “not processed.”
This is why the architecture matters more than the screenshot of the workflow canvas.
What stays private
The public workshop explains the system without publishing the parts that create an avoidable competitive or security risk.
We do not publish production credentials, private client data, exact ICP thresholds, proprietary scoring prompts, confidential data contracts, production database details, or a drop-in copy of the live workflow. The public build is educational. The private system is operational.
That boundary also makes the workshop better. Instead of asking people to copy our exact machine, we can teach them how to make the decisions required to build one that fits their own business.
What to measure
The useful metrics begin before the CRM. Measure how many source records were found, how many were unique, how many could be inspected, how many were enriched successfully, how many were rejected by hard rules, how many needed AI judgment, how many reached human review, and how many became real opportunities.
Then connect the system to sales reality. Which qualified records produced conversations? Which became pipeline? Which criteria predicted quality and which merely sounded intelligent? A qualification system should be allowed to learn from the people who actually talk to the market.
Workshop version
In the live build-along, we would create a smaller, sanitized version of this architecture using DataForSEO and n8n. The goal is not to recreate a 25,000-record production machine in one session. The goal is to leave with a working model that demonstrates the architecture: source data, inspection, enrichment, controlled qualification, persistent state, and a useful destination.
That is enough structure to build the first serious version without pretending that a collection of connected nodes is already a production system.
Next useful step
If you want this workshop taught to your team, community, or technical audience, use the workshop request page and tell us what your audience should be able to build when the session ends. If you are more interested in the Blue Bell architecture itself, explore the DataForSEO × n8n Lab and the systems notes connected to it.