Zilliant just told the market it can process pricing requests roughly three times faster than a rival, and up to seventy times faster under peak load, based on a benchmark run for FTZ, Denmark’s largest automotive parts distributor. Those are real, measured numbers from a real evaluation. They are also not a pricing strategy, and RevOps leaders reading the announcement as proof of one are buying the wrong argument.
The benchmark is real. The inference from it is not.
FTZ ran a genuine technical test: 1,000 randomized pricing requests, the same customer-side test client, directly comparable conditions between Zilliant and a competing platform. Zilliant won on sequential response time and won bigger on throughput under maximum load. Andreas True, CIO at FTZ, said the platform “needs to support live, high-volume price calls from the webshop and operational systems without creating a bottleneck,” and the benchmark gave FTZ confidence Zilliant could do that at scale.
That is a legitimate, narrow finding: this system answers pricing queries faster than that system, under this specific load pattern. It says nothing about whether the prices either system calculates are the right ones. A pricing engine that returns a bad price in ten milliseconds is not an improvement over one that returns a good price in thirty. Speed is an infrastructure property. Getting the price right is a strategy property. Vendors have every incentive to let buyers blur the two, because infrastructure benchmarks produce clean, quotable numbers and strategy quality does not.
Advertisement
The counter-argument, stated fairly
The strongest defense of treating speed as strategically meaningful is that in a high-volume digital business, latency is not cosmetic. Tony Norman Christensen, Head of Strategic Pricing & Analytics at FTZ, made close to this case directly: “Pricing is becoming part of the customer experience at FTZ. We selected Zilliant because it gives our pricing team the governance, automation and visibility we need, while supporting the speed expected from a digital business like ours.” A pricing system that times out or lags under load does not just look slow. It breaks the webshop experience, stalls quote generation for reps, and forces a distributor managing over 300,000 SKUs to fall back on stale cached prices or manual overrides. At that scale, a governance policy nobody can execute in real time is not really a policy at all. Pascal Yammine, Chief Executive Officer at Zilliant, put the vendor’s version of the same point plainly: “For a distributor managing hundreds of thousands of products, customer-specific conditions and real-time digital interactions, pricing performance is not a technical detail.”
He is not wrong that performance is a precondition. He is wrong to imply it is the differentiator.
Why the rebuttal still holds
Notice what FTZ’s own quote actually asks for: governance, automation and visibility, with speed listed last, as a supporting requirement rather than the goal itself. That ordering is correct, and it undercuts the marketing framing built around the benchmark. Governance means someone has defined the rules a price has to satisfy: margin floors, customer-tier logic, competitive guardrails, exception handling. Automation means those rules execute without a human re-keying them for every quote. Visibility means someone can see why a given price came out the way it did. None of that is measured by a benchmark counting requests per second. A system with excellent governance and mediocre throughput will still produce defensible prices, just more slowly. A system with best-in-class throughput and thin governance will produce bad prices very quickly, and at 70x the throughput, it will produce them at a scale that makes them much harder to catch and unwind.
This publication has made a version of this argument before about a different corner of the pricing stack: that distributors chasing a software fix are usually solving the wrong layer of the problem, and that the harder, unglamorous work is margin governance, not tooling. The same logic applies here. It also echoes a broader pattern this publication has tracked in revenue execution generally: teams tend to blame execution speed for problems that actually trace back to design, whether that design failure sits in a compensation plan or, in this case, in a pricing rulebook nobody built with enough rigor before the benchmark race started.
What RevOps buyers should actually ask
None of this means FTZ made a bad choice, or that Zilliant’s platform is weak. It means the benchmark should not be the headline evidence for either claim. A RevOps leader evaluating a pricing platform on the strength of a vendor-commissioned speed test should ask a different set of questions first: what governance model does this system enforce, who owns exception approval, how is a bad price rule caught before it ships at scale, and only then, how fast does the system execute the rules once they are right. Buy for governance. Benchmark for confirmation that governance can run at your volume. Reverse that order, and a distributor risks building a very fast system for enforcing whatever pricing logic it happened to have on the day it signed the contract.
Source: Zilliant
