Choose the question the story answers
Start with the concern a prospective client brings to the project. They may want to know whether you understand their sector, can handle a particular constraint or have delivered similar work. Choose a project that helps answer that question, then explain the situation in language they would recognise.
Gather the agreed scope, approved outputs and a short account from the people involved. Ask what needed to change, what your team was responsible for and which decisions mattered. Include constraints that explain the work: an existing brand, a tight content supply, several approval groups or a staged launch.
Keep your role clear from the beginning. Designing a website for an engineering practice does not mean delivering the engineering projects featured on it. Credit collaborators where their contribution affects the story.
Say what your evidence can support
Separate what you delivered from what happened afterwards. A before-and-after image can show a changed page layout. A project record can support the scope completed. Neither establishes that the work increased revenue or caused better enquiries.
Scroll across to see every column if needed
| What you want to say | What to check |
|---|---|
| We delivered this work. | Agreed scope, approved output and your team’s actual role. |
| The experience changed. | A matched comparison and a clear description of the visible difference. |
| The client said this. | The exact quote, attribution, context and publication approval. |
| A business result improved. | The metric, source, baseline, period and other changes that may explain it. |
When results are unavailable, describe the delivered work and the reason for the decision. That can still help a buyer judge relevance. If a client reports a benefit, attribute it accurately; do not quietly convert their account into an independently measured fact.
Show readers what to look at
Approved MLEI example: this is the static Home comparison already used in the MLEI case study, showing Streamlnr’s website work. It is the supplied earlier/current pair, rather than a new capture. The comparison demonstrates how to describe a visible change precisely.
- Opening hierarchy. The earlier page begins with introductory paragraphs and a bulleted value list above market tiles. The redesigned opening makes a large engineering headline and short supporting statement the first content to read.
- Routes to project information. The redesigned image groups “Our Projects” and “Capability Statement” beneath the introduction. This is a specific, visible change a reader can locate in the comparison.
Supported wording: “The redesigned homepage brings the project and capability-statement routes together beneath the opening message.” Overreaching wording: “The redesign helped more buyers find the right information and improved lead quality.” The images support the first sentence. The second needs evidence of visitor behaviour and enquiry quality that these captures do not provide.
Get approval for the story you will publish
Ask who can approve the organisation’s name, project details, quotations and images. Agree the intended audience and publication locations before preparing the final story. Publicly visible material is not blanket permission to reuse it, and removing a client’s name does not resolve every confidentiality issue.
Send the actual draft and selected media to the authorised reviewer. Make your role, any reported results and outstanding questions easy to check. Obtain approval for that version before publication; silence is not approval. Remove personal details and confidential material from anything intended for public use.
What to record for evidence and approval
- Role: the precise work your team delivered and the contributors who need credit.
- Evidence: the proposed claim, supporting record or image, relevant version or date, and what it cannot establish.
- Permission: the authorised reviewer, actual approval date, exact wording and media version, permitted publication locations and any restrictions.
- Next review: who owns the record and what triggers another check, such as revised copy, changed facts or withdrawn permission.
Keep these working records privately with the responsible owner. Mark unanswered questions as pending rather than filling gaps with assumed approval.
Keep the final story easy to follow
Give the reader a short sequence they can follow. Each part should do a different job:
- Situation: explain what the client needed and what made the project worth doing.
- Role: state the part your team was engaged to deliver, including important limits.
- Decisions: choose one or two changes and explain the constraint or buyer need behind them.
- Delivery: show the approved output, with an image or quote beside the claim it supports.
- Result: report what the evidence establishes. If only the delivered experience is documented, say what changed and leave business performance unclaimed.
Use the prompt below with approved public notes to create a first draft and a short list of review questions. Then check every factual statement against your records and approved wording. Link the finished story to the service it demonstrates, so a prospective client can move from relevant experience to understanding how you might help them.
Put it to work.
Copy a prompt into Claude or ChatGPT, replace the bracketed details and review the result with your team.
Claude
ChatGPT
Use public information. Leave out personal or confidential details. This page copies text only; it does not send anything to an AI service.
Draft a project story from approved notes
Use public project information and notes already approved for public use in Claude or ChatGPT.