Sunday, February 15, 2009

Anatomy of a proposal...telling a story in your solution

Part of the Learn to Write Proposals online proposal guide.

Telling the story of your solution


You may have the best ideas and products in the world…but how do you put them into words? How to write a business proposal about them?

Easy…tell a story. I suggest that this is done in a three parts solution section in your business proposal.

1) Win Theme

Let the client know straight away why you are the best and most appropriate supplier. What is it that sets you apart? See here for our article on win themes

2) Description, benefits and evidence

State what you can do and how you are going to do it. Explain what your products and services can deliver and what difference they will make. Go into the detail of how it works remembering with each function or output you describe explain what that means for the client – how does it help them? How is your bid going to solve their business issues? Then, as in all good business development provide supporting evidence to back up your case. Testimonial and experience go a long way to proving you can deliver (as you've done it before) and also giving you credibility to the client.

Most importantly – make it clear what you are proposing. Don’t be vague, be specific and relevant.

3) The user experience

This is the storytelling part. Explaining how a typical user will use, or has benefited from, your product or service is incredibly powerful. Stories aren’t that often used, but can convey a message to evaluators that has impact and real meaning to them – particularly not-technical evaluators who may gloss over technical sections.

It allows you to insert in the minds of evaluators an image of success, ease-of-use and quality that a description of pure functionality doesn’t allow. This is the soft approach describing the benefits through the stories of user interaction.

Don’t make your stories too long – 150 to 350 words should do, but if you wish include two or three from different viewpoints; the end user, the manager, the technician, etc. User experiences can be used if you don’t have supporting evidence of your solution’s capabilities. Instead, provide a story of a user and how they needed something (problem) what they did with your product (describe a favourable scenario) then finally how easy it was to get the desired outcome (benefits). Although this isn’t real evidence it describes to evaluators how it will work in the real world – a very powerful device.

Another way to use stories is to provide real evidential anecdotes. These could be used as mini case studies to back up your solution. Use a narrative style to explain what the client’s issues were, how you won their work, what you did and how it benefited them.

Remember, when using scenarios and stories, alter the style of your writing to be more narrative and friendly. Use the third person and imagine that you are preparing text to be read out aloud.

Next...We'll have an example story for you...then onto schedules and project plans.