Website procurement toolkit
A website RFP that providers can actually answer
Download an editable website RFP, a supplier-response sheet and a launch responsibility matrix. Give every provider the same requirements, acceptance criteria and pricing questions. Free to use with any provider; no signup required.
Choose the level of procurement the project needs
A website request for proposal turns the business brief into comparable commitments. It asks each provider to respond to the same requirements, explain what is included, name the dependencies, price the work and show how you will decide it is ready.
Use this pack when several people need to approve a website or several suppliers are quoting. It includes an editable request, a requirement-by-requirement response sheet and a launch responsibility matrix. There is no signup gate, and you can use it with any provider.
If one person can decide on a clearly scoped website, a useful website brief may be enough. An RFP becomes valuable when the cost, integrations, migration or approval process needs a more formal comparison.
The brief explains the business. The RFP asks providers to make their proposed work inspectable. Keep it proportionate: remove requirements that do not apply and resolve essential unknowns before asking everyone for a fixed price.
The table scrolls sideways on smaller screens.
| In the download | What you use it for |
|---|---|
| Editable Markdown request | State the decision, scope, response deadline, proposal format and commercial questions. Open it in a text editor or copy it into your own document. |
| Requirements CSV | Give each requirement an ID, a priority and acceptance evidence. Ask suppliers to answer each row, including exclusions and dependencies. |
| Launch responsibilities CSV | Name the executor and approver for content, access, URLs, DNS, email, enquiry checks, publication and handover. |
The CSV rows are starter requirements, not a specification already approved for your project or a list of everything included in UpOnUp's standard offer. Keep blank commercial fields unknown until a supplier answers them.
Ask for outcomes you can inspect
“Professional,” “fast” and “SEO-ready” leave too much open to interpretation. Describe the deliverable and the evidence you expect to review.
The table scrolls sideways on smaller screens.
| Broad request | More useful acceptance criterion |
|---|---|
| “The website must explain our services.” | The agreed page map identifies each service, its audience and the next action; the business owner approves the final facts and copy. |
| “It must work on mobile.” | Review the agreed pages and core journeys at the agreed small-screen and desktop sizes; record any layout or interaction exception. |
| “The contact form must work.” | An authorized test reaches the intended recipient, the visitor sees the expected confirmation and the reply owner is known. |
| “Keep our SEO.” | The old-URL inventory has an agreed disposition for each relevant address, with matching redirect, canonical and crawl-access checks where applicable. No unchanged-ranking promise is implied. |
| “We need accessibility.” | State the target standard and scope, the evaluation method, who tests it and how unresolved findings affect acceptance. |
W3C's WCAG reference supplies testable accessibility criteria. A target in an RFP still needs a defined scope and evaluation; a provider's general accessibility claim is not a test record. W3C WCAG 2.2 reference.
For a move that changes URLs, Google's guidance covers mapping old addresses, updating internal links and annotations, and appropriate redirects. Make those deliverables someone’s responsibility rather than writing “SEO included” beside the redesign. Google's site-move guidance.
Give suppliers one response format
Ask for a row-by-row response using Included, Separate quote, Excluded or Needs clarification. “Yes” without a deliverable, limit or dependency is often too vague to compare.
For each response, ask what will be delivered, what you must provide and when it can be reviewed. Keep the commercial summary separate from the requirement rows so a fee covering several requirements is not accidentally added several times.
The downloadable request asks for:
- The proposed scope and any difference from your request.
- A response to every retained requirement ID.
- One-off charges, recurring charges, currency, tax treatment and quote validity.
- The milestones, required inputs and approval responsibilities.
- Exclusions, third-party dependencies and the process for a scope change.
- Ownership, delivery files, hosting choices and ongoing-service terms.
If you need regional or translated content, identify the actual versions and who approves them. A single “multilingual” tick box cannot describe the pages, forms, messages and maintenance involved. Use the language and regional-version guide to define that part of the request.
Name who can approve each part of launch
A website provider may coordinate the move without controlling every account. The business, outgoing provider, registrar, DNS operator and email provider can each hold a different part of the process. Record named people before the switch, and never put passwords in an RFP or public form.
The table scrolls sideways on smaller screens.
| Launch decision | Person who normally needs to confirm it | Evidence to retain |
|---|---|---|
| Business facts and content | The authorized business approver. | The approved version and unresolved exceptions. |
| Old pages and their destinations | The business owner with the website provider. | An agreed URL disposition map. |
| Domain/DNS changes | The authorized account operator and business approver. | A bounded change plan and preserved prior settings. |
| Existing email remains usable | The email owner or provider. | Agreed checks before and after the switch. |
| Enquiry delivery and response | The recipient and the person responsible for replies. | Authorized test receipt and a known follow-up owner. |
| Public release and rollback | The named release approver and operator. | Go/no-go decision, release identity and reversal plan. |
| Ongoing service and file handover | The business owner and selected supplier. | Delivery record and agreed future responsibilities. |
These are proposed roles to adapt, not permission for a supplier to access or change an account. Cloudflare's email-record documentation illustrates why website and email checks need separate owners: mail routing and authentication depend on provider-specific DNS records. Confirm the actual setup with the email provider involved. Email-record guidance.
Record the decision, not just the winning price
Resolve must-have gaps first. Then compare the complete cost, relevant work, delivery approach and remaining dependencies. You do not need an elaborate weighted score if it hides a requirement that one proposal cannot meet.
Keep a short decision record: the selected proposal version, accepted scope, exclusions, unresolved points, price and currency, approver and reason. The downloadable request includes this section. An unanswered question remains open; it does not become included work when the supplier is selected.
Questions before you send the request
Is this suitable for a small website?
Yes, if you shorten it. Keep the requirements that affect your actual decision. For a straightforward purchase, the brief builder and provider comparison worksheet may be quicker than a full RFP.
Should every supplier include every starter requirement?
No. You decide what applies, and suppliers confirm what their proposed scope includes. Some projects need a new enquiry website; others include migrations, languages or integrations that require separate work. An honest exclusion is more useful than an ambiguous promise.
Does completing the template commission the work?
The template asks for proposals and explicitly asks suppliers not to start work or incur costs before separate authorization. Agree the final scope and commercial terms through your own purchasing process before work begins.
Bring us the requirements that matter
UpOnUp can respond against a defined website scope. Our standard offer covers original design, copywriting and responsive development for up to 25 agreed pages with an agreed enquiry route. Additional languages, ecommerce, bespoke software and complex integrations need a separate agreement.
Send the current website and the work you want priced. We will explain what fits the offer, what needs clarification and what belongs in a separate scope.
Ask UpOnUp about your requirements · Review current scope and terms · Plan an international website