Choose a Customer Story That Answers This Prospect's Question

Three customer stories are sitting in the deck, and the one with the recognizable name is winning. It has a good logo, a clean paragraph of praise, and an answer to a question the buyer didn't ask. The buyer's question was about who does the work after launch. The famous case answers a different question, about whether the product works at scale. Both are real answers. Only one of them belongs on this slide.

The best customer story is the relevant, supportable comparison, not the most famous name. Relevance comes from shared conditions: the same kind of starting problem, a recognizable workflow, and an outcome the record can defend. A story that shares a sector with the prospect but not its constraints will read as impressive and answer nothing.

So the work happens in a fixed order. Write the buyer's question down in their words, conditions included. Compare the cases on that basis. Separate what a customer said from what anyone measured. Then state the lesson and the difference that remains unresolved, so the prospect knows what to check rather than what to hope.

Turn the buyer's concern into a selection question

Most sales teams pick a case by scanning for a familiar logo or a matching industry label. Both are weak filters. Two companies can serve the same industry and still run their operations nothing alike: different shift lengths, different coverage rules, different numbers of people who touch the schedule, different tolerances for a manager approving things by phone at 6 a.m.

What actually selects a case is the prospect's unresolved question. Write it as a sentence before you open the case library.

These are three genuinely different questions:

• Can a 45-person operation keep the schedule running with the manager it already has?
• Will the tool handle our contract's notice rule for shift changes?
• Can the tool coordinate four sites that currently plan in isolation?

A related industry label cannot tell you which of those is in play. Ask the buyer. A question about adoption under a thin administrative team is a different question from a question about a feature, and cases that answer one will often say nothing about the other.

For the rest of this article I'll use an invented prospect and two invented cases, so the reasoning has something concrete to work on. Nothing here describes a real customer, and no real endorsement or measured result is being quoted. The exercise is to practice selection.

The prospect (fictional). A catering and events operator with two sites, about 45 hourly staff, one operations manager, and no IT department. They have no plan to hire a scheduler. The unresolved question: Can a team our size keep shift changes running without adding a full-time administrator?

That sentence is the filter. Everything else — the brand name, the industry, the size of the logo — is secondary.

Compare what had to change for each customer

Once the question is written, compare cases on the actual mechanics rather than on their headline results. Four things need filling in for each one:

1. The starting problem — what was broken, or at least what was awkward, before.
2. The original workflow — who did what, and how often.
3. What the offering contributed — configuration, automation, visibility, whatever it actually did.
4. What the customer and other parties did — setup, training, data preparation, rule-writing, and any continuing support.

That fourth item is the one that usually gets skipped, and it is often the answer to an adoption question. Implementation is a project. Adoption is a Tuesday.

Here is the comparison, with both cases fictional.

Case A is not irrelevant, but it does not answer the asked question. What it shows is an arrangement that assumes a dedicated internal owner — exactly the thing the prospect says they won't hire. That does not make Case A a bad story. It makes it a story about coordinating many locations, which is a real concern and possibly a different slide.

Case B is closer to the prospect's question, because its record describes who does the work after launch and confirms the site never added a scheduling role over the period covered. But notice how careful the causal language has to be. The tool did not, by itself, remove the administrative load. A handoff was designed: the manager kept the template, the leads took approvals, and a notice rule reduced the number of exceptions that reached anyone. The record shows an outcome that followed deployment. It does not separate the software's contribution from the process the plant manager built around it. That distinction matters, because the prospect will need to build a similar process, and the process is the transferable part.

This is the discipline the fourth item enforces: name what the customer contributed, and say plainly that it was part of why things worked.

Separate the customer's opinion from the outcome record

The FTC's Advertising FAQ's: A Guide for Small Business, in its section on endorsements and testimonials, separates two things that sales decks tend to blur: a customer's honest experience, and a representation the advertiser has to be able to substantiate. That line is worth borrowing even where the guide may not govern your situation directly. It is US consumer-protection guidance for advertisers, not a legal opinion, and it says nothing about any particular company or about business-to-business decks. The distinction it draws, though, is the same one a buyer will eventually draw for you.

A customer's quote is an account of that person's experience. It is evidence of how someone felt about a rollout, at a point in time, from where they sat. A measured result is a different kind of object entirely: it needs a definition of what was measured, an observation period, and a comparison that makes the number mean something. "Onboarding dropped by XX%" is not a fact until you can say dropped from what, measured how, over how long, for whom.

The practical failure is not usually fabrication. It is adjacency. An enthusiastic quote sits above a performance figure, and readers merge them into one claim. The quote is doing work it was never qualified to do. Keep them in separate places in the slide, and let each carry only its own weight.

In our fictional cases, the record for Case B contains the plant manager's own account of how the schedule now fits into her week. That is experience, not measurement. It also contains a documented staffing fact: no scheduling role was added over the period covered. That is stronger for an adoption question than a compliment, and it is still bounded — a staffing list cannot show you whether extra hours quietly moved into the plant manager's evenings. Case A's record contains an endorsement about multi-site coordination and no measured figures at all. Neither record can support a claim about typical performance, and the deck should not imply one.

Then there is permission, which is broader than most people assume. Being allowed to show a customer's name is not the same as being allowed to quote their operations manager, reproduce a screenshot, show a logo in this context, publish a figure, or use the story with a different audience in a different medium. Each of those is a separate question. Get the customer's approval for the specific wording and the specific assets, in the specific place they'll appear. This is a check to route to whoever reviews marketing claims on your side; it is not something a comparison table resolves.

State the lesson and the unresolved difference

Now the deck can say something useful. The lesson from Case B is that the administrative load was carried by a designed handoff plus periodic outside support — an owner for the template, leads who approve swaps, a notice rule that keeps most requests from escalating, and a vendor who stays reachable after go-live. That is what the prospect has to evaluate against their own operation.

The unresolved differences are where the honesty goes. Case B is a single site; the prospect has two, and the record says nothing about the handoff across locations. The support in Case B is periodic, not continuous — the prospect needs to know the terms, the response time, and what happens in a busy season or after a shift lead leaves. The two-day notice rule is the customer's own policy, and it only works if the leads are willing to enforce it; that's a management question, not a software one. And eleven months is not eleven years.

Drafted for the slide, the case introduction might read something like this — hypothetical, and built to be filled in with verified material:

[Fictional customer], one production site, 38 hourly employees. Eleven months ago, this site introduced automated shift patterns and swap routing. It did not add a scheduling administrator. The plant manager still builds the weekly template; two shift leads approve swaps under a two-day notice rule the site set itself; the vendor configured the initial rules and continues with quarterly check-ins and a support line. The question this case answers is who owns the schedule after launch, not how much faster the schedule is built. The support arrangement is the part to price and staff, not the part to skip.

That introduction names the process, names the support difference, and marks the boundary. What it deliberately does not do is claim the prospect will get the same arrangement, or that the arrangement is free of dependencies.

If neither available case survives this comparison, say so. A short, honest sentence — "we don't have a customer who has run this without a dedicated owner; here's how we'd find out whether you could" — is more persuasive than a prestigious logo doing an unrelated job. Offer the evaluation instead: a defined pilot, a named person who'd own the template, a list of what the leads would have to agree to, and a check-in date to review it.

What this case belongs to

Keep Case A in the library. If the prospect later asks whether the tool can reconcile scheduling across two locations, Case A's record speaks to that, and it can appear then as a reference rather than as the anchor of the deck.

Case B belongs in this conversation because it takes the buyer's question seriously — it's a case about who does the work, which is what was asked. What it leaves unanswered is whether the same handoff holds across more than one site, and whether the support that made it work stays available at the same rhythm over time. Those are the two things the prospect should ask before the next meeting, and the two things your team should be able to answer, or admit it can't yet.

Frequently asked questions

How should I choose which customer story belongs in a deck?

Start with the prospect's unresolved question, written in their words with conditions included. Compare cases on shared starting problem, workflow, and defensible outcome, not on logo recognition or industry label. The relevant, supportable comparison belongs on the slide; a famous name may answer a different question.

What four mechanics should I compare across customer cases?

The starting problem, the original workflow, what the offering contributed, and what the customer and other parties did. The fourth is often skipped and is usually the answer to an adoption question, because implementation is a project while adoption is an ongoing routine.

Why can a recognizable logo still be the wrong case?

It may answer a question the buyer did not ask. A multi-site coordination case can show an arrangement that assumes a dedicated internal owner, which says nothing about adoption under a thin administrative team. Keep it for a later question if relevant.

Can a customer quote support a performance claim?

No. A quote is an account of someone's experience at a point in time. A measured result needs a definition, observation period, and comparison that makes the number meaningful. Keep them separate, because adjacency can make readers merge them into a claim neither supports. Permission is also specific to wording, assets, context, and audience.

What if no available case answers the buyer's question?

Say so plainly. A short honest sentence about not having a customer who ran it that way, plus an evaluation offer such as a defined pilot, a named owner, what leads would agree to, and a check-in date, is more persuasive than an unrelated prestigious logo.

Further reading

• Build a Sales Deck Around the Customer’s Decision, Not Your Company History — For building the whole deck around the buyer's decision rather than company history, with adoption effort and unresolved dependencies given visible places.
• Pitch a Customer Pilot With a Decision at the End — When no customer case survives the comparison, read this to propose a bounded pilot whose observation informs the buyer's next decision.