Procurement software, built by people who've actually run procurement.

Who we are and what we are for

eSourcing Data is a UK software company serving public procurement. Our work sits with the people who run competitions and manage contracts: category managers, commercial leads, contract managers, governance and audit teams, and the service colleagues who write requirements and score responses. We are not a general purpose workflow tool with a procurement label attached. Everything in the product exists because a practitioner needed it to complete a regulated step, evidence a decision, or answer a question from an auditor months after the award.

The organisation is practitioner led. Product decisions are shaped by people who have run tenders, sat in moderation sessions, defended scores under challenge, and lived with the consequences of a contract that was awarded well or badly. That background matters more than it may sound. A great deal of procurement software is built by teams who have read the regulations but never had to apply them under time pressure, with an incomplete specification and a stakeholder group that disagrees.

We also take the view that the sector benefits when good information is freely available. Public procurement is spending public money, and the rules governing it are published for everyone. Our contribution to that principle is the Procurement Library, an open explainer resource covering the official Procurement Act 2023 guidance, Procurement Policy Notes and the commercial playbooks. It is available at /resources/library without a login, a form or a sales conversation.

Built for the Procurement Act 2023, not retrofitted

The Procurement Act 2023 came into force on 24 February 2025 and it did more than rename familiar things. It restructured the notice regime across the life of a contract, introduced new assessment and award concepts, changed how exclusion and supplier misconduct are handled, and replaced the Dynamic Purchasing System with Dynamic Markets. Utilities qualification systems became utilities dynamic markets. Transparency obligations now extend into contract performance rather than stopping at the award.

Retrofitting matters because the differences are structural rather than cosmetic. A system designed around the old procedures tends to treat notices as an afterthought, holds the evaluation record loosely, and has no natural home for the ongoing transparency duties that now attach to a live contract. You can bolt these on, and many products have, but the result is usually a set of parallel processes that rely on someone remembering to complete them.

Our approach was to model the statutory process as the backbone of the software. The stages a competition passes through, the records each stage produces, and the notices each stage may require are part of the structure rather than optional extras. Where the Act allows discretion, the product supports the choice rather than forcing one path. Where the Act imposes a duty, the workflow makes the duty visible before the deadline rather than after it.

What source to contract coverage means

Source to contract describes the full commercial cycle from identifying a need to managing the resulting contract to its end. It is a deliberately broad term, so it is worth being specific about what it covers in our case. The point of covering the whole cycle is continuity: the requirement written at the start should be traceable to the specification, the evaluation criteria, the award decision and the performance measures that follow.

Fragmentation is the usual failure. Sourcing happens in one system, supplier information in a spreadsheet, evaluation in email attachments, and contract management in a shared drive that nobody maintains. Each handover loses context. By the time a contract manager needs to know why a supplier was awarded, or an auditor asks how a score was reached, the reasoning lives in the memory of someone who has since moved roles.

Keeping the chain intact also changes what reporting can tell you. When sourcing, supplier and contract data share a single record, questions such as which categories are approaching expiry, which suppliers hold multiple contracts, or where social value commitments were made and never checked become answerable. Those are ordinary management questions that are surprisingly hard to answer when the evidence is scattered across four systems and a mailbox.

• Sourcing and tendering, including below threshold workflows
• Supplier onboarding, qualification and ongoing assurance
• Evaluation, moderation and the record of how scores were reached
• Contract management through to expiry, extension or retender
• Governance, audit trail and transparency notice support
• Analytics and reporting across the whole commercial cycle

How we work with buyers

Public sector buying teams differ enormously in size and shape. A district council may have a small central team supporting service departments that run their own low value purchases. A large NHS body may have specialist category teams and a formal governance structure. A housing association may sit outside the classic definitions but face the same expectations from residents, regulators and lenders. We work with all of these, and the starting point is always the existing process rather than a blank page.

Implementation is deliberately unglamorous. We map the current route to market, identify where the process depends on undocumented knowledge, and configure the system to match how the organisation actually works before suggesting changes. Templates, question libraries, evaluation models and approval routes are set up to reflect local standing orders and financial thresholds. The aim is that the first competition run in the system feels familiar rather than foreign.

Support continues after go live because procurement teams change and the rules move. Guidance is issued, Procurement Policy Notes land, and internal audit asks new questions. Being close to buyers through that cycle is how we learn what needs to change in the product. It is also why we publish plain English explainers openly: if the sector understands the rules better, the conversations we have with buyers are more useful for everyone.

Serving both sides of the market

Procurement has two sides, and a system that only understands one of them tends to make the other side worse. eSourcing Data serves buyers, but the group also operates platforms for suppliers. WinAContract at winacontract.co.uk is a free UK tender search service, aimed at helping organisations find opportunities they would otherwise never see. BidWriter at bid.winacontract.co.uk is an AI assisted bid writing tool for suppliers preparing responses.

There is a practical reason for this rather than simply a commercial one. Buyers complain about poor quality bids. Suppliers complain that tenders are hard to find, hard to interpret and disproportionate to the value at stake. Both complaints are usually right, and both are made worse when the two sides work with completely different information. Seeing supplier behaviour at scale informs how we design the buyer side, particularly around clarity of questions and proportionality of requirements.

The platforms are separate products with separate purposes. A buyer using eSourcing Data is not steered towards suppliers using our other services, and supplier information is not shared across the platforms for competitive advantage. The value of operating across both sides is understanding, not leverage. Suppliers can read more at /for-suppliers and buyers at /for-buyers.

Dynamic Markets and the shift from Dynamic Purchasing Systems

Dynamic Markets are one of the clearest examples of why the Act needed a fresh approach in software rather than a relabelled screen. A Dynamic Market must remain permanently open. Membership cannot be capped. Applications must be assessed within a reasonable time, and where an application is pending it must be considered before a competition running on that market concludes. Those obligations are continuous rather than periodic, which is a different operating model from a closed framework.

Utilities operate under a variant of this. Water, energy and transport utilities may run utilities dynamic markets, may charge suppliers membership and award fees, and may run member only tenders. General contracting authorities may not charge membership fees. Getting these distinctions wrong is a real risk, because the commercial arrangements and the supplier communications differ depending on which regime the market sits under.

In practical terms this means the assessment queue has to be a managed operational process with owners, timescales and visibility, not an inbox someone checks when they remember. It also means competition timetables need to be aware of pending applicants. Our Dynamic Markets support is designed around those realities, and there is a fuller explanation at /dynamic-markets.

Availability through G-Cloud 15

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. Listing the capability as discrete services rather than one large bundle is deliberate: it allows a buying organisation to take the parts it needs, such as evaluation or contract management, without committing to a wider deployment before it is ready.

Purchases made through the framework are call off contracts. The buying organisation runs its own search and assessment on the Digital Marketplace, applies its published requirements, and awards a call off against the framework terms. The framework does not remove the buyer's responsibility to document why a service was selected, and the service definitions and pricing documents published against each listing exist to support exactly that record.

For teams unfamiliar with the route, the practical benefit is time. A compliant call off avoids a full competition for software that is already available under agreed terms. Our service directory sets out what is listed and what each service covers, at /g-cloud-15/service-directory, with background on the framework itself at /g-cloud-15.

Plain English and open guidance

Public procurement has a language problem. The statutory drafting is precise because it has to be, but precision in legislation translates badly into everyday practice. Requirements written in that register are harder for suppliers to answer well, and harder for internal stakeholders to review honestly. Poor bids are frequently a symptom of unclear questions rather than weak suppliers.

We hold ourselves to plain English in the product and in what we publish. Screens explain what a step is for, not just what it is called. Guidance content avoids restating the legislation back at the reader and instead explains what the duty means for the person doing the work, what evidence it produces, and what usually goes wrong. Where something is genuinely uncertain or subject to interpretation, we say so rather than manufacturing false confidence.

The Procurement Library at /resources/library is the main expression of this. It covers the official Procurement Act 2023 guidance, Procurement Policy Notes and the commercial playbooks in language a practitioner can use. It is free and open because the underlying documents are public and the sector is better served by them being understood than by them being gatekept.

How the organisation is structured

We are organised around procurement practice rather than software function. Rather than teams named after technical layers, the work is grouped by the parts of the commercial cycle they serve: sourcing and competition, supplier assurance, evaluation and moderation, contract management, and governance and reporting. Each area is expected to understand the regulatory context it operates in, not just the screens it maintains.

That structure has consequences for how change is prioritised. A request from a buyer is assessed against what the process actually requires, whether the need is general or local, and whether meeting it would make the compliant path harder for everyone else. Configurability is preferred to bespoke work, because bespoke work tends to strand an organisation on a version of the product that stops improving.

On the operational side, data is held in the UK and the platform is designed to meet GDPR obligations, which for public bodies is a baseline requirement rather than a feature. Information governance, records retention and freedom of information handling are ordinary parts of procurement life, and the system is built with the assumption that its records will eventually be read by someone outside the team that created them.