Why Most Pricing Pages Kill Conversions Before They Start
Something we keep noticing in conversion audits:
The pricing page is almost always the single biggest source of lost revenue on a B2B site. Not the homepage. Not the landing pages. The pricing page.
And the reason is counterintuitive. It’s not that the pricing is wrong.
It’s that the page is designed to show information instead of helping someone choose. Those sound similar. They produce completely different outcomes.
When we watch session recordings, the pattern repeats over and over. Visitor scrolls down the pricing table, pauses, scrolls back up, leaves. They arrived ready to buy. The page made them hesitate.
Most teams treat the pricing page like a feature comparison spreadsheet. Three columns, a list of checkmarks, a button at the bottom. Built once, never revisited.
Meanwhile it’s quietly bleeding 40-60% of visitors who had genuine buying intent.
The gap between “showing someone options” and “helping someone decide” is where most of that revenue disappears.
We wrote about why this happens and where it breaks down.
Your Website Doesn’t Have A Tone Of Voice And It Shows
Tone of voice is not a branding luxury. It’s a conversion variable.
Most mid-market companies treat it as something the marketing team will get around to eventually. A nice-to-have once the “real” website work is done.
Meanwhile their homepage sounds corporate, their About page sounds like a different company, and their service pages read like they were lifted from a competitor with the name swapped in.
Visitors notice this. They can’t always articulate it. But the subconscious signal is clear: this company doesn’t really know who it is.
And if a company doesn’t know who it is, why would a buyer trust it with their budget?
Here’s what surprised me most. Inconsistent tone doesn’t just hurt trust. It slows down everything downstream. Content production takes longer because writers have no reference point. Sales teams stop using the website in conversations because certain pages don’t represent them well.
The common fix is picking “formal” or “casual” and applying it everywhere. That misses the point entirely. Tone is the consistent personality behind your word choices and how you frame ideas. It should feel as recognisable as a familiar person’s speaking style.
Ten pages in, a visitor should feel like the same knowledgeable person has been talking to them throughout.
Most sites fail that test by page two.
We wrote about what actually breaks down and why it matters more than teams realise.
Honest question: if you read your own website end to end right now, would it sound like one person or three?
What A Good Case Study Looks Like And Why Most Are Terrible
80% of case studies have the same fatal flaw.
Eighty percent.
We see it every time we audit a company’s proof library. The case study reads like the vendor is the protagonist. “We delivered a world-class solution.” “Our team transformed their operations.”
The prospect reading that doesn’t care about your heroism. They’re scanning for someone who had a problem like theirs.
And here’s what makes it worse. Even the ones that get the hero right usually botch the problem statement. “The client needed a better solution” tells nobody anything.
Specificity is what creates the moment of recognition. Revenue at risk. A process that couldn’t scale. A compliance deadline nobody was ready for. That’s what makes a prospect think “that sounds exactly like us.”
Without that, your case study is a brochure with a quote bolted on. It lands with a thud in every sales conversation where you try to use it.
If you’re relying on case studies to help close deals right now, this is worth ten minutes of your time.
The Part Of A Website Migration Nobody Plans For
The site launched on time. Redirects worked. Staging looked great.
Three weeks later, marketing couldn’t update a landing page without filing a dev ticket. Sales discovered their lead forms were routing to the wrong place. The content team’s entire publishing workflow had been wiped out.
Nobody saw it coming because nobody scoped it.
The technical migration got a detailed proposal, sprint plans, a Gantt chart. The operational reality on the other side of launch? That got zero budget, zero planning, and zero ownership.
This is the pattern we see over and over. A company spends six figures moving to a new platform. The agency delivers a technically sound website. Then the gap between “the site is live” and “the team can actually operate it” quietly unravels the whole thing.
Not because of broken redirects or bad templates. Because nobody planned for the fact that every team would need to work differently after launch. New tools, new workflows, new content processes, new responsibilities.
The proposal became the project plan. And everything outside that boundary became someone else’s problem.
If you’re planning a migration right now, we wrote about the part that almost never makes it into the scope. It should.
Freelancer vs Agency For Your Website Build
There’s a complexity range where most mid-market website projects land.
It’s too complex for a solo freelancer to comfortably own. But not complex enough to justify what a mid-size agency charges for dedicated PM, design, dev, and QA.
That grey zone is where the most project failures happen.
Not because of bad talent. Good freelancers and good agencies both exist. The failures happen because companies pick their delivery model based on budget rather than the coordination demands of the build itself.
Here’s what makes it worse. A freelancer who costs half as much but delivers a site that can’t integrate with your CRM or lacks proper SEO architecture isn’t cheaper. They’re more expensive. And an agency charging six figures who can’t explain what they’re building until they start building it isn’t more professional.
The real deciding factor is whether you understand your own project well enough to brief either option properly. Most teams don’t. And that gap between what you think you need and what the project actually requires is where the budget disappears.
We published our full thinking on this one.
Writing A Website RFP That Actually Gets Useful Responses
We’ve reviewed hundreds of website RFPs that clients brought to us after getting confusing proposals back.
The pattern is almost always the same.
The document asked vendors to describe their company history, list certifications, provide references. Pages and pages focused on the vendor. Almost nothing about the actual project.
So every agency filled in the blanks differently. Made different assumptions. Priced different scopes. And the client ended up with five proposals they couldn’t meaningfully compare.
Here’s what caught me off guard when I first saw this pattern: the budget inflation isn’t coming from greedy vendors. It’s coming from ambiguity. When a vendor encounters a vague requirement, they either price it low and recover through change orders, or price it high to cover the unknowns.
Neither outcome is good for you. One leads to scope creep. The other means you’re paying a risk premium for your own lack of preparation.
Most RFP templates make this worse. They were designed to evaluate vendors, not to communicate projects. The vendor with the best copywriter wins.
We wrote about what a substantive RFP actually focuses on instead.
what is website accessibility and why should i care
What most mid-market teams think accessibility means:
Screen readers. Alt text on a few images. A compliance checkbox somewhere on the backlog.
What it actually involves:
Four distinct principles covering every interaction on your site. Keyboard operability. Colour contrast ratios. Semantic HTML structure. Predictable form behaviour. Video captions. Code that assistive tech can actually parse.
The gap between those two lists is enormous.
And here’s what gets missed: roughly one in five people in the UK has some form of disability. Add temporary impairments like a broken wrist or age-related vision decline, and the real number is far higher.
These aren’t edge cases. They’re your buyers, your procurement contacts, your decision-makers.
Most B2B companies file this under “we’ll get to it eventually.” Meanwhile their site is quietly excluding revenue, accumulating legal exposure, and hurting search performance all at once.
The cost of fixing it goes up the longer you wait.
We wrote about where this breaks down and why it matters more than most teams realise.
how to optimise images for my website without losing quality
Images account for 40-70% of total page weight on most mid-market B2B websites we look at.
Not code. Not fonts. Not third-party scripts. Images.
A typical page carrying 4MB of assets has 2-3MB of photos that could be 400-600KB without a single visible difference. That’s a 60-80% reduction sitting right there, untouched.
So why hasn’t it been done?
Because the risk feels wrong. Nobody on the marketing team wants to be the person who made the site look cheap. So the 5000-pixel stock photo stays exactly as uploaded. The CMS serves it at full resolution to every device. Phones get the same file as desktops.
The original image was prepared for print or maximum flexibility. A full-width hero on a Retina display needs about 1600-1800 pixels wide. The other 3,200 pixels? Downloaded and immediately discarded by the browser. Every single visit.
The performance cost is real. Largest Contentful Paint, Core Web Vitals, bounce rates, search rankings. All dragged down by assets nobody ever resized because the process felt too risky to touch.
This isn’t a hosting problem. It’s a workflow problem. And the gap between knowing that and actually fixing it without breaking things is wider than most teams expect.
We wrote about where this goes wrong and what makes it tricky.
how to choose the right hosting for my website
Your pages take 4+ seconds to load.
The instinct: optimise images. Add a caching plugin. Minify the CSS.
Usually treating the symptom, not the cause.
Most mid-market sites we audit with performance problems trace back to something nobody wants to revisit: the hosting environment.
→ Server response time is 800ms+ before a single asset starts loading
→ That slow TTFB eats 40-60% of the total page load budget
→ Core Web Vitals tank, and no amount of front-end optimisation can compensate
The painful part? Hosting was chosen months earlier based on price or a passing recommendation. Before anyone had defined what “good performance” actually looked like for the site.
By the time it surfaces as a problem, it’s baked in. Migration is disruptive and expensive.
The comparison sites most teams use to choose? Those rankings are based on affiliate commissions, not performance data.
We mapped this out in our latest article. Worth reading before you pick a host, not after.
what is a cdn and does my website need one
“We added a CDN so the site should be faster now.”
This sentence has cost more teams more wasted months than I can count.
A CDN solves exactly one problem: the physical distance between your server and your visitors. London server, Sydney visitor, 17,000 kilometres of latency. That’s the gap it closes.
But most slow websites aren’t slow because of distance.
They’re slow because of bloated code. Unoptimised images. A pile of third-party scripts nobody audited.
Put a CDN in front of that and you get the same sluggish experience delivered from a server that happens to be closer. Marginally better. Fundamentally unchanged.
There’s also a metric most teams never look at: cache hit ratio. It determines whether your CDN is actually serving files from the edge or just bouncing requests back to your origin server anyway. A badly configured CDN can quietly do almost nothing.
The real question isn’t “do we need a CDN.” It’s “do we know which problem is actually making this site slow.”
If you’ve been assuming a CDN would move the needle and it hasn’t, this piece explains why.