What does a skeptical buyer actually check first?
They look for someone like them. Before a buyer reads your claims, they scan for evidence that a company their size, in their situation, with their constraints, already made this work. Everything else is decoration until that question is answered.
This is the single most reliable pattern I see in B2B website work. Buyers do not start at the top of your homepage and read down. They hunt. They are looking for a signal that says this is for me, and they will leave the moment they conclude it is not.
Most sites answer the wrong question first. They explain what the product does before they establish who it is for and who it has already worked for. That ordering feels logical to the person who built the product and backwards to the person evaluating it.
Why do logos fail as proof?
Because a logo proves a transaction happened, not that it went well. A row of recognisable brands tells a buyer you have sold before. It does not tell them what changed, for whom, or whether the same thing could happen for them.
Logos also carry a quiet risk. If your wall of logos is all enterprise and your visitor is a twelve person team, you have just told them they are the wrong customer. I have watched founders add impressive logos and then wonder why smaller deals slowed down.
That does not mean remove them. It means stop treating them as the proof and start treating them as context. The proof is the sentence underneath that says what one of those companies actually got. I have made this argument at more length in why customer logos are not proof.
What makes a number believable?
Specificity and provenance. A believable number names who measured it, over what period, and against what baseline. An unbelievable number is round, unattributed and flattering.
Compare two sentences. "Customers save thousands of hours." Versus "Across the cases we handled between launch and today, the system has saved more than 50,000 hours." The second one is checkable, bounded and attributable. The first one could mean anything.
I hold my own numbers to that rule. When I say the automation I built for Ajust on Airtable and WhaleSync has delivered more than 25,000 cases, helped more than 400,000 people and saved more than 50,000 hours, those are measured outcomes from a live system, not a rounded estimate I liked the sound of. If I could not point at where a number came from, I would not print it.
The discipline is uncomfortable, because it usually means your proof is smaller than you want it to be. Smaller and true beats large and vague every single time, and buyers who have been burned can tell the difference instantly.
Which single case study should you write first?
Write the one about your most typical customer, not your most impressive one. The best case study is the one where the most visitors recognise themselves, and that is almost never the biggest logo you landed.
Founders resist this. The instinct is to lead with the prestige name, because it feels like it confers credibility. It does confer credibility, but of the wrong kind. It proves you can service a company nothing like the visitor.
The practical test is to look at your last ten closed deals, find the shape that repeats, and write that one properly. Include the situation before, the decision they were weighing, what they tried first, what changed and what it cost them in time or money. That structure does more work than three glossy quotes.
How many you need afterwards is a separate question, and the answer is fewer than people think. I have gone through that arithmetic in how many case studies a B2B site actually needs.
How much detail is too much?
You have gone too far when the detail stops being checkable. Specifics that a reader could verify or recognise build trust. Specifics invented to sound rigorous destroy it the moment one of them is wrong.
There is a failure mode I see often where a case study reads like a novel. Invented emotional beats, imagined quotes, a tidy narrative arc. Buyers in the market have read a hundred of these and they discount all of them, including the honest ones.
The fix is boring. Say what happened. Say what you do not know. If the customer will not let you share revenue impact, say that you cannot share revenue impact rather than substituting a softer metric and hoping nobody notices the swap.
What proof works when you cannot name the customer?
Describe the situation precisely and the company vaguely. "A regulated healthcare provider with a two person marketing team" tells a reader far more than a logo they half recognise, and it breaks no confidentiality.
Anonymised proof gets a bad reputation because it is usually done lazily. "A leading enterprise client" is not anonymisation, it is a shrug. The information a buyer needs is the shape of the problem, the constraints and the outcome. The name is the least useful part.
When I describe the CRM work I did for Kismet Health, connecting their stack into HubSpot through Zapier, the useful detail is the stack and the constraint, not the brand. That is what a similar company recognises. I have written up the mechanics of doing this well in how to write a customer story when the customer cannot be named.
Where should proof sit on the page?
Next to the claim it supports. Proof grouped into a testimonials section is proof nobody reads. Proof placed immediately after the specific promise it backs is proof that does work.
Think about what a skeptical reader does. They hit a claim, they form a doubt, and in that second they are either reassured or they are gone. A carousel eight sections down does not help them. One relevant sentence underneath the claim does.
This also solves a design problem. Most pages have one proof block because proof was treated as a section rather than a behaviour. Spread it out, and suddenly you need less of it, because each piece is working directly on a specific objection.
What proof do buyers look for when nobody talks to sales?
They look for the things a salesperson would normally handle: pricing, security posture, implementation effort and what happens if it goes wrong. When a buyer evaluates alone, silence on those topics reads as a red flag rather than as discretion.
Self serve evaluation has changed what counts as proof. A clear page about how you handle data, an honest implementation timeline and a real answer about pricing structure are now proof, because they demonstrate that you have thought about the buyer's risk rather than just your own conversion rate.
The same applies to how answer engines describe you. If your site never states plainly who you are for and what you charge, something else will fill that gap with a guess. I would rather be the source of the answer than the subject of one.
How do I decide what proof to build for a client?
I ask what objection is killing deals, then I build proof for that objection only. Proof built for a hypothetical doubt is expensive decoration. Proof built for a real one changes the pipeline.
The way I find it is unglamorous. Read the last twenty sales conversations, find the sentence that appears again and again, and build directly against it. Across more than 70 projects for more than 25 clients over more than six years, that sentence has almost never been the one the founder expected.
My own site follows the same logic. I publish my pricing structure and I have written more than 350 articles, because the objection I actually face is whether I know what I am doing and whether I am affordable. Those two doubts get answered before anyone emails me.
What should you do next?
Open your homepage and find the strongest claim on it. Then ask what a suspicious version of your buyer would need to see, right there, to believe it. If the answer is not on the page within a screen of the claim, you have found your next piece of work.
Do that for the three biggest claims on the site and you will end up with a short, specific list of proof to build. It will look less impressive than a redesign and it will move more deals.
If you want someone to go through your site and tell you honestly which of your proof is actually working, reach out. I am happy to look and tell you which parts I would cut.
Get found, cited and the back office automated
Let's make your site the source AI engines quote and wire up the systems behind it.
Read more blogs
Let's get your website found and cited by AI
Tell me what you're working on, whether AI search is skipping your product, your back office is buried in manual work, or you need a build that does both.