# RFP Technical Response: [Bid name] for [Client name]

> Bidder-side technical volume answering a Request for Proposal: the customer's problem in their own
> terms, win themes with proof, the proposed solution and its architecture, functional and
> non-functional coverage, security and compliance, implementation, team, transition to service,
> assumptions and risks, case studies and the link to the compliance matrix. Structure aligned with
> common proposal practice as described in the APMP Body of Knowledge and the Shipley Proposal
> Guide, and with the acquirer's view of supplier selection in ISO/IEC/IEEE 41062:2024 (software
> acquisition). Quality attributes follow the ISO/IEC 25010:2023 product quality model. Replace
> every `[bracketed]` value and every row marked *Example*; the worked example answers an RFP for an
> account-based ticketing back office for a regional transit authority.

<!--
Guidance: How to use this template
- Build the compliance matrix first (RFP Compliance Matrix, `business/rfp-compliance-matrix`).
  Every heading here answers at least one requirement ID, and every ID points to a heading.
- Follow the issuer's instructions over this template. If the RFP prescribes section order, page
  limits or a response form, renumber this outline to match. Evaluators score their own structure.
- Write the executive summary and win themes first, then rewrite them last. Each win theme must
  reappear, with proof, in the sections that evaluators score.
- Keep price out of this volume unless the RFP asks for it here. The commercial volume (Business
  Proposal, `business/business-proposal`) and Solution Estimate (`project/solution-estimate`)
  carry the numbers; this volume carries the scope they price.
- Section 17 is for the bid team only. Delete it before submission.
- Related: Request for Proposal (`business/rfp`), Opportunity Qualification
  (`business/opportunity-qualification`), Bill of Materials (`business/bill-of-materials`),
  Statement of Work (`business/statement-of-work`), Demo Script (`business/demo-script`),
  Solution Architecture Document (`architecture/solution-architecture`), NFR Catalogue
  (`requirements/nfr-catalogue`), RAID Log (`project/raid-log`).
-->

## Document control

<!-- Guidance: Identify the opportunity, the exact RFP version and addenda you answer, and the volume. A response that ignores an addendum can be ruled non-compliant before it is read. -->

| Field | Value |
|---|---|
| Document ID | [RTR-001] |
| Opportunity ID | [OPP-YYYY-NNN] |
| RFP reference | [Issuer reference], version [x], addenda [1 to n] acknowledged |
| Issuer | [Client name, procuring unit] |
| Volume | [Technical volume / Volume 2 of 4] |
| Submission deadline | YYYY-MM-DD HH:MM [time zone] |
| Page limit and format | [Limit, font, margins, file type as instructed] |
| Version | [0.1] |
| Status | [Draft / Pink team / Red team / Gold team / Submitted] |
| Owner | [@bid-manager] |
| Solution lead | [@solution-architect] |
| Approvers/reviewers | [@sales-lead], [@delivery-lead], [@legal], [@security-lead], [@executive-sponsor] |
| Last updated | YYYY-MM-DD |
| Classification | [Commercial in confidence; supplier proprietary] |

### Approvals

| Gate | Role | Name | Decision | Date |
|---|---|---|---|---|
| Solution review | Chief or lead architect | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Red team | Independent review lead | [@name] | [Decision] | YYYY-MM-DD |
| Legal and contracts | Contracts manager | [@name] | [Decision] | YYYY-MM-DD |
| Final bid approval | Executive sponsor | [@name] | [Bid / No bid / Bid with conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Storyboard and section owners assigned |
| 0.9 | YYYY-MM-DD | [@name] | *Example:* Red team comments resolved; addendum 2 answered |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Submitted version |

## Contents

1. [Response overview and instructions compliance](#1-response-overview-and-instructions-compliance)
2. [Executive summary](#2-executive-summary)
3. [Understanding of the requirement](#3-understanding-of-the-requirement)
4. [Proposed solution overview](#4-proposed-solution-overview)
5. [Solution architecture](#5-solution-architecture)
6. [Functional coverage](#6-functional-coverage)
7. [Non-functional approach](#7-non-functional-approach)
8. [Security, privacy and compliance](#8-security-privacy-and-compliance)
9. [Implementation approach and plan](#9-implementation-approach-and-plan)
10. [Integration, data migration and cutover](#10-integration-data-migration-and-cutover)
11. [Team, governance and client responsibilities](#11-team-governance-and-client-responsibilities)
12. [Transition, service and support](#12-transition-service-and-support)
13. [Assumptions, exclusions and dependencies](#13-assumptions-exclusions-and-dependencies)
14. [Risks and mitigations](#14-risks-and-mitigations)
15. [Relevant experience and case studies](#15-relevant-experience-and-case-studies)
16. [Compliance matrix and deviations](#16-compliance-matrix-and-deviations)
17. [Bid team review checklist](#17-bid-team-review-checklist)
18. [Glossary and references](#18-glossary-and-references)

## 1. Response overview and instructions compliance

<!-- Guidance: Show the evaluator in one page that you followed every instruction and where each scored item is answered. Questions: which instruction section and evaluation criterion does each part of this volume answer? Pitfall: a beautiful response that breaks the page limit or the file naming rule and is never scored. -->

This volume is [Bidder name]'s technical response to [Client name] RFP [reference], including
addenda [1 to n]. It describes the solution, how it will be delivered and run, and the evidence that
it will work. Prices appear only in the commercial volume.

### 1.1 Volume map to the issuer's instructions and evaluation criteria

| RFP instruction or form | Evaluation criterion | Answered in | Page budget |
|---|---|---|---|
| *Example:* Instructions 4.2 Technical solution | Criterion T1 Solution fit (30%) | Sections 4 to 6 | 12 pages |
| *Example:* Instructions 4.3 Non-functional and security | Criterion T2 Quality and security (20%) | Sections 7 and 8 | 8 pages |
| *Example:* Instructions 4.4 Delivery approach | Criterion T3 Delivery and risk (20%) | Sections 9, 10, 13, 14 | 10 pages |
| *Example:* Instructions 4.5 Team and service | Criterion T4 Team and service (15%) | Sections 11 and 12 | 6 pages |
| *Example:* Instructions 4.6 Experience | Criterion T5 Experience (15%) | Section 15 | 4 pages |
| [Instruction] | [Criterion and weight] | [Section] | [Pages] |

### 1.2 Submission compliance

| Check | Requirement in the RFP | Status |
|---|---|---|
| *Example:* Format | PDF, A4, 11-point minimum, 40 pages maximum for this volume | Met: 39 pages |
| *Example:* Mandatory forms | Form B (declaration), Form D (requirement response sheet) completed | Met |
| *Example:* Addenda | Addenda 1 and 2 acknowledged on Form A | Met |
| [Check] | [Requirement] | [Met / Not met with reason] |

## 2. Executive summary

<!-- Guidance: Write for the decision maker who reads only this section. Lead with the client's outcome, not your company history. Questions: what does the client want to achieve, why is our solution the safest way to get there, and what proof do we offer? Close with the three facts that make delivery credible: a reference, a named team and a de-risking step such as a pilot. Pitfall: generic claims ("leading", "innovative") with no evidence an evaluator can score. -->

### 2.1 Objective and solution in two paragraphs

[Restate the client's goal, the deadline that matters to them and how they will measure success,
using their vocabulary.] *Example:* The authority wants every rider to tap a bank card or a mobile
wallet on any bus or tram from the start of the 2028 timetable year, with fares capped daily and
weekly, and wants to retire the closed smartcard back office before its support contract ends.

[Summarise what you propose, how it is delivered and the main benefit.] *Example:* We propose an
account-based ticketing back office running as a managed service in two cloud regions within the
country, integrated with the authority's existing validators through their published interface,
delivered in three releases over about 15 months including hypercare, with fare capping live in
release 1 on the pilot routes.

### 2.2 Win themes

<!-- Guidance: Three to five themes. Each one links a client hot button to a feature, the benefit to the client, a proof point the evaluator can check, and why a competitor cannot easily say the same (the discriminator). -->

| ID | Client hot button | Feature | Benefit to the client | Proof | Discriminator |
|---|---|---|---|---|---|
| WT-001 *(Example)* | Go-live before the smartcard support contract ends | Release plan with fare capping live on pilot routes in month 7 | Risk of running two back offices beyond the deadline is removed | Same release pattern delivered for [Reference client] in 11 months (case study CS-001) | Only bidder with a production pilot of the same validator interface |
| WT-002 *(Example)* | Rider data must stay in the country | Both regions in-country; keys held in the authority's HSM tenancy | Meets the data residency clause without exceptions | ISO/IEC 27001:2022 certificate whose scope covers both regions (Appendix C) | No cross-border support access; 24 by 7 support is delivered from in-country teams only |
| WT-003 *(Example)* | Fare policy changes take months today | Fare rules as configuration, tested in a simulator | Fare changes in days, tested against last month's journeys | Demonstration scenario D-04 in the demo script | Simulator replays real tap data before a rule is published |
| [WT-NNN] | [Hot button] | [Feature] | [Benefit] | [Proof] | [Discriminator] |

## 3. Understanding of the requirement

<!-- Guidance: Prove that you understood the problem before you describe the answer. Questions: what is the current state, what drives the change, what constraints bind it, and how will success be measured? Pitfall: copying the RFP background back to the client; add insight they did not write down. -->

### 3.1 Current situation

[Describe the client's current process, systems and pain points as you understand them from the RFP,
the bidders' conference and any discovery sessions.] *Example:* Riders top up a closed smartcard at
140 retail agents; the back office is a single on-premises system whose vendor ends support in March
2028; fare changes need a vendor release; card reader firmware is managed by a separate supplier.

### 3.2 Drivers and desired outcomes

| ID | Driver | Outcome the client expects | How it will be measured |
|---|---|---|---|
| DRV-001 *(Example)* | End of support of the current back office | Old system switched off | Decommission date met; no dual running after month 20 |
| DRV-002 *(Example)* | Rider convenience | Open-loop payment on all routes | Share of journeys paid by bank card or wallet |
| DRV-003 *(Example)* | Fare policy agility | Fare changes without code releases | Lead time for a fare change from approval to live |
| [DRV-NNN] | [Driver] | [Outcome] | [Measure] |

### 3.3 Constraints and implied requirements

List what binds the solution and what the RFP implies without saying it; competitors miss these.

| Type | Constraint or implied requirement | Source | Our response |
|---|---|---|---|
| *Example:* Regulatory | Card payment environment in PCI DSS scope | RFP 6.3 | Section 8.3; PSP tokenisation keeps card data out of the back office and reduces the authority's PCI DSS scope; validators and any component that handles the PAN stay in scope |
| *Example:* Implied | Validators cannot be replaced in this contract | RFP 2.1 states the validator contract runs to 2030 | Section 10.1, integration through the existing interface |
| [Type] | [Constraint] | [Source] | [Section] |

*Example* of a question that shaped the solution: capping runs in the back office, not on
validators, because validators are offline for up to 10 minutes in two tunnels and caps must be
right when taps arrive late.

## 4. Proposed solution overview

<!-- Guidance: Give the evaluator the whole picture on one page before the detail. Questions: what is in scope, what are the main building blocks, who uses them and what is reused versus built? Pitfall: listing products without saying what each one does for the client. -->

### 4.1 Scope of the proposed solution

| In scope | Out of scope (and who provides it) |
|---|---|
| *Example:* Account-based back office, fare engine, rider web and app accounts, customer service console | Validators and their firmware (existing validator supplier) |
| *Example:* Payment gateway integration and tokenisation | Acquiring bank contract (authority) |
| *Example:* Reporting and revenue apportionment data feed | Finance system changes (authority's ERP partner) |
| [Item] | [Item and owner] |

### 4.2 Solution context

Show every actor and external system named in the RFP, and who supplies each one.

```mermaid
flowchart LR
  rider[Rider: card, wallet or app] --> val[Existing validators]
  val -->|tap events| abt[Account-based back office]
  abt --> fare[Fare engine and capping]
  abt --> pay[Payment gateway and tokenisation]
  pay --> acq[Acquirer]
  abt --> crm[Customer service console]
  abt --> app[Rider web and mobile account]
  abt --> rep[Reporting and apportionment feed]
  rep --> erp[Authority ERP]
```

### 4.3 Building blocks

| Building block | What it does for the client | Delivery type | Reference to detail |
|---|---|---|---|
| *Example:* Tap ingestion | Receives and de-duplicates taps from all validators, including late offline batches | Configured product | Section 5.2 |
| *Example:* Fare engine | Prices journeys, applies caps and concessions | Configured product with fare rules as data | Section 6.2 |
| *Example:* Apportionment feed | Daily revenue file per operator | Custom extension | Section 6.1 |
| [Block] | [Purpose] | [Product / Configured / Extension / Custom / Third party] | [Section] |

## 5. Solution architecture

<!-- Guidance: Give evaluators enough architecture to trust the design and enough traceability to score it. Questions: which views matter for this client (logical, integration, data, deployment), which decisions are significant and why, and how does the design respect the client's principles? Pitfall: pasting a generic product diagram that does not show the client's systems. -->

### 5.1 Architecture principles applied

| Client principle (from the RFP) | How the solution applies it |
|---|---|
| *Example:* Cloud first, in-country hosting | Managed service in two in-country regions; no data leaves the country |
| *Example:* Open standards for integration | Published REST and event interfaces; contract tests delivered with the code |
| [Principle] | [Application] |

### 5.2 Logical and integration view

[Describe the main components, their responsibilities and how they interact. Show every external
system named in the RFP.]

```mermaid
sequenceDiagram
  participant V as Validator
  participant I as Tap ingestion
  participant F as Fare engine
  participant P as Payment gateway
  participant A as Rider account
  V->>I: Tap event (token, time, location)
  I->>P: First-tap card status check (deny list or nominal authorisation)
  I->>I: De-duplicate and order by device time
  I->>F: Journey candidate
  F->>F: Price journey and apply daily and weekly caps
  F->>P: Aggregate charge at end of travel day
  P-->>F: Authorisation result
  F->>A: Journey history and charge visible to the rider
```

### 5.3 Data view

| Data domain | Owner | Store and residency | Retention | Sensitive? |
|---|---|---|---|---|
| *Example:* Tap events | Authority | Event store, in-country, encrypted | 7 years for audit | Pseudonymous token only |
| *Example:* Rider accounts | Authority | Relational store, in-country | Until closure plus [n] years | Personal data |
| *Example:* Payment tokens | Payment service provider | PSP vault, outside the authority's environment | Per PSP terms | Card data never stored by the back office |
| [Domain] | [Owner] | [Store] | [Retention] | [Yes / No] |

### 5.4 Deployment view

[Describe regions, environments, network links to the client and who operates each layer.]

| Environment | Purpose | Hosting | Operated by |
|---|---|---|---|
| *Example:* Production | Live service | Two in-country regions, active-active | Bidder managed service |
| *Example:* Fare simulator | Fare rule testing on replayed taps | Single region | Authority fare team with bidder support |
| [Environment] | [Purpose] | [Hosting] | [Operator] |

### 5.5 Significant architecture decisions

| ID | Decision | Alternatives considered | Reason |
|---|---|---|---|
| AD-001 *(Example)* | Capping in the back office, not on validators | Validator-side capping | Late offline taps would make caps wrong; one source of truth |
| AD-002 *(Example)* | Tokenisation by the payment service provider | Back-office token vault | Keeps stored card data out of the back office and minimises the authority's PCI DSS scope |
| [AD-NNN] | [Decision] | [Alternatives] | [Reason] |

After award, carry these into the Architecture Decision Log (`architecture/architecture-decision-log`).

## 6. Functional coverage

<!-- Guidance: Summarise coverage by capability and let the compliance matrix carry the line-by-line answers. Questions: which capabilities are standard, configured, extended or custom, and what does the client see in each one? Pitfall: claiming "fully compliant" for everything; evaluators trust honest partial answers with a plan more than blanket claims. -->

Fit levels (Standard, Configured, Extended, Custom, Third party, Roadmap) are defined in the status
legend of the compliance matrix; use the same words here.

### 6.1 Coverage by capability

| Capability | Requirement IDs | Standard | Configured | Extended | Custom | Notes |
|---|---|---|---|---|---|---|
| *Example:* Fare calculation and capping | FR-010 to FR-028 | 14 | 5 | 0 | 0 | Concession rules configured with the fare team |
| *Example:* Rider account and refunds | FR-030 to FR-047 | 12 | 4 | 2 | 0 | Refund approval workflow extended |
| *Example:* Revenue apportionment | FR-060 to FR-066 | 2 | 1 | 0 | 4 | Operator split rules are client-specific |
| [Capability] | [IDs] | [n] | [n] | [n] | [n] | [Notes] |

### 6.2 Capability narratives

Per scored capability: what the user does, what the system does, the IDs answered, where it is shown.

*Example:* **Fare capping.** A rider taps the same card on a bus and a tram during the day. Each tap
is priced as it arrives; once the day's charges reach the daily cap, later journeys are priced at
zero and the rider's account shows "Capped today". Late offline taps are re-priced in device-time
order, so the result is identical whatever order taps arrive in. Answers FR-012, FR-013 and FR-019;
shown in demo scenario D-02.

## 7. Non-functional approach

<!-- Guidance: Answer each quality requirement with a target, the design approach and evidence. Use the client's numbers where the RFP gives them; propose numbers where it does not and say so. Questions: how will we prove each target before go-live? Pitfall: restating the requirement as the answer ("the system will be scalable"). -->

The table follows the product quality characteristics of ISO/IEC 25010:2023 so that no quality
concern is missed. Detailed targets are recorded in the NFR Catalogue
(`requirements/nfr-catalogue`).

| Characteristic | Client requirement or proposed target | Design approach | Evidence and verification |
|---|---|---|---|
| Functional suitability | *Example:* Fare results identical to the published fare table | Fare rules as data; regression suite of 2,000 priced journeys | Fare simulator report before each fare change |
| Performance efficiency | *Example:* Ingest peak of [n] taps per second; journey visible to rider within 60 seconds | Partitioned event ingestion; autoscaling consumers | Load test at twice the forecast peak in pre-production |
| Compatibility | *Example:* Works with existing validator interface version [x] | Adapter for the published interface; contract tests | Interoperability test with the validator supplier |
| Interaction capability | *Example:* WCAG 2.2 level AA for rider web and app | Accessible design system; screen reader testing | Accessibility conformance report (Appendix D) |
| Reliability | *Example:* 99.9% monthly availability for tap ingestion | Active-active across two regions; store-and-forward on validators | Failover test each quarter; availability report |
| Security | See section 8 | Defence in depth, least privilege, encryption | Penetration test before go-live; certifications |
| Maintainability | *Example:* Monthly releases without downtime | Blue-green deployment; automated tests | Release record from reference clients |
| Flexibility | *Example:* Add a new operator in under four weeks | Operator as configuration | Demonstration in pre-production |
| Safety | *Example:* Not applicable to this service; no safety function | | Statement only |
| [Characteristic] | [Target] | [Approach] | [Evidence] |

## 8. Security, privacy and compliance

<!-- Guidance: Answer the security questionnaire in its own form if the RFP provides one, and summarise the approach here. Questions: which certifications cover the delivering entity and locations, where does data live, who can access it, and what is the client's residual responsibility? Pitfall: citing a certificate whose scope does not cover the service or the sites proposed. -->

### 8.1 Certifications and attestations

| Certification or report | Scope covering this service? | Validity | Evidence |
|---|---|---|---|
| *Example:* ISO/IEC 27001:2022 | Yes: managed service operations and both regions | Valid to YYYY-MM-DD | Certificate, Appendix C |
| *Example:* SOC 2 Type II | Yes: back office platform | Report period YYYY-MM-DD to YYYY-MM-DD | Available under NDA |
| *Example:* PCI DSS v4.0.1 | Payment service provider is a Level 1 service provider | Attestation of Compliance dated YYYY-MM-DD | PSP AOC, Appendix C |
| [Certification] | [Scope] | [Validity] | [Evidence] |

### 8.2 Security approach

| Area | Approach |
|---|---|
| Identity and access | *Example:* Single sign-on for staff through the authority's identity provider; multi-factor authentication for all privileged access; access reviews every quarter |
| Data protection | *Example:* Encryption in transit and at rest; customer-managed keys held in the authority's key tenancy |
| Vulnerability management | *Example:* Continuous scanning; critical fixes within the time stated in the SLA |
| Logging and monitoring | *Example:* Security events forwarded to the authority's SOC in near real time |
| Secure development | *Example:* Threat modelling for each release, dependency scanning, signed builds |
| [Area] | [Approach] |

Reference the detailed design in Security Architecture (`security/security-architecture`) and the
threat model, Threat Model (`security/threat-model`), after award.

### 8.3 Privacy and data residency

[State the lawful basis relied on by the client, the processor role you take, the location of all
processing including support access, and how data subject requests are handled.] *Example:* All
rider data and backups stay in the two in-country regions; support engineers with production access
are based in the country; data subject requests are handled in the customer service console within
the deadlines set by the applicable data protection law. List each regulatory and accessibility
obligation with how it is met and the evidence. *Example:* PCI DSS v4.0.1: PSP tokenisation
minimises scope, while validators and any component that handles the PAN stay in scope and the
authority validates compliance as its acquirer directs (PSP AOC, section 5.3); WCAG 2.2 AA for rider
web and app (conformance report, Appendix D).

## 9. Implementation approach and plan

<!-- Guidance: Show a plan the evaluator believes, with the client's own milestones. Questions: which method, which releases, what does the client get at each milestone, what must the client provide and how is acceptance done? Pitfall: a plan with no client activities in it, which hides the client effort the evaluator knows exists. -->

[Describe the method: phases, iteration length, how scope is managed, how the client takes part.]
*Example:* A short mobilisation and design phase, then three releases built in two-week iterations,
each ending with a demonstration to the fare and customer service teams and a release decision by
the authority's steering group.

### 9.1 Plan and milestones

```mermaid
gantt
  title Example delivery plan
  dateFormat YYYY-MM-DD
  Mobilisation and discovery :m1, 2027-01-04, 6w
  Design and environments    :m2, after m1, 8w
  Build and test R1 pilot routes :r1, after m2, 16w
  Build and test R2 all routes :r2, after r1, 14w
  Build and test R3 retire legacy :r3, after r2, 12w
  Hypercare and handover     :h1, after r3, 8w
```

| Milestone | Week (month) *(Example)* | What the client receives | Acceptance criterion |
|---|---|---|---|
| M1 Design approved | 14 (3.2) | High-level design, test strategy, environments | Design authority sign-off |
| M2 Pilot live | 30 (6.9) | Open-loop payment and capping on pilot routes | Pilot exit criteria met for four weeks |
| M3 All routes live | 44 (10.1) | Service on every route and mode | Operational acceptance test passed |
| M4 Legacy retired | 56 (12.9) | Old back office switched off; data archived | Reconciliation signed off |
| [Milestone] | [Month] | [Deliverable] | [Criterion] |

Weeks are counted from contract start and summed from the gantt durations (6 + 8 = 14, plus 16 = 30,
plus 14 = 44, plus 12 = 56); months are weeks divided by 4.35. Hypercare ends at week 64. Recompute
both when you change durations.

List each deliverable with its format and the client's review time (*Example:* high-level design, 10
working days). The binding deliverable list and acceptance process move into the Statement of Work
(`business/statement-of-work`) after award.

## 10. Integration, data migration and cutover

<!-- Guidance: Integration and migration are where evaluators look for delivery risk. Questions: which interfaces exist, who changes what, which data moves, how is it reconciled and how is cutover done without losing revenue? Pitfall: assuming the client's other suppliers will change their systems at no cost and on your schedule. -->

### 10.1 Interfaces

| ID | Interface | Direction | Protocol and standard | Change needed by | Test approach |
|---|---|---|---|---|---|
| INT-001 *(Example)* | Validators to tap ingestion | Inbound | Validator supplier's published API v[x] | No change to validators | Contract tests and joint test with the validator supplier |
| INT-002 *(Example)* | Payment gateway | Outbound | PSP API | None | PSP certification process |
| INT-003 *(Example)* | Apportionment feed to ERP | Outbound | Daily file over SFTP | ERP partner adds an import job | End-to-end test with sample days |
| [INT-NNN] | [Interface] | [Direction] | [Protocol] | [Party] | [Test] |

### 10.2 Data migration

[Describe the data in scope, the source, the transformation, the number of rehearsals and the
reconciliation.] Use Data Migration Strategy (`architecture/data-migration-strategy`) for the
detailed approach after award. *Example:* Registered smartcard accounts and their balances move to
the new back office; three rehearsals; balance totals reconciled to the cent per account before each
cutover decision. [Explain how cutover happens: by route, by mode or all at once, the rollback
point, and how both systems run in parallel.] Plan detail goes into Cutover Plan
(`project/cutover-plan`).

## 11. Team, governance and client responsibilities

<!-- Guidance: Name the key people and show they are committed. Questions: who are the key personnel, what have they done before, how much of their time is committed, how are decisions and escalations handled, and what must the client provide? Pitfall: naming people who will not be available, or omitting client responsibilities that later become change requests. -->

### 11.1 Key personnel

| Role | Name | Relevant experience | Commitment | Location |
|---|---|---|---|---|
| *Example:* Engagement lead | [Name] | Led two ticketing back office programmes | 50% for the duration | In-country |
| *Example:* Solution architect | [Name] | Designed the reference solution at [Reference client] | 100% to month 12, then 25% | In-country |
| [Role] | [Name] | [Experience] | [Percentage and period] | [Location] |

CVs: Appendix [B]. [State the substitution rule, e.g. no key personnel change without consent.]

### 11.2 Governance

| Forum | Purpose | Frequency | Bidder attendees | Client attendees |
|---|---|---|---|---|
| *Example:* Steering group | Scope, release and risk decisions | Monthly | Engagement lead, delivery manager | Sponsor, head of fares, IT director |
| *Example:* Design authority | Architecture decisions and deviations | Every two weeks | Solution architect | Enterprise architect, security lead |
| [Forum] | [Purpose] | [Frequency] | [Attendees] | [Attendees] |

### 11.3 Responsibilities (RACI)

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

| Activity | Bidder | Client | Validator supplier | PSP |
|---|---|---|---|---|
| *Example:* Fare rules definition | C | A, R | I | I |
| *Example:* Back office build and test | A, R | C | I | I |
| *Example:* Validator interface testing | R | A | R | I |
| *Example:* Operational acceptance | R | A | C | C |
| [Activity] | [ ] | [ ] | [ ] | [ ] |

### 11.4 What we need from the client

| ID | Client responsibility | Needed by | Effort estimate *(Example)* |
|---|---|---|---|
| CR-001 *(Example)* | Product owner available three days a week | Month 1 | 0.6 FTE |
| CR-002 *(Example)* | Validator supplier engaged for the bench test and joint testing | Months 2 and 5 | Contract variation with the validator supplier |
| [CR-NNN] | [Responsibility] | [Date] | [Effort] |

## 12. Transition, service and support

<!-- Guidance: Show how the solution is run after go-live and who does what. Questions: what service levels do we offer, what support hours and channels, how is hypercare done and how does the client exit? Pitfall: offering service levels in this volume that differ from the commercial volume or the contract schedule. -->

[Describe the period of elevated support after each release, its exit criteria and the team (detail
in Hypercare Plan, `ops/hypercare-plan`), then how operations are handed over and how the client can
exit: data export formats, notice periods and assistance (see Operations Handover,
`ops/operations-handover`).]

### 12.1 Service levels offered

| Service measure | Offered level *(Example)* | Measurement |
|---|---|---|
| Tap ingestion availability | 99.9% per month | Synthetic and real tap monitoring |
| Priority 1 incident response | 15 minutes, 24 by 7 | Service desk timestamps |
| Priority 1 restoration target | 4 hours | Incident records |
| [Measure] | [Level] | [Measurement] |

The binding levels and service credits are in the Service Level Agreement
(`ops/service-level-agreement`); this table must match it.

## 13. Assumptions, exclusions and dependencies

<!-- Guidance: Every assumption is a potential change request; keep them few, specific and testable. Questions: what must be true for the scope and plan to hold, what is explicitly not included, and what do we depend on from others? Pitfall: so many assumptions that the evaluator scores the response as non-compliant. -->

| ID | Type | Statement | Impact if false | Owner |
|---|---|---|---|---|
| AS-001 *(Example)* | Assumption | Validators send taps through the published interface version [x] | Adapter rework; plan impact four weeks | Client |
| AS-002 *(Example)* | Assumption | Fare policy is frozen two months before each release | Re-test of fare rules | Client |
| EX-001 *(Example)* | Exclusion | Retail agent network changes | Not priced; available as an option | Bidder |
| DEP-001 *(Example)* | Dependency | Acquirer onboarding completed by month 6 | Pilot go-live moves | Client and PSP |
| [ID] | [Assumption / Exclusion / Dependency] | [Statement] | [Impact] | [Owner] |

Keep these identical to the commercial volume; carry them into the RAID Log (`project/raid-log`) at award.

## 14. Risks and mitigations

<!-- Guidance: Show the evaluator that you see the risks they worry about and have a plan. Questions: what could stop the client reaching the outcome, how likely is it, what do we do about it and who owns it? Pitfall: listing only risks to the bidder (margin, staffing) instead of risks to the client's outcome. -->

| ID | Risk to the client's outcome | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| RSK-001 *(Example)* | Validator interface behaves differently from its documentation | Medium | High | Bench test of the interface in month 2 with a loaned validator; joint test in month 5 | Bidder with validator supplier |
| RSK-002 *(Example)* | Riders unaware of the change at pilot launch | Medium | Medium | Communications plan with the authority's marketing team | Client |
| RSK-003 *(Example)* | Late fare policy decisions | High | Medium | Fare simulator available from month 3; decision deadlines in the plan | Client |
| [RSK-NNN] | [Risk] | [Low / Medium / High] | [Low / Medium / High] | [Mitigation] | [Owner] |

## 15. Relevant experience and case studies

<!-- Guidance: Pick references that match the client's scale, sector and risk, and that can be contacted. Questions: what was the problem, what did we deliver, what measurable result did the client get, and who can confirm it? Pitfall: case studies about a different product, or results the reference client will not confirm. -->

| ID | Client and sector | Scope delivered | Result | Reference contact |
|---|---|---|---|---|
| CS-001 *(Example)* | [Reference client], metropolitan transit | Account-based back office, open-loop payment | Live in 11 months; [n]% of journeys by bank card after one year | [Name, role, contact] |
| CS-002 *(Example)* | [Reference client], regional rail | Fare engine replacement | Fare change lead time reduced from months to days | [Name, role, contact] |
| [CS-NNN] | [Client and sector] | [Scope] | [Result] | [Contact] |

Confirm every result with the reference client and keep written permission to name them.

## 16. Compliance matrix and deviations

<!-- Guidance: Point to the compliance matrix and summarise the result honestly. Questions: how many requirements are fully met, partly met, met by an alternative, or not met, and why? Pitfall: hiding deviations in assumptions; state them here once, clearly. -->

Line-by-line answers: RFP Compliance Matrix (`business/rfp-compliance-matrix`), as [Form D].

*Example* summary: of 240 requirements, 212 are compliant (88.3%), 18 partially compliant (7.5%),
7 met by an alternative (2.9%) and 3 not compliant (1.3%); each share is the count divided by 240,
rounded to one decimal place.

| ID | Requirement | Deviation | Reason and benefit to the client |
|---|---|---|---|
| DEV-001 *(Example)* | NFR-034 Recovery point objective of zero | Five-second recovery point objective for the reporting store only | Tap and payment stores keep zero data loss; reporting rebuilds from events |
| [DEV-NNN] | [Requirement] | [Deviation] | [Reason] |

## 17. Bid team review checklist

<!-- Guidance: Internal only. Use this list at the red team and gold team reviews, then delete the section before submission. -->

| Check | Done |
|---|---|
| Every scored criterion has a clearly labelled answer within the page budget | [ ] |
| Every win theme appears in the executive summary and with proof in a scored section | [ ] |
| Every requirement ID in the compliance matrix points to a real heading in this volume | [ ] |
| Assumptions, exclusions and service levels match the commercial volume and the draft contract | [ ] |
| Named key personnel have confirmed their availability in writing | [ ] |
| Reference clients have approved their case study and contact details | [ ] |
| Certificates cited are valid on the submission date and their scope covers the service | [ ] |

## 18. Glossary and references

<!-- Guidance: Define the client's terms and any acronym an evaluator may not know. Keep references to documents you actually used. -->

### 18.1 Glossary

| Term | Meaning |
|---|---|
| Win theme | A short, client-centred reason to choose this bid, backed by proof |
| Hot button | An issue the client cares strongly about, stated or implied |
| Discriminator | A feature of this bid that competitors cannot easily match |
| Proof point | Evidence the evaluator can check: a reference, a metric, a certificate, a demonstration |
| Compliance matrix | Table mapping each requirement in the RFP to its status and the place where it is answered |
| PAN and PSP | Primary account number (the payment card number); payment service provider, which tokenises cards and requests authorisations |
| Pink, red and gold team | Successive internal reviews: storyboard or early draft, full draft scored as an evaluator would, final executive approval |
| [Term] | [Meaning] |

### 18.2 References

| ID | Reference | Version / date |
|---|---|---|
| REF-01 | Client RFP [reference] and addenda [1 to n] | YYYY-MM-DD |
| REF-02 | APMP Body of Knowledge (Association of Proposal Management Professionals), online at bok.apmp.org | Current online edition |
| REF-03 | Shipley Proposal Guide (Shipley Associates) | 5th edition |
| REF-04 | ISO/IEC/IEEE 41062:2024, Software engineering: Life cycle processes: Software acquisition | Edition 2, 2024-10 |
| REF-05 | ISO/IEC 25010:2023, Systems and software Quality Requirements and Evaluation (SQuaRE): Product quality model | Edition 2, 2023-11 |
| REF-06 | US Federal Acquisition Regulation 15.204-1 to 15.204-5 (uniform contract format; Section L instructions and Section M evaluation factors), when answering US federal solicitations | FAC 2026-01 (check acquisition.gov) |
| REF-07 | RFP Compliance Matrix (`business/rfp-compliance-matrix`) | [x.y] |
| REF-08 | [Security questionnaire, for example CSA CAIQ v4.1] | [Date] |

## Standard and licence note

Structure aligned with common bid and proposal practice as described in the APMP Body of Knowledge
and the Shipley Proposal Guide (5th edition), with the supplier-selection concerns of ISO/IEC/IEEE
41062:2024 and the product quality model of ISO/IEC 25010:2023. These sources are copyrighted: this
template uses only general concepts and section names (win themes, compliance matrix, colour team
reviews, quality characteristics); all text, tables and examples are original, and no definitions or
checklists are reproduced. For US federal bids, the uniform contract format in FAR 15.204 is a
public-domain US regulation; check the current text and any agency deviations at acquisition.gov, as
Part 15 is being restructured. Always follow the issuer's instructions over this template, and check
the current editions of the cited standards. APMP and Shipley are trademarks of their owners; this
template is not affiliated with or endorsed by them. Template licence: MIT.