When your docs and your pricing page disagree

The mismatch, and the cheapest fix in this series

When a provider's pricing page says one rate and its docs, console or API reference say another, a buyer who notices has no way to tell which is right, and may ask sales for a quote in writing. The fix is cheap: keep one source of truth for prices, generate every page that shows a price from it, and check the pages against each other on a schedule. Of every change in this series, this one costs least.

It is also easy to skip, because pricing and docs often belong to different teams. Marketing owns the pricing page, engineering owns the docs, and nobody owns the gap between them. Naming one owner for every place a price appears is most of the fix.

The mismatch is easy to find from outside. Open the pricing page in one tab and the docs page for the same instance type in another, and compare. If a buyer can do that in a minute, so can a competitor writing a comparison page about you.

How the copies drift apart

The usual story: a rate changes, marketing updates the pricing page the same day, and the docs page that quoted the old rate in an example stays as it was. Months later a buyer working through a tutorial sees a different figure from the one they budgeted with. Neither team did anything wrong on its own page.

Other copies hide in the instance picker in the console, in the CLI help text, in a blog post announcing the launch price, and in a PDF that sales sends out. Each is a place the old rate can survive. The more copies there are, the longer the old rate lives.

Launch posts need particular care, because they are written to be shared and can keep turning up in searches for the product name after the price in them has changed. A note at the top of an old announcement pointing to the current pricing page costs a minute and stops it competing with your own table.

What it costs when a directory reads the wrong one

We read rates from each provider's pricing page, with the URL and the date, and hold 464 current observations from 48 providers. When the pricing page and the docs disagree, the pricing page is the one we read, and a buyer who then checks the docs finds a different number and wonders which of us is wrong.

If the pricing page itself is the stale copy, the wrong figure is what we show until it is fixed. A claimed vendor can dispute a value with evidence, and published corrections record what changed, but the cleaner route is a pricing page that is right in the first place.

What a buyer can conclude from two figures

Two figures from the same vendor give a buyer nothing to choose between them. One reasonable conclusion is that the vendor does not track its own prices, which is worse for the vendor than either figure. The cautious budget uses the higher one.

Some go further and ask in writing which is correct. The answer may come from sales, a day later, as a quote that differs again because it includes a discount. By then the buyer has three numbers for one card, and the provider with one clear number on every page looks easier to deal with.

Billing units drift the same way prices do. A docs page that says per-second billing next to a pricing page that says per-hour billing raises the same doubt, and so does a minimum term mentioned in one place and missing from the other.

A routine that keeps them in step

Put prices in one file or one table that every page reads: the pricing page, the docs, the console and the CLI. If that is out of reach this quarter, at least keep a list of every place a price appears, with an owner for each.

Remove prices from places that do not need them. A tutorial can say "see the pricing page for current rates" instead of quoting one. Every figure you delete from a secondary page is a figure that can never go stale there.

Then check monthly. A short script that fetches each page, pulls out the rates and compares them with the source file will catch drift in minutes. Without the script, a named person with a calendar reminder is the next best thing, and far better than nobody.

When a price changes

Treat a price change like a release. Change the source, regenerate the pages, update the "prices last changed" date, and add a line to the changelog with the old rate, the new rate and the day. A buyer who sees the change recorded trusts the new figure; a buyer who discovers it from an invoice does not.

Tell the places that copy you. A directory that reads your page on a schedule will pick up the change at its next read, and a stale figure in the meantime is visible to buyers. How we read provider pages describes the schedule and the 21 day rule that hides anything older.

Brief support and sales on the same day. A buyer who asks about the new rate and gets the old one from a person has found a third disagreeing copy, and that one is harder to forgive than a page.