Sometimes after you make all the changes needed to customize boilerplate proposal files, it ends up taking longer than it would have to write it in the first place. It sure would be nice to know if that is going to be the case before you start. We have developed a model that shows the factors that determine the extent of the changes needed, so you can determine whether boilerplate is really an option for the type of proposals that you do.
Whether it makes sense to use boilerplate in your proposals primarily depends on:
- The type of offering. If you are proposing a unique or engineered solution, you may not be able to employ re-use material effectively. Even if you are responding to similar requests, the number of edits required to adapt it may exceed the time it would have taken to write it in the first place. If you are proposing a product or a commoditized service, you may be able to employ re-use material effectively, if your customers' concerns are also consistent.
- The consistency of RFPs. If your RFPs are very consistent, you may be able to use re-use material effectively. If your proposals don’t have a written RFP, then whether you can effectively employ re-use material will depend on the consistency of your customers’ concerns and evaluation processes.
In addition, the following concerns can also impact whether or not using boilerplate works in your environment.
- The consistency of customer concerns and evaluation. Even if you are proposing the same thing, if your customers have different concerns or follow different evaluation processes, you will need to customize your response to reflect it. Since your proposal should show how your offering responds to the customer’s concerns, a difference in customer concerns can totally change the context and how you describe your offering.
- The strength of your writers. If you have weak writers, you may want to rely more on re-use material. Instead of training and guiding them through the process of creating winning proposal copy, it may be easier to write something good once and then re-use it often. However, this can be dangerous. Even if you provide detailed checklists and guidance, if the writers are weak to begin with, you may find that you are submitting proposals that are not customized and your win rate will suffer.
When you look at the nature of your offering and the RFP, you can actually see where boilerplate might be applicable.
This model shows us that:
- Boilerplate works best when you are offering the same services/products on every bid and the RFP is the same each time.
- Boilerplate requires time consuming edits when you offer different services/products on every bid and the RFP are different each time.
In between these are two conditions where boilerplate may or may not be a good solution:
- When you offer the same services/products on every bid, but the RFP is different each time.
- When you offer different services/products on every bid, but the format, structure, and content of the RFP is the same each time.
The most important thing to remember is that there is a difference between being similar and being the same. Most of your offerings and most of your RFPs will be similar. They may be about the same things. But unless they ask for exactly the same things, in the same order, using the same terminology, and evaluate them against the same terminology, the response will have to be different. The amount of that difference is what determines whether boilerplate helps or hurts.
