What is an RFP?

A Request for Proposal (RFP) is exactly what it sounds like – a document that requests vendors to indicate their interest and outline their qualifications for consideration to be hired for a project. Of course, it’s a bit more complicated than simply putting out the call for proposals.

When an organization is looking to have a – typically large – project completed, they will put together a comprehensive document that outlines what the project is, what the expectations and constraints are, and how prospective partners should respond. Budgets, functional requirements, and timelines are all included in the document, as well.

Putting out an RFP allows agencies that are looking for larger or more complex projects to respond, reducing the amount of time an organization needs to spend sussing out potential vendors. Instead, that time is put back into the creation of the RFP itself and the evaluation of the responses.

When done correctly, an RFP for a website project can quickly uncover the vendors that have the experience and strengths that you need and make you aware of any weaknesses they may have that you’ll need to workaround.

When Should I Use an RFP (and When Can I Skip It)?

For some organizations, this is an easy question to answer – you should use an RFP for any project that is required by the company’s rules. For some, including public groups like government organizations, schools, museums, and so forth, an RFP is required before a vendor is selected.

In other cases, projects must meet a specific threshold – a certain budget or outsourcing size – before an RFP must be used.

If you are not required to use an RFP for your website project, there are still a few reasons to consider putting one together, as well as a few good reasons when using an RFP isn’t the right path to take.

When an RFP isn’t required, you can still consider using one when:

• The project is large and highly critical to your business
• You have a committee that will be responsible for evaluating and choosing the best vendor
• You want to understand if your project is feasible for the budget you’ve allocated

There are definitely times when using an RFP adds complexity to a project and shouldn’t be used:

• The project is small
• You don’t have the staff in place to evaluate responses
• You don’t have a lot of clarity on the project or its budget
• You have a limited timeframe to find, hire, and complete the project

In addition to that, a poorly written RFP with unrealistic budgets, vague requirements, and unnecessary hurdles can likely ward off many of the stronger and more experienced agencies and consulting firms leaving you with less experienced partners. This is why getting the RFP right before you send it out is just as important as the response selection process itself. 

What’s the Process?

While the creation of the RFP itself may be involved, the steps of the RFP process are fairly straightforward.

First, create the RFP itself. This can be the longest and most complicated part of the process since you’ll need to understand things like the scope of the project, technical requirements and constraints, budgets, dependencies, timelines or schedules, and the goals of the site. Gathering this information can be time-consuming, but the more detailed and accurate you can be the easier the evaluation portion of the process will be, and the more likely your chosen vendor will be able to stick to your budget and their proposal. To get this part of the RFP well defined, you will have to undergo your own discovery process.

Next, the RFP is sent out to vendors and agencies. You can post the RFP publicly so that potential vendors can find it. You can also send the RFP to specific vendors that you have identified and ask them to provide a response. You’ll want to make sure that you have a clear timeline for submissions included with the RFP.

It’s customary to include an opportunity for interested vendors to discuss your website proposal with you. Make sure that you’re including space in the response timeline for these meetings.

Once you’ve gathered all the proposals, it’s time for your internal team to review and evaluate the responses. Many organizations find that creating a scoring matrix based on the requirements can help kick off the evaluation process and narrow down the list of respondents to a handful of top contenders.

When you have narrowed the list of agencies to those you feel have the strongest potential for meeting your website project requirements, you can begin further vetting. This may include interviews, pitches from the vendors, or further responses that define how they will approach working with you.

Types of Website Projects for an RFP

We’ve mentioned that the size or complexity of the project can impact your decision to issue an RFP. That doesn’t limit the type of project that can be included, however. Multiple types of website projects call for proposal requests to ensure you’re getting the best possible vendor for your project.

Static or Minimally Dynamic Sites

If your site will be primarily a static set of pages with minimal interactivity, you may be wondering if an RFP is needed. If it’s a site of only a few pages, then that’s a good question. But not all static sites are small, nor are they all simple behind the scenes

While your site might be primarily informational, you may have specific needs on the backend, around administration, or around security and access control. You could also have a site with 10s or hundreds of pages. All of these cases warrant an RFP process.

E-commerce sites

E-commerce sites can quickly become large and complex projects. Automation, integration, and administration for these sites can be extensive, or they may need customization or simplification on the backend so that your team can easily manage the online store after launch.

Re-platforming an e-commerce site can also be a significant project, even if you’re upgrading your storefront on the same technology stack. As technology has evolved, so have many platforms, making even an upgrade a major undertaking.

Customer Portals and Intranets

Both customer portals and intranets have important elements that make them more complex than the typical website project. Many must integrate with a variety of systems behind the scenes, such as billing and CRMs for customers or HR applications and ERPs for intranets. This means your chosen vendor may need specialized knowledge to complete the integrations, or the ability to set up security and authentication systems to protect a variety of data.

Dynamic Websites

Even if a site is small, it can have extensive dynamic elements that increase the skill level needed to complete the project. Sites that depend heavily on user interaction must not only function well, but they also need to provide an experience that is pleasant and intuitive for the end-user.

Knowledge Bases and Content Repositories

Knowledge bases and content repositories require websites to have the ability to discover new data, allow for inputs, and scale as new information and artifacts become available. Finding the right vendor who has experience with these specific types of sites can be the key to a successful and timely launch.

Your RFP Roadmap

Here are the sections that should be included in your RFP.

Company Introduction and Background

This section will offer potential vendors an overview of the company and what it does. Discussing the size of the organization, or even the sub-organization that the project is for is appropriate here, as is pertinent information like locations if a company is global.

Project Overview

Your project overview should provide enough information that a vendor can quickly identify if they are a good fit. The type of project should be identified as well as the relative size, although a more detailed description of the scope is included later in the RFP.

Project Background and Goals

You’ll want to provide the potential vendors with an idea of what you hope to achieve with your website. This might be something like a desire to increase sales through a better interface, upgrade your website to take advantage of integrations and new technologies, or provide access to customers to increase their satisfaction. Whatever the purpose for undertaking this project, it should be succinctly stated here.

Audience

Who will this website be for? Is it for B2C customers to track orders and edit information? For internal teams to find onboarding and company information through self-service? To offer an online store for B2B customers to place orders?

When defining the audience, go beyond simply defining the user basics. Will all of the users be from one country? Will there be a need for other languages? For other currencies? Will some audiences have one level of access, while others will need more?

Scope

The more specific you can define the scope of your project, the more accurate the responses you’ll receive. For example, if the website your RFP is for requires the vendor to build out not only a large set of webpages on a content management system but to integrate with your CRM and other backend systems, it’s important to note that.

If you know how many pages will be included, if there will need to be customizations of a given system or training on the new site’s administration, that should be included in the scope as well. Your scope description should include whatever boundaries and expectations you have of the vendor so that they can provide an accurate response.

Design and Functional Requirements

Even a straightforward, static site will have some design and functional requirements that should be considered as part of the RFP. For example, if your organization is required to provide an ADA compliant site, that should be explained. This isn’t a place to define brand guidelines and so forth, but to describe those requirements that may impact timelines, budget, or require specialized skill sets.

Other things to consider adding to this section are requirements like localization or globalization of the site, high-level access and security requirements that need to be considered existing systems that the site will need to interface with, and any restrictions on technology that your organization might have.

Target Deliverables

What do you expect to be delivered when the project is done? Be as complete and specific as possible. If you expect that the vendor will provide a website, content translation to another language, databases, and APIs for integrations, be sure to state that.

Examples

It can be helpful to potential vendors to see the kinds of websites you’re aiming for. If you have examples of sites that have similar functionality, audiences, or purposes that you can share, this can go a long way to getting a comprehensive response from agencies.

Potential Roadblocks or Challenges

Do you already know that there are challenges or possible issues with getting the project done? For instance, will the site need to be set up alongside the implementation of a 3PL or accounting system, and you know that a delay in one project will result in delays in the other? Will your site interact with a warehouse automation system that you haven’t taken delivery of yet? Do you have an aging ERP that you’ll be replacing in the future that will need to be accounted for?

Any realistic roadblocks or issues should be noted so that the agency bidding on your project can account for these challenges in their response.

Timelines and Time Constraints

If your project has a hard deadline, that should be stated clearly. If the project will be dependent on other mission-critical projects or have projects that will depend upon the site’s completion, that should be noted as well.

Budget

Clarifying the budget for potential vendors in the RFP has a number of benefits. First, vendors can self-select out of the process if they don’t think they can complete the website described for the given budget range. Agencies will know from the start what their ceiling for the project will be, and can match resources and timelines to accommodate those restrictions. And your team won’t wade through proposals only to find that your chosen partner can’t do the project for the budget you’ve allocated.

An additional benefit, and one that is sometimes overlooked, is that stating your budget can allow you to test the waters and see if your project is realistic for what you’ve set aside for it. If you get few responses, or if you’re getting a lot of pushback from potential vendors, you may need to rethink your budget, timeline, scope, or all three.

Submission Instructions

Finally, you’ll want to outline clearly what the process and the submission instructions are for the agencies. Walkthrough the steps of the RFP process, the evaluation criteria, and most importantly the RFP timeline. Be clear and upfront about the RFP due date, and what the steps following submission will be. Also include contact information so that website agencies can reach you with questions.

Conclusion

A properly managed website RFP process will allow highly qualified and experienced vendors to come to you. They will know what to expect from the project, what the timeline looks like, and even what your budget constraints are right from the start. Your selection committee will be able to define their ideal partner and then quickly evaluate the suitability of the responses you receive based on that criteria. And, in the end, you’ll be able to identify exactly the right agency for your project based on your organization’s needs.