Don’t Guess Your Lead Routing: Building a Regression Test Suite for GTM Prompts

Most GTM teams start their AI journey in a web playground. You paste a few lead descriptions, tweak the prompt until the output looks right, and copy-paste it into an n8n workflow or a Python script. It works until it doesn't.

The problem with "vibe-based" testing is that LLMs are non-deterministic, and providers update models constantly. A prompt that works for Claude 3 Opus might fail in subtle, expensive ways on Claude 3.5 Sonnet. You might add one instruction to handle a specific edge case only to find you've accidentally broken routing for your most common lead type.

If your lead classification logic lives in a prompt, you need to treat it like code. That means version control, regression testing, and deterministic scoring.

The Failure of Manual Spot Checks

When you are routing leads in real-time, the stakes are high. A false positive sends junk to your most expensive account executives. A false negative lets a high-intent buyer sit in a generic nurture sequence for three days while they book a demo with your competitor.

Manual testing fails because humans are bad at identifying drift across hundreds of variations. You might check three examples, see they look fine, and miss the fact that your "intent" score for mid-market buyers just dropped 15% across the board. To fix this, you need a local evaluation harness that compares prompt outputs against a "golden set" of labeled historical data.

Building the Evaluation Harness

You don't need a complex enterprise AI observability platform. A simple Python script using Pydantic will get you further than any web UI. Pydantic is essential because it forces the LLM to return structured data that you can actually measure.

First, define what a "correct" classification looks like. We aren't looking for a text summary; we want specific categories and a confidence score.

from pydantic import BaseModel, Field
from typing import Literal

class LeadClassification(BaseModel):
    intent_level: Literal["high", "medium", "low"]
    persona_match: bool
    suggested_routing: Literal["ae_direct", "sdr_triage", "nurture"]
    confidence_score: float = Field(..., ge=0, le=1)
    reasoning: str

By using Pydantic, your evaluation script can automatically flag any response that doesn't fit the schema. If the model starts hallucinating new routing categories, the test fails immediately.

The Golden Set: Your Source of Truth

Your evaluation is only as good as your data. You need a CSV or JSON file containing 50 to 100 historical leads. For each lead, you should have the raw input (form submission or email body) and the "ground truth" label—the decision a human expert would have made.

When you run your test suite, you compare the LLM’s suggested_routing against the ground truth. This allows you to calculate actual performance metrics:

• Precision: When the AI labels a lead as "high intent," how often is it right?
• Recall: Of all the truly high-intent leads in your set, how many did the AI actually catch?
• F1 Score: The mathematical balance between the two.

In GTM, you usually want high recall for AE routing. It is better to have an SDR manually disqualify a few extra leads than to have a million-dollar opportunity disappear into a nurture sequence because the AI was too picky.

Comparing Models: Latency vs. Accuracy

A regression suite lets you swap models safely. You might be using GPT-4o because it is reliable, but it is slow and expensive for high-volume triage. With a test harness, you can run your golden set through a faster model like Claude 3 Haiku or GPT-4o-mini and compare results side-by-side.

Model	Accuracy	Latency (Avg)	Cost Tier
GPT-4o	94%	2.1s	High
Claude 3.5 Sonnet	96%	1.8s	Moderate
Claude 3 Haiku	89%	0.6s	Low

If Haiku gets you 89% accuracy but responds in a third of the time for a fraction of the cost, it might be the better choice for an initial triage layer. You can't make that trade-off confidently without the data to back it up.

Handling Ambiguity with Confidence Scores

No model is perfect. The secret to a robust revenue system is knowing when the AI is guessing. In your prompt, instruct the model to provide a confidence_score.

In your production routing logic, set a threshold. If the confidence score is below 0.7, bypass the automated routing and send the lead to a human queue for manual review. Your evaluation suite should test this: if a prompt update causes 30% of leads to hit the "low confidence" bucket, your prompt is getting more ambiguous, even if the "correct" answers are technically right.

When Rule Engines Still Win

Don't throw an LLM at every routing problem. Deterministic rules are still superior for firmographic data. If you have a Clearbit or ZoomInfo integration that identifies a company as having 5,000 employees, you don't need an LLM to decide if they are "Enterprise." A simple if statement is faster, cheaper, and 100% accurate.

Use LLMs for the messy, unstructured parts of the lead record—like parsing the "How can we help?" field where a buyer says, "We need to replace our current vendor by Q3 because their API is down once a week." That is semantic intent a rule engine will never catch.

The Operational Reality

Building a Python test suite might feel like overkill for a team getting ten leads a day. If your volume is that low, manual review is a fine use of your time.

But as you scale—or as you start relying on these classifications to trigger automated outbound sequences or Slack alerts—the cost of a silent regression grows. Spending a day building a regression harness is an insurance policy against the morning you wake up to find your SDRs haven't seen a lead in 12 hours because a model update broke your regex or prompt logic.

Treating GTM prompts like an engineering asset doesn't mean you need to be a full-stack developer. It just means you need to stop guessing and start measuring. If you can't prove a prompt update improved the system, it shouldn't be in your revenue pipeline.