The problem with proposal re-use repositories

Here's the problem with proposal re-use repositories. Imagine two customers who both want the same system, application, product, service, solution or whatever you offer. The specs are the same. However... One customer is decentralized, another is centralized. One customer has a formal culture, one is informal. One wants innovation, another is risk averse. One wants to manage the staff on the project, another doesn't want to be bothered. One is value conscious, the other is price fixated. One has clear authorities for making decisions, another tends to be consensus driven. One values punctuality, another has higher priorities. Now, how should you position the benefits of your offering? What results will it deliver? How will it be implemented? What does the customer care about? What do they want to see in your proposal?

Context matters.

Go ahead and create your proposals from a re-use repository. I'll write a response that is compliant with the same specifications, only I’ll position things in the right context. My proposal will speak directly to the customer’s goals and desires. Mine will take longer to write. But which do you think will win?

Pretend you are the customer. Which would you pick --- the generic repository response or the one from the vendor that did their homework, doesn't treat their customers like interchangeable parts, and addresses your specific issues?

Never mind that having a re-use repository will probably result in submitting proposals that contain errors and will cost you far more to maintain than they will to create. It’s easy not to worry about it because most people don’t bother to maintain them! They are willing to spend money on software, but not on the data that will go into it. You can also ignore the fact that when you build your proposal process around having a re-use repository, you pretty much guarantee that people will never customize their proposals as much as they should. Forget about all that and just focus on whether it helps or hurts your ability to be competitive.

When you send all your customers the same proposal text, you guarantee that it will not be written to the right context for every one of them. And yet the winner will be the one who does the best job of putting their proposal in context. Instead of submitting a proposal that is not competitive, you should just not bid.

Then again, maybe the bid is not competitive. If all of your bids are not competitive and the proposal is just a formality, then setting up a re-use repository might make sense.

Proposal re-use might also make sense if:

• Your margins are so slim that you can’t afford to prepare a proposal that is specific to each customer. What you are really trying to do is just take orders. If your customers are okay with that, then a generic proposal can result in orders.
• The customer doesn’t care about you. If you supply a commodity, such as a product that the customer can get from any reseller and they don’t already have a relationship with you, then they might not care where they get it from. They don’t want to read your proposal. They just want to get the product, and probably as inexpensively as possible. A generic proposal won’t offend them or lose you points so long as it satisfies their ordering process.
• Every customer gets the same offering. You might think that a description will be the same every time, but it really shouldn’t be. The goals, benefits, and results that should be addressed in every paragraph will need to reflect the customer’s specific context, just like in the example above.
• You don’t know your customers well enough to put things in context for them. For most companies this means that instead of using generic re-use material, you should get to know your customers in order to be competitive. However, if you are in a market where you can’t predict who the next customer will be and no one knows the customer, you may be able to get away with re-using proposal narratives.
• The evaluation is pass/fail. When the customer performs a pass/fail evaluation you don’t get any points for being better.
• Your customers require tons of data. Factual information can be recycled. You’ll still need to put it in context.
• You don’t win your proposals through positioning or strategy. This probably means that you compete on price. If how you strategize and position yourself in order to win is different for each customer, then each proposal must reflect that or else you have a strategy without any implementation.

There is a “middle of the road” strategy. If the description of your offering is the same every time, then you might be able to separate where you talk about positioning and strategy from where you describe the offering. You might be able to address the customer’s specific context in the cover letter, or address benefits and results in a special text box at the beginning of each section. Maybe. The problem is that it is difficult to claim with credibility that your offering delivers specific benefits and results when the description of it is generic.

You should never seek out a proposal re-use solution because you don’t want to go to the effort of writing a proposal or because you are understaffed. The former would be like saying you don’t want to go to the effort of competing, and the latter is like saying you’re not staffed to be competitive. Neither of those issues will be solved by a re-use repository.

If your resources are strained, then you should consider not bidding. It’s better than submitting a bid that is not competitive. When you cut corners in order to respond to every “opportunity,” you respond to every opportunity with a less competitive proposal. Wishing it were otherwise won’t change the facts, nor will “trying harder” or wanting it more. The only way to compete against an information advantage that is delivered in writing is to deliver a better information advantage in writing. You will win more business by only bidding the ones where you have an information advantage and the resources to demonstrate it in writing.