Customer Story Engine

Customer Story Engine

When to use

Use this skill when you need to turn a customer sale, renewal, implementation, interview, support note, or founder/sales anecdote into a credible customer story.

Use it for:

• Capturing a story after every sale or meaningful customer outcome
• Turning past customer notes into usable proof
• Preparing customer interview questions
• Creating a website customer story
• Creating a one-page customer-story PDF for sales
• Building sales proof from true before/after examples
• Finding better messaging from real customer situations

Core belief: stories sell better than claims. A customer story beats twenty product pages when it shows a real person facing a real problem, making a change, and getting a tangible result.

ADI Marketing principle: "We tell true stories to the right people at the right time."

Inputs

Ask for or infer the following:

• Company, product, or service being sold
• Customer type, role, and situation
• The old make-do process before buying
• The trigger: the specific event that made them call, act, or finally decide
• What the product or service changed
• The tangible result: money saved, flight saved, fuel sale protected, time saved, risk reduced, peace of mind, or another real outcome
• Direct customer quotes or plain-language notes
• What can and cannot be claimed publicly
• Customer permission status, if known
• Desired output: story brief, case study, one-pager, website post, sales proof, or interview guide

If proof is thin, still create the story structure, but label gaps clearly. Do not invent numbers, quotes, outcomes, logos, names, timelines, or customer permission.

Story capture questions

Use these questions in an interview, follow-up email, sales handoff, or internal debrief.

1. Situation: what was happening before?

• What was the old way of doing this?
• What tools, spreadsheets, calls, texts, sticky notes, manual steps, or workarounds were involved?
• Who had to coordinate the work?
• What usually went fine?
• Where did the old way get messy, slow, risky, expensive, or stressful?
• What did the customer tolerate because it was familiar?

2. Trigger: what made them act?

• What specific event made the customer call, search, ask, buy, or finally prioritize the problem?
• Was there a missed sale, urgent request, failed handoff, customer complaint, audit, deadline, outage, executive concern, growth push, or operational scare?
• Why did the problem become urgent then?
• What would have happened if they had kept doing it the old way?
• Who felt the pain most clearly?

3. Solution: what changed?

• What did the product or service help them do differently?
• Which part of the job became easier, clearer, safer, faster, or more reliable?
• What did the team stop doing?
• What did the team start doing?
• What made the change credible or practical for the people doing the work?

4. Result: what happened after?

• What tangible outcome can be stated honestly?
• Did they save money, protect revenue, avoid a missed flight, prevent a fuel sale from slipping away, reduce rework, respond faster, or improve handoff confidence?
• What changed in the customer's day-to-day work?
• What emotional result matters: confidence, peace of mind, fewer surprises, better control, or less scrambling?
• What proof is available: quote, metric, before/after detail, timeline, anecdote, usage data, or customer approval?

5. Plain-language quote prompts

Ask questions that invite useful wording:

• How would you describe the old way to another person in your job?
• What was the moment you realized the old process was not good enough?
• What do you no longer worry about?
• What would you tell someone who thinks the current workaround is fine?
• Finish this sentence: "Before this, we were relying on..."
• Finish this sentence: "Now I can..."

Workflow

1. Lead with the problem, not the product

Start the story with the customer's situation. The product should enter only after the reader understands the old process and why it was not good enough.

A strong opening names:

• Who the customer is
• What job they were trying to get done
• What make-do process they used
• Where that process broke
• Why the moment mattered

Avoid opening with product features, company adjectives, or a generic claim.

2. Find the make-do process

The old way is often the most important part of the story. Capture it concretely.

Examples of make-do processes:

• Phone calls, radio, email, texts, and memory
• Spreadsheets and sticky notes
• Manual handoffs between teams
• One person who knows where everything is
• A shared inbox nobody fully owns
• A process that works on slow days but breaks when volume rises

The real competition is often not another vendor. It is the customer's current workaround.

3. Identify the trigger

Do not settle for "they wanted to improve efficiency." Find the moment that made the problem visible.

Use this pattern:

• Situation: old make-do process
• Trigger: specific event that made them act
• Solution: how the product made the job better
• Result: tangible outcome

A trigger makes the story believable because it explains why the customer changed now.

4. Separate truth from interpretation

Keep facts, quotes, and marketing interpretation separate.

For every important claim, ask:

• Is this directly stated by the customer?
• Is it inferred from the notes?
• Is it a proof gap?
• Can it be used publicly?

Never polish a story until it becomes fake. Better to be plain and true than slick and hollow.

5. Build the before/after

Show the change in simple terms.

Before:

• What was hard?
• What was risky?
• What did people have to remember, chase, check, or repeat?
• What could go wrong?

After:

• What is clearer now?
• What no longer falls through the cracks?
• What can the customer do with more confidence?
• What tangible result can be stated honestly?

6. Choose the right story asset

Turn the same captured story into the right format for the job.

• Story brief: internal raw material for marketing and sales
• Website post: public narrative that helps the next buyer see themselves
• One-page PDF: sales proof that can be sent after a call
• Case study: fuller story with approved customer identity and proof
• Sales proof: short anecdote, quote, before/after, or objection-handling point

7. Write like a teacher and storyteller

The role is not advertiser. The role is teacher and storyteller.

Use direct, honest, helpful, plain-spoken language. Explain the problem clearly. Help the reader recognize the risk in the old way and the practical improvement in the new way.

Output format

Produce only the sections needed for the requested output. If the user asks for a complete story-engine package, include all of these.

1. Story brief

• Customer type
• Audience this story is for
• Situation / old way
• Trigger event
• Product or service change
• Result
• Emotional outcome
• Direct quotes or usable phrases
• Proof level: approved, stated, inferred, or missing
• Permission status
• Gaps to validate

2. Story spine

Use this structure:

1. Before: the customer was relying on [old make-do process].
2. Break: [specific trigger] showed why that process was no longer good enough.
3. Change: with [product/service], the customer could [new way of working].
4. Result: they achieved [tangible outcome] and felt [emotional outcome].
5. Lesson: for similar buyers, the point is [plain-spoken takeaway].

3. Website customer story

Recommended structure:

• Headline focused on the problem or result, not a product slogan
• Short summary
• The old way
• The moment it became urgent
• What changed
• The result
• Customer quote, if available and approved
• Plain call to action tied to the problem

4. One-page PDF

Recommended structure:

• Title
• Customer snapshot
• The problem
• The trigger
• The solution
• The result
• Quote or proof box
• Why it matters for similar customers
• Sales follow-up question

5. Sales proof

Include short assets sales can use:

• 30-second story
• Objection-handling proof
• Discovery questions
• Before/after bullets
• Proof-safe claims
• Claims to avoid

Quality bar

A strong customer story:

• Is true and does not inflate proof
• Leads with the customer's problem, not the product
• Names the old make-do process clearly
• Includes the specific trigger that made the customer act
• Shows a concrete before/after change
• Connects the result to tangible value such as money saved, revenue protected, flight saved, fuel sale protected, risk reduced, or peace of mind
• Uses customer language where possible
• Sounds like a helpful person explaining what happened, not an ad campaign
• Can be used by sales in a real conversation
• Makes the next similar buyer think, "That is exactly the problem we have"

Anti-patterns

Avoid:

• Inventing proof, numbers, quotes, customer names, or permission
• Leading with features before the reader understands the problem
• Writing a hero story about the vendor instead of the customer
• Saying "efficiency," "innovation," "transformation," or "seamless" when the real story is more concrete
• Turning a plain customer story into corporate brochure copy
• Hiding weak proof behind hype
• Using technical language for its own sake
• Making every result sound like ROI if the real outcome is confidence, safety, reliability, or peace of mind
• Flattening the trigger into a generic business challenge
• Publishing a public case study before approval is clear

Tone

Write in a direct, honest, helpful, plain-spoken style.

Use:

• Clear nouns and verbs
• Specific situations
• Short sentences when they help clarity
• Customer words over internal jargon
• Honest limits on proof

Avoid:

• Corporate language
• Slick ad copy
• Salesy hype
• Technical-for-technical's-sake explanations
• Hyperbole
• Jargon

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: adam-lagerhausen
• Source: adam-lagerhausen/b2b-marketing-skills
• License: MIT

Install and usage instructions live in the source repository linked above.