# How to Build an AI Lead Qualifier for Service Businesses (Filter, Don't Just Follow Up) > Answering every lead fast is one problem. Deciding which of those leads is worth the owner's time is a different one — and for businesses that get more inquiries than they can serve, it's the more expensive problem. Here's how to spec, build, and sell an agent that qualifies instead of just replies. Reviewed by Maxime Houle, Founder, SeldonFrame. Facts checked July 2026. HTML version: https://www.seldonframe.com/guides/how-to-build-an-ai-lead-qualifier ## This isn't the speed-to-lead pitch It's worth drawing this line up front, because these two agents look alike from a distance — and get pitched to the same buyer. A *speed-to-lead agent* solves for time: it replies in seconds so a lead doesn't go cold in an unanswered inbox. This guide solves a different problem. It's for businesses that already reply fast, or that get more inquiries than they can serve — paid on-site estimators, contractors with a bounded service area, firms with intake requirements, anyone who's learned the hard way that **not every inquiry is a fit**. For those businesses, the cost isn't a slow reply. It's hours spent driving to a job outside the service area, quoting work they don't do, or sitting on a call with someone who was never going to book. The qualifier's job is to let every lead feel answered — **nobody gets ignored** — while it sorts the pipeline before a human sees it. That way the **owner's time goes to the leads worth having**. If you haven't read the [speed-to-lead guide](/guides/how-to-build-and-sell-a-speed-to-lead-agent), start there for the instant-response case. This one picks up after the reply is already sent. ## The spec A qualifier is a short conversational intake, not an interrogation: what's the job, where is it, roughly when, and — only if the business actually prices this way — a budget band. **Three to five questions**, asked in whatever order the conversation naturally goes, not a rigid form marching through fields. Every answer gets scored against the business's own criteria, not a generic template. That means service area (does the address fall inside the radius they'll actually drive), job type (do they do this kind of work at all), and minimums (is this job big enough to be worth a visit). That scoring produces a CRM tag — hot, nurture, or decline. Hot leads get an instant handoff to the owner, the same way a speed-to-lead agent would hand one off. Qualification and speed aren't in competition — **a good pipeline runs both**. The decline path is the part most builders skip — and shouldn't. A lead outside the service area or job scope needs a graceful, specific answer, not a form that silently goes nowhere. Ideally that means a referral, or an honest "that's not something we handle." And here's the *guardrail* that matters most: the agent recommends a tag, but it never makes the final call on anything ambiguous, and it never quotes a firm price. **Scoring a lead hot or cold is a judgment call** trained on the business's own criteria — deciding what to charge is the owner's call, always. > 💡 Kind of like: A guardrail here is a cashier who's allowed to ring up a sale but not authorize a refund over $50 — happy to act fast within the lines, but the moment it's a judgment call above their scope, it goes to a manager. **How a qualifier sorts a lead** Intake (3-5 questions) → Score (vs. the business's own criteria) → Route (hot, nurture, or decline) ## The build, honestly, both paths DIY, this is a form or chat intake with a few questions, a set of scoring rules written in whatever logic your stack supports, and a write path into the CRM that tags the lead and files the answers. Connecting that intake to the tools it needs to read and write — the calendar, the CRM, the messaging channel — is exactly the integration problem the *Model Context Protocol* (MCP) was built to reduce. The standard describes itself as letting an AI application "connect to data sources... tools... and workflows" without a custom integration per tool. None of the individual pieces are hard. The real work is translating the owner's actual judgment — "we don't do jobs under $500," "we don't cross the river" — into rules a script can apply consistently, and **keeping those rules current** as the business's criteria change. That translation is **the real asset here** — more than the code around it. A written **scoring-criteria doc** (often the client's judgment put into words for the first time) is worth more to the relationship than the automation wrapped around it, because the owner can review it, correct it, and hand it to a new hire later. The assembled path is what we build: SeldonFrame wires intake, CRM tagging, and routing into one conversation, so the scoring criteria live alongside the agent rather than being reconstructed in a separate integration layer. SeldonFrame is our own product, so this particular recommendation comes from the interested party — discount it accordingly. Either path needs the same criteria doc; the difference is how much of the wiring is pre-connected. > 💡 Kind of like: MCP is a universal power adapter for an agent's tools — build the plug once, and it works in the calendar outlet, the CRM outlet, and the messaging outlet without a new adapter for each one. ## Selling it: a different pain than missed calls Don't pitch this with the speed-to-lead line — a business that already answers fast doesn't feel that pain. Ask a different question instead: "how much time did you spend last week on quotes that went nowhere?" Most owners who do paid estimates or field a lot of out-of-area calls have a number for that. It's usually a number **they've never said out loud** to anyone selling them software. The best-fit verticals follow from the problem: contractors who send someone out for a paid estimate, firms with real intake requirements (licensing, permits, insurance types), and any business with a hard service-area boundary. If the owner has ever said "I wish people would stop calling about jobs we don't do," **that's the opening line for this pitch** — not the speed-to-lead one. ## Pricing and running it Same shape as most agent retainers: a **monthly fee**, with a report the owner actually reads. For a qualifier, that report covers leads processed and hot-lead response time — so the qualification layer doesn't quietly become the new bottleneck. It also includes an honest, clearly-labeled estimate of owner-hours saved. That's never a hard number presented as measured fact, since there's no way to observe the counterfactual hours a business would have spent without the agent. Criteria drift, and the retainer should account for that. Sit down with the client **quarterly**, walk through what got tagged hot, nurture, and decline, and adjust the rules to match what they'd have actually wanted. A qualifier tuned once at setup and never revisited **slowly drifts out of sync** with how the business actually operates. ## Failure modes to design against **Over-qualifying** is the most common failure: an agent that keeps asking questions until a genuinely hot lead gets annoyed and leaves. Cap the question count, and bias toward handing off early when a lead is clearly interested. Qualification should never cost you a lead speed-to-lead would have caught. **Scoring on criteria the client never agreed to** is the second failure mode. A rule you inferred, rather than one the owner confirmed in the criteria doc, will eventually tag the wrong lead the wrong way — and the client finds out from a customer complaint instead of from you. Third: **silently declining leads the owner would have wanted** is worse than it sounds. Nobody notices until a competitor books the job. Log every decline with the reason, and review the log with the client. Don't let the decline path run as a black box. Fourth — the general rule under the other three — is the **false-positive trap**. It's better to pass a maybe to the human than to auto-decline it. A qualifier that's too eager to say no costs the business real revenue, in a way that's much harder to notice than a qualifier that's a little too generous with hot tags. > ⚠️ Watch out: A false-decline is invisible on your dashboard — the lead just vanishes into someone else's pipeline. A false-hot lead at least shows up as a wasted call. Bias every rule toward the mistake you can see. ## FAQ **How many questions should a qualifier ask?** As few as it takes to sort the lead — usually three to five. Enough to score service area, job type, and rough scope; any more than that risks reading as an interrogation and losing a lead that speed-to-lead would have kept. **Can it qualify phone leads, or just form and chat leads?** The scoring logic is channel-agnostic — it's the same three or four questions either way. Applying it to a phone call requires a voice agent (or a human reading from the same script) rather than a form, but the underlying spec — ask, score, tag, hand off or decline — doesn't change. If the handoff to the owner happens over SMS, budget for it as a real per-message cost rather than something free in the background — Twilio's US pricing lists $0.0083 per outbound SMS segment before carrier fees, which is small per message but adds up across a busy pipeline. **What CRM does it need?** Any CRM that can hold a lead record and a tag field works — the qualifier just needs a write path in. The important part isn't which CRM; it's that the tag (hot / nurture / decline) and the answers that produced it are visible to whoever picks up the lead next. **Should it ever quote prices?** No. A qualifier scores and tags; it doesn't price. The one exception is a budget band the client has explicitly approved in writing for the agent to state — and even then, treat it as a range, never a firm quote, and keep it opt-in per client rather than a default. ## Try it - Related free tool: https://www.seldonframe.com/tools/speed-to-lead-calculator - Go deeper: https://www.seldonframe.com/marketplace - Build your AI front office free (about 3 minutes): https://www.seldonframe.com/signup ## Sources - [Model Context Protocol — "What is the Model Context Protocol (MCP)?"](https://modelcontextprotocol.io/introduction) - [Twilio — SMS Pricing (US)](https://www.twilio.com/en-us/sms/pricing/us)