How to write a website RFP

A request-for-proposal (RFP) is quite a formal-sounding document. But for a digital studio like us, no matter what form it comes in, it’s an important part of the exploration and assessment pre-project we sometimes go through until we get to the exciting bit: starting that new website project.

But – it’s actually a really important step in the process. First of all, it helps you (a potential client of ours) find and secure the right partner to deliver your website. And if prepared in the right way, it’s a really useful way to set expectations for you and our studio. It helps everyone set the scene, so there are no curveballs later on.

In this post, we’re going to cover why RFPs are an important part of the website project process, and exactly what we, Adaptable, love to see in one.

Key points we’ll cover:

• Is there really a difference between a website RFP and a brief?
• Why produce and distribute an RFP?
• What to include in your RFP
• Setting your own expectations – i.e. what to expect to get back in return

Website RFP vs Brief

The terms “RFP” and “brief” when it comes to website projects seem to be used pretty interchangeably. In our experience, some clients call a document an RFP, some call it a brief, and the content is very similar. Strictly speaking – a brief gives some sort of specific creative or technical direction with challenges to overcome, while an RFP goes into more detail around the procurement process and what the ideal partner looks like. We would usually prefer to work with an RFP, as this enables us to ensure we are a good fit, then bring our experience and knowledge to the table, working more closely with the client to guide the project in ways they may not have thought previously possible.

To summarise, an RFP focuses on the top-level project requirements and objectives – everything a digital product studio like us would need to provide a proposal for a project.

Why an RFP is useful

An RFP is useful first of all in helping you set some high-level objectives for the project and get some key requirements on paper. You can then use this information to seek out potential partners who can support you with the project – who should be able to (if you’ve written a good RFP) self-identify whether they’ll be suitable to fulfil it or not. This sets everyone’s expectations upfront, and also saves a lot of time back and forth trying to get to the bottom of your requirements.

From our perspective, as a digital studio, when we receive a well-written RFP we get a clear set of requirements, constraints and objectives for a project that we can propose an approach for and estimate against. In return, this helps you get a detailed and tailored proposal that can help you make an informed decision about the way forward.

Both parties get off to a good start, an organised RFP process and detailed document means you’ll get an equally good proposal and response.

What to include in a website RFP

The following is a list (a wish list, if you will) of the type of details we love to see within an RFP. You should include all of this as a minimum to get useful responses to your RFP.

Project overview

In this section, you should start by giving a brief description of your organisation and the background to the project. Why are you relaunching your website? What context do we need to understand about your organisation and the projects’ objectives? For example:

Dunder Mifflin is an established provider of paper products and office supplies in the North Eastern USA. Established in 1949, we have seen growth and decline but are poised for a paper industry comeback, led by the success of our Scranton branch.

We are looking to relaunch our corporate website to offer an end-to-end purchasing experience – one which is reflective of our focus on quality and customer service.

In the RFP you should also include the budget and the timelines for the project. These may seem like two pieces of relatively throwaway information – but they are really important for us as a digital studio in order to a) assess our suitability and capability to deliver the project and b) be able to produce a proposal. You would be amazed at how many RFPs and briefs we receive which do not include the budget or the timeline for the project. Budgets don’t always have to be one fixed figure as part of the RFP. Even a to-and-from figure (e.g. £40 – 50k) is helpful so we know what we propose is achievable within your budget.

Project overview section checklist:

• Description of your organisation
• Project background and high-level objectives
• Budget
• Timelines (when ideally should the project be completed by, and are there any internal/external milestones that are connected to the launch)

Further context and objectives

In this section, you should dig a little deeper into your objectives and your wider digital or marketing strategy as it relates to the website project. This is your opportunity to give a bit more context about your strategy, your industry and what you hope to achieve.

Further context and objectives checklist:

• Detail any work you’ve already undertaken around your existing digital experience or your brand: market research, internal stakeholder engagement, strategy, brand guidelines – it’s very helpful to see as much detail as possible on these, so make sure you link off to relevant documents if possible
• Relevant objectives related to the project’s digital or marketing outcomes that should be considered in the proposal (e.g. increasing leads and enquiries, improving load speeds, etc)
• A brief overview of your target audience and key users – who uses your website, and what do they expect to get from it? Equally, if this is unknown, it’s completely fine to say that, as we can provide support in uncovering this information.

Technical requirements and considerations

This section should start to get a little more into the nitty-gritty of the deliverable you expect to get from this project. While some of the detail around the how, what and why might change as we begin the project and scope out the strategy, this is your chance to set your stall out for what is absolutely necessary. This helps us understand the scope of the work involved in delivering the project.

Technical requirements and considerations checklist:

• Top-level functionality – e.g. eCommerce, user authentication, content management, custom tools, etc.
• Preferred CMS – note while this isn’t necessary to include (we’d always assess and recommend the best CMS for your requirements) it will be helpful to know what you use at the moment or if you do have a preference.
• Integrations – does the website need to integrate with any internal, third-party or specialist tools/platforms
• Server/hosting requirements – do you want us to host it, or do you need to host it internally, or elsewhere
• Migration – what kind of content and data will need to be migrated across from the current website to the new one?
• Content – do you have a plan for content, will it be handled by your marketing team or do you require our support?
• Compliance requirements – we would always design and develop in line with core web standards, but it’s useful to know if there are any other standards specific to your industry or organisation we would need to comply with

An outline of the process

Speaking from experience, it’s really helpful for us if you include a timeline and outline for your procurement process within the RFP. Responses to RFPs can take up to 5 different team members’ skill sets to formulate a complete proposal so it sets us off on the right foot when we know what to expect and when as part of the process.

What to include:

• Your timelines for the response, review and selection process: deadline for proposals, when you’ll be reviewing them, when you’ll let us know if we’ll move on to the next stage or not, and when the winning partner will be selected
• How you’ll be reviewing/evaluating proposals – i.e. is cost the most important factor, experience, etc

What you expect from us

This section isn’t essential for us to produce a proposal – but it’s really useful in helping to asses whether we’ll be a good fit. We like to build successful partnerships with our clients, so it’s good to understand whether we share the same values and whether we have the background, experience and processes that will fit with you.

Here you might outline:

• How important previous experience in your industry/sector is to you in selecting a partner
• How you prefer to work with external agencies like Adaptable
• Any values/attributes of your chosen partner that would be important to you

Setting your own expectations

It’s important once you’ve put your RFP out there into the world, and you start getting responses, that you have a framework for what to expect (so you’re not disappointed or frustrated).

First of all, it’s unlikely you’ll be receiving any designs, concepts or locked-in detail around the technical strategy. You’ll be making a decision based on our previous work, our capabilities and honestly, on whether you’d like to work with our team based on what you’ve seen and heard from us.

Secondly, you get out of this process what you put into it. It takes time, effort and cost for us to create a proposal – so setting expectations, and giving as much detail as possible early on helps both parties avoid wasting time on creating a proposal for a project that won’t be a good fit culturally, budget-wise or where the timeframes don’t work for either party.

Key takeaways

• An RFP is a really helpful way to set out your expectations for a website project
• It helps you and us as your website partner set off on the right foot
• Don’t get too hung up on the terminology – whether you call it an RFP or a brief, include the right information and you’ll get a detailed and tailored proposal to help make an informed decision
• What to include:
  • Project and organisation overview
  • Budget
  • Timeline
  • Further context around objectives, strategy/research already done, target audience/key users
  • Must-have technical/functional requirements
  • What you expect from us
  • An outline of the procurement process
• You get out of this process what you put in. The more detail you provide, the more useful responses you’ll get.

If you’ve been using this blog post to write an RFP – hi 👋. We’d love to take a look and understand how we can help. Just send it to us here.