- Confirm project eligibility and permissions
- Collect baseline and delivery evidence
- Separate actions from observed outcomes
- Write context and limitations clearly
- Approve the final version and maintain it
What evidence should you gather before interviewing the client?
Collect the agreed scope, relevant dates, original business problem, delivered work, and available measurement definitions. Identify which records can support each statement. A campaign report, a signed-off design, and a client recollection provide different forms of evidence. Do not treat them as interchangeable simply because they all concern the same project.
Create a claim record with the proposed statement, supporting source, source owner, period covered, and publication permission. Add an unresolved column. For example, a team may be able to verify that a new inquiry form launched but still need to establish whether a reported increase reflects successful submissions or only button clicks.
Check whether the project can be named and which materials can be shown. Permission to perform the work does not necessarily establish permission to publish private analytics, customer information, logos, screenshots, or quotes. Obtain the appropriate approvals through the parties responsible for the relationship and any relevant agreements.
Which interview questions produce a useful story?
Ask the client to describe the situation before the project in concrete terms. What task was difficult? Who was affected? What information or process was missing? A useful answer might describe staff manually sorting inquiries from several forms. A vague answer such as wanting to grow needs follow-up before it becomes a meaningful problem statement.
Ask what constraints shaped the work. These might include an existing system, a limited content set, a seasonal deadline, or a review process. Record why the team chose the final approach and which alternatives were considered. These decisions help readers assess relevance to their own circumstances.
Ask separately about delivered work and later outcomes. What changed on the website or in the process? What did the team observe afterward? Which observations are documented, and which are impressions? Preserve that distinction in the interview notes. Do not lead the client toward a percentage or testimonial they did not actually provide.
What structure should the written case study follow?
Open with the verified problem and the specific change. Name the business only when approved, and provide enough context for the reader to understand its situation. Avoid using an anonymous label so broad that it suggests experience the writer cannot demonstrate. If anonymity is required, explain the permitted context without revealing the client indirectly.
Describe the approach through decisions, not a list of tools. Explain how the work addressed the original problem, what the team delivered, and what the client contributed. A reader should be able to distinguish the agency's work from work performed by the client, another partner, or a platform.
Present outcomes with the period, definition, source, and important limitations. Close with what the project illustrates and what remains different for another business. A relevant invitation to discuss a similar problem can follow, but it should not turn one project into a guarantee of equivalent results.
How do you report numbers without overstating them?
Keep the numerator, denominator, time period, and measurement method together. If a conversion rate changed, establish what counted as a conversion and what population the rate used. A shift in event definitions can make before-and-after figures incomparable even when the dashboard displays a neat percentage.
Consider a wholly fictional example: a website records twelve successful inquiry submissions from six hundred sessions during one period and eighteen from six hundred during another. The rates are two percent and three percent. That is a one-percentage-point difference and a fifty-percent relative increase. These invented figures demonstrate arithmetic only; they are not a Dappr result or a performance benchmark.
Even correct arithmetic does not establish causation. Check changes in traffic sources, offers, seasonality, staffing, tracking, and other work during the comparison. Describe the observed association accurately. If the evidence does not isolate the effect of a redesign, do not write that the redesign alone caused the entire increase.
What can you publish when there is no reliable performance metric?
Write about a verified delivery or process outcome. A case study can show how a confusing service selection became a clearer intake path, how approved content was organized, or how a team received a maintainable handover. Support those statements with the actual deliverables and appropriate review.
For a fictional document-services business, imagine a project that replaces three inconsistent request forms with one reviewed intake flow. A process case study could explain the original ambiguity, the approved categories, the handoff to staff, and the acceptance checks. It should not claim time savings or increased sales unless those outcomes were measured adequately.
Use descriptive observations with attribution when appropriate. A client may say the new process is easier for their team, but that statement is a reported experience rather than a quantified efficiency result. Preserve the distinction. It is better to publish a narrower supported story than to attach an invented return-on-investment figure.
How should quotes, screenshots, and comparisons be reviewed?
Keep quotes faithful to the speaker's meaning and obtain approval for the final use. Do not combine fragments into a stronger endorsement or put words in quotation marks that the client never said. If a quote needs clarification, ask for a revised approved statement rather than quietly rewriting the opinion.
FTC guidance emphasizes honest, nonmisleading endorsements and appropriate disclosure of material connections. It also addresses exceptional-results claims. Apply qualified review to the particular advertisement or case study where needed; a generic results-vary sentence does not automatically settle every issue. This guide is an editorial workflow, not a legal determination.
Inspect screenshots for private information, misleading date ranges, cropped context, and outdated interfaces. A before-and-after image should compare the relevant task fairly. Label mockups or recreated illustrations as such, and do not pass an illustrative dashboard off as a live client report. Keep the evidence behind the published visual available to the responsible team.
What does a practical case-study template contain?
Use a working document with these fields: project identity and permission, audience, initial problem, constraints, agreed scope, key decisions, delivered work, evidence for outcomes, limitations, approved quotes, approved visuals, and final reviewers. Complete the evidence fields before polishing the headline. A missing result is a question to resolve, not a blank for an AI tool to fill.
For the fictional document-services example, the opening could state that the project created one consistent request path from three forms. The approach section could explain how categories were agreed and tested. The outcome section could state what acceptance checks passed and what was not measured. The example remains fictional and should never appear in a portfolio as real client proof.
Make the review version concrete. Include the actual headline, body, quote wording, visuals, captions, links, and proposed distribution channels. A client approving a rough outline has not necessarily approved a later social advertisement using a shortened claim. Record approval of the final intended use through the normal project process.
How should a published case study be maintained?
Assign someone to review the page when the client relationship, underlying offer, or relevant facts change. Preserve historical context where it is meaningful. A result measured in a past period should not be silently rewritten as a current ongoing result, and a former client should not be presented as a current engagement without confirmation.
When repurposing, carry the essential qualifications with the claim. A social card that removes the timeframe or changes observed to guaranteed can become misleading even if the full case study is careful. Link to the detailed explanation where useful, but do not rely on that link to repair a false standalone statement.
Dappr project examples require actual approved source material. If you want help developing a case study, bring the project records, measurement definitions, permissions, and people who can verify the work. The first deliverable is a supported story for review, not fabricated portfolio evidence.
Questions before you begin
Can a case study be useful without a client quote?
Yes. Clear context, documented decisions, and verified deliverables can support a useful story. Do not invent a testimonial to complete a preferred format. Use a quote only when it is authentic, relevant, and approved for the intended use.
Can an anonymous case study use altered results?
No. Anonymity protects identity; it does not justify changing facts. If details must be generalized, preserve the meaning and obtain appropriate approval. Do not turn a confidential real project into an embellished fictional success story.
Can AI draft the case study?
AI can help organize approved material and suggest wording, but people must verify every claim, calculation, quote, and permission. Keep missing evidence visible instead of allowing the tool to invent a plausible result.
What should the headline emphasize?
Emphasize the verified problem and concrete change. Use a numerical result only when it is supported and presented with appropriate context. A clear delivery outcome can be stronger than an exaggerated growth claim.