Lead qualification is the one place in local marketing where the cost of getting it wrong is not wasted money. It is a customer who never hears back, and who never tells you.

That asymmetry should shape the whole design. A campaign that overspends shows up in the account within a week. A qualification rule that quietly filters out fifteen percent of your real enquiries shows up nowhere at all, because the evidence of the mistake is a pile of records nobody opens. Build the system so that the invisible failure becomes visible, and most of the rest follows.

Sorting, ranking, and rejecting are three different powers

They get bundled together under one word and they carry completely different risk.

Sorting is routing: this is a commercial enquiry, send it to the commercial team. Low risk, immediately useful, and it is where most of the actual time saving lives.

Ranking is ordering the queue so the most promising work gets called first. Moderate risk. A bad ranking costs you speed on a good lead, but everyone still gets a call.

Rejecting is deciding somebody does not get a response. High risk, and it should be reserved for facts, never for judgement. Grant the first two freely. Grant the third narrowly, and only where the reason can be stated in one sentence a person would defend out loud.

Facts the software can check, judgements it cannot

Sort your criteria into these two columns before you write a single rule, because the columns behave differently and mixing them is how these systems go wrong.

Facts are checkable and stable. Is the address inside the service area. Is the requested service on the list you offer. Is the requested date one you have capacity for. Is the property type one you work on. Is this a duplicate of an enquiry logged yesterday. Is this obvious spam, meaning a form submission with a link in the name field, not a badly written one.

Judgements are not. Whether this person sounds serious. Whether the budget is realistic. Whether the job is worth the drive. Whether they will actually go ahead. These are commercial calls that depend on the season, the state of the schedule, and knowledge nobody has written down. Software can surface the evidence for them. It should not make them.

The line between the columns is not about how clever the model is. It is about whether a wrong answer is correctable. A misread address gets fixed when somebody calls. A lead scored as unserious and closed is simply gone.

The proxy problem, which is both an ethical and a commercial mistake

Any system that learns from your past bookings will find patterns you did not intend to teach it. Postcode, street name, the language somebody writes in, the phone carrier, how the message is spelled, the time of night it arrived. These correlate with income, ethnicity, and immigration status, and a model that uses them is discriminating whether or not anyone chose to.

For businesses working on homes, that is a real legal exposure and not a hypothetical one. It is also commercially wrong on its own terms. The badly typed message at eleven at night is frequently a homeowner with a genuine problem and a phone, and the enquiry that reads as professional is frequently somebody collecting a third quote for a job they will give to their brother-in-law.

The practical rule: qualification may use what the customer asked for and where the property is against your published service area. It may not use inferences about who the customer appears to be. If you cannot explain a rule to the customer it excludes, do not ship the rule.

Uncertain means escalate, never discard

Every classifier has a middle band, and the middle band is where the money is. Boundary addresses. Requests that mention two services, one of which you do not offer. Urgent language with no detail. Somebody asking about a job type you took on last year and have not decided about since.

Design the escalation path first, before the confident cases. A useful system has three outputs, not two: route it, flag it for a person with the reason attached, or reject it against a named fact. If the middle output does not exist, the model will resolve its uncertainty by guessing, and it will guess in the direction of whatever your training examples were biased toward.

Set the threshold conservatively at launch and expect the flagged pile to be large. Shrinking it is a monthly tuning job you do with evidence, not a setting you get right on day one.

Write the eligibility table by hand first

Before any model is involved, produce the table in plain language: services you take, services you refer out, area with the border cases named, property types, minimum job conditions, and anything seasonal. Have the owner sign it off, because half of these turn out to be assumptions different people in the business hold differently.

Doing this on its own improves your intake. It also gives you something to audit against, which a prompt does not. When a lead is rejected, the record should name the rule, so the answer to "why did we not call this person" is a line of text rather than an investigation. Our AI readiness checklist covers the same test for any workflow: if you cannot write the rule down, it is not ready to be automated.

Audit the rejections, weekly at first

This is the discipline that separates a qualification system that works from one that is slowly costing you jobs.

Once a week, someone who knows the business reads every rejected and every deprioritised lead. Not a sample. All of them, while the volume still makes that possible. You are looking for two things: leads that should have been called, and rules that fired for the wrong reason. Expect to find both in the first month, and expect the count to fall.

When the volume outgrows a full read, move to a stratified sample and keep reading every rejection in the categories closest to the boundary. The day nobody reads the rejected pile is the day the system stops being supervised, whatever the dashboard says.

Measure downstream, never at the decision

A qualification model will happily report that ninety percent of leads it passed were qualified. That is circular. It graded its own homework.

The honest measures are all downstream. Of the leads it routed, how many became booked jobs. Of the leads it flagged, how many turned out to be real, which tells you whether the threshold is set sensibly. Of the leads it rejected, how many were wrong on audit. And underneath all of it, total booked work compared with the month before you turned it on, because a system that improves every ratio while reducing the absolute number of jobs is not helping.

Take the baseline first. Our measurement plan guide covers the smallest version of that worth keeping.

What a responsible first version looks like

Routing only, with no rejection at all. Every enquiry still reaches a person; the system decides who and in what order, and writes the summary that saves them reading the whole thing. Run that for a month. It captures most of the practical benefit at almost none of the risk, and it produces the evidence you need before granting anything stronger.

The permission ladder underneath this, read, draft, execute, is set out in our piece on approval workflows for AI agents, and qualification is a good example of why the rungs matter. What happens before this step, capturing enough for the decision to be possible, is covered in our guide to AI intake systems.

Building it as one bounded workflow with a named owner and a written rule table is what AI workflow automation should mean. The alternative, a scoring model nobody can explain sitting between your marketing spend and your phone, is a liability wearing the costume of an efficiency.

FAQs

Can AI reject leads automatically?

That is risky. A safer first version flags likely fit and exceptions while a person controls final decisions.

What information should be collected?

Only information that changes routing, qualification, preparation, or the next step.

How do we know if it works?

Review response time, contact rate, booked appointments, estimate quality, and false rejections.