eSourcing & procurement software, compared.

Define requirements before you look at any product

The single most useful thing you can do is write down how procurement actually works in your organisation today, before any supplier shows you anything. Map the route a requirement takes from the moment a budget holder identifies a need to the point a contract is signed, mobilised and reviewed. Include the parts that are ugly: the spreadsheet that tracks contract expiries, the mailbox that receives supplier questions, the approval that always sits with one person on leave in August.

Then separate needs from preferences. A need is something that, if unmet, blocks a lawful or workable process: publishing notices with the right data, running sealed tenders, keeping an audit trail, meeting accessibility duties. A preference is something that would be pleasant: a particular dashboard layout, a specific colour scheme, a report you could rebuild in a spreadsheet. Teams that skip this step end up scoring products on the things salespeople chose to show, not on the things that will decide success.

Finally, agree who the users really are. Category specialists will use the system daily and will learn anything. Budget holders, service managers, panel evaluators and suppliers will use it a handful of times a year. If the occasional users cannot complete their tasks without a phone call, the platform will generate work rather than remove it. Write down the tasks each group must complete unaided, because these become your demonstration scripts later.

• Current process map, with volumes: tenders per year, below threshold volumes, contracts under management
• Named user groups and the tasks each must complete without help
• Legal and policy obligations that must be evidenced, not just supported
• Constraints you cannot change: finance system, identity provider, records retention rules

Build a weighted criteria model

A weighted model turns opinion into something you can defend. Agree the criteria and the weightings before you see any responses, sign them off with the people who will use the system, and do not adjust them once evaluation begins. If a criterion cannot be evidenced, either rewrite it so it can be or remove it. Vague headings such as flexibility or innovation invite scoring on impression.

Most organisations end up with eight areas. Functional fit covers whether the software does the work you actually do. Compliance covers the Procurement Act 2023 and your wider legal duties. Usability covers occasional users and suppliers. Integration covers the systems the platform must live alongside. Security and data protection covers residency, access control and resilience. Support and implementation covers what happens after signature. Total cost of ownership covers everything you will pay over the term. Roadmap and viability covers whether the product will still suit you in five years.

Weight these according to your risk, not according to convention. An organisation with a small central team and many occasional buyers should weight usability heavily. One with a complex finance estate should weight integration heavily. Record the rationale for each weighting in a short paragraph. That record is what protects the decision if it is questioned later, and it also keeps the panel honest when a charismatic demonstration tempts everyone to move the goalposts.

• Functional fit against your mapped process
• Procurement Act 2023 compliance and evidencing
• Usability for occasional internal users and for suppliers
• Integration and interoperability
• Security, data protection and UK data residency
• Support, implementation and training
• Total cost of ownership across the full term
• Product roadmap and supplier viability

Treat Procurement Act 2023 compliance as a first class criterion

The Procurement Act 2023 came into force on 24 February 2025 and changed both the shape of competitions and the transparency expected around them. Compliance is not a tick box on a specification: it is a set of behaviours the software must make easy and evidence automatically. Ask how each platform handles notices across the contract lifecycle, how it captures the assessment summaries that must go to suppliers, and how it records the reasons behind decisions so that a challenge or an internal audit can be answered from the system.

Pay particular attention to Dynamic Markets, which replaced the Dynamic Purchasing System, and to utilities dynamic markets, which replaced utilities qualification systems. Dynamic Markets are permanently open, membership cannot be capped, applications must be assessed within a reasonable time, and pending applications must be considered before a competition concludes. That last point is an operational trap: a platform that cannot show you who is mid application while a competition is running will create risk that no amount of careful process design can remove.

Also test the transparency chain end to end. Data you enter once should flow to the notices that depend on it, rather than being retyped into a form and diverging. Ask how the supplier sees what you publish, how corrections are handled, and how the system keeps a version history. If the answer is that a person remembers to update three places, you have found a future incident rather than a compliance feature.

Run a scripted demonstration, not a sales demonstration

A standard demonstration shows the software at its best, in a clean environment, driven by someone who uses it every day. It tells you almost nothing about how your evaluation panel will cope on a wet Tuesday. Replace it with a script. Send every shortlisted supplier the same scenarios in advance, tell them they may not use slides, and ask that a member of your own team drives part of the session with only verbal guidance. Score against your model immediately afterwards, while the detail is fresh.

Write scenarios that mirror your real work rather than showcase pieces. Include something below threshold, because that is where most volume sits and where clunky tools cost the most time. Include a moderation session with a disagreement, a supplier clarification that arrives late, and a document that needs replacing after publication. Ask to see what happens when someone makes a mistake, because recovery paths reveal more about a product than happy paths ever will.

Watch for tells. Repeated switching between modules to complete one task suggests the product was assembled rather than designed. Frequent references to configuration or to the professional services team suggest cost you have not yet been quoted. Answers of the form that is on the roadmap should be captured in writing with a date, or scored as absent.

• Publish a below threshold requirement and award it
• Run a moderated evaluation where two evaluators disagree
• Handle a clarification received after the deadline
• Assess a Dynamic Market application while a competition is live
• Onboard a supplier who has never used the system before
• Produce an audit pack for a completed procurement
• Report on contract expiries in the next twelve months

Reference calls and the questions that reveal problems

Every supplier will offer references who are happy. That does not make the calls worthless, it means you must ask questions a happy customer will still answer honestly. Avoid asking whether they would recommend the product. Ask instead what surprised them after go live, what they would specify differently now, and which parts of their process still happen outside the system. The gaps people describe casually are usually the ones your own team would hit six months in.

Ask about the implementation timeline against the plan, who did the work, and how much internal effort it consumed. Ask what happened the first time something broke, how long support took to respond, and whether the fix required a change request. Ask how upgrades arrive, whether they can be deferred, and how much retesting each one triggers. Ask what suppliers say about registering and bidding, because supplier friction eventually becomes buyer workload.

If you can, speak to someone the supplier did not nominate. Peer networks and sector forums usually produce a name, and one unprompted conversation is worth several curated ones.

Design a proof of concept or trial that proves something

A trial without a defined question is a demonstration with a longer timescale. Before you start, write down what you are testing, what evidence you will accept, and who decides. Pick a narrow but real slice of work, ideally a live requirement with genuine stakeholders, and run it end to end. Set a fixed period, a fixed scope and an agreed data set, so that comparison across suppliers stays fair and the exercise does not quietly expand.

Configure the trial the way you would actually operate, not the way that makes it easiest. Use your own document templates, your own approval thresholds and your own evaluation criteria. Involve at least two occasional users who receive no more training than a real colleague would. Record the time taken for each task, the questions asked, and the points at which someone needed help. These small measurements will separate products far more reliably than any feature list.

Agree in advance what happens to the data afterwards. You should be able to export everything you created and have the supplier confirm deletion. A trial that leaves your information sitting in an environment you no longer control is a data protection issue, and testing that exit works is itself useful evidence about the product.

Commercial models and what actually drives cost

Pricing structures vary, and the structure matters more than the headline. Some models charge by named user, some by concurrent user, some by module, some by volume of activity such as tenders published or contracts managed, and some by organisation size. Each rewards different behaviour. A named user model discourages you from involving occasional evaluators, which is often exactly the wrong incentive. A volume model can penalise you for doing the right thing and running proper competitions below threshold.

Build a total cost of ownership model over the full likely term rather than the first year. Include implementation and configuration, data migration, integration work, training and refresher training, support tiers above the standard offering, any charges for additional environments, and the internal staff time you will spend. Then model growth: what happens if your user count doubles, if you add a service area, or if you take on procurement for a partner organisation. Ask for the uplift mechanism in writing, including how it is capped.

Test the model against your own worst case rather than the supplier's typical customer. If a structure only works while your usage stays low, you are buying a constraint. Predictable pricing is usually worth more to a public sector budget than a small saving in year one.

Procurement routes: frameworks, call off contracts and Dynamic Markets

How you buy shapes how long the exercise takes and how much of the evaluation you have to run yourself. A full competition gives you complete control over criteria and is appropriate for a large, long term commitment. A framework agreement gives you pre agreed terms and a shorter route, either through direct award where the framework permits it or through a further competition among appointed suppliers. Dynamic Markets suit situations where you expect to run repeat competitions and want the supplier pool to stay open.

For cloud software, many buyers use the G Cloud route on the Digital Marketplace, where purchases are made as call off contracts against the framework terms. eSourcing Data software is available to public buyers through RM1557.15 G Cloud 15, with 28 software services listed on the Digital Marketplace alongside cloud support services. That route still expects you to compare options against your requirements and record why you selected what you selected, so the comparison work described here remains necessary rather than optional.

Whichever route you choose, keep the evaluation record consistent with it. Frameworks reduce process, not diligence. Write down the route chosen and the reason, the options considered, the criteria and weightings applied, and the outcome. That record is the difference between a decision that survives scrutiny and one that has to be explained from memory a year later by someone who has since changed jobs.

Migration, integration, exit and lock in

Ask early and specifically about data migration, because it is the most commonly underestimated part of any implementation. Establish what will be migrated, in what format, by whom, and who is responsible for cleansing. Contract records, supplier records and historic procurement files each behave differently. Historic tender documents in particular often turn out to be a large volume of files with inconsistent naming, and deciding what genuinely needs to move is a useful exercise regardless of which product you pick.

Integration should be assessed by what already exists rather than what is possible in principle. Ask for documented interfaces, examples of the same integration delivered elsewhere, and clarity on whether the work is included or chargeable. Identity and single sign on, finance and purchase to pay, and any case management or records system are the usual candidates. Check that data flows both ways where you need it to, because a one way feed frequently creates a reconciliation task nobody planned for.

Exit deserves the same attention as entry. Establish before you sign what you can extract, in what formats, how often, and whether documents come out with their metadata and audit history intact. Confirm notice periods, transition assistance and the deletion process at the end of the contract. Lock in is rarely a single dramatic obstacle: it is the accumulation of data you cannot get out cleanly, integrations you cannot rebuild quickly and knowledge that lives only in one supplier's configuration.

Common evaluation mistakes

The most frequent mistake is comparing feature lists. Every mature platform will tick almost every box, because the lists are written to be ticked. What differs is how the work feels when a real person with a real deadline does it, which is why scripted demonstrations and structured trials earn their place. The second is letting the procurement team evaluate alone, then wondering why occasional users resist a system they never saw.

Other recurring errors are easy to name and easy to avoid. Weighting the criteria after seeing responses. Treating compliance as a specification line rather than something to test. Scoring a roadmap promise as if it were a delivered feature. Ignoring the supplier side of the experience. Underestimating internal effort during implementation. Failing to model cost at the volumes you expect in three years rather than the volumes you have today.

Finally, do not rush the decision and then rush the implementation too. The evaluation is the cheap part. If the comparison takes an extra fortnight and produces a clearer requirement, a realistic plan and a shared understanding of what good looks like, that fortnight pays for itself during the first year.