Inbound Leads, Researched and Routed Before the Prospect Closes the Tab

The problem

Every inbound lead arrived looking identical: a name, an email, a short message.

Which meant the founder with an approved budget sat in the same queue as someone browsing out of curiosity. To know who deserved the first call, someone had to research each company by hand — its size, its industry, whether the message meant anything. That work takes time, and it usually got done after the lead had already gone cold.

The ask wasn't “add AI.” The real requirement, which surfaced during scoping, was stricter: a system safe enough to run unattended on real revenue-bearing leads — one that never pings the team twice for the same person, never drops a lead silently, and says something the moment it breaks.

What the system does

One system takes over the moment a lead arrives.

1. It filters before it spends. Personal email addresses skip the paid company-research step entirely — budget goes only toward leads worth researching.
2. It researches the company. Size, industry, funding, age — none of which was in the form submission.
3. It scores and tiers. Every lead gets an A/B/C tier and a 0–100 buying-intent score, each with written reasoning a salesperson can read and argue with — not an unexplained number.
4. It routes to the right place. A-tier hits the urgent sales channel with a follow-up task due in 4 hours. B-tier goes to the standard channel with a 2-day task. C-tier enters long-term nurture with a 7-day task.
5. It writes the first sentence. Every notification carries an opening line written for that specific lead, so nobody starts from a blank page.
6. It logs everything. Each processed lead becomes one row in a sheet the client opens directly, without touching the technical system.

What it looks like in practice

Every screen below is a live run, not a mockup.

What makes it safe to leave running

Most systems like this stop at “lead arrives → AI scores it → someone gets a message.” This one ships with three safeguards, each tested against real failure conditions before handover.

Instant failure alerting

When something breaks, an alert names the exact step that failed, why, and links straight to the failed run. Verified by deliberately breaking the live system and watching a real alert arrive — not a simulated one.

Duplicate blocking

Double form submissions are a fact of life. The system blocks the same lead being processed twice within 24 hours — before it can spend research budget, interrupt the sales team a second time, or create a duplicate task. Verified by firing an identical submission twice: the first processed fully, the second stopped cold with no side effects.

A readable audit trail

Every lead becomes one row: date, identity, tier, score, data confidence, and where it was routed. The client reads it directly — and the same table is the memory the duplicate check relies on. One artifact, two jobs, nothing to keep in sync.

Three decisions that changed the outcome

The AI proposes; code decides

During testing, the model was instructed not to exceed a certain score when company data was thin. It exceeded it anyway. A model costing roughly 13× more exceeded it by a wider margin. The fix wasn't paying more — it was a hard limit enforced in code, which has held on every run since.

The commercial consequence: the cheaper model became the correct choice, because the guarantee no longer depended on the model's judgment at all.

Cost control is architectural, not an afterthought

Personal email addresses never reach the paid research service. Weak matches are rejected at the source, before they are paid for. Spend tracks the value of the lead rather than the volume of traffic.

A silent failure was caught in testing, not production

During duplicate-blocking tests, a first-time lead — under one specific condition — could exit the pipeline with no error message at all. Every genuinely new lead would have vanished without a trace. It surfaced because failure paths were tested, not just success paths, and it was fixed before launch. That is the concrete value of testing what can break rather than only what should work.

How it was verified

A deliberately awkward test set: a large global company whose contact was not a decision-maker (correctly scored low despite the company's size), a personal email address, a high-urgency lead with thin company data (the score-limit stress test), and clean A- and B-tier profiles. Each one was checked in four places — the notification, the CRM record, the created task, and the audit log.

Then the failure paths: a real production failure to prove the alerting, and a two-shot submission to prove duplicate blocking.

Results

• A complete manual triage step is now automatic: every lead is researched, scored, routed, tasked and logged with no human involvement.
• Form submission to team notification in under seven seconds, measured across live runs.
• Duplicate notifications and duplicate tasks are impossible inside the protection window — by design and by test.
• Any hard failure reaches a person with a direct link to the problem.

What changes when your business changes

The two things most likely to change — the definition of an ideal customer, and who follow-up tasks are assigned to — are each isolated to a single point. When the client's criteria evolve or their team changes, nothing else in the system needs touching.

If your inbound looks like this

Built for one agency, but the pattern transfers to any business where leads arrive faster than anyone can qualify them and the good ones cool off in a shared inbox. The system is rebuilt around your CRM, your channels, and your definition of a good lead.