Elements of a good proposal

Howdy! 👋 Today we focus on the content side of things. What sections and elements should your proposals contain? What to avoid at all costs? Some practices we find good and bad will be outlined, so let's get to reading! 

Utility of a proposal

Despite a seemingly obvious purpose of any business proposal, one must consider that the actual goal is different for both parties.

The receiver wishes to get concise, easy to read data and searches for arguments for and against a given proposal. Not just the cost, mind you, though this is important indeed.

The proposal maker (seller) aims to convert. They want as many proposals as humanly possible to get approved. If a data set shows clearly that including or excluding something simply works - they will do it. The actual practices vary between industries. For example, companies offering gas and electricity have found out that simply sending a renewal proposal to a big receiver is not enough. Renewals of this sort are treated as regular bills and often overlooked. Hence they applied some *very* strong wording, going as far as to threatening lack of light and involvement of debt collectors. Yikes.

1. Background

IT companies are, luckily, less extreme. Since projects differ in scope, most often their proposals contain a summary, an abstract or a background - a restatement of the end customer's needs. No matter the name, these may had been established via phone, e-mail or during a meeting, and a short summary serves to ensure the customer that yes indeed, this software house, has an idea of what they will be building. From the offering company's point of view, this small but major section is the key to avoiding huge misunderstanding that can destroy  a project later on.

Background does not have to be in the proposal document itself - it can be inside an attachment or e-mail with the proposal.

If a specification was provided by the customer or worked out together, it can serve the purpose of a background. As long as at least a single sentence of very general "what we're building" is provided - you're good to go.

The typical length of a background is around 200 words.

2. Time & money

The meat of the proposal and what the customer will be looking at is usually WHEN and HOW MUCH. These don't have to be 2nd in order, but are definitely at the top of importance.

Avoid providing summed numbers 1st. If I approached you and said "I will build the app you dream of in 2 months and $200K budget" you'd probably find such terms outrageous. 2 entire months is a lot time, and there are certainly companies willing to code cheaper!

In reality, think back to all the IT projects you have requested or made for your customers. Many of them took months indeed, and chances are, some were even more expensive.

Price and time depend on the scope, so state the scope first!

This can't be stressed enough. First, list all the modules and things the customer will actually get, outlining the effort needed at every step. First the small chunks, then the bigger ones, and the final sum at the very end.

Big numbers are scary, any many customers run away when hearing the quote. That's because they don't have full knowledge from where the cost comes. Always underline that:
‍

• They're getting expert, veteran personnel for their project
• Tools can be rather expensive (especially IDEs and PM tools)
• The project is actually made up of a lot of small, cheap chunks (screens/modules/microservices)
  ‍

A properly broken-down estimation that goes piece-by-piece and then shows the sum is usually the way to go. Online tools really shine here, as they allow for expandable sections. This allows the customer to dig into the details if they want, but not suffer from overbearing amount of numbers if they don't.

Time is very easy if you operate based on work hour estimates to ballpark costs. Having a nifty "X hours" next to each line leaves you with a task of - gasp! - adding them together to get the final result. Not too had, eh?

If you want to get really fancy and close more deals, consider the following: break the time into smaller chunks as well. Something along the lines of:

• 1 week - UI design
• 3 weeks - MVP
• 4 weeks - Alpha version only for customer
• 6 weeks - Beta version for select users
• 8 weeks - Launch

Notice that intervals between each milestone take just 1 to 2 weeks. For software development it's hard to regard this as "too much time". And you know what? It's exactly 2 months we have mentioned at the start of this section. It does sound more manageable now, doesn't it?

Some companies go as far as drawing simple timelines with milestones.

3. The why

Chances are, your customer will ask more than just your company for a quote. For some projects these offers will end up in similar figures and time frames. You never know if and when this happens, but it's good to be prepared, just in case.

Spoiler alert: Since the customer has talked to you, they already like something about you.

This means that you don't have to think hard on this section. If you had the foresight to ask what caught the customer's attention in your company - you're good to go. If not, why not simply ask? Providing this rationale and reminding them why you are a good choice is often beneficial to both parties.

Similarly to background, you may wish to avoid clutter in the proposal proper by moving the rationale to an e-mail with the proposal attached or a separate attachment.

4. The how

This point is the most glaring and obvious omission found out in the wild. I have seen way too many companies supplying a decent proposal and leaving things at that.

What I allude to here is not just the sales process. It's quite obvious that after radio silence from the customer a salesperson will ask them "heya, is the proposal we sent you okay?".

Give the customer a clear and easy path to proceed

Your proposals might be great. If the customer takes a look at them and finds them great as well, for heaven's sake, give them an option to simply say "Hell yeah!". Preferably something even easier then saying "if you find this good, you call us or send us an e-mail". A single button leading to quick online signature is definitely a good practice. If you charge anything upfront, a quick online payment gate is also much appreciated. Just remember to take money after the contract is signed.

P.S. We're introducing a quick-convert feature to Apropo soon as well. Follow our Facebook, Linkedin or Twitter for the announcement once it's done.

Stay tuned for the next time 👋

‍