# Request for Proposal: <software category>

Issued by <organisation>, <date>. Responses due <date>.

## 1. Purpose

We are selecting <category> for <scope: business units, countries, users>. This RFP asks for structured answers with references. An answer without a reference to documentation, a contract or a demonstrable configuration is recorded as a vendor statement, not as a verified capability.

## 2. Our situation

- Users: <number>, in <countries>
- ERP and systems of record: <ERP, HR, identity provider>
- Current tooling: <what is replaced and why>
- Go-live target: <date>; contract term: <years>

## 3. Requirements

Kind: M = mandatory (unmet means excluded), P = preferred (weighted), N = nice to have.

| # | Requirement | Kind | Weight | Vendor answer | Reference |
| --- | --- | --- | --- | --- | --- |
| 1 | Integration with <ERP> for <objects> | M | 30 | | |
| 2 | SOC 2 Type II report available under NDA | M | 20 | | |
| 3 | Single sign-on via SAML with our identity provider | M | 10 | | |
| 4 | Data residency in <region> | P | 15 | | |
| 5 | Public API with documentation | P | 15 | | |
| 6 | Audit log of user and system actions, exportable | P | 10 | | |

## 4. Commercial

- Pricing model (seat, platform, usage) and list price, or a statement that pricing is quote-based
- Implementation cost, by phase, and what is included
- Minimum term, renewal terms, price change clauses

## 5. Implementation

- Typical timeline for an organisation of our size, with the assumptions behind it
- Internal effort you expect from us (roles, days)
- Partners you would involve, and their role

## 6. Security and compliance

- Certifications with report dates
- Sub-processors and where data is processed
- Incident notification terms

## 7. Evaluation

Answers are scored per requirement by <roles>, weighted as shown. The weighted result is one input; references, demonstrations and reference calls are the others. No answer is scored higher for being longer.