Build a customer story that its evidence and permission can support

Choose a reader question and a real relationship basis

A useful case answers a specific question: how did this team change a reporting handoff, what work was actually delivered and what remains unknown? Start with the real source and the customer’s role in that work. Do not turn a prospect, internal fixture, unpaid demonstration or unverified checkout into a paying customer. Use the appropriate relationship description even when a stronger label would make the opening more persuasive.

Keep the purpose narrow enough for a complete story. A project update can establish release status, while an interview can describe a practitioner’s experience. A customer case must connect that context to the exact delivered work, the supported outcome statement and an agreed public version. The packet below is entirely fictional practice; none of its tasks, approvals or numbers describes a real Wrapped.li customer.

Separate the work, the source and the proposed result

Build a small private chain: context and constraints; work actually performed; deliverable/version; observation or customer report; reproducible calculation; limits; proposed wording. A checked delivery and acceptance record can establish what was handed over without proving that later reporting became faster. A satisfied quote is evidence of what that person said, not automatically a measured time saving.

GOV.UK’s analysis guidance separates observations from interpretation and actions. Apply that distinction to your draft: identify whose report a statement is, what was inspected and what you are inferring. HM Treasury’s evaluation guidance distinguishes outcome change from attribution. Its policy context is different from a customer story, but the same causal question matters: what else could account for the observed change?

Trace the full constructed four-task example

The original practice source contains four fictional handoff tasks. Three have both before and after durations: 12/8, 10/9 and 14/11 minutes. The fourth has an after value of 10 but no baseline. On the three complete pairs, the before median is 12 and the after median is 9. The descriptive reduction between those medians is 3 minutes, or 25% relative to 12. Keep the fourth task and its missing baseline visible rather than inventing it.

This does not establish that a product made a customer 25% faster. The inputs are constructed, no customer was observed and no causal design was run. Even in a real before/after case, changed instructions, task difficulty or concurrent work could matter. Comparing three before values with all four after values would also change the selected group. The checker exposes the complete-pair selection and retains the missing case.

Use the supplied completed evidence note to inspect the exact rows, unit, selection and limits. The accompanying story draft says what changed in this fictional rehearsal and what was not measured. It does not add a testimonial, revenue figure or result from a typical customer. The exercise is a writing and evidence trace, not another original research study.

Review permission for the whole exact public version

Review the actual agreement and the person authorized to make the sharing decision. Separate participation, private notes, named quotation, company identity, screenshot/data use, public story, destination and language. GOV.UK’s research-consent guidance is useful for purpose and record design; it is not a universal customer-release form or a guarantee of legal permission for your case.

Attach the proposed headline, body, numbers and media to the review, not just the flattering quotation. A translation or changed result creates a different review object. In the practice packet, approval references exact file bytes and language, so a same-named replacement cannot silently inherit it. A digest identifies the reviewed version; it cannot prove that a real authorized customer approved it or that the underlying result is true.

Make the publish-or-hold decision explicit

S1 is a constructed private-only agreement: the numbers can be traced, but public use is not allowed. Hold the public story. S2 permits an earlier exact version, while the current draft changes a number. Hold that replacement for a new review. S3 permits the English version only; the German draft remains outside that fictional approval. A translated file does not inherit the language scope.

S4 supplies a fictional exact-version public agreement and a bounded draft that preserves the three complete pairs, missing baseline and absence of causal evidence. Its result is ready for the deliberate publication step in the exercise, not published, endorsed by a real person or independently validated. The full localized drafts and decisions are downloadable, so you can review the actual proposed story rather than infer it from a summary.

Keep a useful case record after the intended release

A compact structure is context, work delivered, supported observation, limitations and an available next step. Keep the private source and review record behind it. Add a public URL and date only after a real authorized publication has been checked. If a source, figure or permission changes, identify affected owned destinations and review the correction instead of replacing the old evidence invisibly.

Handle a real withdrawal or correction through the actual agreement and responsible data process. Do not promise recall of every outside copy or treat a request receipt as its completed outcome. These examples neither contact customers nor publish their information. They establish no real reader preference, paying customer, business lift or independent editorial review.