The perfect website RFP template

The only thing more ridiculous than this beach photo is the idea that a free website RFP template can change your life. So, we're not even suggesting that. But, our free website RFP template can definitely reduce the amount of suffering you will experience during a process that takes anywhere from 2-6 weeks. Probably worth considering! Keep reading for a link to access our template.

Why the RFP process sucks

It's not really anybody's fault. Generally speaking, when the word "process" is being used to describe something it already sucks. The best we can do is hope to make it better by avoiding some of the common pitfalls like:

• Mismatched expectations between you and the people responding
• Proposals with wildly different scopes or budgets
• Missing information in the RFP
• Project timeline or budget overruns later due to missing on incomplete requirements

You get the idea, right? We've all encountered these issues. So, here's what we propose to do about it.

The basics - who, what and when?

Start your RFP document with a summary that includes:

• Who’s issuing the RFP? Include a short summary of your brand and list the main point of contact.
• What project do you need? Describe it in 1-2 sentences. There will be plenty of time for details later.
• What is the overall timeline? In the simplest possible way describe the timing of your project as well as when the RFP response is due.

Get our free website RFP Template here:

The details of your project

This is where things most often fall apart in RFPs. How do you know how much detail to include? Here is a helpful checklist:

• What type of project is it? Website, application, interactive, AR/VR, software development, etc.
• What is your goal? Describe why you’re doing it. This can include functional improvements, new features, revenue goals, meeting new audience needs, etc. Three to five targets are ideal.
• Who is your audience? Describe your end users. If you have personas or profiles, briefly describe your primary 2-3 user groups.
• What are the general requirements? Include a description of the specific things you want to accomplish - think about what success looks like and describe that.
• What are the technical requirements? Do you have specific tech you want or need to use? This includes CMS preferences, hosting, third-party apps and services you’re using, analytics and tracking software needs, reporting and data integrations, CRM, etc.
• What services do you need? Be specific about the services you’re looking for - and what you don’t need. Maybe you will handle design in-house but want a UX professional to review your work. Or, maybe you need content migration help. Being clear about who’s on your team and what work they’ll do can make the estimates you’ll receive more accurate.

A better RFP process

In order to make the whole thing go smoothly for all involved, be clear about what you expect and when.

Here’s what a solid RFP process looks like:

• RFP issue date
• Call for interest
• Deadline for any legal requirements to be completed (like a non-disclosure agreement (NDA) or other required docs)
• Deadline for questions to be submitted - decide if you will share the answers with all who submit or only respond directly to those who ask.
• Put your RFP on a cloud-based service like Google docs so you can maintain a live FAQ page to track questions and answers throughout the process.
• RFP proposal/ response deadline - when do you want to receive the proposals
• Selection process - will there be presentations allowed? Will you select finalists? Is there an internal committee?
• Date you will notify finalists
• Presentation dates (if applicable)
• Date final selection will be made

You may want to make this process more or less complex depending on your specific situation. But this outline should provide you with the most robust process that you can pare down as needed.

What should be in proposal responses?

When someone submits a proposal, what do you want them to include? Don’t ask for a bunch of boilerplate content if you don’t expect to read it. If all you want to see is a plan and a budget, cool. If you need to see work samples and employee bios, also cool. But, think about what you can feasibly read - and ask for that.

This outline could include:

• Company history
• Project team members
• Relevant previous projects
• Project plan or approach describing how they would tackle your requirements
• Project timeline
• Project budget
• Anything that is NOT included in the project plan or budget

If you think through these topics and spend an extra hour or two putting the document together, you’ll save a ton of time in the questions phase and also get better responses that will be more likely to meet your needs. Plus, all those potential partners will waste less time guessing and be able to deliver their best work, too. Everybody wins!