Evals for GTM Teams

If you peek behind the hood of how GTM teams use AI today, you’ll quickly see that most can’t tell you whether it actually works or not.

They’ll show you a new dashboard, a custom script, an automation that syncs calls.

Everything looks great. But that’s not what they’re measured on. GTM teams are measured on revenue.

Running AI in your GTM motion without measuring output quality is gambling with next quarter’s pipeline and the trust of your target market. “The model feels good enough” is not a quality bar for customer-facing output.

Yet that’s what AI in GTM looks like today. Someone read a few outputs when it launched. It looked good. So it went live.

This is a big part of why AI SDRs failed. Your AI SDR has no QA function. Neither do your AI-written emails, or your AI signal capture.

Software teams don’t ship this way. Code gets tests, staging environments, monitoring, alerts. Engineers know that system errors can’t be caught at a glance.

GTM teams never needed any of this, because our tools were deterministic. Your Salesforce record either saved correctly or threw an error. Your GTM AI, however, does neither. It fails without telling you, and you only find out when your numbers tank.

That’s where evals come in. Evals are your GTM AI’s QA function.

Working evals

A working eval answers four questions:

1. Are we hitting our quality bar before outreach hits the market?
2. Which model performs the best for this specific task?
3. Is this model overkill (slow and costly) for what we are trying to achieve?
4. Should this even be an LLM or a rule engine?

Three properties of GTM AI make this non-optional.

Errors compound. GTM AI runs in pipelines. If you have a four-step LLM pipeline (scrape → enrich → qualify → personalize) and each step runs at 95% accuracy, the send at the end is 81% accurate, not 95% (credit to Kyle Norton’s talk at SaaStr for this). At 80% per step, your send is 41%.

Failures are silent. When code breaks, an error page shows up. When your AI personalization breaks, an email goes out to the wrong prospect with the wrong message about the wrong signal - and no alert fires. You burn the prospect and only find out when the numbers disappoint you in a few weeks.

Volume multiplies both. The whole point of AI in GTM is doing 1,000x the volume at speed. Without measurement, that means one systematic error repeats 1,000 times before a human notices.

So what is an eval?

An eval is a repeatable test that scores AI output against a definition of “good” you wrote down before shipping. Most GTM teams are running on vibes instead.

Evals are predefined by the metrics that matter most to you. In a GTM context, that looks like:

• What % of accounts your AI marks “qualified” actually fit your ICP
• What % of the claims in your personalization are factually true
• What % of AI outputs an SDR would send without editing

Three habits make it real:

1. Define “good” before you ship - clearly enough that two humans scoring the same output reach the same verdict.
2. Re-test against a fixed dataset on every change: new prompt, new model, new data source.
3. Keep checking production. Automated scoring plus a human reading samples until you can tell your outputs are reliable.

The last point is important because models drift and data sources can rot over time.

GTM teams have to answer two challenging questions.

The first is defining your criteria. What makes an account qualified? What does on-brand messaging look like? This is also why you can’t just take another vendor’s evals - your GTM requirements are uniquely yours.

Second is pricing your errors. A false positive (bad-fit account marked qualified) costs you SDR cycles and brand reputation. A false negative (high-quality prospect filtered out) is pipeline you’ll never know you missed out on. This is largely determined by your GTM motion (enterprise vs. high-volume motion).

What it looks like, end to end

Here’s one of the two evals we’re open-sourcing, built the same way we eval client work at Zevenue - but on public data anyone can rerun.

The task: determine which funded AI companies actually ship their own AI. Done on public data - website, careers, docs, engineering blog. If you sell to companies with real AI, that claim is your qualification problem.

This starts by defining a rubric upfront: Shipped - proprietary AI live in the product. Building - real ML hiring and infra, nothing live yet. Wrapping - a real feature, but a third-party model does the work. Washing - AI claims with no identifiable mechanism.

Scoring: run each model over the same data, compare to the human labels, count the misses - then price them. This is the false positive vs. false negative evaluation mentioned earlier.

Where this went

The results of that eval are now published: Can Frontier Models Spot AI-Washing? We Tested 12 of Them - frontier and open-weight models judging 243 hand-labeled companies on frozen evidence: accuracy, cost per thousand accounts, how much of the list each model can safely handle unsupervised, and which “AI-powered” companies fooled which models. The dataset and harness are on GitHub.

The second eval, after that: the same method pointed at research agents (Exa, p0, Claygent) - which one does the best account research starting from nothing but a domain.