Don't Publish an SLA Number You Can't Evidence
While reworking our pricing page we audited every claim on it against something we could actually produce if asked. Three did not survive:
- a financially-backed 99.999% SLA on the top tier — with no SLA document to link
- SOC 2 and PCI listed as Enterprise features — with no attestation anywhere
- "100+ integrations" — with no integration list published, and no way for a reader to check
All three were removed. Not softened — removed, and replaced with statements we can stand behind.
Why these claims are worse than saying less
The buyer who matters will ask. Small deals do not check. The enterprise deal that justifies the claim is exactly the one where a security reviewer requests the SOC 2 report in week one. "We don't actually have one" at that point does not cost you a feature — it costs the deal and the credibility of everything else you said.
A financially-backed SLA is a contractual promise. The phrase means specific money moves when availability misses the number. If no document defines the measurement window, exclusions, claim process and credit schedule, the words describe an obligation nobody has written, scoped or priced. Published on a pricing page next to a buy button, it is a term of sale.
Unverifiable numbers are load-bearing in the wrong direction. "100+ integrations" invites "which ones?". If the honest answer is a list nobody has compiled, the number was decoration. Any reader who checks learns something about the rest of the page.
Five nines is a very large claim. 99.999% is about 26 seconds of downtime a month — across every dependency, including ones you buy. Publishing it signals either an unusual engineering investment or that nobody did the arithmetic. Technical buyers know which is more common.
What we published instead
Instead of a five-nines SLA: "Dedicated CSM & a written availability SLA." True — Enterprise agreements include one — and it describes a document that exists rather than a number nobody could produce. When the signed SLA is finalised, the figure goes back with a link to it.
Instead of SOC 2 and PCI: "HIPAA BAA, compliance evidence packet, data residency options." Each is a real thing a customer can obtain. The BAA is signed at no charge from the mid tier. The evidence packet is a document describing how the service is operated, prepared for a security review. Data residency is scoped per contract.
Instead of "100+ integrations": nothing, for now. The page lists the integration categories it can evidence. When the integration list is published, the claim returns with a link to it.
Removing a number without replacing it feels like weakening the page. It is not, because an unverifiable number was never persuading the reader who mattered.
The audit, if you want to run it on your own pages
Go through every claim and sort it into one of three buckets:
- Evidenced — there is a document, a list, a report or a measurement you can produce today. Keep it, and link to the evidence. A linked claim is far stronger than an asserted one.
- True but undocumented — accurate, but you cannot hand anyone proof. Rewrite it as the thing you can evidence, or publish the evidence and move it to bucket one.
- Unverified — nobody can say where the number came from. Remove it.
Numbers attract the most scrutiny, so start there: uptime percentages, response and resolution times, customer counts, integration counts, "trusted by" logos, certification names, and any claim containing "industry-leading" or "guaranteed".
For each, ask the question a procurement reviewer will: "Can you send me that?" If the honest answer is no, it does not belong on a page with a buy button.
Where the replacements should point
An audit like this usually produces a pile of "available on request" items, which can read as evasive if that is all you have. The fix is to give them a home — a trust or security page that states, in plain language, what you commit to in writing and what a buyer can obtain during a review.
Ours says explicitly that it claims no certifications, no encryption specifics and no subprocessor list, because none of those are documented anywhere citable yet. That reads as oddly honest for a marketing site. It is also the page a security reviewer checks hardest, and a narrow accurate page survives that reading in a way a broad vague one does not.
Then the backlog becomes concrete: get the SLA written, get the attestation if the market needs it, publish the integration list. Each one moves a claim from bucket three to bucket one, and each is a real improvement to the offer rather than to the copy.
The underlying standard
The bar is not "could we defend this in an argument". It is: if a customer asks for the evidence behind this sentence, can we send it today?
Anything that fails that test is borrowed credibility. It works until someone checks, and the people who check are the ones you most want to sell to.
