Nearly everything sold to businesses now has AI written on it somewhere, which makes the label useless for telling things apart. The useful questions are not about the technology at all. They are about who owns what, what happens when it goes wrong, and how anyone would know it worked.
These are also, deliberately, the six we would want asked of us.
What job does it own, and how would we know it did it?
Not what it can do. What it owns, in a sentence, with a countable output attached. "It answers every enquiry within five minutes and books what it can into the diary" is a job. "It uses AI to improve customer engagement" is a description of a category.
The follow-on matters more: how would you know, at the end of a month, whether that happened? If the answer is a dashboard of activity rather than a count of things produced, you are being shown effort. Effort is not the thing you are buying.
What does it do when it is not sure?
Every system meets something it was not built for. The only question is what happens next, and there are exactly two answers. It guesses, or it hands the job to a person with the reason attached.
Ask directly, and be suspicious of an answer that implies this never happens. A vendor who has thought about production has a specific answer here, usually involving who it goes to and what they see. A vendor who has only ever demonstrated it will tell you the model is very accurate, which is not a response to the question.
Where does the finished work end up?
Into your existing systems, or into a new place someone has to remember to check?
This sounds administrative and it is the single most common reason good tools go unused. Work that lands in your CRM, your inbox, your calendar gets used because it is in the path people already walk. Work that lands in a separate portal is one more thing to open, and after a few busy weeks it stops being opened. The tool did not fail. It was just never in the way of anyone's day.
When it gets something wrong, who fixes it and at whose cost?
Establish the line between a fix and a change before you sign, because you will be having this conversation eventually and the terms are better set now.
Something not doing what was agreed is a fix, and it should be included. Something new that you have decided you want is a change, and it is fair for that to be priced. What you are checking for is whether the vendor draws that line at all. If everything after go-live is quoted, the incentive is to hand over quickly rather than to make it work, and you will feel that in month two.
Related and worth asking in the same breath: what were the acceptance criteria, and were they written down before the build started? Agreed in advance, they turn "is this working" into a check anyone can run. Agreed afterwards, they turn it into a negotiation.
What do we keep if we leave?
Ask it plainly, early, while everyone is still friendly. The leads, the records, the documents it produced: are those yours, and can you export them without a conversation? What happens to the system itself?
There are reasonable answers on both sides of this. Owning the output while the machine that produces it stays with the vendor is a normal and honest arrangement, and it is usually the reason a system is a monthly fee rather than a large build cost. Owning the whole thing outright is also fine, and generally costs more up front. What is not fine is not knowing. Anyone who is vague about this at the start will be vague about it at the end, when it matters considerably more.
Who is on the hook for running it?
The last one, and the one most often skipped, because the answer is usually buried in the word "training".
If the arrangement is that they build it and your team runs it, then you have hired a builder and you are the operator. That can be the right choice, but it means someone in your business now owns a system they did not design, and that person has a day job. If the arrangement is that they run it, then ask what happens when it breaks on a Saturday, and who you call.
Neither is wrong. Buying one while believing you bought the other is where the disappointment comes from.
The pattern underneath all six
Every one of these is really the same question asked from a different angle: is this a system with a job and an owner, or a capability with a subscription attached?
Capabilities are abundant now and getting cheaper every year. What stays scarce is the judgment about which job is worth automating, and the willingness to be held to what it produces. That is the thing worth paying for, and the six questions above are a reasonable way to find out whether it is what you are being offered.
Ask us the same six. Some of the answers are already on the questions page, and the rest take about ten minutes on a call. Publishing the list and then dodging it would be a poor look.