What Is Proposal Automation (Really)?

According to Wikipedia, proposal automation software — also known as proposal management or proposal writing software — is software… 

“designed to help users develop proposals, presentations, and responses to RFPs. Proposal management software is becoming increasingly popular in companies that manage frequent and extensive proposal writing projects. Such software allows businesses to automate the more routine tasks while easily tracking multiple versions.”


This definition makes intuitive sense, but still leaves a great deal of gray area. After all, there are lots of ways to define a proposal. So let’s peel the onion a bit to get to a practical definition.

No matter the focus of your business, a Proposal presented to a potential customer is a strategic document, essential to the growth of the business; producing impactful Proposals is a key asset for many businesses. But what makes a Proposal successful is much more specific to its context, including your business or industry and the circumstances under which it’s generated. That means that the tasks that should be automated will differ too.

What are the major categories that Proposals can fall into? When you look at standard types of proposals, the two main categories that are cited in the industry are solicited vs. unsolicited. Solicited proposals can be further broken down into those requested formally vs. informally requested proposals. But how does that impact automation? 

Formally Solicited Proposals

The process for formally solicited proposals begins with a request from a buyer, typically in the form of a published RFx (Request for Proposal, Request for Quotation, or Request for Information) or an Invitation to Bid (ITB). What’s common among these various request types is that they are typically published publicly, they outline the buyer’s need, and they kick-off a competitive process where each vendor responding must think not only about answering the questions, but doing so in a way that positions them most compellingly to the buying entity.

But the information requested in each of these formats differs fairly significantly, so how you’re going to construct your response to each will be different as well. For example, one of the most important parts of an RFQ response is a price quote, so the helpful automation in this scenario will be your quotation capabilities and marrying your quote with a short but persuasive narrative on the other factors that make your products the best (such as superior quality or short lead times).

RFP responses are typically the longest and most complex proposals that are constructed in the solicited category, but there is still a lot of variation in what is required in an RFP response based on the requestor (Federal Government vs. State-Local-Education (SLED) vs. Commercial businesses) and what product or service is being purchased.

Federal RFP responses provide companies with the least amount of flexibility by providing rigid restrictions on everything from font size to page count. And compliance with the specific requirements set out in Sections C, L and M of the RFP are an absolute must for your proposal to win the bid. In these situations, creation of a compliance matrix, mapping of the matrix to the project timeline, and control over the document construction process may be the most essential tasks to automate. 

Commercial RFPs can look like a whole other animal entirely, either allowing for creativity in submissions at one end of the spectrum, to entry of straightforward answers to questions in an Excel grid at the other end. Depending on the types of RFPs you’re seeing in the Commercial sector, the tasks to automate will again be different.

(To get a better handle on the differences between the various types of RFx vehicles, we recommend this article from the training firm, Negotiation Experts. While written to instruct buyers, it provides helpful insights for bidders into the thought process behind each type of request.)

Informally Solicited Proposals and Unsolicited Proposals

We’re grouping these two types of proposals together because there are many commonalities behind how they are developed. Informally solicited proposals occur most often when there is a buying relationship already in place, and the buyer indicates their needs to an existing supplier. Frequently it’s not a competitive situation, and the goal of the document is to reflect back to the buyer an understanding of their requirements, provide an overview of the work to be done, and establish an initial price point for the work or product set. 

An unsolicited proposal, also called a proactive proposal or sales proposal, is offered to a prospective buyer as part of an interactive sales process, where the role of the document is to reinforce the sales messages being delivered.

In either case, these documents are typically constructed by Sales and Business Development teams with a more sales-oriented message. They may leverage many standard elements, but also require customization to be persuasive to the client or prospect. These types of proposals are frequently constructed as slide decks or very visually appealing text documents.

What is often important for constructing these proposals is the ability to leverage a set of modular messages that are pre-produced or easily dropped into customized templates. Integration with CRM systems to include customer-specific data could be key. And ease of use is a must.

How to Think About Whether You Need Proposal Automation

Given all the “what ifs” we’ve listed, how can you think about whether you need Proposal Automation, and if so, what type of system? 

Start with understanding the work of proposal creation in your organization. Likely you’re producing more than one type of proposal (and maybe responding to Security Questionnaires and DDQs, too, which are often supported by a Proposal Automation tool). So determine your top use case and where you are experiencing the biggest bottlenecks. Repeat that same analysis for each proposal type where you are devoting significant effort in the organization. Then determine whether one (or more than one) solution will help you address your pain points.

You’ll still need to peel your own organizational onion, but you’ll have a better sense of where to start. And if this isn’t detailed enough direction, stay tuned for our upcoming guide on selecting a Proposal Automation solution. We’ll step through the process as well as talk through other considerations you won’t want to ignore.