What to Actually Figure Out Before You Compare Any AI Vendor

Numa is built around a specific, well-defined problem, missed calls, disconnected departments, reactive-only communication, rather than a generic pitch meant to fit any dealership's situation, and that specificity only matters if a GM has done the same work on their own side first. Research on how B2B purchasing decisions actually get made puts requirements definition before vendor comparison, not during it, as a distinct, necessary step. Most dealerships skip straight to comparing vendors instead, which is exactly backwards from what the research says works.

The Research: Requirements Come Before Vendor Comparison, Not During It

This isn't just intuition. Gartner's own research on the B2B buying journey breaks a complex purchase decision into six distinct stages: problem identification, solution exploration, requirements building, supplier selection, validation, and consensus creation. Requirements building is its own dedicated stage, and it comes before supplier selection in the sequence, not somewhere inside it. The framework treats defining what you actually need as separate, necessary work that has to happen before comparing specific vendors even starts.

The same research found buyers spend only 5% to 6% of their total purchase time with any single supplier, and 6sense's 2025 B2B Buyer Experience Report found buyers complete roughly 61% of their evaluation before ever engaging a vendor directly. Most of the actual decision-making work happens independently, before a single demo, which means how well that independent work gets done matters more than most buyers assume.

Key takeaway: Gartner's own B2B buying research treats requirements building as a distinct stage that comes before comparing vendors, not something that happens naturally during vendor conversations. Skipping it isn't a shortcut. It's skipping a step the research says determines how good the eventual comparison actually is.

Why Skipping This Step Is So Common, Even Though It Predicts Worse Outcomes

If most of a purchase decision happens independently and only a small fraction of time gets spent with any single vendor, a poorly defined requirement doesn't get corrected by a great sales conversation later. It gets carried straight into the comparison, where every vendor's demo looks impressive in slightly different ways and there's no clear standard to measure any of them against. A GM walking into vendor conversations with "we need better AI" as the requirement is set up to be persuaded by whichever pitch sounds most confident, rather than the one that actually solves the specific problem the dealership has.

What Requirements Building Actually Means for a Dealership Evaluating AI

Translated into something concrete, this means identifying the specific, measurable gap before looking at a single vendor. Is the actual problem missed calls during specific hours, or hold times that are technically fine but frustrating? Is it a staffing cost problem, where the same result could be achieved for less money, or a coverage gap where no amount of current staffing solves the problem? Is it customer retention showing up as a slow leak rather than a spike in complaints? Each of these is a different requirement, and each one points toward evaluating vendors on a different specific capability rather than a generic "does it have AI" comparison.

Pulling the actual numbers before evaluating anything new is what makes this concrete rather than a vague intention. A missed-call rate, an average response time, a CSI trend over the last two quarters, and a rough sense of current cost per handled contact are the specific inputs that turn "we need better AI" into an actual requirement a vendor conversation can be measured against.

Key takeaway: "We need better AI" isn't a requirement. A missed-call rate, a response-time trend, and a current cost per contact are, and only one of those two gives a vendor conversation something real to be measured against.

Numa perspective: A vendor conversation without a defined requirement isn't really an evaluation. It's an audition, and whichever pitch performs best wins regardless of whether it solves the problem that actually exists.

Why This Also Protects Against Vague AI Marketing Claims

The gap between what a vendor claims and what a product actually does is much easier to catch when there's a specific requirement to test the claim against. A vendor demo built to impress a generic audience is far more persuasive than the same demo tested against "does this specifically reduce missed calls during our documented peak hours" or "does this specifically address the retention pattern we've already identified in our own data." A defined requirement turns a vendor's pitch from something to be persuaded by into something to be tested, which is a fundamentally different, more defensible conversation.

The Bottom Line: Know the Question Before You Start Comparing Answers

Most dealerships treat vendor comparison as the starting point of the decision, when the research on how B2B purchases actually succeed treats it as the fourth step, after the problem and the requirement have already been defined clearly. Numa is built to solve specific problems, and a GM who's done the requirements-building work beforehand is in a position to evaluate that specificity honestly, against a real standard, rather than being swayed by whichever demo happens to be the most polished. The dealerships that get the most out of any vendor conversation aren't the ones with the most meetings. They're the ones who knew exactly what they needed before the first one started.

Frequently Asked Questions

Why does requirements definition matter before comparing AI vendors?

Research on B2B purchasing, including Gartner's own buying journey framework, treats requirements building as a distinct stage that comes before supplier selection, not something that happens naturally during vendor conversations. Buyers spend only a small fraction of total purchase time with any single vendor, so a poorly defined requirement carries directly into the comparison rather than getting corrected along the way.

What does "requirements building" actually look like for a dealership evaluating AI?

It means identifying a specific, measurable gap before looking at any vendor: is the problem missed calls during specific hours, a staffing cost issue, a coverage gap, or a slow retention leak. Each of these points toward a different capability to evaluate, rather than a generic comparison of which vendor's AI seems most impressive.

What numbers should a dealership know before evaluating any new vendor?

A current missed-call rate, average response time, a CSI trend over recent quarters, and a rough sense of current cost per handled contact turn a vague sense of needing improvement into an actual, testable requirement. Without these, a vendor's claimed results have nothing specific to be measured against.

How does having a defined requirement protect against vague AI marketing claims?

A vendor's demo is far more persuasive to a general audience than it is when tested against a specific requirement, like whether it actually reduces missed calls during documented peak hours. A defined requirement turns a pitch into something that can be tested rather than something to simply be impressed by.

Is it possible to define requirements too narrowly before comparing vendors?

It's possible, but the more common failure by far is defining requirements too vaguely or skipping the step entirely. A reasonably specific requirement still allows room for a vendor to demonstrate additional capabilities beyond the original ask; a missing requirement leaves nothing concrete to evaluate any vendor's claims against in the first place.

See how Numa is built to solve the specific problems a dealership actually has. Talk to Numa.