The process for responding to RFPs in the software industry has to be one of the most inefficient processes in today’s business world. Software vendors spend days, if not weeks, preparing responses which require a virtual a scavenger hunt for answers to obscure questions. The answers are packaged into 50-200 page long documents that are a nightmare to format and rarely read by the customers. And the bulk of the pain associated with the process is not shouldered by the sales representative leading the deal, but usually by the sales operations or enablement teams tasked with responding to RFPs.
Below are six painful aspects of today’s software RFP process.
The Same (but Different) Questions Appear Over-and-Over Again
There is a high degree of overlap in the questions that customers ask software vendors in RFPs. Almost every RFP asks similar questions about the company, customer support, security, business continuity. The repetition between RFPs should be a productivity booster. After you answer a question for one customer you should be able to place it in a library of answers that can be used for future RFP responses. However, the productivity benefit is often discounted because there is no standardization in the way the question is asked from customer to customer. As a result, software vendors must spend hours reviewing each question one-by-one to manually match it to the most similar questions from prior RFPs (or their answer library).
RFPs are Resource Hogs
RFPs consume a lot of resources within the company. Yes, there is a high degree of overlap in the questions asked between RFPs. However, with every RFP there are always a subset of 10-15% of the questions that have never been answered before. These new questions usually require RFP managers to go on an information “scavenger hunt” across the organization. “Who can tell me the current employee count for all our offices in Southeast Asia?” “What is the mean time to repair trouble tickets classified as Sev-3?” “Do our European Data Center providers reside in any known flood planes or airport flight paths?”
Most customers do not provide any guidelines on the desired length of a response. As a result, many sales teams will err on the side of providing more detail than less. It is common to see page-long responses to questions that could be concisely answered in a few sentences. Some sales teams will include tables, charts or complex graphics as visual aids to accompany the questions, further lengthening the documents. As a result, the typical software RFP response quickly becomes bloated subsuming upwards of 50, 100 or even 200 pages.
The Formatting Nightmare
Some customers request RFP responses be submitted in Microsoft Word. Others want the responses in a Microsoft Excel spreadsheet. A handful want the answers inputted into a procurement or sourcing application. The result is a time-consuming process of cutting and pasting answers from your answer library into the customer’s document. Regardless of whether the response is in Microsoft Word or Excel, formatting is always a challenge. Most sales teams struggle with tasks such as formatting tables, inserting images and applying footers. As a result, after all the answers to the RFP are assembled, there is usually a multi-day effort to clean up the formatting in the document. Someone must go through to insert a table of contents; standardize the fonts; and crop the Windows menu out of screen shots.
Customers Don’t Read the Responses
Most sales leaders are skeptical that their customers actually read the proposal responses they submit. But can we blame them? Who has time to read 50-200 page responses from 6 to 10 different vendors? What the customer is really looking for in the responses are the outliers. How do the different vendors compare? Is there any real differentiation? Or do they all offer the same features and functionality? Customers are also looking for any red-flags. Are there any negative responses to questions that might pose an information security or regulatory compliance risk? But with 50-200 page answers the differentiation is not easy to discern. Customers must review each answer one-by-one, comparing the responses between vendors to identify any differentiation or risks. Most customers don’t bother, instead focusing on the easily comparable quantitative data such as pricing and implementation timeframes.
No One Wants to Own the RFP
At most software companies RFP ownership is about as sought-after as a venereal disease. The responsibility bounces like a hot potato between sales operations, sales enablement, marketing and sometimes product management. One thing is almost always certain – the sales representative (who owns the deal and gets the commission) – typically does the least amount of work in preparing a response. In my experience the sales rep leads the pricing and the executive summary, never bothering to read the remainder of the response. Sales leaders don’t want their reps writing RFP responses. They want the reps spending time managing the customer relationship and quarterbacking the deal cycle.
The big question is how do we fix this mess? More thoughts in my next post.