Writing the Perfect Website RFP

How do you write an RFP that delivers the best responses? Here are some do’s and don’ts—and some just plain rants.

Let me preface this with a disclaimer: I know—for many of you—that you have strict rules you must follow to write your RFP. I know there are legal issues, document-legacy issues, and bad boss issues. Website companies expect some hoops to jump through and some legaleze—but your RFP response is being written by the sales guy, not the guy with the law degree.

You’re starting a relationship here. This isn’t just about you—it’s about setting expectations with someone you hope to be working with long after your site is launched. So (like starting personal relationships) you need to find that balance between “getting to know each other better” and “high-maintenance.”


RFP Infographic


Know what you want. If your company doesn’t really know what it wants in a website, then expect your RFP responses to reflect that—with lots of assumptions, risks, and constraints. You don’t have to have everything figured out—often that is a collective decision with your chosen website development partner—but if you have internal disagreements going into the project, they will only be amplified once the project begins.

Lower the risk for you and your developer. One of the primary goals for any RFP is to lower the risk of the project—for both the client and the website developer. Here are some ways to do this:

• Clearly state the deliverables.
• Be realistic about your expectations, and the cost to build a good website.
• Be realistic about your own company’s abilities to write content, market the site, and do content management following launch.
• Instead of emailed Q/A, have a face-to-face meeting where you can present your ideas in person, and questions can be asked in person. You’d be surprised how much insight you both will gain from this meeting—and how much that insight lowers the overall risk of the project.
• Define the scope, budget, and timeline as clearly as possible.
• Expect an estimate—not a fixed cost. You should, however, expect a more-accurate cost and timeline following the discovery/architecture phase.

This is important to remember: good website companies would rather hear “no” to their response than a “yes” to an RFP with a low chance to succeed.

Keep it simple. Most RFP responses take hours to write. In some cases, you’ll get no response at all if you make it too complicated. Your RFP should not be a test to see which company can perfectly follow your 58 rules for RFP submission—it should be the start of a give-and-take process that will—in the end—result in a trusted, long-term partnership. Asking for details like hourly rates for each team member, the qualifications of each team member, each team member’s experience with your particular industry, links, examples, case studies, achievements, ownership, state ID numbers, etc. might seem like completely responsible questions to ask—but they turn your RFP into Mount Everest.

Good website development companies are already busy, and will pick and choose which RFP’s will get their response. We live in an age where you can see what kind of cars are in the parking lot of a website company 1,000 miles away—you shouldn’t need them to write their biography for your RFP. Do your own research in addition to what you ask for in the RFP.

Your RFP process isn’t just for you—it’s the start of a relationship with someone you hope will be a trusted partner for years. The trick to getting great responses is finding that balance between being diligent and asking for too much.

(Note: in searching for a graphic for this blog, I found the perfect graphic…thank you toemailvendorselection.com!)


This entry was posted in Technology and tagged , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>