TripleSpeed
Case study  ·  Agency new business  ·  2026

The RFP response that stopped taking 6 weeks

A 6 week RFP response process became about 30 minutes per proposal. The draft sounds like the agency, and the proposals team edits the rest by hand.

A founder-led digital agency in the Southwest, about 50 people: websites, product design, and the campaigns that launch them. New business runs on RFPs, and every response took 6 weeks. Somewhere around week 4, the strategist writing the approach got pulled back onto a launch, the case studies in the draft were still the ones from the last response, and the founder was rewriting the executive summary at 11pm because it didn’t sound like the agency.

Nobody in that building treated RFPs as admin. Responding to them is how the agency makes money. So a response that takes 6 weeks isn’t an ops annoyance. It’s a revenue problem with a calendar attached.

01

Before

On paper the process was reasonable. The RFP lands, the new-business team of 2 books a discovery call, and a shared document starts making the rounds: the approach from a strategist, the relevant work from whoever remembers it, bios, a timeline, a price. Then things came up, because things always come up. A launch slipped. The strategist went back to billable work, where a strategist belongs. The document sat. Each of those weeks was defensible on its own, and together they were 6.

The weeks weren’t the whole cost. Everyone who touched a proposal was someone not billing, and the RFPs the agency passed on because the calendar couldn’t take another one never showed up on any report.

They had tried the obvious fixes. A boilerplate library, which made every proposal faster and every proposal read like the last one with a different logo on it. Then a chat tool: somebody pasted in an RFP and got back confident, well-organized prose that could have come from any agency in the country. An evaluation committee spots that register in a paragraph. It went back in the drawer.

The slow part of a proposal was never the typing. It was getting the people who know how the agency thinks into the same document at the same time.

02

What was done

We didn’t start with the RFP. We started with everything the agency already knew about itself and had never put in one place.

Its menu of services, the real one, including what it doesn’t do. Its case studies. Its strengths and, the harder document, its weaknesses: where it loses, what it shouldn’t bid on. Its approaches, meaning how it actually runs discovery, design, and launch. The system was trained on all of it, so when an RFP arrives, the half of the proposal that’s about the agency is already known.

That’s what let the input side stay small. The generator takes 2 inputs: the URL of the company or product being pitched, for context, and a link to a recording of a conversation between the agency and the client, usually the discovery call. The URL says who they are. The recording says what they actually asked for, including the thing they mentioned twice that the RFP never did.

Interface comp: the intake screen of the proposal generator, in a workspace labeled Proposals. The heading reads Who are we pitching. Field 01, company or product URL, holds https://fernmoor.example. Field 02, call recording link, holds Discovery call: Fernmoor Trail Supply, 48 minutes, recorded with consent. Below them is a single button, Generate proposal. A side panel headed Already known lists services including what we don’t do, case studies, strengths and weaknesses, approaches, and past proposals, years of them, and ends with Nothing here to fill in.
01  ·  The intake Interface comp. 2 fields and a button: everything else the proposal needs, the system already knows, because the agency already knew it. Interface comps: the system runs; these screens illustrate it. Real captures replace them as client access allows. Fernmoor Trail Supply is a fictional brand invented for this demo.

The proposal lives on a website, so the output goes where the proposal lives. The system fills out the site’s CMS section by section: the read on the client, the approach, the relevant work, the team, the timeline. The proposals team opens it in the same editor they’d use for any page and changes whatever needs a human.

Interface comp: the proposal site’s CMS editor on a draft page titled Proposal: Fernmoor Trail Supply. A progress trail down the left reads 2 of 5 written: Our read on Fernmoor and Approach are checked, Relevant work is writing, Team and Timeline are queued. The main pane shows the finished Approach section, which opens on Fernmoor selling gear to people who plan their trips weeks ahead while the site treats them like impulse buyers, and the Relevant work heading being written above 2 empty case study slots. Page settings on the right list the owner as Proposals lead.
02  ·  The CMS filling itself Interface comp. The proposal gets built inside the editor the team already uses; nobody opens a new app.

That editing step is where the build earns its keep. Every hand edit is recorded along with why it was made. A diff only says what changed. The reason says what was wrong: we lead with their problem, not our awards. We stopped offering that service.

Interface comp: the Approach section of the Fernmoor proposal in edit mode. The generated line, We are an award-winning agency with deep experience across retail, is struck through in red. The proposals lead’s rewrite sits under it: Fernmoor loses customers between the trail and the checkout. That is where we start. An edit record on the right shows the before and the after, and a field labeled Why this edit reads We lead with their problem, not our awards, above a note that says 1 sentence, the system learns from it, and a Save reason button.
03  ·  One edit, one reason Interface comp. An edit with a reason is a rule the system keeps, not a one-off fix.

The system learns from those edits, so the same mistake doesn’t come back on the next proposal. The proposals team isn’t asked to train anything, fill out a feedback form, or open a new tool. They edit proposals, which they were always going to do, and write one sentence about why.

Interface comp: a later proposal for a different client, Halcyon Row Bakeries, with all 5 sections written. The Approach section opens on the client’s problem: Halcyon Row sells out of bread by 10 AM and turns away the afternoon orders that would pay for a second bake. That is where we start. A margin note reads Applied from a recorded edit, quotes We lead with their problem, not our awards, credits the proposals lead on the Fernmoor proposal, and links to the original edit. A line under it reads 3 recorded edits applied on this page.
04  ·  The next proposal Interface comp. A different client, and the same correction never has to be made twice. Halcyon Row Bakeries is a fictional brand invented for this demo.

The edits are the training data nobody had to schedule.

03

The wobble

The first proposals came out generic. Not wrong: the services were real, the case studies were theirs, the client’s name was spelled right. They just read like AI, in that smooth, interchangeable register evaluation committees now see in every stack, and anyone who had read the agency’s real proposals could tell inside a page. That was the moment the build nearly became the chat tool they had already given up on. The menu of services and the case studies told the system what the agency sells. They didn’t tell it how the agency talks: where it gets blunt, what it refuses to promise, how it opens an approach section, which sentences it has never once written. The only place that lives is the proposals themselves. So we went back for the archive and trained on lots and lots of the agency’s past proposals, years of them. It stopped sounding like AI only after it had absorbed years of the agency sounding like itself.

Interface comp: 2 versions of the Fernmoor Approach section side by side. The left, labeled First proposals, written from services and case studies, reads We bring a proven, strategic approach to every engagement, combining creative excellence with data-driven insight to deliver results that matter. The right, labeled After the archive, written after training on years of past proposals, reads Your site sells gear. Your customers want the trail. We start by moving the trail maps above the fold and the checkout 2 clicks closer. A strip along the bottom reads same client, same section, same inputs.
05  ·  Same section, 2 voices Interface comp. The voice came from the agency’s own years of proposals, not from the model.
04

After

A 6 week RFP response process became about 30 minutes per proposal. The inputs didn’t grow to get there. Still 2: a URL and a call recording.

Nobody pretends the draft ships untouched. It gets the team most of the way there, and the proposals team edits the rest by hand, which is the design, not a shortfall. Their time moved from assembling a proposal to judging one.

The texture says more than the clock. Strategists stopped getting pulled off billable work to write approach sections from a blank page. The founder stopped rewriting the executive summary at 11pm, because the draft already sounds like the agency. The case studies in each proposal are the ones that fit that client, not the ones from the last response. And the question at the new-business meeting changed. It used to be whether the team could get a response out in time. Now it’s whether this one is worth bidding.

05

What it required

The founder in the weekly check-in, personally. Nobody else could say with authority what the agency is bad at, and that list mattered as much as the case studies.

The archive, handed over whole: years of past proposals, including the ones nobody enjoys rereading. There is no shortcut, because the wobble proved the voice lives in the archive and nowhere else.

Every discovery call recorded, with the prospect’s consent, because the recording is half the input.

And one new habit, which we won’t pretend costs nothing: a reason on every edit. It’s one sentence. It’s also the whole learning loop, and a team that edits without writing down why gets a system that keeps making the same mistake.

The first draft used to be the whole job. Now it’s the part we edit.
The founder  ·  Composite dialogue
Next

Book a discovery call

30 minutes with the people who would do the build. Bring the question your client asked you.

Book a discovery call