How to choose an AI vendor

That order matters more than any single step. Much of what goes wrong in an AI purchase is set up early, when a product is chosen before anyone has agreed what it is for. Here is how to work through each step.

1. Define the problem before you look at products

Write the problem in one sentence, in business terms. "We want to use AI in customer support" isn't a problem yet. "Our support team spends too much time looking for answers" is.

Then pick the one metric that would prove it worked, and measure where it stands today. Without a baseline, you won't be able to show what the project returned, however well it goes.

If you have several ideas competing for attention, rank them by value and by readiness. A valuable use case still has to wait if the data it needs is out of reach or no one can own it.

2. Name who decides and who has to agree

An AI purchase usually touches finance, security, procurement and the team that will use the tool. Each will have its own questions.

Before you evaluate anything, name the person who owns the budget and the decision, and list who else needs to agree. Bring those people in early. An objection raised while you are setting criteria is easy to handle. The same objection raised after you have chosen a vendor can stop the project.

A quick way to see what you still have open is to go through a short checklist like our decision check. It shows where you are in the decision and what to do next.

3. Keep the shortlist short

Two or three vendors is usually enough. A longer list spreads your attention thin without improving the decision.

Start with what the problem calls for rather than with the category leaders, and ask whether a tool you already pay for could do the job.

4. Set must-haves and weight your criteria before any demo

Separate your requirements into two groups.

Must-haves are yes or no questions. Can the vendor meet your data handling rules? Does it connect to the systems it has to? A vendor that fails one is out, so keep this list to real deal breakers.

Weighted criteria are how you compare the vendors that remain. A sensible starting point has five:

• Fit to the goal: will it move the metric you chose?
• Time to value: how soon will you see a result, and how much work will it take from your team?
• Security and data: would your security team be comfortable with it?
• Total cost: what does it cost over the full term, including the work on your side?
• Vendor strength: can this vendor support you through the term?

Give fit to the goal the largest weight unless you have a good reason not to, and adjust the rest to your situation. If you handle sensitive data, raise security. If you face a hard deadline, raise time to value.

Agree the weights before any demo. A good demo is persuasive, and weights set afterward tend to drift toward the favorite.

5. Score on evidence, not on the demo

Ask every vendor for the same things, so that you can compare the answers:

• A demo on your use case rather than the standard script.
• A trial on your own work or data.
• Conversations with current customers who had a similar problem.
• Security documentation, including where your data is stored, who can access it, how long it is kept and whether it is used to train models.
• A full written price for your expected use over the term, including implementation, support, usage charges and renewal terms.

Score each criterion from 1 to 5, agree what each number means, and have the people closest to each criterion do the scoring. Security should score security. Finance should score cost.

Then change the weights a little and score again. If a small shift changes the winner, the vendors are close, and your next step should settle the difference.

6. Test the leader on real work

Vendor demos show a product at its best. Before you commit, run a proof of value with your leading vendor on real work, with real users. Agree the pass mark before it starts, and make it a number tied to your goal, so the result is a clear yes or no.

We cover this in more detail in how to run an AI pilot that leads to a decision.

7. Make the case and choose how to buy

With a result in hand, write a business case that finance can check: the cost, the expected return, the risks and how you will measure the outcome. Answer the likely security questions up front, and agree the path through procurement.

Also think about how you will buy. Each vendor you buy from directly is another supplier to onboard, contract and renew. That is fine for one tool, but the admin grows with each one you add. If you expect to add more, it is worth putting a number on it, using a calculator like what buying direct costs you with your own figures.

Mistakes to avoid

• Letting one team buy alone. A tool that hasn't been through security and finance can stall just when you want to expand it.
• Treating the score as the decision. If the team's preference differs from the numbers, find out why.
• Skipping the plan for after the purchase. Decide who owns the project, what data and access it needs, and how you will measure success. A tool nobody uses is a cost.

The option to choose none

A good evaluation can end with "none of these." If no vendor would move your metric, or the problem turns out to be smaller than it looked, stopping is the right result. It's far cheaper to stop now than after a rollout.

If you would like help running an evaluation, here is how we work. We run the same process with any vendor that fits your problem.