Link Search Menu Expand Document
Countable Ops Manual

Proposal Writing Process

Table of Contents

Purpose

To clearly outline the process of writing proposals.

Scope

Extensive process coverage with multiple sub-lists; might benefit from being further broken down and reorganized.

Process

In brackets, we indicate the approximate time to allocate (not actual effort, just time to leave open)

  1. CAPTURE - find RFPs you can win (This should be happening all the time)
  2. PRE-QUALIFY - look a bit deeper (Score in our OPPORTUNITIES sheet)
  3. QUALIFY - (5 days) (ask questions as soon as possible after deciding to write, wait for responses)
  4. DRAFT - (2 to 6 days) (coordinator creates working doc right away, tags people in based on roles and expertise)
  5. REVIEW - (2-3 days) (use an external/impartial reviewer to simulate grading the proposal)
  6. REFINE - (1-3 days) (incorporate requested changes, saving time for one major refinement/copyedit)
    • Note: we’ll now observe a content freeze one full day before submission to allow for this)
  7. SUBMIT - (1 day)
  8. LEARN - save any feedback we get on RFPs in the same folder; update this document as we learn

Further notes to the above process points:

  • Reserve the last day for polishing (no new content contributions, by design)
  • 48 hours before the deadline is the last point we can do the offiical review/scoring.
  • For contributors, the coordinator should indicate what portions they should look at. Most people don’t need to read the whole thing.
  • Provide some indexing on what documents we have, for easier navigation of the repo?
  • By the 48 hours mark, a good quality version with all content and a lens to evaluation (in navigation) should be present.

Scoring Opportunities

In the Opportunities (SCORE) spreadsheet, we allot Pipeline % in the following manner:

  • When we’ve decided to apply for an opportunity, set it at 20%
  • When the application is clearly moving forward/we’re a frontrunner, set it at 50%
  • When we’ve received the opportunity, set it at 100%
  • If we’ve lost the opportunity, set it at 0%

1. RFP Lead Capture

Record the RFP due date, organization and link in a spreadsheet, along with its score as follows:

  • 20 points if the RFP is in your niche of products and services.
    • Partial points if the industry matches, but not the exact service/product (it’s nearby).
  • 10 points for tech match. Mention of any from: Django, Node, Postgres, Vue, React, javascript, web mapping, etc.
    • Deduct points for .NET, SAP.
  • 10 points if the final result publicly browsable, for portfolio value.
  • 10 if scoring criteria is explained in the RFP.
  • 10 points if Scrum or Agile is mentioned, partial (5) points if it the project is phased with a prototype.
  • 20 points for contract size. 0 for $10k, 5 for $20k, 10 for $50k, 15 for $100k, 20 for $200k and up, 15 for over $500k, 10 for over $1M.
    • (This reflects our ideal project budget range of $100-500k)
  • 10 points if the RFP offers losing proposals a debrief on the scoring.
  • BONUS points if it’s an existing relationship, we can keep the IP for future use, or open source it, or some other circumstance.

50 points is the cut-off for moving on to PRE-QUALIFY

2. Pre-qualify

  1. Review all evaluation criteria. What is the estimated score we could get on the project? Is it within 5% of frontrunner’s estimated score? If not, move on.
  2. Look deeper at the proposal to see if it’s in your niche and you have a uniquely great offering that will both let you execute well and develop your niche stratgically. If not, move on.
  3. Estimate bid size, based on beating the frontrunner’s score by 5%. If there’s no budget for the project, estimate one based on past similar projects by the frontrunner, prospect, and software category. Is this amount profitable? If not, move on.
  4. Is the total timeline under 10 days? If so, the proposal is probably “wired” to be given to a specific company. Skip it.
  5. Determine who is the “frontrunner”, most likely to bid and win the project. Is there a strong off-the-shelf solution which is compatible, with a local supplier? What is the industry “state of the art” in this area. What is being used by others? What companies have won similar projects in the past. What vendors have the client used for similar projects before? Who has beat you on similar RFPs before? Public sector projects will often list applicants directly, or you will be able to identify them in the Q\&A addendum shared with the group a few days in.

3. Qualify

You’ll want to ask a few questions before writing. If possible, get on the phone with someone in order to make a “conceptual agreement”.

The goals are to get the interest and then the guidance of the buyer, and understand their priorities.

Demonstrate a genuine interest in the outcome of the project, build trust, and fill in gaps regarding how well the proposals fits.

  1. If any of the critical info in our capture questions is unknown, ask it now (approx budget, technology options, can we use Scrum,
  2. Ask: What is the most important benefit to this project for a successful outcome?
  3. Make a super clear, one sentence statement of your unique approach. Ask the prospect if it’s a good approach.
  4. Ask questions to clarify any scoring criteria so you’re 100% clear what they each mean.
  5. Ask questions to help you understand what the evaluators are looking for.
  6. If the project solves a real problem, there should be an existing (partial, bad) solution. Ask “How are you currently getting by without this solution? What process will we be replacing?”.
  7. Get clarity on anything that might disqualify you, if you’re unsure about any of the mandatory criteria.
  8. If any key consideration is left out of the proposal, ask if it’s important the product be: Secure, Flexible, Scalable, Low maintenance or total ownership cost, Durable data.

Also, create several touchpoints (LinkedIn, email, phone) to get to know them before you write. If there’s a way to demonstrate your system working, that is ideal.

Attend any pre-proposal call, webinar or meeting in order to meet the evaluators.

Do any further research to have information you need to decide to write.

4. Deciding to Write

With all the above done, you should now determine whether to write, or move on to a new RFP. You should know your approximate chances of winning, the value of the contract, and your alternatives, and make the best choice.

Are you the frontrunner? If not, can you propose a solution that is better in some way that matters to the prospect?

The answer to one of these questions should be YES if you want to write. You must believe you have a good chance of winning based on all the information so far.

Proposal Writing Roles

Assign the key Proposal Writing Roles to people at the top of the proposal draft.

Getting Organized

  1. Create a folder for the proposal in Google Drive
  2. Save the original RFP and any supporting documents there.
  3. Past the mandatory and scored criteria from the RFP into a new Google Doc (in the color RED) to start a proposal outline (see below)
  4. Include, at the top of the outline (in the color GREEN): who is filling each of the Roles defined above, links to similar successful proposals and notes on their score, any answers to questions we wrote, or notes from the qualification process.

Outline

Copy most if not all of the original proposal into a Google Doc, invite everyone who will work on it, and proceed to copy the structure of the original RFP as your proposal structure. Write your proposal inline to the original RFP.

  • Write responses inline to the original RFP and mirror RFP document structure. Then, add the following sections if they’re not already there, but keep them very small/simple.

    • In the intro (if applicable), summarize the real needs underlying the proposal.
    • Who is the buyer’s customer and how will they benefit?
    • Indicate how technology has changed recently to allow a better solution, and how we deliver that.
    • Indicate a low total cost of ownership, and side benefits to their business. Indicate they’ll want to use the new system all the time.
    • Indicate why your company is specifically interested in this project and its results.
    • What makes your solution unique?
    • High level summary of your approach, with evidence from past projects that it will work.
    • How will a successful outcome be measured?

Writing Style

  • Optimize for clarity, not sophistication or length.
  • It should be clear how every sentence relates to the evlauation criteria. If any sentence is not clearly providing evidence or building trust, remove it. Efficient communication that knows just what to leave out is a great demonstration of confidence and expertise.
  • Include a visual or diagrams (about one every 2 pages)
  • Use the active voice, with optimistic tone.
  • Mention the customer, more often than you mention your own company.

Angle

  • What really matters (hidden need), and why will you deliver it better than the other bidders?

    • How is your approach different and will lead to a better result?
    • How does this project relate to your mission, values, and your team’s experience? Include a couple stories about this, to create a special connection to the project.

In particular, if you’re not the frontrunner, this is critical. Plant a seed of doubt about the frontrunner and build on that.

A good one is that as a newcomer you can provide more customization because your product is still more flexible and early in its development lifecycle.

If you are the a frontrunner, point to your past successes. Your angle is to create concern that other solutions don’t have as much evidence of ability to deliver.

Team

Include photos and some personal notes that relate each team member to the project, and their relevant past successes.

Case Studies

  • Highlight their industry, location and other parts of their identity.
  • Draw attention to the relevance of your prior work.
  • Leave out details that don’t indicate how similar your prior projects are to the current RFP, or how successful they were.

Platform

List features of your platform that align with the real problems behind the RFP and the stated criteria, and for each feature, list the benefits which solve those problems and provide evidence.

Addressing Criteria

If the RFP has scoring criteria already, this should be your focus.

Don’t try to be clever and make up a proposal structure based on your domain knowledge.

Instead, write your proposal inline to the original RFP, and include the original wording in a different font. This will make it easy to mark, clear you’ve missed no mandatory criteria, and clear how to score you.

In each section, the person creating the outline should make a note of the person from our team best qualified to write that section so it’s very clear who is contributing each section of the proposal. Mention and assign that person using a Google Docs comment.

There are usually 2 types of criteria. First, a list of things that could disqualify you. Second, a list of categories where you can score points.

For the first category, make a checklist and make sure you’re 100% confident in those items being checked off before you submit.

For the actual scoring, it’s likely the prospect has a committee reviewing scores, and likely they’ll even be “blind”. This means they’ll be worried about being perceived as unfair, and will usually follow the criteria quite literally.

For scoring criteria that are clear, focus on creating the most truthful answer that will get the highest score. Get a “proxy” person to score you, and iterate to improve your score.

For scoring criteria that are less clear, there’s going to be more subjectivity. Find out what probably matters most to your evaluators, going back to the questions you asked earlier.

5. External Review Step

  • Get an external reviewer to pretend to be the buyer.
  • They must evaluate according to the official criteria.
  • Refine before sending.

6. Submit

Submission platforms can be buggy or broken sometimes, so get familiar with the platform you are submitting on and click through to the last step right away.

Make sure you leave enough time to submit: we recommend submitting 1 day in advance in case something goes wrong.

7. Learn

The best way to measure proposal win-rate is simply to measure the “revenue won” because it reflects the proposal value. Knowing your overall percentage is helpful too, in order to evaluate our ability to win a given new proposal.

Get a debriefing whenever possible - If you lose, always ask for a DEBRIEF with the evaluator and a breakdown of our score. This is one of the most valuable tools for winning the next proposal.

Balance risk-taking and revenue.