What Proposal Teams Actually Do All Day (And Where the Hours Go)

TL;DR: Responding to an RFP takes 20-40 hours of team effort on average, and most of that time isn't writing. It's reading, strategizing, chasing SMEs for input, and wrestling with formatting. Understanding where the hours actually go is the first step to getting them back.

It's 4:47 PM on a Tuesday when the email arrives. New RFP. Due in three weeks. 206 pages.

Someone on the team does the math out loud: that's 14 business days, minus the two days it'll take to get leadership buy-in on the go/no-go decision. So really, 12 days. For a 206-page RFP that touches cybersecurity, cloud migration, change management, and something called "digital workplace transformation enablement" that nobody can define.

This is how most proposal cycles start. And if you've been in this world for any amount of time, you already know what happens next.

The first 48 hours are just reading

Nobody writes anything on day one. The team prints the RFP (yes, still prints, in 2026) or loads it into a PDF viewer with enough sticky notes to wallpaper a bathroom. The goal is to figure out what the client is actually asking for underneath all the procurement language.

This takes longer than outsiders think. Government RFPs in particular love to bury evaluation criteria in appendices, cross-reference requirements across sections, and use language specific enough to imply they already have a preferred vendor. Reading an RFP is closer to detective work than document review.

By end of day two, someone has built a compliance matrix in Excel. It maps every stated requirement to a section of the response. This spreadsheet becomes the team's bible for the next two weeks. It will be updated 40+ times before submission.

Then the strategy meeting that should take an hour takes three

The capture manager, a couple of subject matter experts, and whoever from BD brought this opportunity in will sit in a room and argue about positioning. What's our differentiator on this one? Do we lead with past performance or technical approach? Did anyone talk to the client before this RFP dropped?

This meeting is where the win theme is supposed to emerge. In practice, it often doesn't. The team agrees on something vague like "we'll emphasize our experience and innovative approach" and moves on, because the clock is already ticking and there's a 206-page response to build.

The win theme problem is real. Without a clear strategic argument for why your company should win this specific contract, every section of the proposal ends up reading like a capabilities brochure. We can do this. We have experience in that. Our team is qualified. It's all true, and none of it is persuasive.

The SME chase

Here's where a proposal manager's job becomes part project management, part hostage negotiation.

Subject matter experts are the people who actually know the technical details that need to go into the proposal. They're also the people who are currently on three other projects, travel 60% of the time, and respond to emails on their own schedule.

Getting draft content from SMEs is the single biggest bottleneck in most proposal processes. Every proposal manager has a story about sending seven follow-up emails, then walking to someone's desk, then enlisting their manager, then finally getting a half-page of bullet points the night before the section is due.

Those bullet points then need to be turned into actual proposal prose. Which means someone on the proposal team rewrites everything from scratch anyway, trying to match the voice and messaging of the rest of the document. The SME's contribution was essential, but the handoff process ate two days that didn't need to be lost.

The formatting black hole

Somewhere around day eight, the writing is mostly done. Or at least, first drafts exist for most sections. Now begins the phase that everyone underestimates: making it all look right.

If the response needs to be a PowerPoint deck (and increasingly, it does), this is where things get painful. Content written in Word or Google Docs needs to move into slides. Every organization has a master template with specific fonts, colors, logo placements, and slide layouts that brand guidelines require. Someone on the team becomes the designated "PowerPoint person" and spends the next several days copying text into slides, adjusting font sizes, fixing alignment, and trying to make 800 words fit on a slide designed for 200.

This isn't creative work. It's manual labor that happens to require a computer. And it accounts for 15-25% of total proposal effort, depending on the complexity of the deliverable format.

The cruel part is that formatting quality matters. Evaluators notice when a deck looks thrown together. Inconsistent fonts, misaligned boxes, slides that are obviously just walls of pasted text. These things signal carelessness, even if the underlying content is strong.

The review cycle that never ends

Draft goes to the review team. Comments come back. Some are substantive ("we need to address their security requirements more directly"). Some are cosmetic ("can we make the headers blue instead of navy"). Some are contradictory ("reviewer A wants more detail, reviewer B wants it shorter").

The proposal team incorporates feedback, sends a revised draft, and the cycle repeats. Two or three review rounds is normal. Four isn't unusual. Each round burns a day or two, and the team is now well into week three with the deadline approaching fast.

The last 72 hours

This is the part that bonds proposal teams together the way shared trauma bonds anyone. The final push before submission involves simultaneous editing by multiple people, increasingly desperate attempts to reach one last SME for a sign-off, and the discovery that someone changed the master template mid-process and now half the slides have the wrong footer.

Pizza gets ordered. Coffee consumption doubles. Someone discovers a compliance requirement that was missed in the original matrix, and a new section needs to be written from scratch at 11 PM. The document gets submitted with minutes to spare, and the team collectively exhales for the first time in days.

Then someone asks: "When's the next one due?"

Where this is going

The breakdown of a typical proposal cycle looks roughly like this: 20% reading and analysis, 15% strategy and positioning, 25% content development, 25% formatting and production, 15% review and revision. Those numbers shift depending on the RFP, the team size, and whether Mercury is in retrograde, but the pattern holds.

What's interesting is that the content development piece, the actual writing, is only about a quarter of the total effort. The rest is coordination, strategy, formatting, and rework.

This is why tools that only speed up writing miss the point. Generating text faster doesn't help if you haven't figured out your win theme, can't get SME input on time, and still need to manually format everything into a 40-slide deck.

We built contrl to address the full pipeline, from RFP analysis through strategy through final PowerPoint output. But that's a story for another post. For now, if anything in this article made you nod, you're probably the exact person we built it for.