How to Write a Case Study That Proves Agency Value

By the end of this guide, you will have a repeatable structure for writing a case study that shows a client's actual situation before and after a project, backed by numbers you can defend if someone asks where they came from. Before you start writing, three things need to be in place: written permission from the client to share figures, access to the original project brief or proposal, and at least one data source outside your own memory, such as analytics, a CRM export, or a support ticket log.

We have written and reviewed enough agency case studies at SUNS Tech to notice a pattern in the ones that fall apart under questioning. The writer remembers the project fondly but cannot point to where a specific number came from. That gap is what this structure is built to prevent.

Confirm you have permission before you write a word

Many agencies draft the case study first and ask for approval later. That order creates two risks: the client may refuse to share the exact numbers already written down, or they may approve a draft that technically breaches a confidentiality clause in the original contract. Check the signed agreement or statement of work for non-disclosure terms before requesting any figures.

To confirm this step is done, you should have a short email or message thread where the client explicitly agrees to which metrics can be published and whether their name or logo can appear. A verbal "sure, go ahead" from a kickoff call months ago is not enough on its own. Get it in writing again before publishing.

What should a case study actually measure?

A case study should measure a change the client cares about, not a change that happens to be easy to screenshot. Page load time, bounce rate, or lines of code written are internal engineering signals, and they only belong in a case study if the client's original goal was explicitly tied to them, such as a slow checkout page causing cart abandonment.

Start from the goal stated in the project brief, not from whatever metric improved the most. If the brief said "reduce manual order processing time," then order processing time is the headline metric, even if a side effect like lower server cost also showed up. Building a case study around the wrong metric is the most common reason readers distrust it, because it signals the story was built backward from a good-looking number instead of forward from a real business problem.

Step 1: Reconstruct the baseline with a dated source

Pull the exact state of the metric before the project began, using a dated export, a timestamped screenshot, or an email where the client described the problem in their own words. If the client said "we lose about a day a week on manual invoice matching," that sentence is the qualitative baseline until a number can be attached to it.

You should be able to point to a file, screenshot, or message with a visible date that predates the project kickoff. If the only evidence is your own recollection of a conversation, label it clearly as an estimate in the text rather than presenting it as a measured figure.

Step 2: Capture the end-state from the same source type

Measure the same metric, from the same tool, using the same definition, after the project has been live long enough to settle into a stable pattern. For a web project, this usually means waiting past the first week of traffic spikes from launch announcements, since that period rarely reflects normal usage.

Compare the reporting period length and the metric definition against the baseline. If the baseline was a 30-day average and the end-state is a 7-day snapshot, the comparison is not valid and needs to be corrected before it goes into the case study.

Step 3: Isolate what your project actually changed

List every other factor that could explain the change: a seasonal sales period, a marketing campaign the client ran independently, a competitor exiting the market, or a pricing shift. Ask the client directly whether anything else changed during the measurement window.

You should be able to write one sentence that rules out the most obvious alternative explanation. If you cannot, soften the claim from "this caused" to "this coincided with," and say so plainly rather than implying a causal link the data does not support.

Step 4: Translate the metric into a business outcome

A raw number like "processing time dropped from four hours to forty minutes" is useful, but readers connect faster with what that means operationally: freeing up a staff member's afternoon, or allowing same-day order fulfillment instead of next-day. Write one sentence that bridges the metric to that real-world outcome.

Read the sentence back to the client before publishing. If they say "that's not quite how we'd put it," rewrite it in their language. The case study should reflect how they actually experienced the change, not how it sounds most impressive on paper.

Step 5: Build the before-and-after narrative in order

Structure the write-up around four beats: the client's situation and constraint, what was tried or considered, what was actually built or delivered, and the measured result. Avoid jumping straight to the result in the opening paragraph. Readers who skip the context will not trust a number they cannot place in a situation.

Have someone unfamiliar with the project read only the first two paragraphs and ask them to summarize the client's problem in one sentence. If they cannot, the setup needs more detail before the result appears.

How should uncertainty be handled in the writing?

State uncertainty directly rather than hiding it behind vague language. If a number is an estimate because the client never formally tracked the metric before the project, write "based on the client's estimate" instead of presenting it as a precise measurement. This reads as more credible, not less, because readers who work in operations or IT can usually tell when a figure is too clean to be real.

The common mistake here is rounding a specific-sounding number to make it seem more rigorous, turning "the client said it felt like half the time" into "reduced by 52%." If you catch yourself doing this, go back to the original client quote and either get a real number from a data source or keep the qualitative description. An honest estimate that holds up is worth more than a precise-looking figure that falls apart the moment the client is asked to confirm it.

Format the case study for skimming and for scrutiny

Decision-makers reading a case study before hiring an agency usually skim first and verify second. Put the headline outcome in a short summary near the top, written in plain language, then let the body carry the supporting detail, context, and any caveats about measurement. A reader who only has two minutes should still walk away with an accurate impression, not a simplified one that overstates the result.

For agencies that handle both delivery and ongoing optimization, this is also where it makes sense to show the project's technical range without turning the case study into a service list. If the underlying work touched custom platform development, a brief mention with a link to the relevant web design and development page gives an interested reader somewhere to go without derailing the narrative. Keep this kind of reference to one, and only where it is genuinely relevant to what was built.

Checklist before publishing

• Written client approval exists for every specific number and for using their name or logo.
• Baseline and end-state metrics come from the same tool, the same definition, and comparable time windows.
• At least one alternative explanation for the change has been considered and either ruled out or disclosed.
• Every estimate is labeled as an estimate, and nothing is rounded to look more precise than the source supports.
• The opening two paragraphs explain the client's situation clearly enough for a reader to summarize it without seeing the result.
• The client has read the final draft, including the exact wording of the outcome, before it goes live.

Putting together a case study is often the point where an agency's past work either earns trust or quietly loses it, long before a prospective client picks up the phone. If you are assembling case studies to support an active pitch, or you want a second opinion on how to present a project honestly without underselling it, our team is glad to talk through what is worth showing and what to leave out. You can see examples of how we've documented our own projects in our portfolio, or reach out directly through our get a quote page to talk through your specific situation.