Case Studies That Sell: Writing Project Pages Clients Actually Read

Ask any partner at a consultancy or law firm which page a serious prospect reads before getting in touch, and the answer is rarely the homepage. It is the work. Buyers of expertise want evidence that you have solved a problem like theirs, for an organisation like theirs, and that the result was worth the money. That makes case study writing one of the most valuable skills a professional firm can develop, and one of the most neglected.

Most project pages fall into one of two traps. Some are a logo, a few images and a single sentence ("We helped Client X with their digital presence"). Others are long, dutiful accounts of every meeting and deliverable, written for the team that did the work rather than the person deciding whether to hire it. Neither persuades anyone. The good news is that a case study that sells follows a fairly reliable structure, and most firms already have the raw material sitting in old proposals and project folders.

Start With the Client's Problem, Not Your Process

The reader of a case study is quietly asking one question: is this firm's experience relevant to my situation? The fastest way to answer it is to open with the client's problem, described in terms the prospect would recognise.

"A regional law firm whose website generated almost no enquiries, despite strong referrals" tells the reader far more than "We redesigned the website for a law firm." It names the type of organisation, the situation and the tension. A prospect with the same problem will lean in. One with a different problem will move on, which is also useful, because it saves both of you a call.

Keep this opening to two or three sentences. Include the context that made the problem difficult: a tight deadline, a merger, a regulatory change, a board that needed convincing. Constraints are what make a story credible, and they are what separate a real project from a template.

Show the Thinking Behind the Work

The middle of a case study is where most firms list deliverables: discovery workshop, wireframes, design, build, launch. That sequence is true of almost every project and so tells the reader almost nothing.

What a prospect actually wants to see is judgement. Which options did you consider, and why did you choose the one you did? What did you learn in the first weeks that changed the plan? Where did you push back on the client, and what happened as a result? A short paragraph on one genuine decision is worth more than a page of process diagrams, because it shows how you think when the brief is unclear, which is exactly the situation the prospect is in.

This is also the place to be honest about difficulty. A project that went perfectly from start to finish reads as either very simple or slightly edited. Mentioning a real obstacle and how it was handled builds more trust than polish ever could.

Make the Results Specific and Believable

Results are the part readers scroll to first, so they deserve care. Specific numbers are ideal when you have them and the client is comfortable sharing them: enquiries per month before and after, time to publish a new article, the share of visitors reaching the contact page. Round them sensibly and give the timeframe. "Enquiries roughly doubled in the six months after launch" is more believable than "a 104.7% increase."

Not every project produces a clean metric, and that is fine. Qualitative results can be just as persuasive if they are concrete. A fund that can now publish quarterly reports without involving a developer, a school whose parents stopped calling the office to find term dates, a partner who reports that new clients mention the website in first meetings: each of these describes a real change in how the organisation works.

What to avoid is the vague middle ground. "Improved user experience" and "a modern, fresh look" are claims every studio makes and no reader can verify.

Let the Client Speak for Themselves

A short quote from the client does something your own writing cannot: it lets a peer vouch for you. The most useful quotes are specific and a little plain. "Our team updates the site themselves now, which they never did before" carries more weight than a paragraph of enthusiasm, because it sounds like something a real person said.

Ask for the quote soon after a project ends, while the result is fresh, and make it easy by suggesting two or three questions rather than asking for "a testimonial." Always attribute it with a name and role where the client allows it. An anonymous quote reads as an invented one, especially in sectors where trust is the whole product.

Structure the Page for Skimming

Even a well-written case study will be skimmed before it is read. Give it a clear shape: a headline that names the client type and outcome, a short summary near the top, then sections for the challenge, the approach and the result. Put the strongest image or result early, and keep paragraphs short enough to read on a phone between meetings.

Images should show the work in context rather than as decoration. A before and after comparison, a key page on a laptop and a phone, or a detail that illustrates a specific decision will all do more than a gallery of screenshots. Finish the page with a clear, low-pressure next step, such as a link to a related project or an invitation to talk about a similar challenge.

Two or three strong case studies, written this way, will usually do more for a firm than a portfolio of twenty thin ones. If you are planning your next project pages and would like a second opinion on what to include, get in touch and Filip & Philip will gladly look at them with you.