customer_story_craft v1.0.0

name: customer_story_craft description: "Write customer stories and case studies end to end: pick the right customer, run a story-extraction interview, draft in a results-first structure, verify every claim, get written approval, and repurpose one approved story into sales and marketing formats. Use when asked to write a case study, customer success story, testimonial page, reference story, or to turn interview notes or a transcript into a publishable story."

Customer Story Craft

Purpose

Turn a real customer result into a story a prospect can trust and a sales rep can actually use. The customer is the main character. The product is the tool they picked up. Every number, quote, and claim in the finished piece traces back to the interview, a document the customer supplied, or a system of record. Nothing is invented to make the story sound better.

This skill covers the full run: candidate selection, interview, draft, claim check, approval, and distribution. A draft without approval is not finished work.

Workflow

1. Pick the candidate

Score candidates before asking anyone for time. A good candidate has all five:

• A result the customer can state in their own words, with a before state and an after state
• A named person who did the work and can speak to it, not only a sponsor who signed the contract
• A problem that matches a segment you sell to now
• Permission in principle: the account owner confirms there is no contract, legal, or relationship reason to stay quiet
• A wrinkle worth telling: something they tried first that failed, a hard rollout, a constraint. Perfect stories read as ads

If metrics are missing, do not drop the story automatically. Use observable milestones instead: go-live date, process steps removed, volume handled, a decision the result made possible. Mark those as qualitative in the draft and never dress them up as measured numbers.

Write a one-paragraph story brief before the interview: customer, person, segment, problem, claimed result, evidence you expect to collect, and the one belief you want a reader to leave with.

2. Run the extraction interview

Use the question bank in references/interview-guide.md. Plan for 30 to 45 minutes, record with permission, and take notes on exact phrases. Customers describe their problem better than marketers do, and their phrasing becomes your headline material.

Interview rules:

• Ask for the before state in concrete terms: who did the work, how often, how long it took, what broke
• Ask what they tried before and why it fell short. This is where credibility comes from
• Ask for the decision: what else they considered, what nearly stopped them, who had to agree
• Ask for numbers three ways: the metric, the baseline, and the time window. A result without all three is not ready to print
• Ask what surprised them and what they would do differently. These answers give you the parts a template cannot
• Close by explaining the approval step plainly: they will see the full draft, every quote, and every number before anything ships, and they can cut anything

Within one working day, send a short thank-you note with a recap of the two or three claims you heard and a request to correct them. Catching a wrong number here is cheap. Catching it after design is not.

3. Draft in results-first structure

Use the template in references/templates.md. The order is fixed:

1. Headline: customer type or name, plus the strongest verified result, plus the time window
2. Results at a glance: three to five bullets, each with metric, baseline, and timeframe
3. About the customer: two or three sentences. Industry, size, and the job of the person quoted
4. The challenge: the before state, the cost of leaving it alone, and what they had already tried
5. Why they chose this: criteria, alternatives considered, and the concern they had to get past
6. What they did: the rollout in steps, including the hard part and how long first results took
7. Results in full: the numbers with context, plus one qualitative change the numbers do not show
8. Quote: the customer in their own words, tied to the challenge or the result, not a generic compliment
9. What others can take from this: one to three practical lessons, written for a peer
10. Next step: one clear call to action matched to the reader segment

Working length for the main version is 700 to 1,200 words. Shorter is fine when the evidence is thin. Longer needs a reason.

Structure note: this follows the Situation, Complication, Resolution pattern. Situation states facts the reader accepts. Complication names the problem that made the old way untenable. Resolution answers that exact problem. If your resolution section brags about a benefit the challenge never raised, cut it or move it to a different story.

4. Verify every claim

Build a claim ledger as you draft. One row per factual claim: the claim as written, the source (interview timestamp, customer document, dashboard, contract), and whether the customer confirmed it.

Hard checks before approval:

• Every number has a baseline, a unit, and a time window in the text or in the ledger
• Every quote is verbatim from the recording or transcript, or the customer has approved the edited version in writing
• Names, titles, company descriptions, and dates match what the customer supplied, spelled their way
• No claim in the story is stronger than the claim the evidence supports. If they said the tool helped, the story does not say the tool caused the whole gain unless they can separate the effect
• Atypical results are handled honestly. If this customer is far ahead of the typical customer, say what is typical or add the context that explains the gap. Under the FTC Endorsement Guides (16 CFR Part 255), an endorsement cannot carry a claim that would be deceptive if the advertiser made it directly, and a testimonial is not substantiation on its own
• Any material connection is disclosed: payment, free product, discount tied to the story, employment, reseller relationship. See references/approval-and-rights.md

Run the draft checker before sending for approval:

bash
python3 ~/workspace/skills/customer-story-craft/bin/check_story.py draft.md --ledger claims.csv

It flags missing sections, numbers without a nearby timeframe, quotes without attribution, and ledger rows marked unconfirmed. It does not replace reading the draft. It catches the boring misses so the human review can focus on accuracy and tone.

5. Get written approval

Send the customer the complete draft, not excerpts. Include: the headline, all quotes, all numbers, where the story will appear, which formats you plan to derive from it, and how long you plan to keep using it.

Track approval at the level of the draft version. Approval of version one does not cover a new headline, a new number, or a stronger claim in version two. Log who approved, their role, the date, the version, and any conditions (logo use yes or no, name the company or describe it only, review again in 12 months). The checklist and a short approval request email are in references/approval-and-rights.md and references/templates.md.

If the customer asks to stay unnamed, write the story with a precise description instead: industry, size range, region, and role of the person quoted. Do not invent a fake name and do not present an unnamed story as a named one.

If approval stalls, send one reminder with a deadline tied to a real event (a launch, a campaign) and an easy out: no reply needed if they want the story dropped. Never publish on silence.

6. Produce the derived formats

One approved story should ship as a set, all drawn from the approved text only:

• Web version: the full story, 700 to 1,200 words, with results at a glance near the top
• One-pager: headline result, three bullets, one quote, one short paragraph on the challenge. For sales handouts
• Slide: one result, one quote, one chart or before and after line. Nothing else on the slide
• Email snippet: two or three sentences a rep can paste, naming the segment and the result
• Quote card: one approved quote, name, title, company, for social and decks
• Short post draft: the problem and the result in the customer's terms, linking to the full story

Any new wording in a derived format that adds a claim, a number, or a quote not in the approved version goes back for approval. Shortening approved text is fine. Strengthening it is not.

7. Distribute and maintain

File the story where a rep can find it by segment, industry, company size, and problem, not by customer name alone. Add it to the relevant product page, the sales library, and the nurture flow for that segment. Ask the featured customer if they want to share it, and make that optional and easy, with a prewritten post they can edit or ignore.

Set a review date, usually 12 months out. On review: confirm the person is still in the role, the numbers are still fair to cite, and the approval still stands. Retire or refresh stories that fail any of those checks.

Output Contract

A completed run delivers:

• Story brief (one paragraph)
• Interview notes or transcript reference, plus the corrected claim recap sent to the customer
• Claim ledger (CSV or table) with source and confirmation status for every factual claim
• Full draft in the fixed structure, with checker output clean or exceptions explained
• Approval record: approver, role, date, version, conditions
• Derived set: web version, one-pager, slide copy, email snippet, quote card text
• Filing record: where it was published and filed, tags used, review date

If any item is missing, say which one and why. Do not present a draft as a published story.

Operating Rules

• Never invent or round a customer metric into something stronger. Report the number the customer gave, with its baseline and window, or leave it out.
• Never write a quote the customer did not say and present it as theirs. A drafted quote is a proposal until they approve that exact wording.
• Never publish without written approval of the version being published. Verbal enthusiasm on a call is not approval.
• The customer can cut anything, at any point, without giving a reason. Make cuts fast and without argument.
• Keep the customer the hero. If the draft reads as a product brochure with a logo pasted in, rewrite it.
• Include the hard part. A story with no obstacle, no failed attempt, and no tradeoff reads as fiction to experienced buyers.
• Disclose material connections and handle atypical results per the FTC Endorsement Guides, 16 CFR Part 255. When in doubt, add context rather than a vague disclaimer.
• Respect confidentiality terms in the customer's contract. If the contract bars public reference, the answer is an unnamed story with permission, or no story.
• One story, one segment. A story stretched to speak to everyone convinces no one. Write spin-off versions for other segments from the same interview only when the evidence supports them.