Before approving the delivery fee, establish what your team will inherit. Trace a material promise through the proposal: what will be delivered, which client inputs it requires, how acceptance will be demonstrated and who takes responsibility after launch. Where the trace stops, the buying decision needs an answer or an explicit condition.
That is the purpose of vendor proposal review: making commitments clear enough to compare and approve. An unanswered question warrants clarification, not an accusation of dishonesty. Judge whether the answer establishes a workable boundary, credible verification and an owner for what remains uncertain.
Read for operating reality
The questions below are editorial recommendations, informed by the cited technology, accessibility and AI guidance. They are not a validated test of vendor quality or a complete procurement standard. Commercial terms, ownership and exit arrangements need review in the context of your engagement.
Look for bounded answers rather than certainty on demand. A useful answer may acknowledge an unknown, specify how it will be investigated and name who decides what happens next. Treat a material omission as a red flag if it remains unresolved and unowned at commitment. An explicit exclusion is different: you can assign the work elsewhere or remove it from the intended outcome.
Shared checks: outcome, boundaries and accountability
Ask what operational change you are buying and which part the vendor can commit to delivering. Separate acceptance of its work from benefits that depend on your adoption decisions, internal resources or other suppliers. Before comparing prices, ask each bidder to make those dependencies explicit.
State the intended operational change.
Define deliverables, exclusions and assumptions.
Name required inputs and their owners.
Agree evidence and approval authority.
Assign support, cost and handover responsibilities.
A recommended review sequence, not a scoring model.
Trace each material promise from the intended outcome to post-launch responsibility.- Scope and client inputs: What is included, excluded or assumed? Which access, data, decisions and client resources are required, and when? Seek named owners and an agreed response if an input is late or unsuitable. Leave unowned dependencies open in the review record.
- Team accountability and change: Who leads delivery, who makes technical or design decisions, and who approves acceptance? How will changed assumptions affect scope, schedule and fees? Ask for a defined approval route; a promise to be flexible does not specify change control.
- Acceptance evidence: What will demonstrate that each deliverable meets the agreed requirements? Name the reviewer, verification method and remediation responsibility. Keep delivery of an artefact separate from acceptance of its quality.
- Security and privacy: Which systems and data will the vendor access, where will data be handled, and who approves and verifies the controls? Request explicit boundaries and responsibilities rather than a general assurance.
- Lifecycle cost: What sits outside the delivery fee, including hosting, licences, support, maintenance and usage charges? Ask for assumptions, exclusions and responsibility for variable costs. Treat an unexplained operating-cost estimate as provisional.
- Ownership and exit: What can you use, modify, transfer and operate independently? Review IP terms, third-party restrictions, editable artefacts, documentation and exit assistance explicitly. Do not assume that payment settles these rights.
Technology proposals: inspect the full lifecycle
The GOV.UK Service Manual’s technology index covers technology choice, development, integration, hosting, testing, security and maintenance. Use that breadth as a coverage prompt, not as a universal commercial selection standard: the source is an index for UK public digital services, not a detailed proposal checklist.
Architecture and integrations: what sits inside the system boundary, what remains in existing platforms and which interfaces must change? Request the rationale for technology choices, integration contracts, access assumptions and responsibility for failures across boundaries. A strong answer identifies decisions still requiring validation and assigns that work. “Integration included” remains incomplete without an interface definition and dependency owner.
Testing and security: which requirements will be verified, in which environments, with what evidence and by whom? NIST’s February 2022 Secure Software Development Framework, version 1.1, supports purchaser–supplier acquisition discussions through a common vocabulary. Use it to discuss secure-development practices, then ask for the evidence relevant to your system. Naming the framework does not demonstrate those practices or guarantee a secure outcome.
For web work, make accessibility part of that acceptance discussion. W3C’s WCAG 2.2 recommendation, dated 12 December 2024, describes testable success criteria and testing through a combination of automated testing and human evaluation. Agree the web-accessibility target, evaluation approach and remediation responsibility. An automated report alone leaves the human-evaluation component unanswered; the cited guidance does not choose a conformance level for your engagement.
Maintenance and handover: who handles defects, dependency updates, deployment, monitoring and incidents after acceptance? Specify the source code, build configuration, documentation and access your team will receive, together with the applicable rights. Ask how the receiving team will demonstrate that it can build, deploy and operate the agreed system. Keep repository access, IP rights and operational readiness as separate review items. Do not close all three on a promise to deliver source code.
Design proposals: follow the workflow into implementation
Review design scope against the decisions it must resolve, rather than screen count alone. Ask what discovery will investigate, which users and stakeholders will participate, who arranges access and how findings will affect the design. Look for a connection between research activities and decisions. If discovery is excluded, record which assumptions you are accepting. These are recommended scope checks, not an independently established standard for evaluating design agencies.
Flows and interaction states: which end-to-end user flows are included, and what will be specified for errors, empty states, permissions and recovery? Ask how the scope handles transitions across teams or systems. Seek a bounded inventory and a validation approach. If only the primary path is covered, assign responsibility for the remaining behaviour before approving the scope.
Design systems and implementation: will the team use, extend or create a design system, and who approves changes? Ask which component behaviours and usage guidance will be delivered, then establish the engineering reviews and implementation support included in the fee. A useful answer names the collaboration points, the receiving owner and the limits of support. “Design system included” leaves component scope and implementation responsibility unresolved.
Accessible design: for web work, carry the WCAG acceptance discussion across the design–engineering boundary. Ask which accessibility decisions will be checked during design, which require evaluation of implemented content and who resolves discrepancies. WCAG’s testable criteria and combined automated and human evaluation approach support that discussion, but do not establish a review standard for every type of design engagement.
Deliverable ownership: exactly which editable files, libraries, research outputs and specifications will transfer, with what permissions and third-party restrictions? Establish who can modify them after the engagement and who receives the handover. Put the agreed terms into the contract; do not infer editable-file delivery, unrestricted reuse or IP assignment from the word “deliverables”.
AI proposals: test the mechanism, not the demo
Start with necessity: which workflow task requires AI, and what would a non-AI approach leave unsolved? Ask for a comparison against the intended outcome, operating constraints and evaluation burden. Look for a specific job and a defined limit on the system’s authority. If the rationale remains unclear, defer commitment to the mechanism rather than designing acceptance criteria around an unexplained choice.
Data access and quality: the Guidelines for AI Procurement white paper hosted by NIST recommends identifying known data limitations in the RFP, requiring tenderers to explain mitigation strategies and considering governance and relevant-data availability from the start. Ask what data the vendor needs, whether access is authorised and how proposed mitigations will be verified. An answer should expose dependencies and decision points, not merely promise to clean the data. The guidance does not establish which mitigation will be adequate for your use case.
Acceptance and ongoing measurement: the same guidance asks about appropriate accuracy criteria, user understanding of outputs, transparency and post-deployment measurement. Translate those concerns into a workflow-specific evaluation plan. Which tasks and operating conditions will be tested? Which failure types matter? Who sets the acceptance thresholds, what evidence permits deployment, and what will administrators measure afterwards? Request a user-training and output-transparency plan alongside performance evidence. The guidance supplies no universal numerical thresholds.
For trustworthiness claims, ask how the testing methods complement one another. NIST’s ARIA Evaluation Planning Manual, published on 18 September 2026, describes combining model testing, red teaming and user testing. Request the evidence each will produce and the limitations that will remain. Their inclusion does not establish that an evaluation is sufficient for every system. As a review rule, do not let a demo or unexplained aggregate metric settle acceptance.
Failure paths and human review: ask what happens when an output is unavailable, unsuitable or disputed. Which actions require approval, who can override or stop the system, and what information will reviewers receive? These are recommended operating-model checks. Seek explicit routing, authority and fallback responsibilities. Leave “human-in-the-loop” unresolved until the proposal names the role, the intervention point and the work that person must perform.
Model dependencies and cost: identify the models, providers and hosted services the solution relies on. Ask which changes require re-evaluation, what can transfer at exit and which rights you will have to configuration, evaluation assets and operational data. Request usage-cost assumptions, monitoring responsibilities and an agreed response when cost limits are reached. Include human review and ongoing evaluation in the cost discussion. Treat these as commercial checks, not a requirement that every solution be provider-independent.
Turn answers into a decision record
For each material commitment, record the answer, evidence, accountable party and residual risk. Separate evidence already available from verification promised during delivery. Then classify the answer and record the action needed before commitment.
Boundary, owner and acceptance method are stated. Check the evidence.
Assign assumption validation and agree what happens if it fails.
Name the decision owner and record the disposition before commitment.
Assign excluded work elsewhere or revise the intended outcome.
Recommended decision categories, not vendor rankings.
Use answer status to determine the next action, not to assign a vendor score.Compare proposals against the same intended operating boundary. Make differences in exclusions, client effort and post-launch responsibility visible alongside price. You need not eliminate every uncertainty before selection, but distinguish what you are funding the vendor to resolve from what your organisation is agreeing to own.
What would we still be unable to operate, verify or hand over if this vendor left after launch?
