Choosing between eSourcing providers.

Understanding the provider landscape without naming names

The UK eSourcing market is not one market. It contains broad enterprise suites where sourcing is one component of a wider finance and spend platform, focused sourcing specialists built primarily for public sector competition, contract management tools that have extended backwards into tendering, and portals operated by collaborative buying organisations. Each shape brings a different centre of gravity, and the shape that suits a large central government department is rarely the shape that suits a district council or a housing association with two procurement officers.

It is also worth recognising that some products you will be shown are national or regional portals with a defined user base, while others are systems you configure and run yourself. The difference affects who your suppliers already have an account with, how much control you have over branding and process, and how much you can change without waiting for someone else's release cycle. Neither model is inherently better, but they answer different questions.

Rather than starting with a shortlist of names, start with the shape of the problem. Once you know whether you need a full source to contract estate, a sourcing engine that integrates with an existing finance system, or a lightweight route for high volume below threshold activity, the candidate list narrows on its own and the conversation with each provider becomes far more useful.

Define the requirement before you look at any product

The most common cause of a disappointing eSourcing implementation is a requirement written after the demos rather than before them. Once a team has seen an impressive screen, the specification tends to describe that screen. Write your requirement first, from your own operating reality: how many competitions you run a year, at what thresholds, across which categories, with how many evaluators, and how much of your activity is below threshold rather than full tender.

Separate what you must have from what you would like. Must have items are usually procedural and legal: sealed submission with enforced deadlines, separation of quality and price, an immutable audit log, notice and record production aligned to the Procurement Act 2023, role based permissions, and exportable evidence. Nice to have items are usually convenience: dashboards, templates, integrations, mobile access. Both matter, but only the first list should decide whether a product passes.

Then describe your users honestly. Central procurement staff will use the system weekly and can absorb complexity. Service managers and budget holders may use it twice a year and will need it to be close to self explanatory. Suppliers, particularly small ones, may use it once. A requirement that only reflects the expert user produces a system that the occasional user quietly avoids, which is how off system buying starts.

• Annual volume of competitions, split by above and below threshold.
• Categories in scope, including works, services, goods and any regulated areas.
• Number of named users, occasional users and external evaluators or advisers.
• Existing systems the platform must sit alongside, such as finance, CRM or document management.
• Data you would need to migrate in, and the state it is currently in.
• Governance requirements from audit, information governance and legal.

An objective evaluation framework

Score providers against the same published criteria you would use in any competition, and write the scoring descriptors before you see any product. A workable framework covers functional fit, alignment with the Procurement Act 2023, usability for occasional users and for suppliers, security and data residency, the support model, roadmap and release cadence, financial standing, and references from comparable organisations. Weight these to reflect your own risk, not a generic template.

Functional fit should be tested against your must have list rather than a feature count. A long feature list often signals a product built for a different buyer type. Procurement Act alignment is best assessed by asking to see the actual notices, records and assessment summaries the system produces, and by testing whether a permanently open supplier pool behaves correctly, since systems designed around a list that opens and then closes tend to need workarounds.

Usability deserves proper weight because it determines adoption. Security and data residency questions should be answered with documents rather than assurances: where data is held, which certifications are current, how access is controlled, how incidents are handled and what the retention and deletion positions are. Support, roadmap and financial standing are the durability tests, and they matter most in year three, not year one.

Questions worth asking, and how to script a scenario based demo

A standard demo shows the happy path. You learn far more by supplying the scenario yourself. Take a real recent competition, preferably one that was awkward, strip anything commercially sensitive, and send the same scenario pack to every provider in advance with the same time allowance. Then watch each of them run it. Comparability is the point: identical inputs, identical time, identical observers scoring against identical descriptors.

Build the script around the moments where process usually fails rather than the moments that look good. Ask to see a clarification answered and distributed to everyone, a submission attempted after the deadline, an evaluator scoring without sight of price, a moderation record capturing why a mark changed, a conflict of interest declaration, and the unsuccessful bidder letter produced from the moderation record rather than written by hand afterwards.

Include the supplier view in the same session. Ask to see registration and first submission from the perspective of a small organisation with no prior account, and count the steps. Finish by asking who configured what you have just watched, how long it took, and whether your own team could do the same without a change request. The answer to that last question tells you a great deal about the true cost of ownership.

• Which of the capabilities shown are live today, and which are on the roadmap?
• How often do you release, and how are customers notified and trained?
• What is included in support, what hours, and is help available to suppliers as well as buyers?
• Who performs configuration changes after go live, and what is chargeable?
• What happens to a pending supplier application if a competition is about to conclude?
• Can we export a complete evidence pack for a single competition without vendor assistance?

Commercial models, contracting and total cost

Pricing structures across the market vary considerably, and comparing headline figures rarely produces a fair comparison. Some products price by named user, some by concurrent user, some by volume of competitions or contracts under management, some by module. Build a total cost model over the full intended term, including implementation, configuration, template rebuilds, training, integration work, support tiers and any charges for adding users or modules later.

Pay close attention to what triggers additional cost. Adding an occasional user, running an unexpectedly busy quarter, needing a new report or connecting a finance system are all ordinary events, and if each carries a charge your budget will drift. Ask for the change control mechanism in writing, including day rates and lead times, so that the cost of ordinary evolution is visible before signature rather than discovered in year two.

On contract terms, look for the things that protect you rather than the things that sound reassuring. Clear service levels with meaningful remedies, defined support response and resolution times, a sensible cap on annual uplift, security and data protection obligations that survive termination, and a documented process for handling a challenge or a freedom of information request that touches system data.

Data ownership, migration in and exit planning

Establish early and in writing that the data in the system is yours: tender records, supplier information, evaluation and moderation records, contract data and the audit log. Ownership is not the whole answer, though. What matters operationally is access, so ask what formats you can export in, whether export covers structured data and attached documents, whether you can do it yourself at any time, and whether the audit trail comes with it in a readable form.

Migration in is usually underestimated. Legacy contract registers are often incomplete, supplier records are duplicated, and historic tender documents sit across shared drives and mailboxes. Decide deliberately what you will bring across: live contracts and current supplier records almost always, historic competitions often not. Cleansing before migration is cheaper than cleansing afterwards, and a smaller, accurate starting data set produces a system people trust.

Exit and transition planning belongs in the evaluation, not in a drawer. Agree at the outset what an orderly exit looks like: notice periods, the format and completeness of the final data extract, how long data remains retrievable after termination, what assistance the provider will give a successor, and the cost of that assistance. Retention obligations for public contract records will usually outlast the software contract, so make sure the exit terms respect them.

Compliant routes to market, including G-Cloud 15

You still need a lawful route to buy the software itself. For cloud software, a call off under RM1557.15 G-Cloud 15 is the route most public buyers use, because the terms are already set and the process is comparatively quick. The Digital Marketplace lets you filter and shortlist services, apply your own requirement, and award a call off contract to the service that best meets your published needs, keeping a record of the search and the reasons for selection.

The alternative is running your own competition under the Procurement Act 2023, which is worth the additional time when your requirement is unusual, when you want to test the market properly, or when the value and term make wider engagement sensible. Whichever route you take, publish the criteria in advance, evaluate consistently and record the rationale. A framework call off is not an excuse for a thin evidence trail.

One point of principle applies to every candidate, including this one. Presence on a framework is a route to market and nothing more. It is not accreditation, approval or endorsement, and no supplier should present it as such. 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, and framework purchases are made as call off contracts.

Where eSourcing Data fits, and how to test that claim

eSourcing Data covers source to contract in a single platform: sourcing and tendering, supplier onboarding and assurance, evaluation and moderation, contract management, governance and audit, analytics and reporting, and below threshold workflows. Data is held with UK data residency and the platform is GDPR compliant, which addresses the questions information governance teams at councils, NHS bodies and housing associations usually raise first.

The right response to that paragraph is to test it rather than accept it, exactly as you should test any provider's summary of itself. Send the same scenario pack, apply the same criteria, ask the same questions about roadmap, support and exit, and score it alongside everything else. A provider that is confident in its product will welcome a structured comparison, and any reluctance to be evaluated on your terms is itself useful information.

If you want to prepare before speaking to anyone, the Procurement Library sets out the official Procurement Act 2023 guidance, Procurement Policy Notes and commercial playbooks, which is a sound basis for writing your requirement and your evaluation criteria. Understanding how Dynamic Markets now operate is particularly worthwhile, because permanently open supplier pools are one of the clearest points of difference between products designed for the current regime and products adapted to it.

Making the decision and getting the first competition live

Bring the evidence together before anyone expresses a preference. Consolidate the scenario demo scores, the security and data responses, the reference conversations, the total cost model and the exit terms into a single moderated assessment with a written rationale for each score. This is the same discipline you would apply to a tender you were running, and it protects the decision if it is later questioned by audit, by members or by an unsuccessful provider.

Take references seriously and choose them yourself. Ask to speak to organisations of comparable size and complexity, and ask them practical questions: what the implementation actually took, what surprised them, how support behaves when something breaks, how easy it is to get changes made, and what they would specify differently now. Ask whether their suppliers complain, because that is a signal that rarely appears in a demo.

Finally, plan the first ninety days as carefully as the purchase. Name the first live competition, agree who configures templates and evaluation models, design permissions before rather than after go live, and train occasional users separately from the core team, because their needs are different. A single well run competition delivered on the new system does more for adoption than any amount of internal communication.