A note on this page. It replaces a URL that delivered a Tenbound survey report on how sales technology gets bought. The response data behind those figures is not available to restate accurately, so no percentages from it appear here. A survey number without its sample and its question wording is not evidence, and reproducing one from memory would be worse than reproducing none.
What follows is the structural pattern the survey described, which is observable without the figures and has not changed.
The three roles, and why deals stall between them
Almost every sales tech purchase involves the same three positions, and they are rarely the same person.
The initiator: a frontline manager. They feel the problem daily. They find the tool, book the demo, and build the internal enthusiasm. They usually have no budget and no signing authority.
The justifier: a VP or director. They convert the request into a number the business will fund. Their question is not "is this good" but "what does this replace, and what does it produce that I can show next quarter."
The blockers: IT, security, procurement, and finance. They are not adversaries; they hold constraints the initiator did not know about. Data processing terms, SSO requirements, CRM write access, and an existing contract that already covers 60% of the feature set.
Deals do not usually die at any one of these. They die in the handoffs, when the case built for one audience is presented unchanged to the next.
The two questions that decide most purchases
Everything else is detail around these.
1. What does it replace? A tool that adds a line item without removing one has to clear a much higher bar, and in a consolidating market most buyers are under explicit instruction to reduce the count of vendors. "It replaces these two contracts" is a stronger case than any feature.
2. Does it write back to the system of record? A tool that produces insight in its own interface creates a second place to look, and the second place loses. Read-only integrations are consistently the reason a tool gets adopted for a quarter and abandoned by renewal.
What buyers underweight, consistently
Implementation cost. The licence is visible; the six weeks of degraded output while the team relearns its workflow is not, and it is usually larger. Nobody puts it in the business case.
Data quality dependency. Execution tools are bought on the assumption that the data feeding them is good. When results disappoint, the tool takes the blame for a data-layer failure. See the four layers.
Overlap with what is already owned. Most stacks contain paid capability nobody is using, because the person who bought it left. An audit before a purchase changes the shortlist more often than any demo does.
What buyers overweight
The demo. A demo shows the product working on curated data with an expert driving. It tells you almost nothing about the failure mode, which is what you will actually live with.
Peer logos. A customer list tells you who signed, not who renewed. The useful question is what their usage looks like in month nine.
The three questions worth asking every vendor
- What does this replace in my stack, specifically? A vendor who cannot
answer is adding, not consolidating.
- When the model or the data is wrong, how fast does a human find out?
Every tool in this category is probabilistic now. The correction loop is the product.
- What does your median customer's usage look like at month nine? Not the
best one. The median.
Where this sits
Buying is Motion and Measurement in the Tenbound Pipeline Architecture Standard: a tool implements a motion, and it can only be judged by whether that motion improved, which requires the measurement to exist before the purchase, not after.
Related: vendor selection method and the four automation layers.
Want the audit before the purchase? The free evaluation reviews what you already own against what you are about to buy.