BTS: My Exact RFP Response Creation Process
Ever since I started working on proposals, I’ve had very few that ran right up to the deadline.
I do everything possible to avoid those situations because they are incredibly stressful, especially when dealing with RFPs; if you miss deadline, you’re out of the running.
I hate working up to the last minute because it means that we likely are behind on establishing a clear win strategy, content came in at the last minute, or changes were being made to pricing and/or the solution right up until it was time to hit submit.
Since those last minute changes can dramatically affect the quality of your proposal (and sometimes result in costly mistakes), I follow a clear process each time that allows me to establish strategy from the beginning, get the content started early, and hit deadlines time and time again.
If you’re sick of pulling your hair out or anxiously watching the clock tick down, check out the behind-the-scenes look at my exact RFP response creation process that I’ve been using for years.
My Complete RFP Response Creation Process
Step 1: Find the Deadlines and Submission Details
Before starting a proposal project or even reading any content in the RFP, I first search the document to find the applicable deadlines and submission details. For shorter documents, I can usually scroll to find this information quickly, but if it’s a long, 100+ page RFP, I’ll search “Deadline”, “Close”, “Date”, or other related terms until I find the deadlines.
There are two main deadlines I watch for:
The RFP Response Deadline. This is the date when the proposal is due, and the one that most impacts the project.
The Question Deadline. Most of the time we’ll have some sort of question to ask the buyer, whether it’s administrative or solution related, and it is essential that the question deadline has not occurred already. For small projects it can be possible to create a response without asking questions, but it’s usually needed.
While searching for the deadlines, I also search for the submission details, which means how they want to receive the proposal. Nowadays most buyers want to see an electronic version, typically a PDF, either submitted via email or through a portal. However, there are still some agencies (normally at the local government level) who want physical copies, which actually bumps up the final deadline because we have to account for printing and shipping.
Assuming these aren’t immediate red flags that the project just isn’t possible, I move on to Step 2.
Step 2: Review Proposal Requirements
Here’s where I look for what they’re expecting to see in the proposal. Most RFPs have some sort of section that details what you should submit, often with questions that must be answered.
In this step, I read through those questions and the overall format expectations to make sure it is something that can be completed by the deadline discovered in Step 1.
If it’s doable, then I move on to Step 3.
Step 3: Read RFP, Document Questions, Create Project Management Plan
Here is where the RFP gets my full attention. Now that the project is viable, I read through the ENTIRE RFP, front to back. That includes the contract section, legal information, forms, pricing, technical details, everything. It is essential to read the entire RFP, not just the information in Step 2, because sometimes required content and/or forms will be hidden in other sections, often the contract section. If you skip over this, it’s possible to miss out on a key piece of information, not include that in your proposal, and be tossed for noncompliance (which is a situation that no one wants).
While reading the RFP, I take notes, highlight key pieces of information, and add comments on any sections that I need to pay attention to later (such as the submission requirements). I also always save a second copy of the RFP with my notes so I have the original, unedited version available throughout the project.
After reading the RFP, I have a good idea of what all is required and how we should proceed. From there, I create a project management plan, often in Excel, or in Word for simple RFPs. For that, I map out the schedule, the tentative dates for deliverables and key meetings, and I take note of when we will need to complete the final review in order to print for submission or finalize for a digital submission. You can see an example schedule below.
I share this plan (I usually call it a task list) with key stakeholders. It includes the project schedule, key deliverables (i.e. sections of content), questions, and notes for the order of the proposal (i.e. if they ask for forms to be first and in a certain order, I document that). It’s easy to have all of this information in one document and then I can update it throughout the project.
Step 4: Hold Kickoff Meeting
Once the plan is in place, I schedule the kickoff meeting with all key stakeholders. Here we talk through the customer, the solution, the project schedule, and who will be providing what information. I have a set of questions I ask on every kickoff meeting.
Depending on the timeline, I may also include the proposal strategy discussion at the kickoff meeting (see below for details). If possible, I try to keep the two meetings separate, but with RFPs, sometimes you have too little time to devote a full meeting to both the strategy and kickoff.
Step 5: Create Outline, Basic Design, and Draft First Sections
With the kickoff meeting out of the way, it’s time to finally get started on the proposal!
I start with outlining the proposal content based on the proposal order outlined in the RFP. I then copy and paste the exact requirements or questions from the RFP into the appropriate sections so that we can write our responses below the question.
Once I have the questions and required sections within the proposal outline, I create a basic design of the proposal, if there isn’t a template (which is the case for many of my clients). I’m most concerned with setting the Styles for the text within the document (i.e. paragraph, Heading 1, Heading 2, etc.). This makes it easier to update the proposal later on, and it’s often too hard to design once all of the text is in the document.
After the design is created, it’s time to start drafting answers to the questions.
Step 5.a: Hold Strategy Sessions (timeline permitting)
If there is time for a separate strategy session, I typically hold that after the outline has been created. The strategy session focuses on identifying the unique selling points, overall proposal strategy, and competitive positioning that we should highlight in the proposal. For particularly complex projects, we might have a few strategy sessions. Most projects are able to have just one meeting (and often the RFP deadline is too short to allow for multiple).
If you have time, I highly recommend having a separate strategy session where you focus on identifying win themes and your key selling points.
Step 6: Manage Deliverables and Draft Additional Sections
With the strategy session complete and the first round of content created, we move into the “project management” phase of the project. Here the focus is on getting key information from the stakeholders and translating that into final proposal content. This step includes several status calls, many follow up emails, and drafting the remaining sections of content.
Step 7: Hold Review Meeting(s)
With the proposal draft done, we start holding review meetings to get feedback on the document.
Depending on the timeline, I may have one review meeting or a few. For longer proposals, it’s better to review in smaller chunks to avoid having a 4 hour meeting.
Before the review meeting, I send the proposal draft to all stakeholders. The draft is typically in Word, and I will add comments throughout detailing areas where I think we should add more content, possibly omit information, or that just needs another set of eyes.
During the review meeting, we talk through ways to improve the proposal (often addressing my comments in the document), what’s working, and anything else we can add that aligns with the win themes and competitive strategy.
Step 8: Revise
The review meeting usually results in action items for everyone, so we all take these to-dos and get to work on gathering the final information, adding it to the proposal, and creating a final, cohesive document.
Step 9: Final Approval
After revisions, the proposal goes out for final approval. By this stage, everyone has already had a chance to review, and ideally only 1-2 people need to review to provide final approval. I don’t recommend having a team of more people review at this stage because the deadline is approaching and all feedback has been incorporated already. It’s easy for the project to fall off track at this point and get stuck in too many revisions, which many times actually hurts your proposal (because you start to dilute the main points and add too many extra pieces).
Step 10: Finalize for Submission
With the final approval received, we finalize the proposal. At this step, all design aspects will be finalized and the proposal will go off to an editor for the final proofread to make sure there are no typos or confusing sentences.
Once the edited document is received, it’s converted into the final, customer-ready PDF with all applicable forms inserted. From there, it can be printed, emailed, or uploaded to a portal for the customer.
Optional Step 11: Debrief
Depending on how the process went, a debrief is often a good idea. During a debrief, I like to document what worked, what didn’t, and any inefficiencies or challenges that I want to avoid next time. I also ask for feedback from the team to see if their assessment aligns with what I experienced.
You can also debrief with the customer once an award has been determined. Many organizations won’t hold debrief meetings with vendors until the RFP is closed, so you have plenty of time to conduct an internal debrief first before meeting with the buyer.
After this, it’s time to start the process all over again with the next RFP!