Website RFP template for corporates

A website RFP (request for proposal) should tell suppliers who you are, what the new site must achieve, what is in scope, what budget range and timeline you are working with, and how you will choose. The template below has twelve sections. Copy the headings into your own document, replace the prompts with your answers and delete anything that does not apply.

A short, specific RFP gets better proposals than a long, vague one. If a section does not apply, say so in one line.

How to use this template

• Fill in what you know. Mark what you do not know as open, and ask suppliers to recommend.
• Describe the problem and the outcome you want. Leave room for suppliers to propose how.
• Send it to a shortlist, not to everyone. Three to five suppliers is enough to compare.
• Give every supplier the same information and the same deadline.
• Offer a call. Suppliers who can ask questions write more accurate proposals.

The template

1. Summary

• Organisation name and website address
• One paragraph on why this project is happening now
• What a successful result looks like, in two or three sentences
• Target launch date
• Proposal deadline and contact person

2. About the organisation

• What the organisation does and who it serves
• Size, locations and markets
• Brands, divisions or subsidiaries the site must cover
• Who is on the project team, and who gives final approval

3. Goals and measures

List three to five goals, each with a way to measure it.

• Goal: for example, more qualified enquiries from a named sector
• Measure: for example, enquiry form submissions and tracked calls per month
• Current figure, if known

4. Audiences

• Primary audiences: who they are and what they need to do on the site
• Secondary audiences: investors, job applicants, media, suppliers
• Countries and languages to be served

5. The current website

• Current platform or CMS, and who hosts it
• What works and should be kept
• What does not work
• Approximate number of pages, and monthly visits if you can share them
• Systems the site is connected to today
• Who holds the logins for the domain, hosting, analytics and Search Console

6. Scope of work

Mark each item as must-have, nice-to-have or not needed.

• Research and strategy: audience, keyword and competitor research
• Sitemap and page structure
• Design: number of unique page layouts, brand guidelines to follow
• Content: who writes, who edits, who supplies photography and video
• Build: preferred platform, or an open request for a recommendation
• Features: for example, careers section, investor documents, store locator, gated downloads, member login, online payments
• Integrations: CRM, marketing automation, recruitment system, booking system, accounting software
• Content migration: what moves across, and who moves it
• SEO: redirects from old URLs, page titles and descriptions, structured data
• Tracking: analytics, conversion tracking, consent management
• Training for the people who will edit the site

7. Technical and compliance requirements

• Hosting: preferred region, any internal IT policy, who will manage it
• Security: single sign-on, user roles, penetration testing, your security questionnaire
• Performance: for example, passing Google's Core Web Vitals on key templates
• Accessibility: the standard and level you are working towards, for example WCAG 2.2 Level AA
• Privacy: the laws that apply to you, such as POPIA or GDPR, and your requirements for data processing agreements
• Browser and device support
• Ownership: confirm that you will own the domain, the design, the content and the code, and state any licence terms you expect

8. Budget

• A budget range for the build
• A separate range for ongoing hosting, maintenance and support, if these are in scope
• What the budget must cover: for example, photography, copywriting, software licences

A range lets suppliers scope a realistic proposal. Without one, proposals vary too widely to compare.

9. Timeline

• RFP issued
• Deadline for supplier questions
• Proposal deadline
• Shortlist presentations
• Decision date
• Project start
• Target launch, and any fixed date behind it such as a rebrand, an event or a financial year end
• How quickly your team can review and approve work at each stage

10. What to include in your proposal

Ask every supplier for the same things, in the same order.

• Company overview, and who will do the work
• Whether any work is subcontracted, and to whom
• Relevant examples, with live links
• Proposed approach and platform, with reasons
• Timeline with stages and what you need from us at each stage
• Cost breakdown by stage, plus ongoing costs
• Assumptions and exclusions
• Support and maintenance after launch
• Two or three references we may contact
• Standard terms and conditions

11. How proposals will be evaluated

State the criteria and their weighting. For example:

• Understanding of the goals
• Relevant experience
• Approach and platform fit
• Team and communication
• Timeline
• Cost and value
• Support after launch

12. Submission details and terms

• Where and how to submit, and in what format
• Page limit, if any
• Who to contact with questions, and whether answers are shared with all suppliers
• Confidentiality terms or NDA
• Any procurement documents suppliers must provide
• A statement that you may choose not to appoint any supplier

Mistakes that weaken an RFP

• Specifying the solution instead of the problem. Naming a platform or feature list too early rules out better options.
• No budget range. Suppliers guess, and the proposals cannot be compared.
• Too many suppliers. A long list means less effort from each one and more reading for you.
• No single owner. Proposals stall when no one has authority to decide.
• Leaving out life after launch. Hosting, updates, security and support need an owner and a budget.

RFP or brief

A full RFP suits organisations with a procurement process and several stakeholders. For a smaller project, a one-page web design brief covering sections 1, 3, 5, 6, 8 and 9 is usually enough, followed by a conversation.

Related reading

• Corporate websites: how Stryx approaches sites with several stakeholders
• Agency vs freelancer vs consultant: which kind of supplier to invite
• How to choose a web design company in South Africa: a checklist for scoring the replies
• The Stryx process: what happens after a supplier is appointed

Stryx responds to RFPs and briefs after an initial discussion. To send one, get in touch.