A manufacturer in Peenya spent eleven lakh on an AI tool last year. It works. The model is fine, the connectors hold, the answers are accurate. Nobody opens it. Ask the finance team why and you get a shrug and a version of the same sentence: it was easier to just check in Tally.
That is not an unusual story and it is not a technical one. In the projects we have watched go wrong, the model was almost never the problem. What failed was the ten seconds between a person having a question and deciding whether to ask the software or the person sitting next to them.
The quiet way it dies
Nobody files a complaint about an AI tool. There is no incident, no angry email, no meeting where somebody says this does not work. What happens is smaller and much harder to see.
The accounts assistant asks it something on the second day. The answer comes back phrased confidently, and she has no way to tell whether it is right. So she checks in Tally anyway. Now she has done the work twice. The third day she skips the tool and goes straight to Tally, because that is the step she trusts.
Nothing breaks. The tool simply stops being opened, and the company mistakes that silence for a verdict on AI.
Six months later somebody notices the licence is up for renewal and asks who is using it. The answer is nobody, and the conclusion drawn in the room is AI did not work for us. That conclusion is wrong, and it is expensive, because it usually stops the company trying again for two years.
Four things that predict it
You can see this coming before you spend anything. In our experience four questions separate the rollouts that stick from the ones that quietly stop.
1. Can the person check the answer?
This is the big one. An answer you cannot verify is worse than no answer, because somebody will eventually act on it. If the tool says twelve dealers are overdue by more than thirty days, the next question in a competent person's head is which twelve, and says who. If the software cannot answer that in one tap, it has just created work rather than removed it.
Every reply should cite the file, the ledger entry, the row. Not as a footnote for auditors, but as the primary way the person decides whether to believe it.
2. Does it speak the language of the business, or the language of the tool?
Every company has its own vocabulary. A dealer, a party, a customer and an account might all be the same entity, and the person asking will use whichever word their team uses. If the tool only responds to one of them, the failure feels like the person's fault, and people do not go back to things that make them feel stupid.
The fix is unglamorous: sit with the team before building anything and write down the ten questions they actually ask, in the words they actually use. Those ten questions are the specification. Everything else is secondary.
3. Is it in the path of the work, or beside it?
A tool that lives in a separate tab is a tool you have to remember. A tool that answers where the work already happens gets used by default. This is why the boring integrations matter more than the impressive ones. Being reachable from the place someone already has open beats being ten percent more accurate.
4. Who is embarrassed if it fails?
Rollouts that stick usually have one person who wanted it, asked for it, and will look bad if it dies. Rollouts that fail were bought centrally and handed down. If you cannot name the person on the floor who is going to be pleased this exists, you do not have a project yet, you have a purchase.
Why a design studio ended up caring about this
We came at AI from the wrong direction, which turns out to be the right one. CandyWrap spent ten years doing brand, packaging and UX work, and the thing you learn in a studio is that adoption is designed. A pack that does not get picked up has failed, however good the artwork is. A screen nobody opens has failed, however good the model is.
Most AI companies are engineering teams that add an interface at the end. That ordering is why so much of this software is technically correct and commercially dead. We start with what the person will ask, what they need to see before they will act on the reply, and how they will check it. The model comes after, because the model is the part you can buy.
What to do instead
If you are considering AI on your own data, three suggestions that cost nothing.
Start with one question that is genuinely painful. Not a platform, not a strategy. One question somebody chases every week: which dealers are overdue, which SKU lost margin, what did we quote this customer last year. Solve that one completely, in front of the person who asks it. If it works, they will bring you the next five themselves.
Insist on seeing it run on your own data before you commit. A demo on somebody else's dataset tells you nothing about whether it will survive your spelling, your duplicates and your fourteen years of habits. Any vendor who will not do this on a sample under NDA is telling you something.
Judge it on whether people use it in week six. Not on accuracy in week one. Accuracy is table stakes and every vendor demos well. Usage is the only number that predicts whether you will still be glad about this next year.
The four-question test, before you spend anything
- Can the person check the answer in under ten seconds?
- Does it use the words your team uses, or the words the software uses?
- Is it in the path of the work, or in a tab someone has to remember?
- Can you name the person on the floor who will be pleased it exists?
Three yeses and a named person is a project. Anything less is a purchase.
Adoption is the deliverable. Everything behind it is plumbing.
