Every martech demo is the same demo. The data is clean. The sync works. The dashboard loads instantly, populated with a fictional company whose leads all have complete records and whose campaigns all perform. Somewhere in minute forty, an AI feature does something impressive to a dataset that has never existed in nature.
None of this is dishonest, exactly. It's just that a demo is the product on its best day, run by the person who knows it best, on data designed to flatter it — and you're about to sign a multi-year contract for the product on its average day, run by your team, on your data. The entire craft of vendor evaluation is closing that gap before the signature instead of after.
Here's the process we use, refined by years of being on every side of it: buying, implementing, and cleaning up after purchases that went the other way.
Write the problem statement before you take the first call
Evaluations fail at the start, not the end — the moment a team begins with "let's look at some tools" instead of "here's what's broken." Once vendors enter, they will happily supply the evaluation criteria for you, and those criteria will be a checklist of their features. Feature checklists are how vendors win: they wrote the checklist.
So before any call: one page. What problem are we solving, in operational terms — not "we need better attribution" but "we cannot connect campaign spend to closed revenue because X." What must integrate with what, at what volume. Who will administer this, with how many hours a week. What does success look like in ninety days. Every tool gets scored against that page and nothing else. A feature that doesn't serve the page is decoration, and decoration is how a €30K problem becomes a €90K platform.
Run the demo on your scenarios, not their script
The standard demo is a guided tour of the product's best neighborhoods. Decline it — politely, and in advance. Send three or four scenarios drawn from your actual workflows a week before: "Show us a lead coming in from a webinar form, syncing to the CRM, getting scored, and routing to a rep — then show us the same lead when the sync fails." Vendors who handle this well are telling you something. So are vendors who steer back to the script.
Two requests that reveal more than any feature walkthrough:
Ask to see the error states. Every system fails; the question is how visibly. What does a sync error look like? Where do failed records go? Who gets notified — anyone? A platform that hides its failures in a log nobody surfaces will do exactly that in production, quietly, for months. The demo of the unhappy path is the demo that matters.
Ask to drive. Fifteen minutes of your admin clicking around, live, uncoached. The gap between "watching an expert operate it" and "operating it" is the gap between the demo and your Tuesday.
And if the evaluation is serious: insist on a sandbox or trial with a sample of your data — real field names, real duplicates, real mess. Vendors who refuse this for an enterprise-priced product have answered a question you hadn't asked yet.
The questions that cut through
A short list that does disproportionate work, collected from evaluations where the answers would have saved money:
"Walk us through a realistic implementation timeline — and who does the work." The quoted timeline is the optimistic path with a dedicated customer team. Ask what the median customer actually experienced, whether implementation is done by the vendor, a required partner, or you, and what it costs when it's not included. "Six weeks" has a way of meaning "six weeks after your engineers finish the prerequisite integration work," which is a different number.
"What does support actually look like at our tier?" Response time commitments in writing, channel (a human? a portal? a chatbot in front of a portal?), and what costs extra. Support quality is invisible in the sales process and defines year two.
"Which of the features we just saw are generally available today, on our tier?" Demos love the roadmap. Anything material to your decision gets confirmed in writing as available now — and anything promised for "next quarter" gets treated as not existing, because on the vendor's roadmap, next quarter is a direction, not a date.
"What does leaving look like?" Data export formats, contract exit terms, what happens to your historical data at termination. Asking about the divorce at the wedding feels rude and is merely professional: switching costs are the vendor's real moat, and they know exactly how high theirs are. You should too.
"Give us two reference customers who look like us." Same size, same stack, same use case — not the logo wall. And when you get them on the phone, ask the only reference question that produces information: "What do you wish you'd known before you signed?" References are hand-picked to be happy; that question lets happy customers be honest anyway.
Read the pricing like an operator
Martech pricing is engineered, and the engineering has patterns. Watch for the usage cliff: pricing tied to database size, contacts, or events, where your natural growth marches you into the next tier — model the cost at your projected volume in eighteen months, not today's. Ask directly about renewal uplift: first-year pricing is an acquisition price, and the standard question "what does year two cost, in writing?" has ended more than one negotiation productively. Add the quiet line items — implementation, required partners, premium support, the connector that turns out to be an add-on — because the license fee is often 60% of the real total. And remember the operational cost that never appears on any quote: someone on your team administers this thing, for hours every week, forever.
None of this is adversarial. It's just accounting done before the signature instead of after, which is the cheaper of the two available times.
The integration question is the whole question
A martech tool doesn't perform in isolation; it performs at the seams — with your CRM, your automation platform, your data layer. So the deepest technical question in any evaluation is not "do you integrate with X" (the answer is always yes) but how: native integration or "via API" — a phrase that can mean anything from "two clicks" to "your engineers build and maintain it." Ask for the field-level sync documentation: what syncs, which direction, how often, what happens on conflict. A vendor who can produce that document has customers who made them write it. A vendor who can't is proposing that you become the customer who does.
Red flags that end the conversation
Some signals we've learned to treat as terminal: the discount that expires this week (real enterprise pricing survives your diligence timeline; manufactured urgency is a statement about how the relationship will go); "that's on the roadmap" as the answer to every gap (a roadmap answer to a requirement is a no wearing optimism); AI positioning with no mechanism (ask what the model actually does with your data — "it's proprietary" to a technical buyer means "stop asking"); and a logo wall in place of reachable references. Individually, each is survivable. Two or more, and you're no longer evaluating a product — you're being processed by a pipeline.
Worth saying plainly: vendors are not the enemy. The good ones — and there are many — will engage with every step above without flinching, because a well-run evaluation selects for exactly the vendors who deserve to win it. The ones who resist the process are volunteering the result.
Vendor evaluation and selection — the problem statement, the scenario demos, the pricing model, the integration diligence — is the core of our tech stack consulting work, and we take no reseller commissions from anyone, which keeps the advice pointed in one direction: yours. Not sure whether you need a new tool or a fixed stack? That's what a stack audit is for — one call, one week, findings yours either way.