AI-readable case studies need more than a logo wall

Take the screenshots and client logo off a portfolio page. What evidence is left?

For plenty of service businesses, agencies and consultants in Dubai, Liverpool and the wider UK, the answer is not much. You can see the finished work looks polished. You may recognise the client. But you cannot tell what was actually delivered, what problem mattered, what got in the way or what changed afterwards.

That is a weak position for a prospective buyer and an awkward one for an AI assistant trying to answer a straightforward question about your experience. It may identify the brand. It may describe the images. It cannot safely say what you did.

A portfolio is not automatically proof

A project gallery can show taste. It does not automatically show capability. A visitor looking for WordPress development, website repair or a service-business website may land on a familiar client name and still leave without knowing whether you redesigned the site, built it, migrated it, wrote the content, fixed a booking journey or simply supplied a visual concept.

The commercial cost is easy to miss. The page may attract attention because of the client name while doing very little to qualify a new enquiry for the relevant service. A nice looking gallery is then carrying a fairly lazy sales job.

AI-readable case studies state the client, sector, starting problem, delivered work, relevant constraints, evidence and outcome in plain language. This lets a buyer, search system or AI assistant extract what happened without guessing from imagery, vague praise or a list of logos. Outcomes should be specific where supportable and carefully qualified where they are not.

This sits within a wider question of whether your site can be interpreted properly. An AI readiness audit for business websites can assess that across key pages, but start with one portfolio entry first. It is usually revealing enough.

Pull apart one project page, field by field

Imagine an architecture practice has a case study containing a hero image, a client logo, three interior photographs and the sentence: delivered a refined digital experience. It looks expensive. It tells a buyer almost nothing useful.

Now put it through a basic extraction test. Can someone who has never seen the project answer the questions below from the page alone?

Proof needs nouns, verbs and evidence. A logo wall is not a case study.

Name the work rather than making people infer it

The most common omission is the intervention. A case study says a client received a new website, then avoids naming the work because the author assumes the screenshots make it obvious.

They do not. A screenshot cannot reliably show whether the work included information architecture, responsive templates, WordPress development, migration, CRM form routing, accessibility improvements or post-launch maintenance. Some of those may be commercially important to the next buyer.

A clearer version might say: Standish rebuilt the consultation enquiry route in WordPress, created reusable service-page templates and replaced a contact form that was sending notifications to an old shared inbox. That last detail is boring, which is exactly why it carries weight. It describes a real operational problem rather than a mood board.

Keep the distinction between a case study and an offer page clear. A service page that explains an offer clearly helps people understand what you sell in general. The case study should show a specific instance of that work, with enough context to make the proof believable.

Do not invent outcomes to complete the story

Case studies often go vague at the end because nobody has verified numbers. The temptation is to reach for claims about engagement, leads or growth. Leave that alone unless the client data and permission support it.

You can still describe an outcome honestly. For example: the client received a clearer route for users to request consultations, the team could edit project pages without returning to a developer, or the launch replaced an outdated site before a planned campaign. These are operational outcomes, not made-up performance claims.

Run the unsupported-claim check

• Can you point to a source, client-approved statement or recorded measurement for every performance claim?
• Does the wording say what changed, rather than quietly claiming why it changed?
• Would the statement still be fair if the project had several suppliers involved?
• If no verified figure exists, can you describe the delivered capability or completed change instead?

There is nothing wrong with writing that no verified performance data was available. It is more credible than claiming a result nobody can substantiate six months later.

The minimum viable structure for a useful case study

You do not need a forty-page project diary. A short case study can do the job if each part earns its place.

1. Set the identity. Name the client type, sector and relevant location where permission allows.
2. Describe the starting problem. State what was difficult for the business, visitor or internal team.
3. List the delivered work. Use plain verbs: redesigned, developed, migrated, integrated, repaired, structured or maintained.
4. Include the constraint. Mention only constraints that affected the work, such as keeping an existing booking system or launching around a campaign date.
5. Show evidence. Use screenshots as supporting material, alongside specific pages, features or process changes.
6. State the outcome carefully. Use verified metrics where available. Otherwise explain the practical result without dressing it up.
7. Give a relevant next step. Help a buyer with a similar problem understand where to go next.

This structure also makes the content more useful when a referral checks your site before calling. They should not need to play detective to work out whether you have handled a similar job.

Use the extraction test before publishing

Copy the case-study text into a plain document. Remove images, captions, testimonials, navigation and anything that depends on visual polish. Then fill in these six fields: client, sector, problem, intervention, evidence and next step.

If you cannot fill one in from the remaining words, neither can a machine with much confidence. The fix is usually content structure, not a hurried burst of schema markup or another block of flattering copy.

For a broader review, an intelligent website audit with human judgement can help separate presentational polish from the pages that actually explain, support and convert. But one case study is a sensible place to start, especially before paying for ads or commissioning another expensive portfolio shoot.

Test whether the case study still explains the work when the images and sales narration are removed. If it does not, the next edit is fairly clear.

Questions about AI-readable case studies

What makes a case study easier for AI systems to interpret?

Clear headings and direct statements help most. Name the client type, sector, original problem, work completed, constraints, evidence and outcome. Keep important facts in the main page copy rather than hiding them inside image captions, sliders or decorative graphics. Structured data may help clarify content after the page itself is clear, but it cannot fill factual gaps.

Should outcomes be included when no verified numbers exist?

Yes, but describe operational outcomes rather than making performance claims. You can state that a new process was introduced, a page template was created, a booking route was repaired or an internal team gained editing control. Avoid implying more leads, revenue or rankings unless those outcomes have been properly measured and can be fairly attributed.