Three Questions Before Any AI Tool
Most businesses were offered a chatbot. Very few were offered a number.
Before we recommend, build, or teach any AI tool, we ask three questions. They are the same three we would ask of a lease, a hire, or a piece of equipment, and none of them is about the technology. What decision does it change? What is it worth, in dollars, as a range? Who will be trained to use it? A tool that cannot answer the first two was not needed, however good the demonstration.
What decision does it change?
Name the decision before the tool: not the task it performs or the report it produces, but what will be decided differently once it exists. Who to call, what to order, which price to hold, which hire to make.
Say a distributor is offered an assistant that reads the day’s customer emails and summarizes them. Asked what decision changes, the owner’s first answer is “we will have summaries.” That is a task, not a decision. The better answer comes a minute later: by nine each morning the owner knows which orders are at risk, and can call those customers the same day. Now there is a decision with an owner, and the tool can be judged by whether that call gets made.
Two honest edge cases. Some tools change no decision and simply remove a chore; that is a fair reason to buy one, and it belongs under the second question, measured in hours. And sometimes the answer is “we do not know yet,” which is not a failure. It means the next step is a small trial with a date to revisit, not a purchase.
What is it worth, in dollars, as a range?
Hours saved or revenue found, written down with its assumptions. A range, never a promise, because the estimate is made before the tool exists and is checked after it does.
Suppose a service company spends about four hours every Monday assembling the week’s report from three systems. An automation could draft it. If it saves two to three of those hours, at what that person’s hour costs the company, over the Mondays in a year, the saving is a range with three assumptions inside it: how many hours, what an hour is worth, and how many Mondays. Each is written down, each can be wrong, and each can be checked.
The edge cases matter most here. Time saved is only worth dollars if the time is used for something. If it is not, the honest number is smaller, and the honest benefit is a person less tired on Monday, which is real but not a dollar. Revenue found is harder to estimate than hours saved, so its range is wider, and we say so rather than narrow it to look confident. And a range whose low end sits below the cost of the tool is a legitimate result. It means not this one, or not yet.
Who will be trained to use it?
Name the person, and find the hours in their week. A tool is not delivered when it is installed, but when the people whose work it touches can use it without help and know what to do when it is wrong.
Imagine a firm installs an assistant that answers questions from its own policies and price list. The office manager who would use it every day was not in the room when it was chosen, was shown it once, and was back to the old way by the second week. Six weeks later the assistant answers questions no one asks. Nothing was wrong with the tool. The training was skipped.
Sometimes the person who will use it is the owner, and the training is an hour at the owner’s desk. Sometimes the honest answer is that no one has the time this quarter, which means the tool is not ready to be bought, or the schedule has to change first. Either way the question is answered before the purchase, not after. Every system we build arrives with its team trained, or it has not been delivered.
The same discipline, in what we build and teach
We began with the numbers, and these are the questions we ask of any purchase. They run through everything we do. In strategic finance and planning, a decision gets a range and its assumptions before it gets made. In the systems we design and build, whether a website, an app, an internal tool, or an automation, each begins as a one-page business case that answers the three questions, and is checked against it thirty days after it goes live. In the training that comes with every system and is offered on its own, a team learns the tools by role, on its own work, with a playbook it keeps, so the answer to the third question is a name and a date rather than a hope.
None of this requires a large company or a large budget. It requires writing the decision down, putting a range beside it, and naming the person who will learn the tool. Designed by Ellory Prism, built with AI assistance.
If there is a tool on the table and no number beside it, bring it to the first conversation. We put the same three questions to it. Nothing to prepare, nothing owed.
