Which AI Model Should You Use to Classify Inbound Leads?

Which AI model should you use to classify inbound leads?

Start with the smallest model that passes your own test set, not the most powerful one available. Lead classification is a narrow, repetitive job: read a form submission, pick a label, explain briefly. A small, fast model usually handles it well. Move up a tier only when your test results show the small model failing on real cases.

Inbound lead classification is one of the most common places GTM teams add AI. A demo request arrives, a model reads the company, role, and message, and decides whether it is a sales lead, a partner, a job seeker, a student, or spam. The label decides who gets the lead and how fast.

The model choice matters more than people expect, but not in the direction they expect. Teams tend to reach for the flagship model because it feels safer. My view is that the bigger risk is a classification step that is slow and expensive enough that nobody wants to run it on every lead.

What does lead classification actually ask a model to do?

Lead classification asks a model to read short, messy text and map it to one label from a fixed list. It does not ask the model to write, plan, or reason across many steps. That makes it a good fit for small models, as long as the labels are clearly defined and the prompt gives examples.

A typical input is a few form fields: name, work email, company, job title, and a free text message. Sometimes you add enrichment data, like company size or industry from a tool such as Clay or Apollo. The output is a label, a confidence level, and a one-line reason.

Because the task is narrow, most of the quality comes from the label definitions, not the model. If "partner" and "agency prospect" overlap in your own head, no model will separate them cleanly. Fixing the definitions often improves results more than switching to a more expensive model.

Why not just use the most powerful model?

Larger models cost more per call and usually respond more slowly. For a task that runs on every inbound lead, those costs add up, and slower responses delay routing. If a small model gets the same labels right on your test set, the larger model buys you nothing except a bigger bill.

Speed matters for inbound more than for most automations. A hot demo request should reach a rep within minutes. If the classification step adds noticeable delay, or times out on a busy day, it works against the reason you built it.

Some vendors now say this directly. Anthropic describes Claude Haiku 5.5 on its launch page as designed for high-volume, cost-sensitive tasks and lists classification requests among its use cases. The same page says it is not the best choice for complex agentic coding, where Sonnet 5.5 and Opus 5.5 are better. That split matches how I think about lead routing.

How do you build a test set for comparing models?

Pull fifty to one hundred real past leads, remove personal data you do not need, and label each one by hand with the correct answer. Include the hard cases: vague messages, personal email addresses, students, competitors, and partners. That labeled set is how you compare models fairly instead of by feel.

Weight the set toward cases that actually confuse your team. If half your real leads are obvious sales inquiries, you do not need fifty of them in the test. You need enough of the borderline ones to see where each model breaks.

Run every candidate model on the same set with the same prompt. Record accuracy overall, accuracy on the hard cases, and how often the model returns something outside your allowed labels. The detailed testing approach is in testing an AI classification step before it routes leads.

Which errors matter most when comparing models?

Not all mistakes cost the same. Labeling a real buyer as spam is the expensive error, because a deal disappears. Labeling spam as a buyer only wastes a few minutes of rep time. Compare models on the expensive errors first, and accept a few more cheap errors if it saves real money.

Write down the cost of each error type before you look at results. For most B2B SaaS teams, a missed sales lead is the worst outcome, a missed partner is next, and misrouted job seekers or students barely matter. That ranking turns a pile of accuracy numbers into a clear decision.

If two models tie on the expensive errors, pick the cheaper and faster one. If the small model misses real buyers that the larger model catches, that is the signal to move up a tier, or to send low-confidence cases to a person.

How do context window and output limits affect the choice?

For lead classification, context window size rarely matters. A form submission and some enrichment data fit easily in any modern model's window. What matters more is keeping the output short and structured, so the label can be parsed reliably by the next step in your automation.

Anthropic's release notes say Claude Haiku 5.5 has a 1M token context window and 128k max output tokens. Those limits are generous for this job, but you should still cap output length in your request. A label plus a short reason needs only a small fraction of that.

Large windows tempt people to stuff in everything: the full website, past emails, the whole CRM record. Resist that. More text means more cost and more chances for the model to latch onto something irrelevant. Send only the fields that actually help decide the label.

Should the model also explain its decision?

Yes, but keep it to one sentence. A short reason helps reps trust the label, helps you debug wrong answers, and gives you training data for better prompts. A long explanation adds cost and latency without making the label more accurate, so ask for brevity explicitly.

I ask for three fields in a structured format: the label, a confidence of high, medium, or low, and a reason under twenty words. The confidence field is what makes the system safe, because it lets you route uncertain cases to a person instead of trusting every answer.

That pattern is covered in depth in routing low-confidence AI classifications to a human. The model choice and the confidence routing work together. A cheaper model with good confidence routing often beats an expensive model trusted blindly.

What else should you check before switching models?

Check the provider's migration notes, your request parameters, and your output parsing. New model versions can reject settings older ones accepted. Anthropic's release notes for October 7, 2026 say code written for Claude Haiku 4.5 can break on Claude Haiku 5.5, including requests that send sampling parameters like temperature.

Many lead classifiers were built with a low temperature to make labels repeatable. If the new model rejects that parameter, the step may fail entirely rather than just changing behavior. Run your test set through the new model in a staging copy of the workflow before you touch production.

Also confirm the new model returns your structured format consistently. A model that occasionally adds extra text around the label can break a parser that expected one clean word. Write your prompt spec so the format is unambiguous, as I described in writing a prompt spec for an AI step in a Zap.

How often should you revisit the model choice?

Revisit it when a provider releases a new small model, when prices change, or when your error rate on real leads drifts up. Otherwise, a quarterly rerun of your test set is enough. Keep the test set updated with new hard cases so the comparison stays honest as your leads change.

Model releases are frequent now, and each one tempts a switch. The test set protects you from chasing headlines. If a new model does not beat your current one on your own leads, it is not better for you, whatever its benchmark scores say.

When you do switch, keep the old model's configuration saved so you can roll back quickly. A classification step touches every inbound lead, so a quick, boring rollback plan is worth more than a clever upgrade.

What should you do next?

Build a labeled test set of fifty to one hundred real leads this week, with your hardest cases overrepresented. Run your current model and one smaller option against it. Compare them on the expensive errors first, then on cost and speed. Pick the cheapest model that does not miss real buyers.

My bias is clear: for inbound lead classification, a small model with sharp label definitions and confidence routing is the right default for most B2B teams. The flagship models are wonderful, but they belong in the steps that need judgment, not in the one that sorts the mail.

If you want help setting up a lead classification step, a test set, or the routing behind it, reach out through pravinkumar.co. I build websites and the automations behind them for lead generation, and lead routing is where small design choices pay off fastest.