The demonstration is convincing, the price is not unreasonable, and the person selling it is not lying to you. And the thing will still sit unused in four months, because the question that decided the outcome was never asked: is this company, today, able to run a system like this at all.
That is not a question about budget or about how technical anyone is. It is five specific capabilities, all of which you can test in an afternoon without buying anything. If you fail three of them, the honest advice is to fix those first and buy the software in six months, and you will spend less money in total.
Why buying does not fix it
The most useful line published on this subject in the last year comes from DORA, the research programme that has measured software delivery across tens of thousands of organisations. Their finding on artificial intelligence is that it acts as an amplifier, magnifying an organisation’s existing strengths and weaknesses.
Read that as a warning rather than a slogan. If your data is clean, an assistant makes it more useful. If your data is inconsistent, an assistant produces confident answers from inconsistent data, faster, to more people. If one person quietly holds a process together, automation removes their judgement from the loop and nobody notices until the exception arrives. Nothing is fixed by the purchase. Everything already there is multiplied.
One: somebody owns it, by name, with time
Not a committee and not the IT supplier. One person inside the company who is accountable for whether this thing works, who has hours in their week for it, and who is allowed to change how the work is done as a result of what it shows.
This is the first item in almost every serious framework for a reason. The United States National Institute of Standards and Technology puts it in the governing function of its AI framework: roles, responsibilities and lines of communication must be documented and clear to individuals and teams throughout the organisation. The UK government’s own playbook lists having the skills and expertise needed to implement and use AI among its ten principles, alongside using the right tool for the job.
The test is not whether you can name someone. It is whether that person, asked in front of you, agrees that they own it and can say how many hours a week they have for it. If the honest answer is that they will fit it around everything else, you have a sponsor, not an owner, and the project will die politely.
Two: someone can answer questions about your own data
Pick the data the system would use — your customers, your products, your prices, your past orders. Then ask a person in the room five questions about it. Where does it live. Who is allowed to change it. When was it last checked. What does this field mean when it is empty. Which of these two systems is right when they disagree.
Most companies cannot answer all five. That is not shameful and it is not fatal, but it is the actual cost of the project, and it is a cost that arrives whether or not you buy anything.
Microsoft’s own adoption guidance puts this before the technology choice rather than after it: confirm the data exists, is accessible, is governed and is of adequate quality, and assess skills and ownership, before adopting. Google’s own guidebook for its practitioners makes the same point about the record rather than the data: dataset documentation can be as important as code documentation — where it came from, what was done to it, and what it should be used for.
Three: you can say what working would look like, as a number
Before the demonstration, write one sentence: this is worth buying if, within three months, this number moves from here to here. Then check that you can measure the number today, without the new system, because a baseline you cannot take now is a baseline you will never have.
Almost every stalled project I have looked at failed here rather than technically. The system worked. Nobody had agreed in advance what working meant, so the review meeting became an argument about impressions, and the renewal was declined for reasons nobody could write down.
Acceptable numbers are boring ones. Hours a week spent on a task. Number of enquiries answered outside working hours. Days between an order and an invoice. Percentage of quotations sent within a day. If the only number anyone offers is a percentage of accuracy quoted by the supplier, you do not have a measure, you have a specification.
Four: the team can absorb a change to how they work
Software does not change a process. People do, and only if the change survives contact with a busy week. So the honest test is historical: name the last change to how your team works that stuck. If the last three were announced and then quietly abandoned, that is the constraint, and it is not solved by better software.
This is also where the difference between a tool and a system shows. A tool that a person chooses to open is adopted or not, individually. A system that sits inside a process changes what everyone does, and it needs someone with the authority to say that the old way has stopped. If nobody in the company has that authority for this process, the project needs a different sponsor before it needs a supplier.
Five: you can turn it off
Ask what happens on the day you stop paying. Where does the data go, in what format, and does the process still run without it.
This sounds like a contract question and it is really a design question, because a system you cannot switch off is one you cannot correct either. The same framework that asks you to document ownership also asks for mechanisms to supersede, disengage or deactivate systems that are not performing as intended. For a small company that reduces to two practical things: an export you have actually run once, and a written note of what people would do instead for a week.
If you fail three of the five
Do the cheap version first, and do it deliberately rather than as a delay. Name the owner and give them the hours. Take the baseline number by hand for a month, which is tedious and always teaches you something. Write down the five data answers you could not give, and fix the two that matter.
Then, if there is a process worth automating, start with the part nobody has written down — which is a separate exercise with its own method, and the one that most often reveals that the problem was never a technology problem. Where AI genuinely does help a company of this size, it tends to be narrow and unglamorous, and what actually works in Arabic customer service is a fair picture of the shape of it.
None of this requires a technology function you do not have. It requires someone to hold the questions, which is what the AI consulting work is for, and what the meeting where nobody was qualified to decide costs when there is nobody to hold them.
Frequently asked questions
Our competitor has already bought something. Are we falling behind?
You are falling behind only if theirs is working, and you have no way of knowing that from outside. A purchase is visible and an outcome is not, which is why the pressure in this market runs ahead of the evidence. The useful question is not whether they bought but whether anything in their operation visibly changed — response times, opening hours, how quickly a quotation arrives. If nothing changed, they bought a licence.
We are five people. Is this framework not too heavy for us?
The five tests get smaller with the company, they do not disappear. At five people the owner is probably you, the data questions take twenty minutes rather than a week, and the baseline is a tally on paper. What does not scale down is the discipline of writing the number before you buy, because at five people a wasted month is proportionally more expensive, not less.
The supplier says implementation includes training. Does that cover the readiness gap?
Training covers how to use the software. It does not cover who owns the outcome, whether your data means what you think, or what number would prove it worked — and no supplier can supply those, because they are facts about your company rather than about the product. Read the implementation line in the proposal for what it actually contains, which is usually configuration and a session, and budget the rest as your own work.
How long should we expect readiness work to take?
For a company of ten to fifty people with an ordinary set of systems, four to eight weeks of part-time work, most of which is deciding things rather than building them. The single longest item is usually agreeing what one field means across two departments who have each been right for years. Nobody enjoys that month and every project that skipped it pays for it later at a worse moment.
Can we do a small pilot instead of all this?
Yes, and a pilot is a good idea provided it is designed to answer a question rather than to produce a demonstration. Pick the narrowest useful task, set the number in advance, run it for a fixed period with real work, and agree beforehand what result would mean stop. A pilot with no stopping condition is not a pilot; it is a purchase with a softer name.