Peer Benchmarks Without Leaking Anyone's Data

A peer benchmark is the strongest single anchor in a renewal conversation. "Companies your size pay this" moves a vendor in a way that "this feels expensive" never will. But a benchmark carries a hazard that most people never think about: to tell you what your peers pay, the tool has to hold what your peers pay, and if any of that leaks back out through a tooltip or a shared cache, you have built a machine that quietly exposes every customer's negotiated rate to every other customer. Here is how our benchmark chip works, and how it surfaces the number without ever leaking the source behind it.

Buckets, and the boundary rule

Per-seat pricing does not compare across company sizes. A 15-person team pays list; a 5,000-seat enterprise negotiates 30% off the same tool. Comparing them is noise. So every benchmark row is keyed to a seat bucket, and the comparison only ever happens within a bucket:

• under 25 seats
• 25 to 99 seats
• 100 to 499 seats
• 500 or more seats

The boundaries resolve upward. A count that lands exactly on a boundary goes to the higher bucket. Exactly 25 seats is in the 25-to-99 band, not under-25. Exactly 100 is in 100-to-499. Exactly 500 is in the 500-plus band. The rule is one line:

if (seats < 25) return "lt_25";
if (seats < 100) return "25_99";
if (seats < 500) return "100_499";
return "gte_500";

One subtlety that trips people up: each tool buckets on its own seat count, not on your company size. If you are a 6,000-employee enterprise with 5,000 Salesforce seats but only 400 seats of a sub-licensed tool, Salesforce sits in the 500-plus band and the sub-licensed tool sits in 100-to-499. The bucket follows the deployment, not the org chart. That per-tool independence is what keeps a small deployment inside a big company from being judged against enterprise-scale medians it will never reach. We go deeper on the dimensional side of this in dimensional SaaS compression.

The band: plus or minus 10% of p50

Inside a bucket, each row carries three numbers: a low, a median (p50), and a high per-seat rate. The comparison that drives the chip color is against the median, with a 10% band:

deltaPct = (actualMonthlyPerSeat - p50) / p50;
if (deltaPct > 0.1) return "over";
if (deltaPct < -0.1) return "under";
return "in_range";

Your effective per-seat rate is your monthly cost divided by your billed seat count. Compare it to the bucket median. More than 10% above the median reads over and the chip goes red. More than 10% below reads under and the chip goes green. Anything within the band reads in range and the chip goes neutral. The 10% band exists because a benchmark is an estimate, not a spot price, and a rate two percent off the median is not a finding. Ten percent is where a gap becomes worth a conversation.

The trust contract

Now the part that matters for whether you can trust the tool at all. Every benchmark row has an internal source: a label and a URL saying where the number came from, and often a sample-size note like "Vendr median across N deals." Those fields are gold for us during a data audit and poison if they ever reach a customer's screen. A tooltip that read "Vendr median, negotiated" would be leaking the provenance of a competitor's rate into your renewal.

So the source fields never leave the server. The benchmarks API selects the low, median, and high rates and the bucket, and nothing else. The source label, the source URL, and the sample-size note are excluded at the query, and the response shape is narrowed at the boundary so they cannot ride along by accident. What the chip and its tooltip actually show is generic copy: aggregated from industry benchmarks for your size band, last updated with a date. No vendor named. No deal count. No negotiated-rate attribution. The number crosses the boundary; the story behind it does not.

The caching follows the same rule. The benchmark response is marked private, so it stays out of any shared or CDN cache. A benchmark is a paid-tier feature, and a shared cache is exactly how a free user behind the same edge could collide into a paid response they were never entitled to. Private caching closes that door. The whole design assumes the most hostile reader possible and gives them nothing but a color and a band.

Where the numbers come from, and where they are going

Version one of the benchmark data is hand-curated from public sources: vendor pricing pages, published procurement medians from firms like Vendr and Tropic, and list rates cross-checked across guides. It is honest and it is defensible, but it is public-source data, which is why the tooltip says "industry benchmarks" and not "your peers."

The schema is built to swap that out without a migration. Once any single (vendor, bucket) cell has at least 10 real customers, that cell can move to an anonymized median derived from actual customer contracts, and the chip copy earns the word "peers" for real. The 10-customer floor is the anonymity threshold: below it, a median could be reverse-engineered toward an individual contract, which is the exact leak the trust contract exists to prevent. The number on the chip gets better as the customer base grows, and the privacy guarantee holds the entire way there.

Worked example: reading a red chip on Salesforce

Take an enterprise running Salesforce at 1,200 seats. That count lands in the 500-plus bucket. The benchmark median for Salesforce at that size is $100 per seat per month, so the in-range band runs from $90 to $110 (10% either side of $100).

Your effective rate comes back at $120. That is 20% above the median, well past the 10% line, so the chip is red and reads over. The gap the chip is pointing at, if you moved from $120 to the $100 median, is 20 x 1,200 x 12, or $288,000 a year of theoretical spread. Apply our standard renegotiation realization factor of 0.5 and the realistic year-one figure is $144,000. The Salesforce renegotiation playbook is the canonical version of that conversation.

Change one input and watch the chip move. At an effective rate of $100 you sit exactly on the median, the chip is neutral, and there is no finding. At $85 you are below the $90 floor, the chip is green, and you are already ahead of your size band. Same tool, same bucket, three different colors, driven entirely by where your negotiated rate sits against the median.

What a red chip does and does not mean

The red chip is a prompt, not a verdict. Here is the honest boundary on it.

What you should conclude. Peers in your size band land lower than you do, by more than the noise threshold. There is a data-backed number to open a renewal with, and "companies at 500-plus seats pay around $100" is a sentence a vendor has to answer. The gap is real enough to be worth the conversation.

What you should not conclude. A red chip is not proof you are overpaying for identical value. You might be carrying more Clouds, a premium support tier, or a smaller volume commit than the median deal, any of which legitimately lifts your rate. And p50 is the median, which means half of your peers pay more than $100, not less. The band does not know your specific edition or bundle. It knows your size and your rate, and it flags the gap so you go ask the question. It does not promise the cut.

Treat the chip as the first sentence of a renegotiation, not the last. It tells you which tools are worth the effort of a real anchor, sized to your seat band, defensible against a vendor who pushes back. On the PEPM side, the rate-renegotiation playbook uses the same median-and-band logic keyed to headcount instead of seats. Pull your stack, read the red chips, and start with the biggest gap. The number is safe to lean on precisely because we built the whole thing so that no one else's number ever leaks to build it.