The label is now attached to almost everything, which makes it useless as a description. Some of what is sold is genuine automation that will save real hours. Some is a rules engine with new branding. Some is a thin layer over a public tool you could use directly for a fraction of the price.
These questions sort them out quickly, and none require technical knowledge.
One: what task, exactly, does this remove from whose day
The answer should name a person and a task. "It will help Amaka stop retyping delivery notes into the ledger." Not "it will transform your operations" or "increase efficiency".
If the vendor cannot name the task, they have not understood your business well enough to be selling to you yet. If they name a task nobody in your business actually does, they are describing a different customer.
Two: what happens when it is wrong
Not whether. When.
Every system of this kind produces wrong output sometimes. The important thing is what the design does about it. Is there a review step. Does it flag low confidence. Can a person correct it, and does the correction stick.
A vendor who claims their system is not wrong is either inexperienced or not being straight with you. Both are reasons to be careful.
Three: where does our data go, and who else can see it
Which servers, in which country, under whose policy. Whether your data is used to train anything. Whether it is shared with a third party that is actually doing the work behind the vendor's interface.
Get the answer in writing, in the contract. Verbal reassurance during a sales conversation is worth nothing afterwards.
If your work involves client confidentiality agreements or personal data, this question is not optional.
Four: what does it cost when we use it twice as much
Pricing for these tools is frequently usage-based, and the usage is easy to underestimate. A price that looks reasonable at fifty transactions a month can become unpleasant at five hundred.
Ask for the cost at your current volume, at double, and at ten times. Ask what happens if you exceed the plan -- whether it stops, throttles, or simply bills you.
Also ask what happens to the price after the first year.
Five: what does it connect to, and what happens if that connection breaks
A tool that cannot reach your existing records is a second place to type things, which is worse than what you have now.
Ask specifically which of your current systems it integrates with, whether that integration is built or would be a project, and who pays for it. Then ask what happens when the other side changes -- because it will.
Six: can we get our data out
The exit question, and the one that most reveals the vendor's posture.
Can you export everything, in a usable format, on demand, without asking permission. What happens to your data if you stop paying. How long before it is deleted.
Any hesitation here is significant. A vendor confident in their product does not need to hold your records hostage.
Seven: who runs this after you leave
Somebody in your business has to own it: handle the exceptions, notice when the output degrades, retrain people when they change roles.
If the answer is that the vendor manages it indefinitely, you have a permanent dependency and should price it accordingly. If the answer is that your staff manage it, ask what training is included and what happens when that person leaves.
The pilot that tells you the truth
Before committing, run it on real work for a fixed period with a defined measure agreed in advance.
Real work, not a demonstration with prepared data. Demonstrations always succeed. The interesting cases are your awkward ones -- the unusual order, the partial payment, the customer with three sites and one account.
Agree beforehand what success looks like, in a number you already track. Hours saved on a specific task. Errors avoided. Response time. Something you can check without the vendor's dashboard telling you it worked.
The answer you should hope for
Occasionally a good vendor will tell you that your process is not ready, or that the problem you have described would be better solved by a decision than a system.
That answer costs them the sale and tells you more about their competence than any demonstration. It is also, for a meaningful share of businesses considering this, the correct answer.