Government procurement software, built for the Procurement Act 2023.

What central and local government actually need from a system

Government buying teams sit between policy and delivery. They run competitions, but they also answer to auditors, ministers, committees, cabinet members and the public. A system that only handles the tender stage leaves the harder half of the job on spreadsheets and shared drives. The practical need is one record that runs from the identification of a requirement, through market engagement and competition, to award, mobilisation and contract management, with every decision timestamped and attributable to a named person.

The second need is control across a large and uneven estate. A department may have a central commercial function, several agencies and dozens of delegated buyers. A council may have a corporate team and directorates that buy independently. Software has to reflect that with roles, delegated authority limits, category ownership and central visibility, without forcing every low value purchase through a heavyweight process nobody will use.

The third need is reporting that survives challenge. Teams are asked repeatedly for the same facts: what is in the pipeline, what was spent with small businesses, which contracts expire next year, how many awards attracted a single tender, where social value commitments landed. If those answers require manual assembly each time, they will be inconsistent, and inconsistency is what draws scrutiny.

• One auditable record from requirement to contract expiry
• Delegated authority, category ownership and central visibility
• Proportionate routes for below threshold and low value spend
• Standing reports for pipeline, spend, expiry and social value

The notice regime and transparency duties under the Procurement Act 2023

The Act expanded publication well beyond the old contract notice and award notice pattern. Depending on the route and value, a procurement may involve a planned procurement notice, a preliminary market engagement notice, a tender notice, a transparency notice for direct award, a contract award notice, a contract details notice, the publication of the contract itself above the relevant threshold, contract change notices, contract performance information and a contract termination notice. Each has its own trigger and timing.

For software, the consequence is that publication cannot be an afterthought bolted on at the end. The system should know which notices a given procurement route requires, prompt for them at the right point, hold the data that populates them and record when each was published and by whom. Where notices are transmitted to the central digital platform, the fields the platform expects should be captured once in the workflow rather than rekeyed from a document.

Transparency also runs into the contract management phase. Assessment of contract performance against key performance indicators, and publication where required, means the contract record has to stay live after award. Teams that treat award as the finish line discover the gap months later, usually when someone asks for performance information that nobody has been collecting in a consistent format. The fix is to set the indicators and the reporting cadence at award, and to hold them in the same record as the contract itself.

Supporting the competitive flexible procedure

The competitive flexible procedure is the biggest practical change for government buyers. It allows a procurement to be designed around the requirement: multiple rounds, negotiation, demonstrations, prototypes, site visits, refinement of requirements between stages, and progressive reduction of the field where that was set out in advance. The freedom is real, but so is the obligation to describe the process clearly in the tender notice and associated documents and then to run the process you described.

Software support for this is mostly about structure. The system needs to model stages rather than assume a single submission, carry different question sets and weightings at each stage, handle down selection with recorded reasons, and keep an audit trail across rounds so that a supplier eliminated at stage two can be shown exactly how that decision was reached. Tools built for a one shot open procedure force teams into workarounds that undermine the audit trail.

It also matters for negotiation and dialogue. Where a stage involves meetings, demonstrations or clarification exchanges, those interactions form part of the evaluation record. Holding notes, attendance, questions raised and any changes to requirements inside the procurement record, rather than in individual inboxes, is what makes the process defensible if a decision is questioned later. Where a negotiation round changes the requirement, the version each supplier responded to must be identifiable.

How government actually buys software: frameworks and call off contracts

Very little government software is bought through a standalone competition. Most is bought through a commercial agreement, with the buyer running a further competition or making a direct award under its terms. The award is a call off contract under the framework, and the framework terms, not the buyer's own template, usually govern the commercial relationship. Understanding which route a framework permits is the first question, not the last.

Frameworks differ in how they work. Some require a further competition among all capable suppliers on the relevant lot. Some permit direct award where the framework sets objective criteria for selecting a supplier without reopening competition. Some are catalogue based, where the buyer assesses published service definitions and pricing against a documented requirement. Getting this wrong is a common source of avoidable challenge, because the framework sets the process and the buyer cannot vary it.

Dynamic Markets sit alongside frameworks and behave differently. They 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. For technology categories with a fast changing supplier base that openness is an advantage, but it means assessing new applicants has to be routine and evidenced rather than occasional.

G-Cloud 15 and the Digital Marketplace route

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. Buyers search the marketplace, filter to the services that meet their requirement, assess the published service definitions and pricing documents against their needs, and award a call off contract under the framework terms. The listing granularity means a department can take a single capability rather than a whole suite.

The practical value of this route is speed with a documented rationale. Because the framework has already tested the commercial terms, the buyer's work is to record the requirement, show how the shortlist was produced, and evidence why the selected service best meets the need. That record is what an internal auditor or a scrutiny committee will ask for, and it is much easier to produce at the time than to reconstruct a year later.

The cloud support services matter for implementation. Configuration, data migration, integration and training can be bought through the same route, which keeps the whole engagement inside one commercial mechanism rather than requiring a separate procurement for the professional services that make the software work. Buyers who scope only the licence often find the timetable slips while a second procurement is arranged. Scoping both together gives a single accountable delivery plan.

• 28 software services listed, split by capability rather than sold as one bundle
• Cloud support services for configuration, migration, integration and training
• Purchases made as call off contracts under the framework terms
• Assessment recorded against published service definitions and pricing

Business case, spend controls and approvals

In central government, a digital purchase of any scale runs into spend controls and business case requirements before it reaches a procurement route. Teams are expected to articulate the strategic case, the economic case with options considered, the commercial approach, the affordability position and the management arrangements. Controls on technology and digital spend mean approvals may be needed outside the department as well as within it, and those approvals take calendar time that should be in the plan from the start.

Local government has a different but comparable path: a cabinet or committee report, contract standing orders, a key decision if the value crosses the threshold, and often a call in period after the decision is published. The procurement timetable has to be built around the committee cycle rather than assuming decisions can be taken on demand, and a slipped report can cost a month or more. Where a decision falls in a pre election period, the delay can be considerably longer than that.

Software should support this rather than sit outside it. Holding the business case reference, the approval record, the funding source and the decision documents against the procurement means the audit trail is complete. It also prevents a common failure, where a competition proceeds on the assumption that funding is confirmed while the approval is in fact still sitting in a queue somewhere.

Security, assurance and data residency

Government buyers will ask where data is held, who can access it, how it is segregated and backed up, what happens at the end of the contract and how incidents are reported. eSourcing Data has UK data residency and is GDPR compliant, which answers the first question directly, but the assurance conversation goes further. Expect questions on access control, encryption at rest and in transit, logging, penetration testing, subprocessors and business continuity.

A data protection impact assessment is normal for a system holding supplier contact details, bid content and evaluator commentary. Commercially sensitive tender content carries its own handling requirements, particularly where evaluation records may later attract a freedom of information request. A system that separates published material from internal deliberation makes those decisions easier to handle, because the reviewer can see immediately which content was always intended for publication and which was created as part of an internal assessment. That distinction is much harder to draw after the fact from a shared drive.

Assurance is not a one off exercise either. Departments and larger councils increasingly expect ongoing evidence: annual reviews, incident notification within defined timescales, evidence of testing, and a clear position on any change to hosting or subprocessing arrangements. Build these obligations into the contract management schedule with named owners and review dates, rather than leaving them to be remembered by whoever happened to run the original procurement.

Accessibility and service standards

Public sector bodies have accessibility obligations for the digital services they operate, and that extends to systems suppliers use to bid. A tendering platform that is hard to use with a screen reader or keyboard is not just an inconvenience, it can exclude capable suppliers and undermine the fairness of the competition. Buyers should ask for an accessibility statement and evidence of testing rather than accepting a general assurance.

Service standards also shape expectations. Government teams working to established digital service standards will look for user research, clear language, sensible error handling and a design that does not require training to complete a basic task. For supplier facing screens in particular, the measure is whether a small business with no procurement specialist can submit a compliant bid without help.

Usability has a direct commercial effect. Every avoidable clarification question, failed upload or missed deadline caused by a confusing interface costs officer time and reduces the pool of responses. Where a category already struggles for competition, an awkward portal makes that worse, and the buyer ends up with a shortlist made up of whoever was persistent rather than whoever was best. Testing the supplier journey with real suppliers before go live is a cheap way to find those problems early, and it usually surfaces issues that internal testing never will.

Implementation in a government context

Implementation in government rarely fails on the technology. It fails on data, roles and change. The data question is what comes across: live contracts, expiry dates, supplier records, spend history and any in flight procurements. Deciding early what will be migrated, what will be archived and what will simply be left behind avoids the drift where two systems run in parallel for a year and neither is trusted.

Roles and permissions need designing against the organisation as it actually operates, including delegated buyers in service areas, finance approvers, legal reviewers and the auditors who need read access. Mapping this before configuration begins is faster than discovering during user testing that the approval chain does not match contract standing orders. It is also worth agreeing who maintains the model afterwards, because staff move and delegations change more often than the system is reviewed.

Phasing works better than a single switch. A common sequence is to bring the contract register and pipeline in first, because that delivers visibility quickly at low risk, then move new competitions onto the platform from a fixed date, then add contract management and reporting once users are comfortable. Let existing competitions finish on the old process to avoid disrupting live procurements.

Local government specifics versus central government

Central government tends to have deeper commercial capability, formal category management, stronger controls and access to cross government agreements. The constraints are approvals and scale: more stakeholders, more assurance, longer lead times, and requirements that often span multiple arms length bodies with their own systems and processes. A departmental rollout is therefore as much a negotiation between organisations as a technical exercise, and the sponsor needs enough authority to settle differences in process across those bodies.

Local government has less specialist resource spread across a far wider range of categories, from social care and highways to leisure and waste. A council team may run a construction framework call off and a domiciliary care recommissioning in the same week. That breadth pushes the requirement towards templates, guided workflows and strong reporting rather than deep category tooling, and towards a system non specialists can use safely.

Both sectors share the same pressure points under the Act: getting the notice regime right, designing flexible procedures properly, evidencing decisions and keeping contract performance information current. The difference is mostly in governance rhythm. Central teams work to spend control gateways, councils work to committee cycles, and the procurement plan has to respect whichever applies. A system that supports both without heavy reconfiguration is more useful than one built around a single model of how a public body makes decisions.