How to evaluate IT vendors: an independent guide

Why IT vendor evaluation is harder than it looks

IT vendors are, by design, good at selling. Their sales processes are structured to create urgency, build personal rapport and demonstrate capability in controlled conditions. Most vendor demos are designed to show you the product at its best – on their hardware, with their data, walked through by someone who has done it hundreds of times. That's not the same as the product working in your environment, with your data, operated by your team.

The other structural problem is that most businesses don't buy enterprise software frequently enough to develop in-house expertise in the process. You're doing it once every three to five years; the vendor's sales team does it every week. That information asymmetry is real and it matters. A structured evaluation framework is how you close the gap.

Defining requirements before the market engages

This is the step most organisations skip or compress, and it's the one that causes the most downstream problems. Before you contact a single vendor, you need a documented requirements set. That means four categories of requirement, all written down:

Functional requirements define what the system must do – the specific capabilities your business needs the software to perform. Be precise. "CRM functionality" is not a requirement; "the ability to track multi-contact relationships against a single account, with activity logging visible to all users across the organisation" is a requirement.

Non-functional requirements cover performance, security, scalability and compliance. What uptime do you need? What security standards must the vendor meet – ISO 27001, Cyber Essentials, SOC 2? Does the system need to handle ten times your current volume without architectural changes?

Integration requirements specify what the new system must connect to and how. If the vendor can't integrate with your existing finance system or your e-commerce platform without a six-figure bespoke build, that's a disqualifier – but you'll only know that if you've defined it upfront.

Commercial requirements cover pricing model, contract flexibility and UK data residency. If your data must be processed and stored in the UK, that needs to be a stated requirement before the evaluation begins, not a question raised during contract review.

Document all of this in a requirements matrix. Weight the requirements – must-have, should-have, nice-to-have – so that when vendors respond, you're scoring against the same criteria for every one of them.

Building a longlist

With requirements defined, you can build a longlist of vendors to evaluate. The right research sources depend on your market segment:

• Analyst reports – Gartner Magic Quadrant and Forrester Wave are the standard reference points for enterprise software. They're not infallible, but they give you a credible starting map of the market.
• Specialist review platforms – G2 and Capterra are more useful for mid-market SaaS products. Filter reviews by company size and sector to get relevant signal rather than aggregate sentiment.
• Peer networks and sector associations – for specialist or vertical tools, direct conversation with peers in your sector will often surface vendors that don't appear in analyst reports at all.

The goal is a longlist of six to ten vendors. You'll evaluate three or four in depth. Anything more than that and the process becomes unmanageable; anything fewer and you risk missing a better option.

Apply your must-have requirements to the longlist before going further. Any vendor who can't meet a must-have requirement is off the list, regardless of brand or reputation.

The RFP process

For significant purchases – broadly, total contract values of £50,000 or more – a formal RFP (Request for Proposal) is worth the investment. An RFP is a structured document sent to shortlisted vendors that asks them to respond to your specific requirements, proposed approach, pricing and references in a standardised format.

The value of an RFP isn't the document itself; it's that it forces vendors to respond to your requirements rather than pitch their standard deck. It also makes comparison structured – you're evaluating responses against the same questions rather than trying to reconcile three different presentations.

For smaller purchases, a structured questionnaire covering the key areas – functionality, integration capability, implementation approach, pricing and contractual terms – achieves much of the same effect with less overhead.

Use RFP responses to reduce your shortlist to three or four vendors before investing time in demos and presentations.

Running vendor presentations and demos

The mistake most organisations make with demos is letting the vendor run them. Give vendors your specific use cases and ask them to demonstrate against those – not a generic walkthrough of features you may never use.

Three things to evaluate during a demo:

UX and usability. Can your non-technical users operate this system on a daily basis? A system that requires significant training or IT support to use day-to-day has a higher total cost than the licence fee suggests.

Actual functionality versus roadmap. Vendors will often show you features that are "coming in Q3" or "in development". Be clear that you're evaluating what exists today, not what's planned. If you're buying on the basis of future capability, that needs to be contractually committed.

How the vendor handles your edge cases. Every business has requirements that don't fit neatly into a standard demo. How the vendor responds when you push them on something difficult – whether they're honest about limitations or try to talk around them – tells you more than how they handle the easy questions.

Reference checks that actually reveal something

Vendor-supplied references will almost always be positive. That's not because the vendor is being dishonest; it's because they're selecting customers who are happy to advocate for them. You need to ask questions that get past the advocacy.

First, ask specifically for references from customers of similar size, in a similar sector, who went live in the last 24 months. Recent references are more relevant; customers who implemented three or four years ago experienced a different product and a different team.

Then ask questions the reference customer won't have been prepped for:

• What went wrong during implementation, and how did the vendor respond?
• What would you do differently if you were starting the project again?
• Have there been issues since go-live, and how has the vendor handled them?
• Has the product lived up to what was sold to you?

These questions reveal vendor behaviour under pressure, not just in the sales process. A vendor with good post-sale support and honest implementation practices will have references who can speak to that directly.

Commercial and financial due diligence

Before finalising a vendor selection, two areas of commercial due diligence are often missed entirely.

Financial health. For UK-registered entities, Companies House gives you access to filed accounts. A vendor with a deteriorating balance sheet, persistent losses or significant debt is an operational risk – particularly if you're signing a multi-year contract. A vendor that goes insolvent 18 months into a five-year agreement is a significant business continuity problem. It's not a remote scenario; it happens regularly in the SaaS market.

Pricing transparency and renewal terms. SaaS vendors in particular are known for pricing that looks competitive at initial contract and escalates sharply at renewal. Before signing, understand exactly what drives price increases – user count, data volume, feature tier – and negotiate renewal caps into the initial contract. It's much harder to negotiate these terms when you're already dependent on the system.

Making and negotiating the final decision

Score vendors against your weighted requirements matrix. The scores should inform the decision, not make it – use them as a structured input alongside qualitative judgement about team, culture fit and risk.

Almost all IT vendor contracts are negotiable, even from larger vendors who present standard terms as fixed. The areas where negotiation matters most:

• Data portability and exit rights. You must be able to extract your data in a usable, documented format if you leave the vendor. This is non-negotiable. Contracts that don't include explicit data export rights put you at serious risk of being locked in.
• Liability caps and SLA credits. Standard vendor contracts cap their liability at a fraction of the annual contract value. Understand what you're covered for if the system fails and what the vendor's obligations are under the SLA.
• Termination for convenience. The right to exit the contract without cause – with reasonable notice – gives you leverage throughout the relationship. Contracts without it leave you dependent on the vendor behaving well.
• Contract length. Vendors will push for longer terms; shorter initial terms with renewal options give you more flexibility. A pilot or proof-of-concept period before a full commitment is worth asking for, particularly for high-value or operationally critical systems.

Get independent legal review of any significant IT contract before signing. The cost of an hour of commercial legal advice is substantially less than the cost of being bound by terms you didn't fully understand.