Case study publishing workflow — interview to promotion

Take a customer case study from first interview through approval, publish, and post-publish promotion without losing the customer's voice

A case study is the highest-trust marketing asset a brand can produce. It also fails more often than any other content type — at the interview stage, at the draft stage, at the customer-approval stage, and at the post-publish promotion stage. Each gate has its own way of killing a case study before it ships.

This recipe walks the case study through every gate. The interview yields the real story. The draft preserves the customer's voice. The approval cycle ends in a clean sign-off, not a rewrite war. The published page does the long-tail work. Promotion lifts it into the audience's attention.

What is this for?

Use this recipe to publish a customer case study end to end. The output is one published case study page on the site, with a matching blog post recap and a coordinated promotion run.

The end state after publishing:

• A case study page at /case-studies/<customer-slug>/ with the full story, the proof, and the CTAs.
• A blog post recap or excerpt in the blog feed, linking to the case study page.
• A customer-approved quote and outcome metric that the team can use in other contexts (sales decks, social, email).
• A promotion run across email, social, and (if relevant) sales enablement channels.
• A signed approval on file, dated, with the customer's authorized contact named.

Good use cases

B2B service or software customer. Customer used the product or service for 3 to 12 months and reached a measurable outcome. Case study runs on the brand's site to feed sales and SEO.

Agency client engagement. Client commissioned a project, the project delivered. Case study runs on the agency site to demonstrate capability and feed new business.

Product proof of value. A customer's specific use of a feature illustrates the feature's value better than any feature page can. Case study is shorter and more feature-focused.

Cohort or program graduate. A customer who went through a program or cohort and reached a defined outcome. Case study runs alongside the program's sales surface.

What NOT to use this for

• Internal celebration of customer wins. That belongs in the team channel, not on the public site. The case study needs the customer's sign-off and a public-facing story.
• Anonymous customer stories without sign-off. "A Fortune 500 customer saw 40% gains" is not a case study; it is a claim without proof. Either get the sign-off and name the customer or do not publish.
• Composite or generic narratives. Stitching three customers into one story is a credibility liability. Each case study is one named customer, one verified story.

How this connects to other features

• Pages + SG-Builder — the case study page is a SG-Builder page. Build it from a case-study template the brand re-uses across customers.
• Blog — the recap blog post lives in the blog and links to the page. Treat them as separate publishes with separate cross-posts.
• Media library — customer headshots, logos, and any screenshots upload to the Media library. Tag them with the customer slug for re-use.
• Custom Codes — the case study page gets schema markup (Article or CaseStudy) and an open-graph image.
• Forms — a CTA form at the bottom of the case study captures interest from readers who match the customer profile.

Before you start

You are signed in as an Administrator. You have a customer identified, contacted, and willing to participate. You have an approval path inside the customer's organization — usually marketing or comms — that can sign off on the published copy.

You have the case-study template page built in SG-Builder, ready to fork per customer. You have the brand's case-study voice agreed — sentence-per-line cadence, no corporate filler, customer voice preserved.

You have the interview questions drafted. You have a recording tool ready (transcription tool of your choice; consent required from the customer before recording).

Where to find it

Steps

1. Run the interview

The interview is where the case study lives or dies. Block 45 to 60 minutes with the customer. Record with consent.

Question structure that works:

1. Before — what was the situation before they picked the product or engagement? Pain in their words.
2. Why us — what made them pick this option over the alternatives they considered?
3. First 30 days — what did the rollout or onboarding look like?
4. What changed — what is different now? Specific outcomes, with numbers if they have them.
5. Surprises — what surprised them, positively or negatively?
6. Advice — what would they tell a peer considering the same product or engagement?

Let the customer talk. Resist the urge to lead. The best case-study lines come from the customer's unprompted phrasing.

Transcribe the recording. Either auto-transcribe and clean up, or have a human transcriptionist do it. The transcript is the source of truth for the draft.

2. Draft the case study

Open the case-study template page in SG-Builder. Save it as a new page titled <customer-name> case study. Slug — /case-studies/<customer-slug>/.

The page structure follows a fixed shape:

• Hero — customer logo + outcome headline (8 to 12 words, names the result).
• One-line summary — 15 to 25 words, names what changed.
• Problem section — 100 to 200 words in the customer's voice.
• Solution section — 150 to 300 words covering what they did.
• Outcome section — 100 to 200 words with specific numbers.
• Quote — one pulled quote, 1 to 3 sentences.
• CTA — book a call, see the product, request a similar engagement.

Draft each section with direct quotes from the transcript wherever possible. The customer's voice should be unmistakable — if the draft reads like the brand wrote both sides, the case study has lost the point.

3. Add the proof — numbers and screenshots

A case study without numbers reads as marketing. A case study with specific numbers reads as evidence.

Pull at least three specifics from the interview:

• A primary outcome metric — time saved, revenue lifted, headcount avoided, error rate cut.
• A secondary metric — something adjacent the customer noticed.
• A timeline — how long before they saw the result.

If the customer is uncomfortable sharing exact numbers, ask for percentage changes or directional bounds ("over 50%" rather than "from 12 to 6"). The customer's approval at the end of the cycle confirms what they will let you publish.

For screenshots — pull what you can from the customer's actual use of the product, with their permission. A real screenshot beats a stock illustration every time.

4. Run an internal voice + accuracy pass

Before sending the draft to the customer, run it past two internal readers:

• Voice reader — does it sound like the brand? Does it preserve the customer's voice? Sentence-per-line cadence, no corporate filler.
• Accuracy reader — usually whoever worked with the customer on the actual engagement. Are the dates right, the names spelled right, the metrics accurate?

Sending an unreviewed draft to the customer wastes the customer's time and signals carelessness. Both readers should sign off before the customer sees it.

5. Send to the customer for approval

Email the draft to the customer contact. Frame the ask clearly:

• Attach a PDF export of the draft, not a link to a staging page (PDFs are easier to mark up and the customer's legal or comms team is more comfortable with PDFs).
• Name what you need: line-level edits, factual corrections, and any flags on what cannot be public.
• Set a deadline: 7 to 10 business days is reasonable. Without a deadline the draft sits.
• Note the publish date you are targeting and that promotion happens within a week of publish.

Most customers come back with minor edits — names, dates, a softened phrase. Some come back with major rewrites that change the story. If the rewrite removes the proof or the specifics, push back politely — the case study only earns the reader's trust if the proof is concrete.

6. Incorporate edits and get the sign-off

When the customer sends edits back, work through each one. Three categories of edits:

• Factual — accept verbatim. A name spelled wrong, a date off by a week, a metric stated incorrectly.
• Tone or phrasing — usually accept. The customer's voice wins over the brand's draft.
• Story-changing — discuss. If the customer wants to remove the proof or the specifics, the case study no longer has the same value. Either find a different angle that the customer will approve or pause the case study.

Send the revised draft back with edits applied. Ask for explicit approval: "If this version reads correctly, please reply with 'approved' or any final edits."

Save the approval email or document. The signed approval is the brand's authorization to publish. Date the approval, name the contact who approved.

7. Build the published page

With approval in hand, the SG-Builder page that has been holding the draft becomes the publish surface. Final pre-publish checklist:

• Hero image — customer logo at the right size, clean background.
• Open-graph image — 1200 × 630 px with the customer name and outcome headline.
• Schema markup — Article or CaseStudy schema in Custom Codes for the page.
• CTA form — embedded form at the bottom for reader inquiries.
• Internal links — at least one to the product page, one to another case study (if relevant), one to a related blog post.
• Tags — case-study, customer name, industry, primary feature used.

Save and publish. Confirm the page renders at the public URL.

8. Write the recap blog post

Navigate to Blog → + Add New. Set the category to Customer stories (or whichever category the brand uses for case studies). Title — How <customer> reached <outcome> or a similar specific framing.

The recap is shorter than the case study — 400 to 800 words. It tells the same story in compressed form and links to the full case study page at the top and bottom.

• Lead — one paragraph naming the customer and the outcome.
• Body — 3 to 5 short sections covering problem, approach, outcome, surprise.
• Pull quote — the same quote that lives on the case study page.
• CTA — link to the case study page.

Tag the post with the customer slug and the industry. Cross-post to social.

9. Promote the case study

Run a coordinated promotion within the week of publish:

The customer's own share is the highest-use promotion. Ask the customer (politely) if they will post about the case study on their LinkedIn. Provide a draft they can edit. Many will say yes if asked clearly.

What success looks like

After publish, week one:

1. The case study page resolves at the public URL with the open-graph preview correct on social.
2. The recap blog post is live, linked to the case study, and shared on social.
3. The signed approval is on file with the customer's authorized contact named.
4. The newsletter mention landed and the post-newsletter analytics show clicks to the case study.
5. The customer's own share, if they made one, is live on their LinkedIn (or wherever they chose).
6. Sales enablement has the case study added to the relevant decks and one-pagers.

What to do if it does not work

The customer goes silent after the draft is sent. The deadline passed and there is no response. Send one polite follow-up at +3 days, one more at +7 days. If still no response, escalate to whoever in the brand has the customer relationship and ask them to nudge.

The customer rewrites the case study into a generic testimonial. The customer's legal or comms team stripped the specifics. Either accept the lighter version (still useful, but lower trust) or find an angle the customer will approve in detail.

The metrics the customer approved feel weak. The case study reads as marginal because the customer would not let strong numbers through. Decide whether to publish anyway (some signal beats none) or shelve the case study and find a stronger one.

The page is published but the recap blog post never went up. Promotion never lifted off because the recap was the assumed driver. Treat the recap as a separate publish task with its own deadline and cross-post sequence.

The page is not pulling traffic. The case study lives on the site but does not appear in search or social. Add internal links from the product page, the homepage, and other case studies. Confirm the schema markup is valid.

The customer asks to take it down later. Treat as a real request. Move the page to draft or remove it, depending on the conversation. Save the version you took down (private archive) — sometimes the customer wants it back up 6 months later.

Variations

Short-form case study (400 words + quote). Some customers will approve a shorter, quote-forward format that does not require a full interview. The page has a hero with the outcome, one short paragraph per section (problem, solution, outcome), and a prominent quote. No 45-minute interview needed — a 15-minute call or a written Q&A via email is enough to fill the format.

Case study index page. Once the brand has three or more published case studies, build a /case-studies/ index page in SG-Builder. Use a filtered loop pointed at the Case Studies content type (or a Blog category). The index page becomes the case study entry point in the main nav. Each published page auto-appears without editing the index.

Sales-deck-first case study. The case study starts as an internal one-pager for the sales team, then gets expanded into a public page once the customer approves. The one-pager has: outcome headline, three bullets, one quote, one logo. The public page expands each bullet into a section. Both share the same approval cycle.

Video case study. Customer agrees to a recorded conversation on camera. The video is the primary asset; the page embeds it, with a written summary below. Upload the video to YouTube or Vimeo (unlisted if the page is the only intended access point) and embed via Custom Codes. The written summary still carries the proof — customers who prefer to skim do not watch the video.

Anti-patterns

Sending a draft without internal review first. Customer receives an unreviewed draft with the wrong dates, misspelled names, and a metric the agency team does not recognize. The customer's confidence in the agency drops. Run the internal pass before anything goes external — even a rough draft review catches the obvious errors.

No deadline on the approval request. The draft lands in the customer's inbox and sits for three weeks because no deadline was given. The pipeline stalls. Every approval request needs a named deadline (seven to ten business days) and a follow-up plan if that date passes without a response.

Publishing before the signed approval is on file. The case study publishes. Six months later, the customer's leadership says the company never approved it and demands removal. Without a signed approval on file — email confirmation with "approved" clearly stated — there is no documentation to fall back on. Collect the approval before publish, every time.

Stripping the customer's voice. The draft reads like the brand's marketing copy. The customer's phrasing, their metaphors, their way of describing the pain — those are the case study's credibility markers. If every sentence could have been written without the interview, the case study has lost its point.

Examples

B2B service customer. Customer hired the agency for a 6-month engagement. Case study covers the engagement scope, the deliverables, and the outcome (named metrics). Page is 1,200 words; recap blog post is 600 words. Customer shares to LinkedIn. The case study feeds the agency's sales pipeline for 18 months.

SaaS product customer with a measurable outcome. Customer used the product for 9 months and cut a specific workflow time by 60%. Case study leads with the metric. Page includes a screenshot of the customer's actual dashboard (with consent). Recap blog post pulls SEO traffic for the customer's industry.

Cohort program graduate. Customer went through a 12-week program and reached the program's defined outcome. Case study lives alongside the program's sales page. Page is shorter — 600 words — because the program is the context. Customer shares to their professional network.

Anonymous-but-detailed case study. Customer cannot be named for compliance reasons but is willing to let specifics through. Case study uses the customer's industry and size in place of the name ("A 50-person SaaS company in the developer-tools space..."). Lower trust than a named case study, but the specifics carry weight.

Multi-customer category piece. Three customers in the same industry, each with their own short case study assembled into one piece. Each customer signs off on their own section. The category piece feeds industry-specific sales and SEO. Each customer is named; no composite story.

Related recipes

• Blog content calendar — 90-day plan — the recap blog post belongs in the editorial calendar; plan the publish date and cross-post against the calendar
• Product launch playbook — a major launch often coincides with a case study publish; coordinate the promotion runs so they reinforce each other
• Webinar promotion — case study customers often make strong webinar panelists; the archive page and the webinar recording can cross-link

Related reading

• Create a page
• Create and manage blog posts
• Media library

Last updated: 2026-05-25