Case Study Marketing: How to Turn Client Work into SEO and Sales Proof

A case study exists so a buyer can check, before they speak to you, that you have solved a problem like theirs, how you went about it, and what you can honestly show for it. It is a verification document, not a trophy. Everything else — the design, the search visibility, the sales use — follows from getting that job right.

That job serves three readers at once. The first is the buyer, who is managing risk: they want to see that someone in a situation like theirs trusted you and that the work was real. The second is a search engine or answer engine, which needs a specific, well-structured page to understand what you do, for whom and with what evidence. The third is your own team, who need something precise to send when a prospect asks, “Have you done this before?”

Buyers who have been let down before read case studies closely. Anyone who has learnt to vet an agency before hiring will skip the adjectives and look for specifics: the sector, the scope, the decisions, the evidence and whether the client is named. A case study that survives that reading is doing its job. One that collapses under it does damage, because it signals that the rest of your claims may be decoration too.

Before writing anything, check that the finished page will let a reader answer these questions:

• Who was the work for, described precisely even when the client is anonymised?
• What was the problem or change that started the project?
• What exactly was delivered, and what sat outside your scope?
• Which decisions shaped the work, and why were they made?
• What evidence exists, and what does that evidence genuinely show?

If a draft cannot answer one of these, the gap belongs in your notes, not on the page.

A portfolio shows what your work looks like; a case study explains why it was done that way and what can be shown about it. Both are useful, but they do different jobs, and confusing them produces weak versions of each.

A portfolio entry is image-led and brief. Its purpose is range: a prospect scrolls through and gets a sense of your craft, your aesthetic and the kinds of clients you work with. It needs strong visuals, an accurate label and a line or two of context. It does not need an argument.

A case study is argument-led and deep. It takes one project and walks through the situation, the scope, the reasoning and the evidence. It is slower to read, and it is meant for a narrower reader: someone who has already shortlisted you and now wants to know whether your thinking holds up.

The common mistake is the thin hybrid: a portfolio entry stretched into a “case study” by adding generic paragraphs about “understanding the client’s vision” around the same screenshots. It is too long to scan and too shallow to persuade. The opposite mistake is trying to write a full case study for every project, which exhausts the team and fills the site with half-evidenced pages.

Use a simple rule to decide:

• Make it a portfolio entry when the value of the project is visible in the work itself, or when the client is happy for the work to be shown but not discussed.
• Make it a case study when the reasoning is the valuable part, when the problem matches buyers you want more of, and when you have evidence and permission to go deeper.
• Keep it for private use when the work is strong but cannot be published, and the client agrees it may be described in one-to-one sales conversations.

The projects that deserve a full case study are the ones with publishable evidence, a client willing to approve it, and a problem that matches the buyers you want to attract, not simply the most attractive work or the most recognisable client name.

Recognisable names are tempting, but a famous logo attached to a small slice of work tells a buyer very little, and it can mislead them about your role. A modest project with clear reasoning, approved evidence and a problem your target buyers share will usually do more selling.

A quick selection pass

Go through recent projects and mark each criterion as strong, partial or missing. Resist the urge to turn this into a points system; it is a conversation aid, not a formula.

• Permission: is the client likely to approve publication, and does the contract allow it?
• Evidence: do you have the live work, clean scope records, approved figures or a client quote?
• Relevance: does the problem match the sector, service and buyer you want more of?
• Substance: were there real decisions worth explaining, or was it straightforward execution?
• Verifiability: can a reader still see the work, or has it been changed beyond recognition since handover?
• Role clarity: did you lead the work, or deliver one component of someone else’s programme?

A project that is strong on permission, evidence and relevance is a case study. A project strong on craft but weak on evidence is often a better portfolio entry for now, with a note to revisit it if the client later shares something publishable.

Projects better left as portfolio entries or private references

Some good projects should not become public case studies. Leave out work under strict confidentiality, work where the relationship ended badly, work that the client or another supplier has since rebuilt, and work where your contribution was minor enough that any story would overstate it. None of these cancels the value of the project; it simply means the proof has to live somewhere other than a public page.

Collect and verify the evidence before drafting a single paragraph, because the evidence decides which story you are allowed to tell. Writing first and hunting for proof afterwards produces copy that runs ahead of its support, and it is always the most impressive sentence that turns out to be unprovable.

Open a single evidence file for the project and fill it from the records, not from memory:

• Scope records: the signed proposal, statement of work, change requests and anything that was descoped.
• Delivery records: launch notes, handover documents, design files, repositories, content inventories and acceptance emails.
• The live work: links and captures, with the date you checked them.
• Client data: any figures the client has shared, with their source, the period they cover and whether publication has been agreed.
• Client words: written feedback, meeting notes and anything that might become an approved quote.
• Process material: research notes, workshop outputs, sketches, wireframes and rejected directions.
• People: who worked on it, including freelancers, partner agencies and the client’s own team.

Separate what you delivered from what happened next

Scope records prove delivery. They say nothing about what the delivery achieved. Keep the two columns apart in the evidence file: one for things you can show were delivered, one for things that happened afterwards. Outcomes usually have many causes — the client’s sales team, pricing, the season, other suppliers, a change in the market — and the second column should only ever be filled from the client’s own data, shared for this purpose.

Note the gaps privately

Once the file is complete, write a short private note of what is missing: no figures, no quote yet, a screenshot that shows personal data. The note guides what you ask the client for. It does not appear on the page. A published case study simply makes the claims its evidence supports; it has no need to announce the ones it cannot make.

You can claim at the level of your strongest verified evidence, and no higher. Every statement in a case study sits on one of five rungs, from figures the client has approved for publication down to estimates that are not evidence at all. Knowing which rung a sentence stands on tells you how firmly it can be written, and whether it can be written at all.

Strongest: figures the client shared and approved for publication

The strongest evidence is a figure from the client’s own records that they have agreed you may publish. Publish it with its context: what was measured, over which period, from which source, and what else changed at the same time. Never round it up, never extend the period to make it look better, and never restate it in a way the client did not approve. If the client shares a figure but asks you to keep it private, it has not reached this rung; it can inform your thinking and nothing more.

Strong: the live work and your own scope records

The live work and your scope records are strong evidence of what was delivered. A reader can visit the site, use the system or see the campaign, and your records confirm what was in scope. Be precise about what this rung proves: delivery, not achievement. “We rebuilt the service pages and the enquiry flow” is fully supported by this evidence. Any sentence about what the rebuild did for the business needs the rung above.

Useful: an approved client quote

A client quote is useful evidence of how the client experienced the work, attributed exactly as they signed it off. Use their name, role and organisation only if they approved all three; otherwise use the description they agreed to, such as a role and a sector. A quote carries the client’s opinion, not a measured result, so do not let a warm sentence about “great results” stand in for the figures you do not have.

Supporting: screenshots, photographs and process material

Screenshots, photographs, wireframes and workshop outputs support the story by showing real work. They make the scope tangible and the process believable. The rule is simple: they must be real. A concept that never shipped is labelled as a concept; a mock-up placed in a device frame is never presented as the live product.

Not evidence: estimates, assumptions and “likely” results

Estimates, projections, assumptions and “likely” results are not evidence, however good they would look. A calculation of what the work probably achieved, an industry average applied to your client, or a result inferred from a change you noticed from outside all belong here. Leave them out of the page, the proposal and the sales call alike.

To use the ladder while drafting, mark each claim-bearing sentence with its rung. Anything you cannot mark is cut or rewritten until it describes what your evidence shows. It is a slow first pass, and it becomes quick with practice.

Ask for permission before you draft, agree what can be named and shown, and get written sign-off on the final version, including every quote, figure and image. Treating approval as a formality at the end is how case studies get pulled after publication. What follows is good practice drawn from real projects, not legal advice; where contracts or regulation make it matter, take proper advice.

Start with the contract and an early conversation

Check the contract and any confidentiality agreement for terms about publicity, naming and portfolio use before you approach the client. Then raise the idea early, ideally at handover while the work is fresh and the relationship is warm. Explain what you would like to publish, where it would appear and how it would be used, including in proposals and on social channels, since some clients are comfortable with one and not the other.

Offer the client clear levels of openness rather than an all-or-nothing request:

• Named, with logo, quote and any approved figures.
• Named, describing the work and scope but no figures.
• Anonymised by sector and situation, with identifying details removed.
• Not published, but available to describe in private sales conversations.

Collecting quotes the right way

The best quotes come from the client’s own words: a feedback email, a call you asked to note, an answer to a specific question such as “What was hard before this project?” Tidy for length if you must, then send the edited version back for approval. Do not write a quote from scratch and ask the client to put their name to it; it reads as manufactured because it is. Keep the approved wording exactly as signed off, including the attribution.

Anonymising properly

If the client prefers anonymity, remove everything that identifies them: logos, names in screenshots, email addresses, distinctive product names, addresses and oddly specific details that a competitor would recognise. Describe the client in terms they have approved. Then keep a record of the approval itself — the email and the version it refers to — so that anyone updating the page later knows exactly what was agreed.

Do not publish any outcome you cannot trace to evidence the client approved, and do not let delivered scope pose as a business result. The pressure to overclaim is strongest exactly where the evidence is thinnest, which is why the rule has to be decided before drafting rather than argued sentence by sentence.

Leave these out of every case study:

• Invented, estimated or modelled figures, even when labelled as approximate.
• Rounded-up versions of real figures, or figures moved to a more flattering period.
• Outcomes with many causes attributed solely to your work.
• Before-and-after comparisons without the dates, sources and context that make them fair.
• Implications that a one-off project produced ongoing effects you never measured.
• Client logos on work where your part was a small, subcontracted slice.
• Awards, features or endorsements you cannot document.
• Superlatives and sweeping comparisons with competitors that no evidence could support.

Scope is not an outcome

The most common overclaim is quiet: a description of scope written in the grammar of results. “A new website that transformed the business” turns a deliverable into an achievement without a shred of support. Rewrite it as what you can show: “A rebuilt website with a new information architecture, rewritten service pages and a simpler enquiry form.” The second sentence is less dramatic and far more persuasive, because a sceptical buyer can check every word of it.

When a draft seems flat without a result, the answer is not a number. It is better context, clearer decisions and more precise scope. If an outcome genuinely matters to the story, ask the client whether they have data they would be willing to share, and wait until they do.

Describe the situation the client was in, precisely enough that a similar buyer recognises their own position, before you mention a single deliverable. The problem section is where a reader decides whether the case study is about someone like them; if it is vague, they stop reading.

Good context covers four things:

• Who the client is: sector, type of organisation and stage, anonymised if needed but never generic.
• What changed or stopped working: a new market, a launch, a rebrand, an outgrown system, a website that no longer matched the business.
• The constraints: existing platforms, regulation, internal capacity, content ownership, approvals.
• The brief versus the need: what the client asked for and, if it differed, what the project turned out to require, framed in a way the client agrees with.

Compare two openings. “The client wanted a modern, engaging online presence” describes nearly every brief ever written. “A family-run manufacturer selling through distributors needed a site that let procurement teams check specifications and certifications without phoning the sales office” describes a real situation a buyer can recognise, and it sets up every decision that follows.

Context does even more work for complex B2B services, where the deliverable is often invisible and the buyer is judging whether you understood a difficult situation. Show the understanding in the problem statement, and the solution sections will read as consequences rather than claims.

Two cautions. Do not blame the client for the problem, and do not criticise a previous supplier by name or by implication; both make the reader wonder how you will describe them one day. And do not exaggerate how bad things were to make the ending look better. An accurate starting point is all the story needs.

State exactly what you delivered, then explain the handful of decisions that shaped it. The reasoning is what separates a case study from a portfolio entry, and it is the part a competitor cannot copy from a screenshot.

State the scope precisely

List the deliverables in plain terms: what was researched, designed, written, built, migrated or trained. Name what was outside your scope and who handled it, whether that was the client’s team, a partner agency or a specialist. Precision here protects you: a buyer who later discovers that a highlighted feature was built by someone else will doubt everything else on the page.

Show process only where it changed the work

Readers do not need a diary of meetings. They need the moments where process changed the outcome of the work itself: the research finding that reordered the navigation, the workshop that killed a feature, the prototype test that simplified a form. Pick those moments, show the artefact if you can, and explain what changed as a result.

Explain design and build decisions

For each important decision, give the reader four things: the decision, the options you considered, why you chose as you did, and the trade-off you accepted. For example, choosing a content management system the client’s marketing team could run without a developer, rather than a more flexible custom build, is a decision with a clear reason and a clear cost. Organising service pages around the questions buyers ask rather than the client’s internal departments is another. Neither needs a result attached to be convincing; the thinking is the proof of competence.

Keep the language concrete. “We adopted a user-centric approach” says nothing. “We interviewed the client’s sales team about the questions prospects ask most often and built the page structure around them” shows a method a buyer can picture.

Use real captures of the delivered work, dated and shown in context, and label anything that is a concept, prototype or mock-up as exactly that. Media is where honest case studies most often slip, usually without anyone intending to mislead: a polished concept frame looks better than the shipped screen, so it quietly takes its place.

Work changes after handover. Clients edit pages, swap images and add features, so capture the work at launch, before it drifts from what you delivered. If you add captures later, label them “as delivered” or date them, and say plainly on the page when the live version has since been changed by others.

A practical media checklist:

• Capture desktop and phone views, including real states such as forms, filters, confirmations and empty states.
• Blur or remove personal data, customer names, internal figures and anything the client considers confidential.
• Credit photographs of physical work to the photographer, and confirm you have permission to use them.
• Label sketches, wireframes and rejected directions as process material, not finished work.
• Never place an unbuilt concept in a device frame and present it as the live product.
• Write alt text that describes what the image actually shows, not a string of keywords.
• Prefer a short screen recording when the value lies in how something works rather than how it looks.

Media should earn its place. Twenty near-identical screens tell a buyer less than four well-chosen captures, each with a caption explaining the decision it illustrates.

Most people who reach a case study through search are checking whether you have solved their kind of problem in their kind of sector, so each page should target that combination of sector, problem and service rather than the client’s name. A client name is rarely searched by anyone except the client, their competitors and your own team.

Case-study pages meet several kinds of search intent:

• Evaluative: a buyer looking for examples of a service in their sector before shortlisting suppliers.
• Verification: a prospect who already knows your name and searches for your work to check your claims.
• Problem-led: someone researching how others handled a situation they now face, such as replatforming a catalogue or restructuring service pages.
• Question-led: a direct question typed into a search box or an AI assistant, where a clear, specific page is more useful than a vague one.

Titles follow from that intent. “Website project for a client” serves nobody. A title that names the sector, the problem and the work, such as a rebuilt specification library for an industrial manufacturer, tells both readers and search engines what the page is about before they open it.

Pages that answer a question directly, state their scope clearly and support their claims with visible evidence are easier to understand, and easier to be cited in AI-generated answers, than pages built from adjectives. No structure guarantees a citation or a ranking, so treat clarity as the aim and discovery as something to measure rather than assume.

Two traps to avoid: stuffing a page with every variation of a keyword, which makes it worse for the human reader, and splitting one project into several thin pages to target more searches. One thorough, well-titled page serves both intent and credibility better.

Lead with a summary a buyer can absorb in seconds — the client type, the problem, what you delivered and the strongest approved evidence — then tell the full story in a predictable order. The summary serves the scanning reader and the answer engine; the depth below it serves the buyer who has shortlisted you.

A structure that works across most services:

1. A descriptive title naming the sector, the problem and the type of work.
2. A summary block covering the client type, the challenge, the scope and the strongest evidence on the ladder.
3. Context and problem, written so a similar buyer recognises their own situation.
4. Scope delivered, as a plain list, including what sat outside it.
5. Process and key decisions, each with its reasoning and trade-off.
6. The work itself, with captioned, real media.
7. Evidence, at the rung you can genuinely claim, with its context.
8. An approved client quote, attributed exactly as signed off.
9. Services involved and related work, linked to the relevant pages.
10. A next step for a reader facing a similar problem.

Make the page readable for people and machines

Use descriptive headings rather than clever ones, so the outline alone explains the project. Keep the summary in plain text rather than baked into an image. Show the published date and, when you revise the page, the updated date. Add structured data only where it matches what is visibly on the page. This page-level discipline is the same work that good search and answer-engine optimisation applies across a whole site: clear entities, honest structure and content that answers the question it targets.

Keep the call to action proportionate

The reader at the bottom of a case study has just finished reading about someone else’s problem. Invite them to talk about theirs, plainly, without a promise that they will get the same outcome. A short line and a single route to an enquiry does more than a banner of urgency.

Link every case study to the service and sector pages it supports, and link back from those pages to the case study, so proof sits next to the claim it backs up. A case study that can only be reached through a work index is proof hidden in a drawer.

The links worth building:

• From each service page to the case studies that show that service, placed near the claim they support rather than in a footer.
• From each case study to every service it involved, so a buyer can move from proof to the offer.
• From sector pages to the case studies in that sector.
• Between related case studies that share a problem, a service or a sector.
• From articles that discuss a topic to the case study that shows it done for real.
• From a work index that can be filtered by sector and service.

Anchor text should describe the destination: the project, the sector or the service. Links labelled “read more” or “click here” tell neither readers nor search engines what they are about to find.

Much of this is decided long before anyone writes a case study: a website built to carry proof has a defined place for evidence on every page that makes a claim, a work index that grows without redesign and templates that keep links consistent. Retrofitting proof into a site that was never designed for it is possible, but it is slower and it tends to stay patchy.

Sales teams use case studies to answer a specific doubt at the moment it comes up, so give them short, matched versions and a way to find the right one quickly, not a single link to a long page. A salesperson in the middle of a conversation needs the case study for this sector and this objection, and they need it in a form they can send in a message.

Build a proof library the team will actually use

Keep a simple, shared index of every case study and private reference. For each, record the sector, the services, the problem, the objections it answers, the permission level, the approved assets and the date the page was last checked. Include one-line and one-paragraph summaries that stay on the same rung of the ladder as the page. When the library is easy to search, salespeople stop improvising proof from memory, which is where most embellishment begins.

Using case studies in proposals

Choose the one or two case studies closest to the prospect’s situation rather than attaching everything. Rewrite the introduction so it connects the earlier problem to the prospect’s, but keep the evidence, figures and quotes exactly as approved. Describe what was delivered and how the work was approached; do not imply that the prospect will see the same outcome. A proposal that says “this is how we handled a similar problem” is credible. One that suggests a result is on its way is a promise you cannot keep.

In calls and sales decks

In a deck, one slide per case study is usually enough: the situation, what was delivered, the strongest approved evidence and the quote. In calls, the same discipline applies to spoken claims. Train the team to describe case studies at the rung they sit on, because an exaggeration said aloud is still an exaggeration, and it tends to surface in the prospect’s reference checks. For private references, confirm that the client is comfortable being described in pitches before anyone mentions them.

Repurpose the verified parts of a case study — a single decision, a real capture, an approved quote — rather than retelling the whole project in every format, and keep each piece on the same rung of the evidence ladder as the page it came from. A finished case study is a source file, and the discipline that went into it should travel with every fragment.

One well-documented project can supply a post explaining a single design decision, a sequence of real, dated captures showing how a page evolved, a short walkthrough video, an email to prospects in the same sector, a section of a newsletter and a worked example inside a talk or guide. Each format takes one idea from the case study and does it justice, instead of compressing everything into a caption.

Deeper projects often justify long-form editorial content as well. An article about the problem the client faced, using the project as its worked example, reaches people who are researching that problem long before they are ready to compare suppliers, and it gives them a natural route to the full case study.

Visual formats work when they stay honest. On social feeds, carousels and short-form creatives built from real captures can walk through a process step by step, but a slide that crops a figure away from its period and source has quietly changed what the figure means.

Before any repurposed piece goes out, check it against a short list:

• The client’s approval covers this channel, including tagging or naming them on social platforms.
• Quotes remain verbatim, with the attribution the client signed off.
• Figures keep their context, or are left out of the format entirely.
• Captions do not suggest a result the full case study does not claim.
• The piece links back to the full case study, so the evidence is one step away.

A sector landing page claims to understand a sector, and case studies from that sector are the evidence for that claim, so place them beside the claims they support and let the page’s confidence match the proof you actually have. Sector buyers look for their own world on the page: their terminology, their regulation, their typical constraints and, above all, work for organisations like theirs.

The fit matters more than the volume. For architecture practices, buyers expect to see how built and published projects are presented, so a sector page aimed at them is far more convincing with one real project walked through carefully than with several paragraphs about understanding design-led firms.

A few rules keep sector pages honest:

• Match each sector page to the case studies that genuinely sit in that sector.
• Do not present work from a different sector as if it belonged to this one.
• Show adjacent work only when you label it honestly and explain why the approach transfers.
• Prefer one well-evidenced project to a row of thin tiles.
• Write the page so it stands on what it can show, without placeholder lines announcing future proof.

Case studies also give sector pages the specific vocabulary and detail that generic pages lack. A page that describes how a real project handled a sector’s approval process or compliance requirements says more about your understanding than any claim of expertise could.

Review every case study on a fixed cycle, and immediately whenever something material changes — the live work, the client relationship, the permission or the evidence — then update it, relabel it or retire it. Proof goes stale quietly, and a buyer who clicks through to a changed website or a client who no longer recognises the description will trust the rest of your pages less.

At each review, work through these questions:

• Is the live work still as described, or has it been changed by the client or another supplier?
• Is the client still happy to be named, and is the person who approved it still there?
• Are figures still shown with their period, source and context?
• Do links to services, sector pages and related work still lead where they should?
• Do the service names on the page still match what you sell today?
• Are captures labelled correctly as delivered, dated or current?
• Has the client produced new evidence they would be willing to approve?

When you update a page, add new evidence only with fresh approval, change the updated date only when the content has materially changed, and record what changed in the proof library so the sales team is working from the same version as the website.

When a case study no longer holds up, retire it deliberately. Remove it from the sales library first, then redirect the page to the most relevant related case study or to the work index rather than leaving a dead end. Retiring a case study is routine maintenance. Leaving stale proof live is the real risk.

Measure whether case studies are found, read and used in real buying journeys, rather than simply counting views, and treat what you learn as direction rather than proof of cause. Case studies rarely act alone; they work alongside referrals, conversations and the rest of the site, so the useful question is where they appear in the journey and what they are used for.

Signals worth tracking:

• The search queries and impressions each page receives, to see which intents it genuinely meets.
• Whether case-study pages appear in the browsing paths of visitors who go on to enquire.
• Answers to an optional question on the enquiry form about what helped someone decide to get in touch.
• Which case studies salespeople send, and at what stage, logged in the proof library.
• How often prospects mention a specific case study in calls, emails or proposal feedback.
• How visitors move between case studies, service pages and sector pages.

Read the signals as patterns. A case study that attracts visits but is rarely sent by sales may need a sharper summary. One that salespeople send constantly but prospects never mention may be too long to read in the moment. A sector that keeps coming up in enquiries without a matching case study points to the next project worth writing up, once the client agrees.

Apply the same honesty to your own reporting. Internal observations about how case studies are used are useful for decisions, but they are not public claims. The evidence ladder applies to marketing about your marketing too.

Turning the method into a routine

The method only compounds when it runs every time a project ends, not in an occasional clear-out of old work. A routine that fits most teams:

1. At handover, raise publication with the client and capture the work as delivered.
2. Build the evidence file from scope records, delivery records and client-approved material.
3. Mark every claim with its rung on the evidence ladder and cut what cannot be marked.
4. Write the context, scope and decisions, then the summary.
5. Get written sign-off on the final draft, including quotes, figures and images.
6. Publish with a descriptive title, a clear summary and links to the relevant service and sector pages.
7. Add the case study to the proof library with short summaries for sales.
8. Repurpose the verified pieces for social, email and editorial use.
9. Review on your fixed cycle, and update, relabel or retire as the evidence changes.

Done this way, every finished project leaves behind something more durable than a screenshot: a page a sceptical buyer can check, a reference the sales team can trust and a source the content team can draw on without ever inventing a result.