← Blog

Label Customer Stories So Sales Can Find the Right One

A salesperson needs a story about introducing a new process across several teams. The library is organised by customer logo and publication date. Finding the relevant detail means opening every article.

Improve the labels before assuming you need another story. A small, maintained set of fields can help someone retrieve useful material in an ordinary sales conversation.

Start with real questions

Ask a few salespeople what they were trying to find recently. Write down their words: “Who involved finance?”, “Which story explains the first team test?” or “Do we have something about a rollout across locations?”

These are retrieval questions, not necessarily new content briefs. First check whether an existing story already answers them.

Avoid collecting every possible attribute. A field is useful when people can apply it consistently and it helps distinguish a relevant story.

Choose a small set of labels

An initial scheme might include:

  • Buyer task: the decision or work the story explains.
  • Operating context: team size or setting, where relevant and approved.
  • Evidence covered: the specific incident, process or supported result.
  • Format: article, video, diagram or another available asset.
  • Usage status: current approved version, review needed or held from use.

Use a short agreed vocabulary where consistency matters. If one person writes “onboarding,” another “implementation” and a third “getting started,” decide whether these mean the same thing in your library.

Keep a sentence explaining each label. Do not create an elaborate taxonomy that nobody has time to maintain.

Complete one story card

Fictional example:

Field Entry
Display title How one service team tested a new enquiry-routing rule
Buyer task Assign responsibility when a request spans two teams
Useful detail The mixed-request incident and agreed escalation route
Operating context One service team; wider rollout not covered
Available formats Approved article and process diagram
Where to start “Handling an exception” section
Usage status Current approved version; next review recorded privately
Does not answer Measured response-time change or multi-location rollout

The final field helps prevent an irrelevant asset from being sent as proof of a broader claim. It can be a brief internal note rather than a prominent public warning.

Test whether another person can retrieve it

Give someone who did not create the labels three realistic questions. Ask them to find a suitable story and point to the detail that answers each one.

Observe where they hesitate. Perhaps they search by role while the library uses department names, or a useful story has an unclear title. Change the label or navigation that caused the problem.

A small retrieval exercise is enough to reveal a confusing category. It is not a statistical claim about sales productivity or conversion.

Keep access and maintenance clear

Link to the approved source rather than several unexplained copies. Label a private sales-only asset clearly so a colleague does not treat it as public material.

Assign someone to update the card when a story changes or is withdrawn. The freshness review handles accuracy over time; the labels should reflect that decision.

If no suitable story exists, record the actual unanswered question for the coverage audit. If the story is found and used, a story-use log can capture whether it helped with the conversation.

The library earns its place when someone can find an appropriate answer, understand its limits and share the correct version. More tags or more assets alone do not establish that result.