Boilerplate language: time saver or huge risk?

In my time working with clients across a variety of business development teams, I often run into the same challenge. Whether I'm stepping in as writer or proposal manager, my client counterparts are always making apologies for not having a better library of proposal resources.

What they're often talking about is documents that can build a boilerplate proposal. They like this term "boilerplate." I think it connotes something they can run with. To me, it's the worst visual ever. Boilerplate language is stale and useless. It's context ignorant, able to be reused over and over again. And it means nothing. At best, it's outdated and offers no real value to creating a compelling proposal.

So, obviously I have thoughts. But let's take this more in stride. What are the advantages and disadvantages of having a library of boilerplate language?

Advantages

• Efficiency - having language to pull from can speed things up, especially if the alternative is explaining every concept from scratch.

• Consistency - especially when you are hiring consultants as technical writers, giving them a jumping off point to help explain how you talk about standard approaches can be helpful.

• Accuracy - particularly for past performance and capacity information, having a set archive could help ensure that actual results and the latest information is being used (but only if it's kept up to date).

Disadvantages

• Stale - every proposal benefits from the fresh energy of a fresh writer, and pulling too much language off the shelf can leave the proposal feeling stale and disjointed.

• Wrong, outdated - this is the biggest killer I see, where no standard language seems to outlast the current proposal process as accurate.

• May be too generic - a good writer can avoid this, but one can also lean too heavily on boilerplate language and neglect delving into the details.

• Creates redundancies rather than nuance - pulling together sections of boilerplate language can easily lead to repetition and redundancy, where a fresh look could more carefully allocate the page limit to the most important information.

So where do I land? I suppose there's an argument for some boilerplate. You could build a library of white papers or marketing materials that have language on technical approaches. You could have a standard pool of resumes for people commonly assigned to project teams, or current certs and reps that you expect to need to submit.

The biggest challenges is ensuring that your boilerplate language is more up to date than the last proposal you worked on. I have yet to see a team actually make this happen successfully. Have a success story? Share it in the comments so we can learn from your wisdom!