I’ve been quoting on websites for almost 20 years, and so in that time I’ve read A LOT of website briefs! I’ve also written a lot on a consultancy basis, as I know what you need to put in them if you want an accurate quote. Unfortunately, a lot of briefs are bad – so, so bad! And they mean so much more back and forth, or the risk of the client getting uncomparable quotes back.

So what are the big 4 things that you should avoid putting in a RFP? 

1. Reporting

Reporting is great – we love building reporting into systems we build. And reporting, if you need it, should absolutely be in your brief. But the issue is when people just state that they need “reporting” and don’t elaborate on what reporting they need. If you’re having something custom built, or even just put together with existing plugins, what reporting you need is going to effect the price.

If it’s being coded, some reports take more time than others. If it’s being done with plugins, the person quoting needs to know what you want in order to tell you if a plugin exists that can do the report you need. You can find yourself in a position of some less thorough developers telling you “yeah sure, the price includes reporting” but then when you come to it, it’s not actually the reporting you want.

You also need to tell the estimator how you want the reports delivered. Should they just appear on the screen, or should you be able to download a CSV file? Maybe you want them in charts, or even downloadable in a PDF?

2. Join / register

Maybe this one is more prevalent for me because we do a lot of membership based sites, but not all Join processes are equal! Some take a user through various rounds of form filling, with wizards on their first login to gather more info. Many require an approval process via an Admin, but equally many don’t. Some just want an email address and a name, some have pages of tick boxes and complicated UX designs to consider for best results. If you’re asking a company to quote on building you a join process, make sure you tell them the details around what you need.

3. A good search

This is a nice one. If you’ve ever written this, thanks for clarifying you want a search to be “good” as opposed to the “bad” search some people want! I completely appreciate that search can be a big area for a lot of companies and be something that causes a lot of pain and leads a company to wanting a new website, but again, you need to be clear on what you need in the new version. If you don’t know and are looking for expert advice, then explain what’s currently wrong with your existing search; you can’t necessarily expect free consultancy / technical planning in a quote, but naming your existing pain points will help the person doing the quote understand the scale of what you’re looking for.

Also grouped in with this no. 3 point is “filtering” or “sorting”. Unless it’s obvious (and whilst you know your business inside out, it may not be obvious to a newcomer) you can’t assume that the person reading the brief will know what you want filtered or sorted. Some searches with filters and sorting are a few hours work to code, some are days and days. So the more detail you can give, the more comparable your quotes will be.

4. etc.

This is my personal favourite. The word “etc.” shouldn’t appear anywhere in your brief, as in this context it’s basically saying “and some other requirements that I’m not detailing”. And that’s where quoting just becomes guess work and the person doing the estimate either ignores the “etc.” so their quote is unrealistically low, or they over compensate for what “etc.” might mean and your quote is unnecessarily high.

Whilst the first step of any big web project is to work out the finer details of what’s required, and all quotes may only be estimates until that’s complete, you can really help yourself collect close estimates and avoid scope creep if you’re as detailed as possible from the offset.