Case Study: How an Architecture Firm Halved Proposal Prep Time

Twelve days. That was how long the principals at a 22-person architecture firm spent on every RFP response.

Not 12 days of actual writing — 12 days of pulling resumes off a shared drive, reformatting project descriptions from four different past proposals, hunting down the right photo of the right building, assembling a qualifications package that looked like it was designed by committee instead of a design firm. Two principals. Two weeks. Every. Single. Pursuit.

They were pursuing 3–4 opportunities per quarter and winning maybe one. The math was brutal: two principals × 12 days × 4 pursuits = 96 principal-days per year spent on business development before a single billable project was won. That's nearly a half-year of senior capacity consumed by proposal assembly.

Something had to change. What changed was how they built the workflow — not just which tools they used.

The Problem: The Proposal Machine Was Broken

The firm's principal described it this way: "We had great project experience. We had the relationships. We kept losing because our proposals looked like they were assembled at 11 PM the night before the deadline — because they were."

The process:

RFP arrives → dump it to a shared folder
Principal reads it (2–3 hours) and decides to pursue
Office manager finds relevant past projects in a folder called "Proposals Archive 2018–present" containing 47 subfolders
Principal writes a first draft from memory, pulling pieces from old proposals
Admin reformats, standardizes fonts, assembles InDesign package
Multiple rounds of edits
Submit — usually at 11:50 PM the night before the deadline

The consistent failure points:

Research gap: Proposals rarely addressed the specific client's situation — they were generic "here's who we are" packages
Content sprawl: Project descriptions existed in 6 different formats across 3 drives
Principal bottleneck: No one else could write the narrative; if a principal was on a deadline, the proposal slipped or got delegated to someone who didn't know the story
No differentiation: Every proposal looked the same because they were all assembled from the same 5-year-old boilerplate

The Solution: A Two-Tool Workflow That Separated Research from Writing

After a brief scoping call, we built a two-stage workflow using Perplexity for intelligence gathering and Claude for synthesis and narrative drafting.

Stage 1: Perplexity for RFP Intelligence (2–3 hours)

The first problem wasn't writing — it was not knowing enough about the specific client, project, and competitive landscape before drafting. Architecture proposals win on specificity. Generic "our team brings deep expertise" language loses to firms that demonstrate they understand this client's exact problem.

We built a Perplexity research protocol that runs on every new RFP:

Research Brief Template:

Client: [Organization name]
Project: [Project type and scope]
Research goals:
1. What are this client's recent capital projects and outcomes?
2. What is their stated priority for this project (from any public documents)?
3. Who else is likely pursuing this? What are their recent wins?
4. What regulatory or community context shapes this project?
5. Any relevant recent news (budget, leadership changes, community feedback)?

A project coordinator with no architecture background runs this in Perplexity. The output: a 4–6 page cited research brief in about 90 minutes. Before this workflow, getting this level of intelligence required a principal spending half a day on Google and LinkedIn. Now it's done before the principal even looks at the project.

Why Perplexity for this stage: Real-time search with citations. Every data point is sourced. When a coordinator writes "the client recently completed a $12M renovation of their central campus" in the research brief, there's a citation behind it. Principals can check the source in 10 seconds. This matters in architecture — one wrong assumption in a proposal can undermine your entire credibility.

Stage 2: Claude for Synthesis and Narrative Drafting (3–4 hours)

Once the research brief exists, Claude takes over. The firm's Claude Project is loaded with:

Their top 15 project descriptions (cleaned, standardized, ~250 words each)
8 principal bio blurbs in different lengths (50/100/200 words)
Their firm's design philosophy document (2 pages)
A proposal structure template based on their best-performing past submissions
The research brief from Stage 1

Prompt used by the project coordinator:

Using the research brief and firm context above, draft a proposal narrative for [Project Name] for [Client]. 

Structure: 
1. Understanding (2 paragraphs — lead with their specific situation, not generic capability)
2. Approach (3–4 paragraphs — our methodology, specifically referencing the client's stated priorities)
3. Relevant Experience (select and weave in 3–4 projects from the firm's library that are most relevant)
4. Team (use the principal bios, emphasize the specific experience most relevant to this project)

Tone: Direct. Client-first. Show we did our research. No generic statements.

Output: a first-draft proposal narrative of 600–1,000 words that actually addresses the specific client, references their situation, and reads like a firm that pays attention.

What the principal does with this draft: Edit, not write. They spend 45–60 minutes refining rather than staring at a blank page for 4 hours. They focus on the sections where their judgment genuinely adds value — the approach and the specific project selections — rather than reformatting a bio for the 40th time.

The Results: 12 Days to 4 Days

After 60 days running the workflow across 6 proposals:

Proposal prep time: 12–14 days → 3–5 days
Principal time per proposal: 3–4 days → 8–10 hours
Coordinator research time: 4–5 hours (new) → replaces 6–8 hours of principal time
First-draft quality: "We stopped being embarrassed by our own first drafts"
Win rate (6-proposal sample): 3 wins vs. 1 win in the prior 6-pursuit period (note: small sample, not statistically significant — but the directional trend is consistent with what the principals expected from better-differentiated proposals)

The more important outcome: the firm started pursuing more opportunities. With principal time per pursuit cut by 60–70%, they went from 3–4 pursuits per quarter to 6–7. At a 25–30% win rate, one additional win per quarter at their average project size ($650K) means $650K in additional annual revenue — from the same team.

What Would Have Broken This

This is the part most firms miss when they try to build this themselves.

The research brief must be standardized. If every coordinator runs a different Perplexity query, the outputs are inconsistent and Claude can't work with them reliably. They spent 3 iterations building a research template that produced consistent output before the workflow stabilized.

The firm's knowledge base has to be clean before you load it into Claude. The first time they ran this, the project library had 15-year-old project descriptions that didn't reflect the firm's current capabilities. Claude used them anyway because they were there. Garbage in, garbage out. They spent two days cleaning the project descriptions before the Claude Project performed the way they needed.

Prompts need to specify what NOT to do. The first draft instructions produced generic capability statements when Claude didn't have enough context. Adding "Do not use generic statements like 'our team brings extensive experience.' Only make claims we can support with specific project examples or client-named work" tightened the output dramatically.

Someone has to own it. The firm designated their studio manager as the AI champion. She runs the Perplexity research on every pursuit, manages the Claude Project, and is the one who catches when the workflow produces something off. The principals review the final narrative. Clear ownership is what separates workflows that get abandoned at month 3 from ones that compound over time.

The Architecture Lesson

Two tools. A coordinator. A project. That's the quick win — and it's real.

But what you're actually building is a workflow that separates three different functions that were previously collapsed into one overloaded principal:

Intelligence gathering (Perplexity): systematic, documented, repeatable
Synthesis and drafting (Claude): fast, consistent, based on your firm's actual history
Judgment and differentiation (principal): the part that actually can't be automated

Most firms fail at AI-assisted proposals not because the tools are bad, but because they try to use one tool to do all three things. Or they skip intelligence gathering entirely and hand Claude a blank RFP. Or they don't load their actual project library into the Claude Project and wonder why the outputs are generic.

The workflow matters more than the tools.

When you're ready to take this further — connecting Perplexity and Claude to your project management system, your CRM, and your document library so research and drafting happen automatically on every new lead — that's where architecture gets more complex. And that's the conversation we help firms have before they build something that works in month 1 and breaks in month 6.

Book a discovery call at cloudbeast.io/schedule.

Cloudbeast Blog