Write a kick-butt proposal

When David Hitch wanted to establish an e-commerce site for his wholesale dry-cleaning supply business, he asked local integrators to send him proposals. Hitch dumped one of those proposals into the trash after reading two paragraphs. "It was too technical for me," he says. "I didn't understand a word they wrote." Instead, Hitch picked a Web developer whose proposal made it clear that he understood what Hitch intended to accomplish.

A top-quality business proposal rarely will get you the job. At best, it can get you into the running; the prospective customer will put your name on the "call these guys" list. But a mediocre proposal will land your heartfelt salesmanship in the bit bucket. That's equally true whether you're responding to a formal corporate RFP (request for proposal) or writing a one-paragraph response to an e-mail message that asks, "Hey, can anybody in town provide me with Web-hosting services?"

To uncover the most effective proposal techniques, we spoke with several service providers, as well as experienced customers who have waded through the resulting stacks of paper. In the end, we uncovered seven secrets to success:

1. Learn what they really want.

If you're lucky, your customer knows what she wants and can explain the requirements clearly. In that case, writing the proposal may be as simple as explaining how you'd solve the problem, showing why your company is qualified to deliver the solution, and providing a price and delivery schedule.

Even so, the requirements often have a deeper, unspoken level. "Every client wants to know how working with you will add value to their business, even though they'd never put that in the RFP," explains Kurt Seybold, a senior e-business consultant at Computer Sciences Corp. There's another benefit to describing the project's return on investment in your proposal. If your customer ever has to justify the project to her management, she'll be armed with the information to do so.

Yet, not every customer knows what she wants, or understands what she's asking for. If you think that's the case, don't be afraid to ask for clarification. If you want to find out what the customer is really after, ask what problem she's trying to solve.

2. Write to your audience.

The proposal that Hitch trashed was probably from someone who knew his technology really well. Before you start writing, determine who'll read your proposal and write to her interests, concerns and technical knowledge. Usually, that means emphasizing business benefits and explaining features, rather than a laundry list of the technical services you'll provide. "Don't let the engineers write the proposal," advises the business development manager for one successful Web developer. "They'll emphasize how instead of why."

The more visual you can be, the better—especially when writing to small and midsize businesses, as well as marketing staffs. Your charts should be functional, depicting how your solution integrates with the company's existing infrastructure.

3. Be concise.

Most proposals can communicate the essentials in five or six pages (with some optional paraphernalia, such as letters of recommendation). That's usually enough to communicate to the customer whether your solution is worth additional investigation. As the King said to Alice in Wonderland, "Begin at the beginning, and go on till you come to the end. Then stop."

Proposal length is less important than getting to the point. According to Vince Littler, who worked in procurement for an energy utility, "When proposals come in, two to four people may look at them initially in half a day, regardless of the contract size. After 20 minutes with each, it is plain who is attuned to the requirements and is working with the grain—basing the proposal on the sound parts of customer analysis. Those who don't do so aren't looked at again."

4. Sell them what they want to buy.

You won't succeed if you try to sell a product or service that doesn't address what the customer said she wants. On the other hand, don't just spit back the RFP's requirements. "That only tells me that you understood us," explains J.D. Runyon, a professional grant writer who has represented several government agencies. You need to strike a balance between answering the RFP qualifications, demonstrating your knowledge of the topic and presenting with an imaginative solution. "I look for solid experience with creative ideas," says Andy Handshaw, the business development manager for the Downtown Phoenix Partnership.

One way to present the proposal to your customer is to write it in the past tense. Tell a story that's placed in the future, a year after you've deployed the solution, and describe how it changed the company. It's more interesting to read, it can demonstrate resilience under pressure, and it encourages you to be more creative. But don't make the story a fairy tale; use this as an opportunity to show how your solution can cope with emergencies, which are inevitable.

5. Establish your credibility.

However brilliant the solution you propose, you have to convince the customer that you can pull off the project. Throughout your proposal, demonstrate your knowledge of the topic, with projects of similar size and scope. "Show me that you know what you're talking about, that you've lived with it," says Runyon.

Provide relevant, recent references. "Don't make me search—give me the contact information," Handshaw says. Because plenty of customers will check out your workmanship before they call you, ensure that your own Web site accurately reflects the work you've done and links to reference accounts. If your references show only small businesses when you're bidding on an enterprise solution, the customer might not believe you can deliver on the deal.

Although business contacts are always valuable, don't cash them in if you're responding to a formal RFP. Even if you get the job, it will come back to haunt you. One procurement officer told us, "If I'm forced to give you the job, I'll kill you on the audit. I'll make sure you never get another contract."

6. Build in contingencies.

Anything that can go wrong with a contract will do so. Make your plans with Murphy's Law firmly planted in mind, because you'll have to deliver what you promise in the proposal. What if the engineering staff's time estimates are wrong? How will your company cope with the results? Think about the legal and business development issues. "Anytime I hear a client say that something—the firewall, getting the art, whatever—isn't going to be a problem, I know that it will," says one site developer. "I add a month to the schedule every time I hear that phrase."

7. Know when not to bid.

Learn which customers you don't want, and which RFPs aren't worth your time. Is the project too big or too small for your company? Is the customer too confused about her requirements? Is this RFP merely someone doing the required paperwork to justify a vendor choice that she's already made? Don't look at the money you'll lose from the job. Look at the money you'll save by not bidding, and the ultimate grief you'll save yourself.