# Elements of a good proposal

.jpg)

**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.

## 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.

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.

"We were supposed to deliver an egg yolk - there was no word of any plates or bowls!"

## 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.

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, and many customers run away when hearing the quote. 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.

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 hard, 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".

### 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 than 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.

Stay tuned for the next time 👋