A vendor who spends the first meeting explaining what model they use, what recovery architecture they have, and how many parameters it includes, is describing their product, not your problem. A useful conversation goes in the opposite direction: He should be the one asking the questions., and they should be about your process, your data, and your exceptions.
This is probably the most reliable signal of all those available in a commercial phase, because it is impossible to simulate without having done the work.
If most of these do not appear in the first conversation, the diagnosis is not being made:
The seventh is especially revealing. A provider who asks what was tried before is looking for the cause of the previous failure; one who doesn't ask is going to repeat it.
If the supplier talks mainly about… | It probably sells… | Risk to you |
|---|---|---|
The model and its capabilities | Access to a technology | That integration remains beyond reach |
Its platform and its connectors | A subscription | Dependence and exit cost |
Success stories from other sectors | Business reference | That your case is nothing like it |
Your process and your exceptions | A system | The usual risk of any project |
None of the first three rows automatically disqualify the company. They simply indicate what is excluded from the contract and, therefore, where the additional cost will appear.
Who owns the code and documentation upon completion? If there are nuances, the answer is that it's not yours.
What happens if we want to change providers within two years? The helpful answer describes documentation, versioned contracts, and transferability, not loyalty.
Who pays for the defects in the delivered code? A defect is not a scope change. It should be corrected at no cost and documented in writing.
What happens if you're late? A response with contractual consequences indicates delivery discipline; a response about agile methodologies does not.
How do you handle permits and traceability? If the answer is that it will be seen in the implementation phase, security will be left until the end.
What is the estimated operating cost over three years? Consumption, evaluation, maintenance and evolution.
What use case would you recommend we NOT do? The best of the seven. A supplier who never rules anything out isn't evaluating.
At The Cloud Group, we include these conditions in the contract precisely because they are what a buyer should demand: ownership of the code and documentation, lifetime defect correction, and a full refund if we deliver late. It's not a risky business position if the engineering is well-organized; it's the consequence of having it organized. You can see them in our written guarantees
«"You don't need to change anything."» If the project doesn't require any changes to how work is done, it won't produce any changes in the results either. McKinsey's 2025 data is clear: the factor that correlates most strongly with EBIT impact is workflow redesign, and only 21% had done so.
«"The model is not wrong about that."» Every probabilistic component can be wrong. A vendor who denies this has either not operated production systems or prefers not to discuss it.
Price well below market value with no explanation. This usually means that the scope excludes integration, permits, testing, or documentation. The lower price is recouped with subsequent scope changes.
And a market warning worth bearing in mind: Gartner estimated in 2025 that, of the thousands of vendors presenting themselves as AI agent specialists, only around 130 actually are, a phenomenon it called *agent washing*.
The structural problem with these purchases is that the information is provided by the candidates, and each one defines the problem in such a way that their product is the solution. Three measures correct this:
The third one is the one that changes the result the most, and it is the role we assume when we participate in an RFP as evaluators and not as candidates: we draft the specifications, evaluate the offers and negotiate the contract, without submitting ourselves to the tender that we are evaluating.
If you had to stick with just one indicator after the first meeting, this one works well: Who has spoken the most?
If you've spoken to someone, they probably want to understand the problem. If the supplier has spoken, they want to impose a solution. The difference is noticeable long before signing, and even more so afterward.
It's about the questions they ask, not the answers they give. A good vendor dedicates the first conversation to understanding the client's process, data, exceptions, stakeholders, and regulatory constraints, rather than describing their model, platform, or technical capabilities.
What process do you want to improve and how much does it cost today, where is the data and who owns it, what percentage of cases are exceptions, who decides and what happens in case of an error, what systems need to be touched, what regulatory restrictions apply, what was tried before and how will success be measured.
Who owns the code and documentation upon completion, what happens if you want to change providers, who pays for defects in the delivered code, what are the consequences of a delay, how are permissions and traceability handled, what is the three-year operating cost, and what use case would you recommend against?.
Three: assurance that no changes will be needed in the way of working, denial that the model could be wrong, and a price well below market value without explanation, which usually excludes integration, permits, testing, or scope documentation.
It's the presentation of AI agent specialists by vendors who aren't. Gartner estimated in 2025 that, of the thousands of vendors advertising in this category, only about 130 had actual capabilities.
Writing the process and weighted criteria before the first demonstration, evaluating with proprietary data and a rare case chosen by the client, and incorporating an independent technical part that does not compete in the same tender it evaluates.
Are you evaluating AI or custom software providers? We can draft the RFP, evaluate the bids, and negotiate the contract using independent technical criteria, without presenting ourselves as candidates. Let's talk →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
