# Website request for proposal

Prepared using the free UpOnUp template. Adapt it for your project and use it with any provider.

Replace bracketed fields, remove requirements that do not apply and attach the relevant files before sending. Do not include passwords, private customer records or confidential access tokens. This request seeks a proposal; please do not begin work or incur charges until we separately authorize the agreed scope.

## 1. Request details

| Field | Buyer to complete |
|---|---|
| Buying organization and website | [Name and URL] |
| Project name and request version | [Project / version / issue date] |
| Main contact | [Name or role and agreed contact route] |
| Decision-maker | [Role authorized to approve scope and supplier] |
| Questions due | [Date, time and named time zone] |
| Proposal due | [Date, time and named time zone] |
| Intended decision date | [Date or not yet set] |
| Desired launch and reason | [Date / business reason / flexibility] |
| Requested quote currency | [One currency] |

Send questions to the main contact. We will record material answers as a dated clarification so participating suppliers can respond to the same requirement.

## 2. The business decision

- Business and offer: [What we do and for whom.]
- Why the website is changing: [The actual problem or opportunity.]
- Primary visitor action: [Enquire, book, buy, use a service or another named action.]
- Intended audiences and markets: [Who must use the site and where we can serve them.]
- Language or regional differences: [Actual versions needed, or English only.]
- Evidence available: [Existing pages, public material, approved brand assets, relevant aggregate reports.]
- Evidence still missing: [Unknowns to resolve; do not substitute invented baselines.]
- Useful result: [What we intend to assess, when and from which evidence.]

## 3. Scope and starter requirements

Use the companion requirements CSV. Keep the IDs when suppliers respond. For each retained row, set priority to Required or Optional, adapt the requirement and acceptance evidence, and name the buyer's decision owner. Remove a row only deliberately; record Not applicable when that is clearer for comparison.

- Pages and content: [Attach an agreed or proposed page list.]
- Functions and integrations: [Name the specific user journey and system, not only a product category.]
- Existing material to preserve: [URLs, downloads, forms, images, content or other assets.]
- Brand assets and rights: [What is supplied and any relevant restrictions.]
- Language/market versions: [Which pages, forms, messages and documents differ; who approves them.]
- Domain, hosting and email: [Current providers and account-controlling roles; no credentials.]
- Known exclusions: [Work this request does not include.]

Starter requirements are prompts for agreement. They are not automatically included in any supplier's base package.

## 4. Supplier response

Please return a proposal using these headings and complete the companion requirements CSV.

### A. Proposed approach and deliverables

Explain the page/content plan, design and development approach, review process and the deliverables we receive. Identify where your proposal differs from our request. Link to relevant work with a short explanation of your actual role; label demonstrations or self-initiated projects accurately.

### B. Requirement-by-requirement response

Use one of: Included; Separate quote; Excluded; Needs clarification. For each retained requirement, state the quoted deliverable, any limit, dependency, acceptance evidence and review milestone. Do not use a general “included” answer to conceal a separate fee or an assumption we have not accepted.

### C. Commercial summary

| Item | Supplier response |
|---|---|
| Full one-off project fee | [Amount and currency; identify the requirement IDs covered] |
| Separately priced options | [Amount, currency and requirement IDs; do not double count] |
| Payment milestones | [Amount or share, trigger and payment terms] |
| Required recurring charges | [Amount, interval, currency and what each covers] |
| Optional ongoing charges | [Amount, interval, currency and scope] |
| Third-party charges | [Who pays, price source, renewal basis and any uncertainty] |
| Taxes and other charges | [Explicit treatment and any buyer information needed] |
| Quote validity | [Expiry date or stated review condition] |
| Currency/transfer assumptions | [Any conversion or transfer-fee assumptions] |

Keep a single commercial summary. The requirement sheet's quote-line reference points here; it is not another set of amounts to add to the total. Unknown charges should be identified rather than entered as zero.

### D. Delivery, approval and dependencies

| Milestone | Deliverable to review | Inputs needed from us | Approver | Proposed date/time zone |
|---|---|---|---|---|
| Scope confirmed | [ ] | [ ] | [ ] | [ ] |
| Initial review | [ ] | [ ] | [ ] | [ ] |
| Refinements complete | [ ] | [ ] | [ ] | [ ] |
| Launch readiness | [ ] | [ ] | [ ] | [ ] |
| Public launch | [ ] | [ ] | [ ] | [ ] |
| Handover and follow-up | [ ] | [ ] | [ ] | [ ] |

State the number or scope of included review rounds, how feedback is consolidated and how a changed requirement affects price or timing. Identify access, content or third-party decisions that could prevent a milestone.

### E. Ownership, access and ongoing work

Explain the agreed ownership and licence position for source files, content, design and third-party assets. List what will be handed over and in what form. State who controls the domain and key accounts, what access your work needs, and how that access will be granted and later removed.

Describe hosting and support choices, any included maintenance, response expectations, limits, cancellation arrangements and the cost/process for later changes. Do not assume a particular service level is included unless it is stated.

### F. Exclusions and clarification record

| ID / subject | Exclusion or open question | Effect on price or delivery | Answer owner | Agreed resolution/version |
|---|---|---|---|---|
| [ ] | [ ] | [ ] | [ ] | [ ] |

## 5. Acceptance and launch responsibilities

Complete the companion launch-responsibilities CSV with named executors and approvers. The proposed roles are starting points, not grants of account access or authority. Mark status Not agreed until the responsible people confirm the row.

Before publication, agree:

- Which version of the website and content is approved.
- Which required acceptance checks have passed and which exceptions, if any, the approver accepts.
- Who can authorize and perform the domain/hosting change.
- What happens to each relevant old URL and how that behavior will be checked.
- Who confirms existing email and approved test-enquiry delivery.
- The previous working state, rollback decision owner and reversal steps.
- The file/access handover, ongoing responsibilities and point when the old service may safely end.

A successful preview is not public-launch acceptance. An indexing submission is not proof of indexing or search performance. Keep the delivery evidence beside the agreed requirement rather than replacing it with a general completion statement.

## 6. Buyer decision record

| Decision field | Buyer to complete |
|---|---|
| Selected supplier and proposal version | [ ] |
| Agreed scope / requirement-sheet version | [ ] |
| Required gaps resolved | [ ] |
| Accepted exclusions and reasons | [ ] |
| Remaining conditions before work may start | [ ] |
| Agreed price, currency and commercial-summary version | [ ] |
| Reason for selection | [Relevant evidence and trade-offs] |
| Approver and date | [ ] |

Keep the completed request, questions, supplier responses and selected versions together. Follow your own purchasing process to confirm the final agreement.

Template and practical guidance: https://uponup.com/guides/website-rfp-template/

Supporting references for technical requirements: [Google site moves](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes), [W3C accessibility criteria](https://www.w3.org/WAI/WCAG22/quickref/). Requirements still need to be adapted to the actual project.