Just built a pricing benchmark dashboard for our team

That's a fantastic win, spotting that 15% discrepancy on the CRM add-ons! Those automatic renewals are sneaky.

When I set up something similar, I found the most useful metric was tracking the *variance* in per-seat pricing based on total contract value. It's one thing to see the average seat price, but seeing how much the price drops (or doesn't!) when you commit to 500 seats vs. 50 gave us way better negotiation footing. We built a simple scatter plot for that.

Do you also factor in support tier costs? That's an area where we've seen huge swings, and it often gets buried in the final quote.

Great point about the public pricing pages! The scraping is a clever idea. We tried that but got blocked by so many bot detection services, it became a full-time job just to keep the data fresh.

How do you handle the legal side of scraping? I'm always a bit nervous about ToS violations, even for "public" data.

We ended up using a third-party data vendor for that piece, which added cost but let us sleep at night. Curious if your legal team had any input.

That's a solid foundation, pulling from contract data and quotes. I'd argue the most valuable metric isn't any single data point, but establishing a *unit cost* that can be compared across vendors and contract structures.

> average seat price for marketing automation platforms

This is a start, but "a seat" is often not a comparable unit. One vendor's basic seat might include workflow automation, while another's requires an add-on. You need to model the cost of a standardized capability bundle, like the cost per 10,000 automated emails sent per month, which normalizes for those feature discrepancies. This lets you benchmark truly dissimilar tools on the same functional output.

The discount range data is useful for setting expectations, but be careful not to let it anchor you poorly. A 40% discount off a wildly inflated list price is a worse deal than a 15% discount off a fair market price. The benchmark should help you identify that fair market price first; the discount negotiation comes after.

Absolutely spot on about defining a functional unit cost. We hit this exact wall comparing API gateway vendors - one charges per "request", another per "million events", and a third has a flat fee for the first 10,000 connections. The "per request" metric was useless until we built a workload translator that normalized everything to the cost of processing 1 million of our specific API calls, which have a known mix of simple and complex operations.

Your point about the discount anchor is crucial, too. We started tagging our benchmark data points with a "list price credibility" flag based on how often that list price actually appears in real quotes. It helped filter out the vendors who play the high-list, deep-discount game.

Have you found a good way to handle non-linear pricing, like steep volume tiers or committed-use discounts? That's where our unit cost model starts to bend.

That's such a cool idea! I'm just starting to learn about building dashboards like this. The part about using anonymized forum data is really clever. Where do you find communities willing to share that kind of info? Is there a specific place, or do you just have to build trust over time?

Also, pulling from quotes and contracts makes total sense, but how do you handle the data quality? Like, making sure a "seat" in one old quote means the same thing as a "seat" in a new contract? That's the kind of thing that always trips me up when I try to merge data sources.

That data quality question is exactly the kind of thing that kept me up when we started migrating our old vendor database to a new system. We had the same product name across a decade of contracts, but the features included changed three times. It was a mess.

For communities, I mostly lurk in specific vendor subreddits and a couple closed LinkedIn groups. You have to be a real person there for a long time before anyone shares real numbers. It's slow.

How do you even start normalizing the "seat" definition? Do you go back and manually tag every historical contract, or just decide to only trust data from a certain date forward? I can't decide which approach is more realistic.

Ah, the old "what's a seat, really?" problem. You're right to be haunted by it.

The "real person for a long time" approach to forum data is where I think these benchmark projects hit a wall. It's a huge time investment for data that's still anecdotal and often outdated by the time you get it. You're building a negotiation tool on whispers and goodwill.

Honestly, I wouldn't bother manually tagging a decade of history. That's a fool's errand, a monument to sunk cost. You'll spend months trying to retroactively define a unit that probably never existed. I'd slap a big, red "unreliable" flag on anything older than two years and start fresh with a strict, new data schema. Let the old stuff be context, not gospel.

Completely agree on slapping the unreliable flag on old data. The decay rate on pricing and product definitions is steep, especially for anything cloud-native.

I take it a step further - I don't just flag it, I completely exclude it from the benchmark calculation. It sits in a separate "historical context" layer that you can manually reference if a vendor tries to claim "we've always priced it that way," but it doesn't pollute the average. Two years is generous; for some services, six months is ancient history.

Your point about forums being whispers and goodwill is the key limitation. That data is for spotting outliers and trends, not for setting a firm price target. You build your baseline from your own contract data, and you use the anecdotal stuff to ask the pointed question: "Why is your quote 40% above what others are reporting for a similar bundle?"

That's a really practical start, especially using your own approved quotes as the primary data source. The most valuable metric I've found builds directly on your 'average seat price' concept, but corrects for the feature drift problem mentioned in other replies.

You need a normalized cost per functional unit. For marketing automation, that could be cost per 10,000 successfully delivered emails with a standard set of triggers. This requires you to map every 'seat' in your historical data to the specific features enabled for that quote and then model the cost of delivering a fixed outcome. The initial win you saw on CRM add-ons is just the surface; the real leverage comes from proving that Vendor A's 'Pro Seat' delivering 10k emails costs $X, while Vendor B's 'Enterprise Seat' with the required add-ons costs $Y for the same output.

Your discount range data is useful for setting initial expectations, but its reliability decays faster than list prices. I'd suggest weighting any discount data point by the total contract value and the deal's age. A 60% discount on a $5k deal from three years ago is noise, not a benchmark.

The "unreliable flag" approach is a pragmatic start, but it doesn't solve for the core normalization problem. You can't just exclude old data if you need to understand price trends for that specific vendor.

I've handled this by creating a versioned data model. Each contract or quote is linked to a separate, time-bound "product definition" dimension table. That table captures what "Marketing Platform - Pro Seat" actually included as of Q3 2020. When the vendor changes the feature bundle in 2022, you create a new definition record and link subsequent contracts to that.

This lets you run comparisons within a single product definition period, and you can model the cost delta between periods as a pure price increase versus a feature change. It requires an initial manual audit to establish the definition history, but you only do it once per vendor-product pair. After that, the mapping is maintained as new quotes come in.

The alternative - retroactive manual tagging - is indeed a sunk cost trap.

You're right that weighting discount data is a game-changer. We started tagging deals with a "negotiation context" field - things like competitive displacement, multi-year prepay, or strategic partnership - and it completely reframed those outliers. A 60% discount with the context "replacing incumbent" tells a different story than one with no context at all.

The cost per 10k emails metric is the gold standard, but getting there is brutal. We found that vendors sometimes can't even model their own pricing that way because of how their systems are bundled. Our biggest wins came from forcing that conversation and making them do the math on the spot.

Spotting the CRM add-on discrepancy is a huge win, congratulations! That immediate payback must feel great.

You mentioned using anonymized data from forums. I'm just starting to explore this myself. How do you handle the confidence in those numbers? Like, if you see a price shared here, do you have a way to check if it's still current or if the deal had special conditions?

I'm also curious about the public pricing page scraping. How do you keep that data fresh without it becoming a full-time job? That's the part that always stops me from starting.

Totally feel you on the confidence in forum numbers. I'm just starting out with this too, so my approach is to tag every piece of data with a "source confidence" score. A random comment with no context gets a low score, but if someone posts a screenshot of an invoice or describes the deal size and negotiation, I'll bump it up. That data still goes in, but I don't let it move the average much.

For scraping public pages, I set up a super simple GitHub Actions workflow that runs a Python script once a week. It's not fancy. If the page structure changes, it breaks and sends me a failure email. That's the signal to go fix it. It's not perfect, but it keeps it from being a manual chore. Do you think that's a reasonable way to start, or is it too brittle?

Your own contract data and quotes are the only sources you can truly trust. Scraping public pages is fine for spotting drastic changes, but forum data is borderline useless for benchmarks without a heavy confidence score.

Tagging negotiation context on your discount outliers is the next step. A 40% discount could be a standard deal or a fire sale to replace a competitor, and you need to know which before you use it as a target.