How to read a software case study

1. Is the customer named, or is it “a leading manufacturer in western India”? An unnamed customer cannot be contacted and cannot object.
2. Is there a baseline? “Reduced stock discrepancies by 40%” means nothing without knowing what it was before.
3. Is there a timeframe? Improvements over three months and over three years are different claims.
4. Is the customer quoted saying something specific, or something that could be said about any product? “It transformed our business” is written by an agency. “We stopped counting stock on Sundays” is not.
5. Does it mention anything that went wrong? Every implementation has something. A study with no friction in it has been edited until it stopped being true.

They are the checks that cost a vendor something to pass. Naming a customer requires consent. Giving a baseline invites arithmetic. A timeframe prevents flattering compression. A specific quote requires an actual conversation. Admitting friction requires a customer secure enough to allow it.

A study passing all five took real work and probably describes something real. One passing none took an afternoon.

Applying those checks to ourselves is why the pieces in our Case Studies section are described as worked scenarios rather than customer stories. They describe representative businesses, and every page says so at the top.

They would fail check one, so we do not make the claim. When there are customers whose results we can publish with their consent and their numbers, they will be published as what they are, and they will pass all five.

Ask any vendor to put you in touch with a customer of roughly your size who has been live for more than a year.

The answer, and the speed of it, tells you more than any document. Reluctance is not proof of anything, but it is information.