# Vendor Evaluation Scorecard: [Procurement or RFP name]

> Evaluation record for selecting a supplier from RFI or RFP responses:
> evaluation plan, evaluators and conflict of interest declarations,
> anchored scoring scale, knock-out criteria, weighted quality criteria,
> individual and consensus scores, demonstrations and proof of concept,
> reference checks, due diligence (financial, security, privacy,
> regulatory, roadmap, exit), price normalisation and scoring, combined
> ranking with sensitivity, risks and negotiation points, and the
> recommendation. Structure aligned with the supplier selection concerns
> of ISO/IEC/IEEE 41062:2024 (software acquisition) and the evaluation
> framework of ISO/IEC 25040:2024. Replace every `[bracketed]` value and
> every row marked *Example*. This is a documentation format, not legal
> or procurement advice; public bodies must follow their procurement law
> and rules, which take precedence.

<!--
Guidance: How to use this template
- Approve sections 1 to 6 (plan, team, scale, knock-outs, criteria and
  weights) before any response is opened. Weights changed after seeing
  responses are the main cause of challenged awards.
- Evaluate quality and price separately. Quality evaluators should not
  see prices until quality scores are moderated.
- Every score needs a short justification that cites the response
  section, demo or reference. A score without evidence cannot be
  defended in a debrief.
- Keep one copy of each evaluator's individual scores (section 7) as
  submitted. Consensus (section 8) is recorded separately; do not
  overwrite the individual sheets.
- The worked example evaluates cloud contact centre platforms for a
  250-agent service desk.
- Related documents: RFP (`business/rfp`), RFI (`business/rfi`), RFP
  Compliance Matrix (`business/rfp-compliance-matrix`), Demo Script
  (`business/demo-script`), Proof of Concept
  (`architecture/proof-of-concept`), Supplier Security Assessment
  (`compliance/supplier-security-assessment`), AI Vendor Risk
  Questionnaire (`compliance/ai-vendor-risk-questionnaire`), DORA ICT
  Third-Party Register (`compliance/dora-ict-third-party-register`),
  Build vs Buy Analysis (`architecture/build-vs-buy-analysis`),
  Technology Selection (`architecture/technology-selection`), Total Cost
  of Ownership Analysis (`architecture/tco-analysis`), Procurement Plan
  (`project/procurement-plan`).
-->

## Document control

<!-- Guidance: Identify the procurement, the evaluation panel and the approval route. Restrict distribution: scores and prices are commercially sensitive until award, and often afterwards. -->

| Field | Value |
|---|---|
| Document ID | [VES-001] |
| Procurement | [RFP ID and title] |
| Lot or scope | [Lot name] |
| Procurement route | [Open / Restricted / Negotiated / Framework call-off / Private sector competitive tender] |
| Responses received | [Number], closing date YYYY-MM-DD |
| Evaluation chair | [@procurement-lead] |
| Version | [0.1] |
| Status | [Plan approved / Evaluation in progress / Moderated / Recommended / Awarded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@procurement-lead], [@business-owner], [@security-architect], [@legal] |
| Last updated | YYYY-MM-DD |
| Classification | [Commercial in confidence, evaluation panel only] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Evaluation chair (plan, sections 1 to 6) | [@name] | [Approved before opening] | YYYY-MM-DD |
| Business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Procurement or sourcing board | [@name] | [Decision] | YYYY-MM-DD |
| Budget holder | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Evaluation plan, criteria and weights |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Plan approved and locked before responses opened |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Knock-out results, individual and consensus scores |
| 2.0 | YYYY-MM-DD | [@name] | *Example:* Recommendation after due diligence and best and final offers |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Evaluation scope and plan](#1-evaluation-scope-and-plan)
2. [Evaluation team and conflicts of interest](#2-evaluation-team-and-conflicts-of-interest)
3. [Scoring scale and rules](#3-scoring-scale-and-rules)
4. [Knock-out criteria](#4-knock-out-criteria)
5. [Weighted quality criteria](#5-weighted-quality-criteria)
6. [Price evaluation method](#6-price-evaluation-method)
7. [Individual scores](#7-individual-scores)
8. [Consensus scores](#8-consensus-scores)
9. [Demonstrations and proof of concept](#9-demonstrations-and-proof-of-concept)
10. [Reference checks](#10-reference-checks)
11. [Due diligence](#11-due-diligence)
12. [Price normalisation and scores](#12-price-normalisation-and-scores)
13. [Combined ranking and sensitivity](#13-combined-ranking-and-sensitivity)
14. [Risks and negotiation points](#14-risks-and-negotiation-points)
15. [Recommendation and debrief](#15-recommendation-and-debrief)
16. [Glossary and references](#16-glossary-and-references)

## 1. Evaluation scope and plan

<!-- Guidance: State what is being bought, the stages of the evaluation and the dates. Bidders should have been told the stages and the weighting in the RFP; this plan must match what they were told. -->

| Item | Value |
|---|---|
| Requirement | *Example:* Cloud contact centre platform (voice, chat, email, workforce management) for 250 agents in 3 countries |
| Contract | *Example:* 5 years, with optional 2-year extension |
| Budget envelope | *Example:* USD 1.6 million over 5 years (not disclosed to bidders) |
| Award basis | *Example:* Best value: quality 70%, price 30% |
| Bidders | *Example:* 4 responses: V1, V2, V3, V4 |

| Stage | Activity | Output | Dates |
|---|---|---|---|
| 0 | Plan, criteria and weights approved; evaluators briefed | This document v1.0 | YYYY-MM-DD |
| 1 | Compliance check (completeness, mandatory forms) | Section 4 | YYYY-MM-DD |
| 2 | Knock-out screening | Section 4 | YYYY-MM-DD |
| 3 | Individual written scoring | Section 7 | YYYY-MM-DD to YYYY-MM-DD |
| 4 | Moderation to consensus | Section 8 | YYYY-MM-DD |
| 5 | Scripted demonstrations and proof of concept (shortlist) | Section 9 | YYYY-MM-DD |
| 6 | References and due diligence | Sections 10, 11 | YYYY-MM-DD |
| 7 | Price opening and normalisation | Section 12 | YYYY-MM-DD |
| 8 | Best and final offer (if used) | Section 12 | YYYY-MM-DD |
| 9 | Recommendation and approval | Section 15 | YYYY-MM-DD |

```mermaid
flowchart LR
  A[Responses received] --> B[Compliance check]
  B --> C{Knock-outs passed?}
  C -- No --> X[Excluded, reason recorded]
  C -- Yes --> D[Individual scoring]
  D --> E[Moderation and consensus]
  E --> F[Demos and PoC for shortlist]
  F --> G[References and due diligence]
  G --> H[Price opening and normalisation]
  H --> I[Combined ranking and sensitivity]
  I --> J[Recommendation and approval]
```

## 2. Evaluation team and conflicts of interest

<!-- Guidance: Name each evaluator, the criteria they score and their declaration. Anyone with a financial, family or recent employment link to a bidder must declare it before seeing responses and is removed from scoring that bidder or the whole evaluation. -->

| Evaluator | Role | Criteria scored | Declaration signed | Conflict declared | Action |
|---|---|---|---|---|---|
| E1 *(Example)* | Contact centre operations manager | Q1, Q5 | YYYY-MM-DD | None | |
| E2 *(Example)* | Solution architect | Q1, Q2, Q4 | YYYY-MM-DD | None | |
| E3 *(Example)* | Security architect | Q1, Q3 | YYYY-MM-DD | None | |
| E4 *(Example)* | Integration lead | Q1, Q2, Q4 | YYYY-MM-DD | Former employee of V4, left 2 years ago | Declared; V4 excluded at knock-out, no further action |
| E5 *(Example)* | Commercial analyst | Price only (section 12) | YYYY-MM-DD | None | Does not see quality scores until moderated |
| Chair *(Example)* | Procurement lead | Does not score; runs moderation | YYYY-MM-DD | None | |

| Activity | Chair | Evaluators | Commercial analyst | Business owner | Legal |
|---|---|---|---|---|---|
| Approve plan and weights | R | C | C | A | C |
| Individual scoring | I | R | I | I | I |
| Moderation | R | C | I | I | I |
| Price evaluation | A | I | R | I | I |
| Due diligence | A | C | C | I | R |
| Recommendation | R | C | C | A | C |

R = responsible, A = accountable, C = consulted, I = informed.

## 3. Scoring scale and rules

<!-- Guidance: Anchor each score to observable evidence so two evaluators reading the same response give the same score. Publish the scale to bidders in the RFP. -->

| Score | Label | Anchor |
|---|---|---|
| 5 | Excellent | Fully meets the requirement with strong evidence; adds value beyond it with no material risk |
| 4 | Good | Fully meets the requirement with good evidence; minor weaknesses only |
| 3 | Acceptable | Meets the requirement; evidence adequate; some weaknesses or risks that are manageable |
| 2 | Weak | Partly meets the requirement; gaps or risks that need significant mitigation |
| 1 | Poor | Barely addresses the requirement; major gaps or unsupported claims |
| 0 | No response | Requirement not addressed |

Rules:

1. Score only what is in the response, the demo, the PoC or the references.
   Knowledge of the bidder from outside the process is not evidence.
2. Write a justification of at least one sentence for every score, citing
   the response section.
3. Score each criterion for all bidders before moving to the next
   criterion, to keep the scale consistent.
4. Clarification questions go through the chair, in writing, to all
   bidders where the answer could change their position.
5. Weighted points for a criterion are the criterion weight times the
   score divided by 5.

## 4. Knock-out criteria

<!-- Guidance: List the pass or fail conditions announced in the RFP. Apply them before scoring and record the evidence for every fail; a bidder excluded without recorded evidence is a challenge waiting to happen. -->

| ID | Knock-out criterion | Evidence required | V1 | V2 | V3 | V4 |
|---|---|---|---|---|---|---|
| KO-1 *(Example)* | Customer data stored and processed in the EU, including support access | Data processing annex, sub-processor list | Pass | Pass | Pass | Fail |
| KO-2 *(Example)* | Current ISO/IEC 27001 certificate or SOC 2 Type II report covering the service | Certificate or report | Pass | Pass | Pass | Pass |
| KO-3 *(Example)* | Accepts the mandatory contract terms (liability cap, audit rights, exit assistance) | Signed compliance statement | Pass | Pass | Pass | Pass |
| KO-4 *(Example)* | Native or API integration with the CRM in use | Documentation, reference | Pass | Pass | Pass | Pass |
| KO-5 *(Example)* | Response complete and on time | Compliance check | Pass | Pass | Pass | Pass |
| **Result** | | | **Continue** | **Continue** | **Continue** | **Excluded** |

*Example* note: V4's sub-processor list places tier 2 support in a
non-EU location with access to call recordings (response section 7.3),
which fails KO-1. The chair confirmed the reading with V4 by written
clarification CQ-09 on YYYY-MM-DD.

## 5. Weighted quality criteria

<!-- Guidance: Weights reflect what matters for this purchase and must sum to the quality share of the award (here 70). Split broad criteria into sub-criteria where evaluators need it, but keep the published weights. -->

| ID | Criterion | What good looks like | Weight | Evaluators |
|---|---|---|---|---|
| Q1 *(Example)* | Functional fit | Covers routing, omnichannel, workforce management and reporting requirements in RFP section 4 with little customisation | 25 | E1, E2, E3, E4 |
| Q2 *(Example)* | Integration and APIs | Documented APIs and events for CRM, identity and data platform; sandbox access | 12 | E2, E4 |
| Q3 *(Example)* | Security, privacy and compliance | Controls, certifications, data protection terms, recording security, AI feature transparency | 12 | E3 |
| Q4 *(Example)* | Non-functional qualities | Availability commitment, voice quality, scalability for seasonal peaks, regional resilience | 8 | E2, E4 |
| Q5 *(Example)* | Delivery approach and references | Credible plan, named team, migration method, similar customers | 8 | E1 |
| Q6 *(Example)* | Vendor viability and roadmap | Financial health, product investment, roadmap fit | 5 | E2 with input from section 11 |
| **Total quality** | | | **70** | |

## 6. Price evaluation method

<!-- Guidance: Fix how prices become a score before prices are opened. Normalise every bid to the same volumes, term and scope so that you compare like with like. -->

Price is scored on the normalised 5-year total cost of each bid
(section 12). The lowest normalised cost $C_{min}$ receives the full
price weight $W_p$; others receive a proportional score:

$$
P_v = W_p \times \frac{C_{min}}{C_v}
$$

| Rule | Value |
|---|---|
| Price weight $W_p$ | *Example:* 30 |
| Volume basis | *Example:* 250 named agents for 60 months, 2 supervisors per 25 agents included in the agent price |
| Included | *Example:* Subscription, telephony bundles, implementation, data migration, training, premium support |
| Excluded | *Example:* Call minutes beyond the bundle (priced separately at the same assumed volume for all bidders), taxes |
| Abnormally low bids | *Example:* A bid more than 30% below the average is investigated in writing before scoring |
| Best and final offer | *Example:* Allowed once, for the top two bidders, on price and contract terms only |

The ratio method is simple and widely used, but it makes each bidder's
score depend on the lowest bid. If that is a concern, use a method fixed
against the budget envelope instead, and state it in the RFP.

## 7. Individual scores

<!-- Guidance: Each evaluator scores alone and submits before moderation. Record the raw scores here, then flag every criterion where the range between evaluators is 2 or more points; those go first in moderation. -->

| Criterion | Bidder | E1 | E2 | E3 | E4 | Mean | Range | Moderation needed |
|---|---|---|---|---|---|---|---|---|
| Q1 *(Example)* | V1 | 4 | 4 | 3 | 5 | 4.00 | 2 | Yes |
| Q1 *(Example)* | V2 | 3 | 3 | 3 | 4 | 3.25 | 1 | No |
| Q1 *(Example)* | V3 | 5 | 4 | 5 | 5 | 4.75 | 1 | No |
| Q2 *(Example)* | V1 | | 3 | | 3 | 3.00 | 0 | No |
| Q2 *(Example)* | V2 | | 5 | | 4 | 4.50 | 1 | No |
| Q2 *(Example)* | V3 | | 2 | | 4 | 3.00 | 2 | Yes |
| [Qn] | [Vn] | [ ] | [ ] | [ ] | [ ] | [ ] | [ ] | [Yes / No] |

Justification log (one row per score, kept in the evaluator's sheet):

| Evaluator | Criterion | Bidder | Score | Justification and evidence |
|---|---|---|---|---|
| E3 *(Example)* | Q1 | V1 | 3 | Workforce management is a partner add-on with a separate login (response 4.6); reporting meets RFP 4.9 |
| E4 *(Example)* | Q1 | V1 | 5 | All routing scenarios in RFP 4.2 shown natively in response 4.2 annex B |

## 8. Consensus scores

<!-- Guidance: In moderation, evaluators discuss evidence, not opinions, and agree one score per criterion and bidder. The consensus score is not the mean; record why it was chosen, especially where it differs from the mean. -->

| Criterion | Weight | V1 score | V1 points | V2 score | V2 points | V3 score | V3 points |
|---|---|---|---|---|---|---|---|
| Q1 Functional fit | 25 | 4 | 20.0 | 3 | 15.0 | 5 | 25.0 |
| Q2 Integration and APIs | 12 | 3 | 7.2 | 5 | 12.0 | 3 | 7.2 |
| Q3 Security, privacy and compliance | 12 | 4 | 9.6 | 4 | 9.6 | 3 | 7.2 |
| Q4 Non-functional qualities | 8 | 4 | 6.4 | 3 | 4.8 | 4 | 6.4 |
| Q5 Delivery approach and references | 8 | 3 | 4.8 | 4 | 6.4 | 4 | 6.4 |
| Q6 Vendor viability and roadmap | 5 | 4 | 4.0 | 3 | 3.0 | 4 | 4.0 |
| **Quality total (of 70)** | **70** | | **52.0** | | **50.8** | | **56.2** |

*Example* arithmetic: points = weight x score / 5, so V3 Q1 is 25 x 5 / 5
= 25.0 and V2 Q4 is 8 x 3 / 5 = 4.8.

| Moderation item | Individual range | Consensus | Rationale |
|---|---|---|---|
| Q1 V1 *(Example)* | 3 to 5 | 4 | Panel agreed that the partner add-on for workforce management meets the requirement but adds a second login; core routing is strong |
| Q2 V2 *(Example)* | 4 to 5 (not flagged; reviewed because the consensus differs from the mean 4.50) | 5 | Response section 5 documents an event stream, webhooks and self-service sandbox access; API coverage exceeds RFP section 5. The PoC in section 9 later tests this claim |
| Q2 V3 *(Example)* | 2 to 4 | 3 | APIs adequate; no event stream, polling needed for real-time agent state (response 5.4) |

## 9. Demonstrations and proof of concept

<!-- Guidance: Give every shortlisted bidder the same script, data and time. Score demos against the same criteria as the written response, using the demo to confirm or correct the written score, not to add new criteria. -->

| Item | Value |
|---|---|
| Shortlist | *Example:* V1, V2, V3 (all bidders that passed knock-outs) |
| Script | *Example:* Demo Script DS-03 (`business/demo-script`), 6 scenarios, 2 hours per bidder |
| PoC scope | *Example:* CRM screen pop and call recording export in our sandbox, 2 weeks, for V2 and V3, whose responses relied on screen pop features released in the last 6 months |
| PoC success criteria | *Example:* Screen pop within 1 second of answer in 95% of 200 test calls; recording export by API within 5 minutes |

| Scenario | V1 | V2 | V3 | Effect on score |
|---|---|---|---|---|
| DS-03-1 Inbound call with CRM screen pop *(Example)* | Shown | Shown | Shown | None |
| DS-03-4 Supervisor rebalances queues during a peak *(Example)* | Shown | Partly: manual steps | Shown | Confirms V2 Q1 score of 3 |
| PoC-1 Screen pop timing *(Example)* | Not in PoC | 0.6 s at p95 | 0.8 s at p95 | Confirms Q2 consensus |

## 10. Reference checks

<!-- Guidance: Call references the bidder did not choose as well as those they did, if the RFP allowed it. Ask the same questions of each, about delivery, service and the relationship, and record answers verbatim in your notes, summarised here. -->

| Bidder | Reference | Size and sector | Delivered on time? | Service quality | Would choose again? | Concerns raised |
|---|---|---|---|---|---|---|
| V1 *(Example)* | Retail bank, 400 agents | Similar | 2 weeks late | Good; 1 major outage in 2 years | Yes | Workforce management add-on support is slow |
| V2 *(Example)* | Utility, 300 agents | Similar | Yes | Good | Yes | Supervisor tools less mature |
| V3 *(Example)* | Insurer, 220 agents | Similar | 3 months late | Very good after go-live | Yes | Implementation team turnover |

## 11. Due diligence

<!-- Guidance: Check what the scorecard cannot: whether the supplier will survive the contract, protect the data, meet regulation, and let you leave. Run the detailed questionnaires in their own templates and record the conclusions here. -->

| Area | Check | V1 | V2 | V3 | Source |
|---|---|---|---|---|---|
| Financial viability | Credit report, audited accounts, funding | *Example:* Stable, profitable | *Example:* Stable, listed company | *Example:* Venture funded, 3 years of runway reported | Credit agency report YYYY-MM-DD |
| Information security | Supplier security assessment | *Example:* Low residual risk | *Example:* Low | *Example:* Medium: penetration test findings open | `compliance/supplier-security-assessment` |
| Privacy | Data processing terms, sub-processors, transfers | *Example:* Acceptable | *Example:* Acceptable | *Example:* Acceptable | DPIA reference |
| AI features | Transparency, training on customer data, opt-out | *Example:* Opt-out by contract | *Example:* No training on customer data | *Example:* Opt-in only | `compliance/ai-vendor-risk-questionnaire` |
| Regulatory (if applicable) | For a financial entity, ICT third-party register entry and contract terms required by DORA | [ ] | [ ] | [ ] | `compliance/dora-ict-third-party-register` |
| Roadmap | Commitments relevant to our needs | *Example:* Native workforce management in 12 months | *Example:* Supervisor tooling upgrade announced | *Example:* Strong | Roadmap briefings under NDA |
| Exit | Data export formats, exit assistance, notice | *Example:* Full export, 6 months assistance | *Example:* Full export, 12 months assistance | *Example:* Export of recordings only on request | Response section 9 |
| Supply chain | Key sub-processors and their locations | *Example:* 3 sub-processors, all EU | *Example:* 4, all EU | *Example:* 2, all EU | Sub-processor lists |

Outcome: [*Example:* No bidder excluded at due diligence. V3's open
penetration test findings and runway are carried as risks in section
14.]

## 12. Price normalisation and scores

<!-- Guidance: Open prices only after quality scores are moderated. Convert every bid to the same basis, show the arithmetic, then apply the method in section 6. -->

All figures in USD thousand over 60 months, *Example* values.

| Price component | V1 | V2 | V3 |
|---|---|---|---|
| Agent subscription per agent per month (USD) | 95 | 75 | 105 |
| Subscription, 250 agents x 60 months | 1,425 | 1,125 | 1,575 |
| Telephony bundles and premium support (included in the agent price for V1 to V3, confirmed in each price schedule) | 0 | 0 | 0 |
| Implementation, migration and training (one-time) | 25 | 55 | 45 |
| **Normalised 5-year cost $C_v$** | **1,450** | **1,180** | **1,620** |
| Price score $P_v = 30 \times 1180 / C_v$ | 24.41 | 30.00 | 21.85 |

*Example* arithmetic: 250 x 60 = 15,000 agent-months; V1 is 15,000 x 95 =
USD 1,425,000. V1 price score is 30 x 1,180 / 1,450 = 24.41, and V3 is 30
x 1,180 / 1,620 = 21.85. V1 and V2 are inside the USD 1.6 million
envelope; V3 (1.62 million) is 1.25% over and is flagged to the budget
holder.

## 13. Combined ranking and sensitivity

<!-- Guidance: Add quality points and price score, rank, then test whether a reasonable change in the quality and price split changes the winner. A small gap or a ranking that flips means the decision rests on judgement: say so and use the best and final offer or negotiation to resolve it. -->

| Bidder | Quality (of 70) | Price (of 30) | Total (of 100) | Rank |
|---|---|---|---|---|
| V1 | 52.0 | 24.41 | 76.41 | 3 |
| V2 | 50.8 | 30.00 | 80.80 | 1 |
| V3 | 56.2 | 21.85 | 78.05 | 2 |

| Scenario | V1 | V2 | V3 | Leader |
|---|---|---|---|---|
| Baseline 70 / 30 | 76.41 | 80.80 | 78.05 | V2 |
| *Example:* 80 / 20 | 75.70 | 78.06 | 78.80 | V3 |
| *Example:* 60 / 40 | 77.12 | 83.54 | 77.31 | V2 |
| *Example:* V3 lowers price by 10% at best and final offer (70 / 30) | 76.41 | 80.80 | 80.48 | V2 |

*Example* arithmetic for 80 / 20: quality points are scaled by 80 / 70
and price points by 20 / 30, so V3 is 56.2 x 80 / 70 + 21.85 x 20 / 30 =
64.23 + 14.57 = 78.80. For the last row, V3's cost becomes 1,458 and its
price score 30 x 1,180 / 1,458 = 24.28, giving 56.2 + 24.28 = 80.48.

*Example* reading: V2 leads at the published 70 / 30 split by 2.75
points, but V3 leads if quality is weighted more. The published weights
govern the award; the sensitivity shows that the result is close and that
V2's weaker supervisor tooling (Q1) should be addressed in negotiation.

## 14. Risks and negotiation points

<!-- Guidance: Carry forward the weaknesses found in scoring, demos, references and due diligence, and turn each into either a contract term, a delivery mitigation or an accepted risk. -->

| ID | Bidder | Risk or gap | Source | Treatment | Owner |
|---|---|---|---|---|---|
| VES-RSK-001 *(Example)* | V2 | Supervisor queue tools need manual steps | Demo DS-03-4, Q1 | Contractual roadmap commitment with service credit if not delivered in 9 months | @procurement-lead |
| VES-RSK-002 *(Example)* | V2 | Availability commitment 99.9% versus target 99.95% | Q4 | Negotiate 99.95% for voice routing, or accept with credits | @solution-architect |
| VES-RSK-003 *(Example)* | V3 | Venture funded; implementation team turnover | Section 11, reference | Escrow of configuration exports; named key personnel clause | @legal |
| VES-RSK-004 *(Example)* | All | Price increase at renewal | Commercial review | Cap of [x]% per year in the contract | @procurement-lead |

## 15. Recommendation and debrief

<!-- Guidance: Recommend the bidder with the highest combined score under the published method, unless due diligence found a reason recorded in section 11. State the conditions, then plan debriefs that explain each bidder's scores against the criteria without disclosing other bidders' confidential information. -->

| Item | Value |
|---|---|
| Recommended bidder | *Example:* V2, total 80.80 |
| Basis | *Example:* Highest combined score under the published 70 / 30 method; passed all knock-outs and due diligence |
| Conditions of award | *Example:* VES-RSK-001 and VES-RSK-002 resolved in contract; PoC results confirmed in acceptance tests |
| Reserve bidder | *Example:* V3, total 78.05 |
| Standstill or notice period | [*Example:* 10 days, if the procurement rules require one] |
| Approval | [Approved / Approved with conditions / Rejected], [@approver], YYYY-MM-DD |

| Bidder | Debrief date | Strengths noted | Weaknesses noted | Delivered by |
|---|---|---|---|---|
| V1 *(Example)* | YYYY-MM-DD | Routing, security controls | Workforce management add-on, delivery plan detail | @procurement-lead, @solution-architect |
| V3 *(Example)* | YYYY-MM-DD | Functional fit, references | Integration events, price | @procurement-lead, @solution-architect |
| V4 *(Example)* | YYYY-MM-DD | Not scored | Failed KO-1, with the evidence cited | @procurement-lead |

## 16. Glossary and references

<!-- Guidance: Define the evaluation terms used and list the procurement documents and standards with versions. -->

### 16.1 Glossary

| Term | Meaning in this template |
|---|---|
| Knock-out criterion | Pass or fail condition; failing it excludes the bid before scoring |
| Weighted criterion | Scored criterion whose points depend on its weight and score |
| Consensus score | Single score per criterion and bidder agreed in moderation, with recorded rationale |
| Moderation | Meeting where evaluators reconcile individual scores using the evidence |
| Normalised cost | Bid price converted to a common volume, term and scope for comparison |
| Best and final offer | Final revised offer requested from shortlisted bidders, within published rules |
| Debrief | Explanation to a bidder of how its bid was scored |
| Standstill period | Pause between award notice and contract signature in some procurement regimes |

### 16.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| ISO/IEC/IEEE 41062:2024, Software engineering, Life cycle processes, Software acquisition, iso.org and standards.ieee.org | Edition 2, published October 2024 | Supplier selection concerns (structure only) |
| ISO/IEC 25040:2024, Quality evaluation framework, iso.org | Edition 2, September 2024 | Planned, criteria-based evaluation (structure only) |
| ISO/IEC 25010:2023, Product quality model, iso.org | Edition 2, November 2023 | Vocabulary for Q4 non-functional qualities |
| NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, csrc.nist.gov | May 2022, updated 1 November 2024 | Supply chain due diligence topics in section 11 |
| [RFP document and addenda] | [ID, version] | Published criteria and weights |
| [Procurement policy or law that applies] | [Version] | Process rules that take precedence |

## Standard and licence note

Structure aligned with the supplier selection concerns of
ISO/IEC/IEEE 41062:2024 and the quality evaluation framework of ISO/IEC
25040:2024, which are copyrighted standards: only their numbers and
titles are used and no clause text, tables or definitions are
reproduced. Supply chain due diligence topics are based on NIST SP
800-161 Rev. 1 (public domain in the United States). The scoring scale,
price formula, moderation rules and all other text are original and
follow common procurement practice; figures in the worked example are
illustrative. Check the current editions at iso.org and csrc.nist.gov
and the procurement rules that apply to you. This is a documentation
format, not legal advice. Template licence: MIT.