A customer logo is not a customer proof point

A recognised customer name can establish familiarity quickly. It leaves important questions unanswered: what did that customer deploy, where is it being used and what has changed as a result? A briefing needs enough detail for an analyst to assess the relevance of the example.

Customer evidence should connect a claim to an actual deployment. If you say your product supports complex enterprises, show the relevant complexity. If you say it improves an operating process, explain the process and the observed result. The customer’s reputation cannot carry that argument on its own.

Make the relationship specific

Begin with the part of the organisation using the product. A deployment in one team, a regional rollout and an enterprise-wide implementation represent different levels of adoption. Describe the scope accurately. A pilot can be useful evidence of learning or technical feasibility, provided it is identified as a pilot.

Explain the original problem, the product or service deployed and the operating environment. Include the responsibilities of implementation partners where they materially affected the result. This gives the analyst a basis for assessing which parts of the story may apply to another organisation.

Then describe the outcome and its basis. For a measured improvement, specify what was measured, over what period and against which starting point. If the evidence is customer feedback rather than a measured result, say so. Precision makes a modest result more useful than an impressive claim with no definition.

Build around the briefing’s question

Choose examples for their relevance to the discussion. A briefing about a new use case needs evidence of that use case. A discussion about adoption across countries needs a clear account of where deployments are active and how they differ. Repeating the same famous names across every presentation can leave the central question unresolved.

An illustrative example shows the difference. “Used by a global manufacturer” says little about deployment. “Used by one manufacturing division to standardise a defined approval process; production deployment confirmed, outcome measurement still underway” gives the analyst a more accurate picture. It also makes the evidence gap visible without inventing a result.

A practical evidence checklist

• Customer context: sector, relevant business unit and operating setting.
• Problem: what the customer needed to change and why.
• Deployment: product, scope, status and timing.
• Delivery: the customer’s work and any material partner contribution.
• Outcome: measured result or clearly identified qualitative feedback.
• Basis: source, date, definition and limits of the evidence.
• Availability: what can be shared and whether a reference conversation is available.
• Ownership: who maintains the example and confirms changes.

Keep the proof current

Assign someone to check that the example still describes the deployment accurately. Expansion, product changes and revised customer permissions can all affect its use. A public case study, a private briefing example and a reference conversation are separate assets; establish what is available for each.

Where a customer cannot be named, retain the useful operating detail that can be shared and explain the limits of verification. Do not fill the gap with a composite presented as a real customer.

Before the next briefing, take the customer slide and ask what each example demonstrates. If the answer is only that a familiar company has a relationship with you, there is more work to do. The strongest evidence explains why that relationship matters to the claim you are making.

Explore the wider guidance in the Kea AR Knowledge Map.

Share this article