5 Ways to make the RFP response process slower (yes, slower)

A Request for Proposal (RFP) can take a long time to complete. If you’ve ever filled out one of these questionnaires, you know what we’re talking about. And unless you’re one of the many users automating RFP responses with 1up, you’re probably unhappy with how tedious and painful the process is.

But what makes the response process so slow?

That’s what we wanted to figure out. So we reached out to one of our customers and offered to manually complete one of their questionnaires.

For this experiment we used a simple RFP written for an enterprise software company specializing in Identity Access Management. It was a vanilla questionnaire consisting of 82 rows with a 300-word limit for answers. That means answers can be as short as “Yes” or about twice as long as this intro.

We had 1 rule: no automation. We wanted our experience to be as close to the user pain as possible in order to truly understand what makes the RFP process so slow?

Fortunately, our customer was kind enough to give us access to a knowledge base they were using for questionnaires – which would give us great content to work off. So we grabbed a Red Bull, put on our Spotify playlist, and got to work.

This RFP had a total of 82 questions and a cover page.

Filling in the answers took us a little over 5 hours over the course of 2 business days. In some cases, we copy/pasted previous answers or relevant excerpts – but still needed to rephrase them to match the context of the question being asked.

Our answers ranged from approximately 20 to 300 words. We found ourselves coming up against the word limit on some of these responses. In these cases we would shorten our answer and reference external sources for more information.

So how did we do? Most humans type at 40 words per minute. Our average answer length was 142 words, so…

(80 answers * 142 words) / 40 words per minute = 284 minutes (4.7 hours)

Surprisingly that estimate is almost exactly as long as the 5 hours we spent typing out responses. That’s excluding the time we spent searching for answers (more on that below). The content was unfamiliar to us so we probably took longer than our customer would in that regard.

Speaking of pencils….

Obviously this was a mistake. We got through 7 rows before carpal tunnel started to kick in and we gave up. 🤷🏾‍♀️

Finding answers was challenging because we were dealing with several unfamiliar data sources. Our knowledge base consisted of:

It took us just over 2 hours to find the right data sources needed for our responses. That’s excluding any time spent typing. We measured this using an tool that tracks screen time spent in an application (finally, a good use for spyware).

The most annoying part of this process was context switching between compliance, security, product, and sales messaging. These data sources are all structured differently so it’s tough to just CTRL+F the answer you’re looking for.

Another issue with storing all of this great data separately was that it was often buried alongside irrelevant information. For example, one section of RFP questions had us digging through sales assets to find performance benchmarks. We assumed this information would be in the product documentation in Confluence.

We were wrong.

One of the tools provided to us was an RFP management system our customer had used to store FAQs and previously-answered questionnaires.

We started here because we thought that the previous questionnaires would have relevant answers we could just copy/paste. But we soon discovered that every answer we found was similar in meaning but just different enough that we had to rewrite it. The time spent in this tool was a little over 2 hours of searching for and comparing similar answers.

Going down the knowledge base rabbit hole set us back quite a bit and taught us a few things about the state of RFP response software:

Validation is a key step in any RFP process, especially when it involves subject matter experts (SMEs).

After completing our portion of the questionnaire, we had a Sales Engineer and an Account Executive review it. Technically, this only took them 1 hour each in combined review time, but it actually took 2 days to get this done because we needed to wait for our colleagues’ schedules to free up.

This is probably the worst part of the process because it was out of our control.

It’s tough to plan around people’s schedules and in this case we think we got lucky. An RFP can involve 3 or more people, requiring you to juggle calendars for your sales, product, IT, compliance, and sales engineering teams.

Our calendar ended up looking something like this:

Alright, so this took less time than we expected. According to Google, the average proofreading process could take ~50 words per minute, so in our case we expected to run through our 11,000 word response in about 3.5 hours.

We knocked it out of the park.

It took us about 45 minutes to do a complete review, cleaning up any grammar and spelling issues along the way. Spellcheck did much of the work, but it wasn’t able to understand most of the tech jargon, product names, and acronyms we used in our responses.

Between searching, writing, collaborating with teammates, and reviewing the final product, we ‘landed the plane’ with 12 hours of physical work and a turnaround time of 3 days.

Our experience completing this RFP manually was painful and we never want to do it again. We gained a newfound appreciation for the teams who do this on a daily basis.

The response process is a grind. It takes patience. It feels like a marathon, but you’re also in a race against competitors. Automating it creates a huge competitive advantage, so let’s see how we can do that.

As a next step, we cleared out the answer column and uploaded our questionnaire into 1up. Here’s how were able to condense time spent on each step of the process:

Getting this process down from multiple business days to just under an hour felt good.

Here’s what that looks like: