Lead Qualification Automation: From Inbound Form to Routed Opportunity

A playbook for qualifying inbound leads with an AI-assisted workflow: what the manual process costs today, which steps a model can take, where the rep keeps the decision, and what it takes to run in production.

5 min read

Complexity: Medium
Estimated savings: Estimate: 5-15 hrs/week of sales admin, scales with inbound volume
Time to deploy: Typically 2-4 weeks

The problem

Inbound leads arrive faster than anyone can read them and slower than the business wants them answered. A form fill at 11pm sits untouched until someone opens the CRM the next morning, and by then the prospect has sent the same message to two competitors.

The expensive part is rarely the reading. It is the sequence around it: look the company up, decide whether it fits, work out who owns it, write a first reply, and log all of it so the pipeline report is not wrong. Each step is small. Done forty times a day, it is a job.

What the manual process looks like today

In most teams the path is roughly this:

A submission lands in a shared inbox and, separately, in the CRM.
Someone opens the company website and LinkedIn to work out what it actually does and how big it is.
They compare that against a mental version of the ideal customer profile.
They pick an owner — by territory, by named account, or by whoever is free.
They write a first reply, usually from a template they retype anyway.
They update the CRM record.

Steps 2, 3 and 5 consume the hours, and they are exactly the steps rule-based automation never covered, because they need judgement rather than a lookup. That is the gap a model closes — and the only gap it should be asked to close.

The qualification workflow

Ten steps from submission to a routed, answered opportunity. The actor on each step is the point: judgement about the person stays with the person.

1
Capture the submission and normalise it
SystemWeb form webhook into a queue
One canonical record per submission, with the raw payload retained so any later decision can be replayed against what actually arrived.
2
De-duplicate against existing accounts and open opportunities
SystemCRM lookup on domain and email
An existing customer asking a question is not a new lead, and routing it as one is the most visible failure this workflow can produce.
3
Enrich the company from licensed public sources
SystemFirmographic enrichment provider
Company attributes only — industry, size band, region, technology footprint. Nothing inferred about the individual.
4
Summarise what the company does and what they asked for
AILLM over the enrichment payload and the message body
A brief a rep can read in ten seconds, written next to the raw message, not instead of it.
5
Score fit against the written ideal customer profile
AILLM with the ICP supplied as an explicit rubric
The rubric is a document the sales lead owns and edits — not a prompt engineering controls.
6
Write one paragraph explaining the score
AI
A score with no reasoning cannot be argued with, so it will not be trusted, so it will be ignored by week three.
7
Route to an owner
SystemDeterministic CRM assignment rules
Territory, named accounts, round robin. Never ask a model to choose a colleague.
8
Draft the first reply
AI
Written to the CRM record as a draft. There is no path from here to an outbox.
9
Review, edit and send
Human
The rep owns the first thing the prospect reads. This is the step that must not be automated away.
10
Take everything the rubric could not place
Human
Low-confidence and unusual submissions go to a named person in a queue, not to a default owner.
11
Write the outcome back and log the run
System
The disagreement rate between the model's score and the rep's decision is the number that tells you whether the rubric is right.

What it takes to implement

A written ideal customer profile. Not a slide — a rubric with named criteria and what each one is worth. The model scores against that document, and your sales lead owns and edits it. If the rubric only exists inside a prompt that engineering controls, sales will not trust the score, and an untrusted score is ignored within a fortnight.

A licensed enrichment source. Firmographics — industry, headcount band, region, technology footprint — from a provider whose terms cover this use. Scraping is not a substitute, and inferring anything about the person rather than the company is a line worth not crossing.

Write access to the CRM, and a place to put a draft. The reply is written to the record as a draft, never to an outbox. Approval is a state change on the record made by a person, which makes "nothing was sent without a human" a property of the system rather than a promise.

A run log. Every retrieval, score, justification and routing decision, retained. It is what you audit when a good lead is misrouted, and it is where the one number that matters comes from.

Where it fails, and what oversight it needs

The rubric is wrong before the model is. Most bad scores trace back to an ICP that describes the customers the company wishes it had. The fix is editorial, not technical.

Long-tail companies defeat enrichment. New entities, holding companies and non-English sites come back thin. Thin enrichment must produce low confidence and a route to a person — never a confident guess from a sparse record.

Scores drift as the business changes. A rubric written for last year's segment will quietly misrank this year's. Re-read it every quarter against closed-won deals.

Automation bias is the real risk. A rep who sees a score and a fluent justification will stop reading the message underneath. Keep the raw submission visible next to the summary, always.

How to tell it is working

One number: the disagreement rate between the model's score and the rep's own decision, tracked weekly. It should fall for the first month and then plateau. If it plateaus high, the rubric is wrong. If it is near zero from day one, the rubric is only restating a rule you could have written in SQL — and you should.

What it might save

This depends almost entirely on inbound volume, so treat any figure as an estimate rather than a result. For a team handling a few dozen inbound leads a week, the realistic saving is in the range of five to fifteen hours of sales admin per week, most of it in enrichment, first-draft writing and CRM hygiene. Below roughly ten leads a week the build is hard to justify; above a few hundred, throughput stops being the constraint and routing quality starts to be.

Want this mapped against your own funnel?

Send us the shape of your inbound and we will tell you which steps are worth automating first.

Talk to us

Frequently Asked Questions

Not in this design. The draft is written to the CRM record and a rep approves it. That is a structural choice rather than a caution setting: approval is a state change a person makes, so 'nothing was sent without a human' is a property of the system rather than a promise about it.

It routes to a named person in a low-confidence queue with the raw submission and whatever enrichment did return. It never gets a confident score assembled from a sparse record, and it never falls to a default owner who is not expecting it.

It depends on inbound volume, so any figure is an estimate rather than a result. For a team handling a few dozen leads a week, plan for something in the range of five to fifteen hours of sales administration per week. Below roughly ten leads a week, the build is hard to justify on time saved alone.

More in this category

Sales Follow-Up Automation: After the Meeting and Through the Pipeline

A playbook for automating post-meeting and pipeline follow-up: capture what was agreed, let a rep confirm it, schedule from rules a sales manager wrote, and draft messages that have something to say.

Medium complexity · 7 min read

Invoice Processing Automation: From Inbox to Posted Entry

A playbook for automating accounts payable intake: classify the document, extract every field with its own confidence, let deterministic checks outrank the model, and send only the exceptions to a person.

High complexity · 8 min read

Support Ticket Triage and Deflection: A Playbook

A playbook for automating tier-1 support: classify, retrieve from your own documentation, answer only what is grounded, escalate everything else — and treat the questions it could not answer as the documentation backlog.

Medium complexity · 5 min read