A B2B services firm finishes a project, everybody moves on to the next one, and the best proof the firm will ever have goes into a folder nobody opens. Six months later somebody asks for case studies for a pitch, and the honest answer is that nobody can remember the numbers.
The problem is not the writing. It is the collection. The facts that make a case study worth reading exist for about two weeks after a project ends, in the heads of the people who did the work and in a client who is currently pleased with you.
This guide builds a routine that captures real results with permission at the moment a project closes, drafts a case study from them and nothing else, and turns the approved version into posts. Setup takes about two hours.
What you are building
Three parts. A closing checklist that captures the facts while they are fresh, a permission step that makes the client a participant rather than a subject, and a drafting step that works only from what was captured and approved. Nothing gets published that the client has not seen.
Tools: your project management board, one short form, an automation tool such as Zapier, Make or n8n, an AI assistant such as ChatGPT or Claude, and wherever your case studies and scheduled posts already live.
Step 1: capture the facts at the moment of closing
Add one step to your project closing process: a short form the project lead fills in during the week the work ends. Five minutes, and it is the entire difference between a case study you can write and one you cannot.
- What the client came to us with, in the words they used at the start.
- What we actually did, in plain language, including anything that changed mid-project.
- What the outcome was, stated as a fact with its source noted: a figure from a client system, a number the client gave us in writing, or a deliverable that now exists.
- What the client said, quoted exactly, with the date and where they said it.
- What was hard, and what we would do differently next time.
- Who at the client can approve a public write-up, and anything or anyone that cannot be named at all.
The source note on the outcome is the most important field in this whole build. A result without a source cannot be published, and knowing that before you draft saves you a conversation with a client about a number you cannot stand behind.
Step 2: ask the client properly
Permission is a short email from the person who ran the work, sent while the client is still pleased with you. Ask for three things at once: to write about the project, to use their name, and to check any figure you plan to quote.
Write a short email asking a client for permission to write about a project we have just finished. Sender: the person who ran the work. Tone: direct, unfussy, no marketing language. It must do four things: say we would like to write a short case study about the project; ask whether they are happy for us to use the company name or would prefer it anonymised; list the specific facts and figures we intend to include so they can correct anything that is wrong; and ask who should approve the final draft. Say plainly that we will send the draft before anything is published and that a no is a perfectly fine answer. Under a hundred and fifty words, one question per paragraph, no exclamation marks. Use the placeholders CLIENT_NAME, PROJECT and FACT_LIST.
Offer the anonymous version in the same email. A named client is better, but an anonymised case study about a real project is worth far more than a named one that never gets approved, and plenty of clients will say yes to the second when they cannot say yes to the first.
Step 3: draft from the captured facts only
The drafting prompt gets the closing form, the approved quote, and nothing else. The rule that keeps this honest is the same rule that made the form useful: where something was not captured, say so rather than filling it in.
Write a case study from the project record below and nothing else. PROJECT RECORD: [paste the closing form and the approved quote]. Structure: the situation the client came to us with; what we did, in three or four steps; what happened, using only outcomes that have a source listed in the record; one quote, reproduced exactly as it is written in the record; and what we would tell a firm in a similar position. Rules: do not invent, estimate, round or infer any figure. Do not write any outcome that has no source in the record. If the record contains no outcome, write NO RESULT CAPTURED and carry on. Do not paraphrase the quote. Do not use the words transformative, seamless or partnership. Under six hundred words, plain sentences. Name the client only if the record says we have permission.
Send the draft to the client before it goes anywhere near a website. Give them a date by which no reply will be treated as a no, and then hold to it.
Step 4: turn one approved case study into posts
Once the client has approved the case study, the expensive part is finished. Everything after that is reformatting the same approved facts for different places.
Here is a case study the client has approved for publication: [paste it]. Write five short posts drawn only from it. One: the problem the client had and why it is common, with no mention of us until the last line. Two: the single decision in the project that mattered most, and why. Three: something that did not work and what we changed. Four: a plain description of what we delivered, for people who want to know what working with us is actually like. Five: the approved quote, reproduced exactly, with one line of context. Rules: use only facts and figures that appear in the case study above. Do not add a result, a percentage or a timescale that is not written there. No hashtags, no emoji, and do not open with a question. Each post under a hundred and twenty words.
Space the five out across a month rather than posting them together. The same project told five different ways over four weeks reads as a firm that does work. The same five in one afternoon reads as a campaign.
Keep the approved case study and the posts in the same folder as the permission email. When a client contact changes and somebody new asks what you have published about them, the whole trail sits in one place and the conversation takes a minute instead of an afternoon.
Step 5: make it run without anyone remembering
- Trigger on a project moving to done on your board.
- Create the closing form task for the project lead, due within five working days, and chase it once if it has not been filled in.
- When the form arrives, save it to the client folder and draft the permission email for the project lead to send. That email is always sent by a person.
- When permission is recorded, call the assistant with the case study prompt and save the draft for review.
- After the client approves, generate the five posts and load them into your scheduler as drafts.
- Keep one sheet listing every project, whether the form was filled in, whether permission was given, and what was published.
Keep that sheet even for the projects that never get published. The next time somebody asks whether a particular client can be mentioned in a pitch, the answer is in a column rather than in an inbox from two years ago.
What changes
Proof stops depending on whether anyone remembered to write it down. Every finished project leaves a record with sources attached, every client is asked while they are still pleased, and the posts are built from material somebody has already approved in writing.
Turning work you have already done into content on a schedule is the subject of Workflow 06: Automate Your Content, the AutomateFirst module about creating and scheduling useful content without staring at a blank page. This guide is one complete build from it, free. The playbook has seven workflows for one payment of $297, with a 30 day refund.
Workflow 06: Automate Your Content
Six more workflows, written exactly like this one
The AutomateFirst playbook covers seven repetitive jobs end to end, with the prompt library, PDF checklists and lifetime access. One payment of $297, no subscription.
Other guides