Sector pursuit field 27 · Technology and digital
Our basic working position: This is the first position we would test—not the final bid position. It changes with every buyer organisation, procurement or commercial team, evaluator group, operational user, budget owner and other stakeholder. The live opportunity, people, documents, conversations and clarifications determine the final pursuit.
Public and private contract pursuit
Same capability. Different buying system.
A software, saas and cloud pitch cannot be carried unchanged from a published public competition into a private sourcing decision. The solution may be similar, but authority, visibility, negotiation, risk appetite and the people shaping the decision can be very different.
Follow the declared route—and the decision behind it.
Buyer settings evidenced in the sector dossier: central government and defence bodies; local authorities and public-service companies; NHS, health and life-science public bodies.
Start with the live notice, conditions, evaluation model, timetable, clarification rules and contract.
- Separate subscription, implementation, integration, migration, support and consumption.
- Test cloud-first policy within its stated organisational scope; do not convert it into cloud-only.
Find the real buying group and approval path.
Private buyers use subscription negotiations, enterprise RFPs, proofs of concept, reseller channels and renewal or consolidation events.
- Establish who initiated the purchase, who owns the budget, who can veto it and how procurement, legal and finance will shape the agreement.
- Test incumbent relationships, negotiation room, approval gates, commercial risk and the evidence each decision-maker needs.
- Use conversations lawfully available in the process to refine the proposition; do not assume a private RFP reveals every deciding factor.
The “buyer” is rarely one person.
Align the business owner, users, product, architecture, security, data protection, procurement, finance and legal.
Sector roles to test: service users and accessibility representatives; business and domain owners; product, architecture and integration teams; data protection and cyber specialists; finance, commercial and change leaders.
The bidder is ready; the response needs precision.
Use focused writing when the software, saas and cloud offer, price, delivery model, responsibilities and approved evidence already withstand challenge. We then align them to the question, stakeholder, evaluation logic and response architecture without pretending prose can repair the underlying business.
Strengthen the bidder, then build the bid.
Use end-to-end management when qualification, solution design, process, team, partners, evidence, commercial logic or mobilisation still needs work. The pursuit becomes a project: gaps are exposed, capability is implemented, owners decide and the written answer grows from a stronger operating position.
Candidate lifecycle movements: Shape → Design → Prove → Deliver. Useful operating lenses to test include Zanshin (sustained operational attention), independent review and handover readiness. They are selected proportionately; they are not certification claims or a substitute for the live contract.
Explore Achmed Esser's Assurance & Delivery Lattice →Relevant practice here can include capture strategy, compliance matrices, solution and pricing alignment, colour-team reviews and implementation transition. We apply the parts that fit the pursuit rather than forcing every competition through one template.
See APMP's winning-business lifecycle →Software, SaaS and cloud procurements start from different problems
Evidence-linked insight · What this changes The Ministry of Defence pipeline concerns a legal case and evidence platform with standards-based APIs, lifecycle controls and sensitive information. Hackney recorded a legal casework software award. NHSBSA published a transparency notice for contingent cloud services, while Oxford explored a scalable HR and payroll SaaS replacement. These are not interchangeable product categories. [ 011, 012, 013, 014 ]
Where we would start first Define whether the buyer needs a product subscription, cloud resource, migration, implementation, integration, managed operation, support or all of these. Separate business capability from hosting model and procurement stage. Match proof to the actual domain, data, scale, security and lifecycle rather than relying on the broad label cloud solution. [ 011, 012, 013, 014 ]
Cloud first does not mean cloud regardless of evidence
Evidence-linked insight · What this changes The Government Cloud First policy is mandatory for central government and strongly recommended for the wider public sector. Official guidance asks organisations to consider public cloud before alternatives, but service requirements, risk, value and constraints still require assessment. The policy is neither universal to every authority nor an instruction to ignore exit or resilience. [ 004, 005, 006 ]
Where we would start first State the target authority's policy position and decision route. Compare viable options against user needs, security, data, integration, operating capability, whole-life cost, sustainability and exit. Record evidence and approvals. Avoid presenting a vendor preference as policy compliance or claiming that cloud adoption alone delivers transformation. [ 003, 004, 005, 006, 010 ]
Pipeline, engagement, transparency and award serve different purposes
Evidence-linked insight · What this changes The four records include pipeline, preliminary engagement, transparency and contract-award notices. A pipeline record is not an open competition; engagement can reshape scope; transparency explains an intended direct award; an award records a decision. None, by itself, supplies every contractual term or future opportunity. [ 001, 002, 011, 012, 013, 014 ]
Where we would start first Track the procurement chronology and latest official documents. Record procedure, justification where relevant, eligibility, estimated demand, deadlines and amendments. Treat published figures as bounded evidence, not sales forecasts. Do not infer that one direct-award rationale applies to another product or that an awarded system has delivered its intended benefits. [ 001, 002, 011, 012, 013, 014 ]
User and business requirements must precede feature theatre
Evidence-linked insight · What this changes A long feature list can look comprehensive while leaving critical workflows, decisions, exceptions and accessibility unresolved. Oxford's notice identifies multiple HR and payroll functions and future scaling context; the MOD record describes a full legal case lifecycle. Both need domain validation, not a generic demonstration script. [ 011, 014 ]
Where we would start first Map users, jobs, events, rules, volumes, data, exceptions and outcomes. Distinguish mandatory, configurable, integration-dependent and future requirements. Build scenario-based demonstrations with traceability to acceptance tests. Record gaps and workarounds honestly, including the operational burden created outside the software. [ 003, 010, 011, 014 ]
Configuration and custom development carry different lifecycle costs
Evidence-linked insight · What this changes SaaS value often depends on using supported configuration and standard releases. Bespoke code can meet a local need but increase testing, upgrade and supplier dependency. Configuration is not automatically free or reversible, and a claimed out-of-the-box feature may still need data, permissions, workflow design and user training. [ 003, 005, 006, 010 ]
Where we would start first Create a fit-gap register showing standard capability, parameter, extension, integration, custom component, workaround and rejected need. Price design, build, testing, support and upgrade impact separately. Obtain buyer decisions for material compromises. Ensure sales demonstrations use the proposed edition and configuration, not unreleased roadmap material. [ 003, 005, 010 ]
A product must fit an ecosystem rather than win alone
Evidence-linked insight · What this changes Case systems, HR platforms and cloud services connect to identity, finance, document storage, reporting, payments, email, archives and other operational tools. A technically possible connection is not an implemented integration. Ownership of interfaces, environments, certificates, testing and downstream change can determine the real delivery risk. [ 011, 013, 014 ]
Where we would start first Draw logical, data, integration and deployment views at an appropriate level. For every interface specify purpose, direction, standard, frequency, volumes, error handling, security, monitoring, owner and dependency. Use standards-based APIs where required but verify actual endpoints and licences. Include integration failure in acceptance and continuity plans. [ 003, 006, 010, 011, 014 ]
Migration is a governed transformation of records
Evidence-linked insight · What this changes Moving data involves extraction, profiling, mapping, cleansing, deduplication, transformation, validation, reconciliation and retention decisions. Legal case evidence and payroll records have different integrity and availability consequences. A record count can reconcile while relationships, permissions, audit history or business meaning remain wrong. [ 009, 011, 014 ]
Where we would start first Agree source systems, data ownership, quality rules, migration scope, cutover windows, tolerances and sign-off. Rehearse with representative volumes and exceptions. Preserve chain-of-custody and auditability where required. Define rejected-record handling and rollback. Price buyer cleansing work and legacy access rather than assuming perfect exports. [ 006, 009, 010, 011, 014 ]
Cloud processing needs explicit information roles
Evidence-linked insight · What this changes SaaS providers, implementation partners, platform operators and subprocessors can each handle personal data. Data location, remote support and international access require more detail than a region name. The Data Protection Act is part of the legal framework, while current UK data-protection obligations and buyer schedules require specialist interpretation. [ 009 ]
Where we would start first Map purposes, controller and processor roles for review, data categories, users, subprocessors, locations, transfers, access, retention, return and erasure. Provide contractual and technical evidence rather than a badge alone. Build privacy into configuration and support. Never promise lawful processing solely because the infrastructure is hosted in the UK. [ 006, 007, 009 ]
Cloud security is a shared evidence problem
Evidence-linked insight · What this changes The NCSC Cloud Security Principles organise areas for assessing cloud services, but applying them requires evidence about the chosen service, configuration and buyer risk. The MOD pipeline explicitly references sensitive classification, encryption, access control and auditability. Those requirements cannot be generalised to every authority or satisfied by marketing claims. [ 007, 011 ]
Where we would start first Create a shared-responsibility and control matrix covering identity, privileged access, encryption, keys, logging, vulnerability, secure development, tenancy, incident response, supply chain and assurance. Link claims to current evidence and scope. Record buyer-owned configuration and risk decisions. Have competent security reviewers test the target architecture. [ 006, 007, 011 ]
Tenancy choices alter control and economics
Evidence-linked insight · What this changes Multi-tenant SaaS can provide scale and regular releases, while dedicated components may offer different isolation or configuration. Neither architecture is inherently suitable without context. Data separation, noisy-neighbour risk, encryption, administrative access, updates and capacity controls must be understood in the actual service. [ 006, 007 ]
Where we would start first Describe tenancy at application, data, infrastructure and support layers. Evidence separation testing, administrative boundaries and scaling behaviour. Explain which controls are common and which are customer-specific. Reconcile any dedicated design to subscription and operating cost, and avoid claiming physical isolation where only logical separation exists. [ 006, 007 ]
Accessibility belongs in product design and assurance
Evidence-linked insight · What this changes Public-sector website and mobile-app accessibility Regulations can apply within their stated scope, while buyers can set broader accessibility requirements for software. Employee and professional systems also need usable journeys. A supplier's historic conformance statement does not establish that the configured, integrated service remains accessible. [ 008, 014 ]
Where we would start first Identify applicable standards and buyer obligations with specialist advice. Test representative workflows, content, authentication, documents and assistive technologies throughout delivery. Record defects, severity, ownership and remediation. Include accessibility in change and release gates. Do not treat automated scanning or a single template audit as complete assurance. [ 003, 008, 010, 014 ]
Product availability is not end-to-end service availability
Evidence-linked insight · What this changes A vendor may measure the SaaS platform while excluding networks, identity, integrations, maintenance or customer configuration. A high monthly percentage can still permit disruptive downtime. Support response does not equal resolution, and service credits do not restore missed payroll, court deadlines or public transactions. [ 011, 013, 014 ]
Where we would start first Define service boundaries, critical transactions, hours, priority, maintenance, clock, exclusions and evidence source. Add integration health, data timeliness and user-impact measures where relevant. Establish incident communication and recovery acceptance. Price stronger objectives only when architecture and operational capacity can support them. [ 006, 007, 010, 011, 014 ]
Continuous release requires governed customer change
Evidence-linked insight · What this changes SaaS providers may deploy frequent security, platform and feature updates. That can reduce unsupported versions but also alter interfaces, workflows and training needs. A roadmap is not a contractual release, and a customer cannot defer every shared-service change indefinitely. [ 003, 005, 006, 010 ]
Where we would start first Set release notice, environment, regression, accessibility, security, integration and communication arrangements. Define urgent-change treatment and rollback limitations. Track deprecations and API versions. Separate committed features from aspirations in the bid, and explain how the buyer influences priorities without implying sole control over the product roadmap. [ 003, 006, 010 ]
Support must bridge product, implementation and business operation
Evidence-linked insight · What this changes Users can encounter configuration, data, integration, product and process problems. If the software vendor, implementation partner and buyer each operate separate queues, cases can circulate without ownership. A knowledge portal may reduce simple demand but cannot replace expert escalation for payroll or evidence-management incidents. [ 011, 012, 014 ]
Where we would start first Design a single diagnostic and escalation journey with clear severity, hours, responsibilities, vendor routes and communications. Name service-management ownership during and after implementation. Define knowledge transfer and administrator capability. Test multi-party incidents before go-live. Ensure the price includes the support tier and volumes actually proposed. [ 010, 011, 014 ]
Implementation is a business transition, not only product setup
Evidence-linked insight · What this changes New SaaS changes roles, controls, workflows, reports and user behaviour. Oxford's potential HR and payroll replacement also sits amid possible organisational scale change; NHSBSA's cloud notice references migration and final transition. Technology go-live can be technically successful while operations remain unprepared. [ 013, 014 ]
Where we would start first Build integrated workstreams for governance, design, data, integration, configuration, testing, security, accessibility, training, communications, cutover and benefits. Give every gate acceptance evidence and an empowered approver. Reflect buyer resource in the plan. Separate critical go-live scope from later optimisation without hiding deferred requirements. [ 003, 010, 013, 014 ]
Acceptance should represent real risk and scale
Evidence-linked insight · What this changes Happy-path demonstrations do not exercise payroll exceptions, legal evidence integrity, role conflicts, API failure, bulk operations or degraded cloud services. Supplier test completion is different from buyer acceptance. Test data and non-production environments can also introduce privacy and security concerns. [ 007, 009, 011, 014 ]
Where we would start first Create a risk-based test strategy covering function, integration, migration, performance, security, accessibility, recovery and operational readiness. Define entry, defect severity, evidence and acceptance authority. Use representative volumes with protected data. Rehearse cutover and rollback. Record residual defects and their commercial treatment. [ 006, 007, 008, 009, 010 ]
Scalability must be tied to a demand envelope
Evidence-linked insight · What this changes Oxford anticipates possible growth in employees and payrolls, while legal evidence systems may face large files and long retention. Cloud capacity can expand, but application design, database behaviour, licensing, integrations and support teams may become constraints. Scalable is not a measurable commitment without load and cost assumptions. [ 011, 014 ]
Where we would start first Define users, concurrency, transactions, file sizes, storage, retention, batch windows and growth cases. Evidence performance tests at agreed envelopes and degradation behaviour beyond them. Explain scaling lead time and limits. Connect every growth scenario to subscription, consumption, support and integration cost. [ 005, 006, 011, 014 ]
Separate recurring, consumption and change economics
Evidence-linked insight · What this changes Software procurements can combine subscriptions, implementation, migration, integrations, environments, support, storage, API calls, egress, training and change. A low licence price can coexist with expensive adoption or exit. Direct-award and award values are not universal price benchmarks because scope and contractual context differ. [ 012, 013, 014 ]
Where we would start first Build a total-cost model over the proposed term with volumes, tiers, currency, indexation, renewal, minimum commitments and exit visible. Map price to the solution bill of materials and plan. Run growth and delay cases. Define catalogue and change governance so optional work does not become an uncontrolled dependency. [ 006, 010, 013, 014 ]
Cloud consumption needs operational financial control
Evidence-linked insight · What this changes Metered resources can align cost with use, but poor tagging, idle capacity, egress and uncontrolled environment creation create budget surprises. A committed-spend discount may save money only if demand materialises. Product teams, finance and engineering need shared visibility rather than a retrospective invoice review. [ 005, 006 ]
Where we would start first Define accounts, budgets, tags, allocation, alerts, forecasting, optimisation authority and exception review. State who can create or resize resources. Separate genuine savings from avoided forecast spend and normalise comparisons. Reconcile optimisation assumptions with resilience, performance and contractual commitments before offering a guaranteed figure. [ 005, 006, 010 ]
Dependency must be assessed across data, code and operations
Evidence-linked insight · What this changes Lock-in is not limited to one cloud vendor. Proprietary workflows, APIs, skills, configuration, data formats and implementation knowledge can all constrain choice. Avoiding every managed feature may also increase cost and reduce service quality, so the goal is informed dependency with an executable exit. [ 003, 005, 006, 010 ]
Where we would start first Create a dependency register with replacement options, export formats, transfer effort, licences and operational knowledge. Decide deliberately where managed capability justifies switching cost. Maintain documentation and automated deployment where proportionate. Explain trade-offs without claiming portability that has not been tested. [ 003, 006, 010 ]
Data return and continuity need contractual precision
Evidence-linked insight · What this changes At expiry or termination, the buyer may need complete data, attachments, audit history, configuration, interface specifications and administrative knowledge. A simple CSV export may be unusable for linked case evidence or payroll history. Erasure, subprocessor retention and continued access must also be controlled. [ 007, 009, 011, 014 ]
Where we would start first Define export content, format, schema, frequency, tools, assistance, fees, timing, validation and deletion evidence at procurement stage. Test representative exports before dependence grows. Plan read-only access and transition overlap where justified. Keep the exit pack current and ensure buyer credentials and keys are recoverable. [ 006, 007, 009, 010 ]
Supplier and product continuity are wider than uptime
Evidence-linked insight · What this changes A financially stable vendor can still retire a feature, lose a critical subprocessor or change commercial terms. A product can remain online while the customer cannot lawfully, securely or affordably use it. Resolution planning therefore includes ownership, supply chain, alternatives, data and operational capability. [ 006, 007, 010, 013 ]
Where we would start first Assess critical suppliers, subprocessors, support dependencies, product roadmap, data recoverability and transition time. Match contract protections and escrow or continuity mechanisms to actual risk rather than using them as boilerplate. Establish triggers for remediation and exit. Keep buyer-side administration and documentation sufficient for emergency action. [ 006, 007, 010 ]
Evaluation evidence should follow the buyer's risk
Evidence-linked insight · What this changes A legal-evidence platform may prioritise auditability, security, lifecycle and APIs; HR and payroll may emphasise statutory processing, scalability, usability and implementation. Cloud procurement can focus on continuity or migration. A generic feature response can miss the evaluators' real failure scenarios. [ 011, 013, 014 ]
Where we would start first Rebuild the current score and pass/fail model from the full pack. Link each proposal to requirement, configuration, evidence, owner, test, dependency and price. Demonstrate with buyer-relevant scenarios. Use clarifications where statements conflict. Have domain, technical, security, accessibility, implementation and commercial reviewers challenge one shared solution. [ 001, 002, 011, 014 ]
Software benefit claims need attributable baselines
Evidence-linked insight · What this changes A new platform may reduce manual work, improve data quality, speed decisions or support compliance, but those outcomes depend on process redesign, adoption, data and buyer decisions. Licence deployment and logins are outputs, not proof of transformed services. An award notice cannot substantiate benefits after go-live. [ 012, 013, 014 ]
Where we would start first Define each intended benefit with baseline, population, calculation, owner, dependency, measurement date and attribution rule. Separate supplier commitments from buyer-led change. Track disbenefits and quality, not only time. Label forecasts and avoid monetising saved minutes twice across roles or projects. [ 003, 010, 012, 013, 014 ]
Product fit, data and exit come before sales language
Evidence-linked insight · What this changes Weak software bids often rely on roadmap features, vague integration, assumed clean data, security badges, inaccessible demonstrations and a subscription figure detached from implementation. These issues cannot be repaired by describing the product as modern, scalable or seamless. Current notices expose distinct lifecycle and domain constraints. [ 011, 013, 014 ]
Where we would start first Confirm route and user need; close mandatory legal, domain, accessibility and security barriers; then reconcile fit-gap, architecture, migration, testing, support, release, continuity and total cost. Challenge every feature and benefit against evidence. Leave unresolved assumptions assigned to clarification, client decision or delivery gate. [ 001, 002, 003, 007, 008, 009 ]
Official records are context rather than product endorsement
Evidence-linked insight · What this changes The MOD notice describes future intent, Hackney records an award, NHSBSA sets out a direct-award rationale and Oxford seeks market input. They do not prove Bid Champions involvement, product quality, implementation success or realised saving. Government guidance also cannot validate a particular supplier configuration. [ 003, 004, 011, 012, 013, 014 ]
Where we would start first Publish performance or client claims only through an approved evidence record containing consent, exact wording, source files, service and period, denominator, attribution, permitted pages and review date. Until then, use public material solely to explain market demands and keep outcome language prospective and conditional. [ 011, 012, 013, 014 ]
The buyer retains risk, policy and acceptance decisions
Evidence-linked insight · What this changes Bid support can structure discovery, create traceability, coordinate specialists and test commercial consistency. It cannot choose lawful processing grounds, accept cyber risk, approve architecture, warrant statutory payroll accuracy, sign a direct-award justification or commit buyer resources. These require empowered officials and professional advice. [ 001, 002, 007, 008, 009 ]
Where we would start first Record every material decision with options, evidence, consequence, advice, approver and date. Propagate the approved position into requirements, contract, plan and price. Where evidence remains unavailable, qualify the commitment and log the blocker rather than supplying an invented implementation fact. [ 001, 002, 007, 008, 009 ]
The pursuit should leave a maintainable product decision record
Evidence-linked insight · What this changes Reusable assets include a capability map, fit-gap register, architecture, interface catalogue, migration rules, shared-control matrix, acceptance model, cost drivers and exit specification. They help govern later implementation only when versioned, owned and linked to the actual product edition and contract. [ 003, 006, 007, 010 ]
Where we would start first Assign operational ownership and review cadence before award. Remove buyer data and tender assumptions before reuse. Update artefacts through design and release, and capture evidence from tests and service operation. Treat one procurement's configuration as a lesson, not a universal reference architecture. [ 003, 006, 007, 010 ]
Relevant anonymised case study
A sole trader secured a £1m software-development contract
The anonymised sole trader secured a £1m, three-year software-development contract as the sole and primary supplier.
- Buyer
- Contracting authority (anonymised)
- Published value band
- £1m awarded contract value
- Outcome
- Sole-supplier contract award recorded
The precise tender-support workstream is confidential. The full case separates Bid Champions’ recorded support, the client’s solution and commitments, and the buyer’s award decision.
Read the complete case studyLive-pursuit check
What we would verify before fixing the strategy.
For a live opportunity, we would recheck the applicable law and standards, the buyer's latest notice and documents, qualification route, amendments, commercial assumptions and delivery conditions. This keeps the analysis useful without treating a general market position as a substitute for the actual competition.
Priority public records to recheck: Government Cloud First policy; Use Cloud First; Digital Legal Case Management System for the SBA, pipeline notice 2026/S 000-019896; Legal Case Management System Software, contract award notice 2026/S 000-009007; Insight Cloud Services, transparency notice 2026/S 000-011696; HR and Payroll System, preliminary market engagement notice 2026/S 000-013996.
Independent verification checks
The public references supporting the evidence points above remain available so a bidder, specialist or decision-maker can test the position against the original authority.
Open 14 public references used to test this sector position
- Procurement Act 2023 — UK Parliament / legislation.gov.uk
- Procurement Regulations 2024 — UK Parliament / legislation.gov.uk
- Technology Code of Practice — Government Digital Service
- Government Cloud First policy — Government Digital Service
- Use Cloud First — Government Digital Service
- Cloud guide for the public sector — Central Digital and Data Office
- Cloud Security Principles — National Cyber Security Centre
- Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — UK Parliament / legislation.gov.uk
- Data Protection Act 2018 — UK Parliament / legislation.gov.uk
- The Digital, Data and Technology Playbook — Cabinet Office
- Digital Legal Case Management System for the SBA, pipeline notice 2026/S 000-019896 — Ministry of Defence / Find a Tender
- Legal Case Management System Software, contract award notice 2026/S 000-009007 — London Borough of Hackney / Find a Tender
- Insight Cloud Services, transparency notice 2026/S 000-011696 — NHS Business Services Authority / Find a Tender
- HR and Payroll System, preliminary market engagement notice 2026/S 000-013996 — Oxford City Council / Find a Tender