A case study can be valuable without a growth percentage or measured time saving. Readers can also learn from the starting situation, decisions made and solution actually delivered. The main point is to make clear what can be demonstrated. A missing measurement is no reason to estimate a result or present an expectation as an outcome.
Start with a substantive question
Do not begin with a list of every task completed. Choose the question that makes the project distinctive or recognisable. Why was the existing approach no longer sufficient? Which dependency needed resolving first? What did the client need to keep doing during the process? This context helps readers understand why a particular decision made sense.
Use only information available and approved for publication. Not every internal obstacle belongs on a public page. Discuss with the client which situations, screenshots and names may be used. A concise, well-supported case study can be more persuasive than a long account that has to remain vague at crucial points.
Describe decisions and demonstrable delivery
A fictional example: a service provider redesigns its application process. Previously, it consisted of several separate documents. The new solution brings questions and attachments together in a recognisable application journey. If that was demonstrably built, the case study can describe precisely that change. Without measurement, whether applications are handled faster remains unknown.
Then explain why the chosen approach fits. Perhaps different employees each needed to review a section, or adding information later was important. These considerations demonstrate expertise without adding impact claims. A case study about custom software may mention technical details where they help explain what changed for users.
Make the distinction between fact and expectation visible
Use wording that reflects the level of evidence. “The new page shows the application status” describes behaviour. “This means employees spend less time searching” may be an expectation or observation, depending on the available evidence. “The team saves hours every day” requires an appropriate measurement. Do not automatically choose the strongest wording because it sounds commercially attractive.
When people share an experience, present it as an experience and quote it only with permission. Do not put a broader conclusion in a customer's mouth. A comment about better oversight, for example, does not prove all errors have disappeared. Check subheadings and captions too; categorical claims sometimes slip in there.
Finish with what readers can take away
A strong case study offers insight into an issue others may recognise. Explain which conditions mattered and which decision another organisation should investigate first. This makes the account useful without promising that the same approach has the same effect everywhere.
Before publication, have the case study reviewed by someone who knows the project in depth and by whoever approves publication. Retain the supporting evidence with the editorial team. Link from relevant service pages to case studies that clarify a concrete decision. If reliable measurements become available later, the case study can be supplemented with the period, definition and context. Until then, an honestly described project can already show plenty about the quality of thinking and execution.