While the discussion around web RFPs typically focuses on selecting a design and development vendor, it's important to remember that an RFP is a reflection of the organization itself.
We've been thinking a lot about requests for proposals (RFPs) lately. More organizations are moving forward with projects that have been sitting on the shelf for months, which means we're seeing a lot of RFPs — and I bet we're not alone.
We often think about RFPs as a one-way road. A company decides it needs a new website and sends out a request for proposal, hoping to hire the right vendor. A short list of web firms competes for the work, the company picks a winner, and the chosen vendor builds the site.
There's another competition happening at the same time. When a firm like Blend Interactive begins to receive two or three RFPs a week, our question shifts: how do we determine which of these are worth our time, and which ones are more work than they’re worth? While vendors compete against each other to win the work, your RFP is also competing against other RFPs for vendor attention.
An RFP does more than document requirements. It signals who you are as an organization, what you value in a relationship, and what it will be like to partner with you. Before anyone evaluates your requirements, your timeline, or your technology choices, they're evaluating you as an organization.
Things that signify a well-thought-out project.
So let’s start with what works. Despite the common thinking that an RFP documents expectations for a vendor or partner, an RFP is also a clear signifier of who you are as a potential client. Vendors can look at the list of proposed services, the way the RFP is written, and even the rigidity of the rules and quickly get a sense of what you'll be like to work with.
When we see an RFP that makes us want to clear the calendar and craft a response, we often see the following:
- A clear problem statement instead of a feature list. "People can't find things on our site" tells us more than three pages of requirements like "must support faceted search." When you describe the problem, we can bring our experience and creativity to the solution.
- Signs of internal alignment. An RFP with a named decision-maker, a clear point of contact, and clear cross-departmental requirements helps a vendor understand the seriousness of the project — and, it shows that the project has support. Bonus points if leadership champions are named — that gives us some assurance the ol’ “swoop and poop” will be kept at bay.
- A budget or budget range. We understand the instinct to hold this back, but a range tells us whether we're the right fit before either side spends too much time hashing out budget. It's the single most useful number you can share.
- Honesty about the solution. "We think we need a specific feature, but we're open to guidance" is one of our favorite sentences to read. It tells us you want a partner to help you think through a problem, not a vendor to follow a prescribed plan.
- Consideration for what happens after launch. When an RFP mentions the editors who'll manage content, or asks how the team will keep the site healthy after go-live, we know we're talking to someone thinking past the launch date. Those projects tend to go better, because they're built for the team that has to live with the site.
Things that raise red flags.
On the other hand, there are plenty of things that give us pause — the kinds of things that, during our sales review meetings, raise a dreaded question: "Is this even worth replying to?”
Those things include:
- Over-specified solutions. The purpose of an RFP is to find a team that can help you solve a problem. It's hard to trust one that prescribes the solution before anyone has had a chance to develop a strategy — and, in fact, it’s often a flag that strategy isn’t really on the table.
- No budget and no willingness to discuss one. We understand that there’s a hesitancy to discuss budget — especially when an RFP is positioned as a part of a longer negotiation. Two fears might be at play here: first, organizations fear that giving a solid number will cause vendors to “claim” the full number; second, organizations don't yet know what a project like this should cost, so they’re hoping the spread of responses will inform them. Unfortunately, withholding the number tends to backfire: with no constraint to build against, firms scope for everything you might possibly want, which pushes every response higher. A vendor that knows where the budget sits from the start can propose something realistic (often less expensive) and built to fit. Providing constraints is the best way to find a real strategic solution.
- Impossible timelines. A hard launch date is fine — in fact, it’s often expected. But a hard launch date with no room for discovery, content entry, and the give-and-take of a creative project — surprises included — tells us the plan isn't grounded in reality.
- Procurement-only contact. Whether it’s a dedicated Q&A period, open and honest communication during the proposal process, or even just a quick call to iron out questions, an RFP should never be a one-sided affair. Whoever you select, your web project is a partnership, and the proposal process is a great way to get a feel for the people you might work with.
- A rubric too focused on features or cost. Again, we understand the desire to stay affordable, but when evaluation criteria focus more on cost or features than partnership fit or strategic capabilities, you're likely choosing a number instead of a team. What’s more, we’ve seen several RFPs that focus on high-end features that the editorial team doesn’t have time to implement or manage due to time and staffing constraints.
