Proposal teams have adopted AI faster than almost any other business function. The data on what actually wins bids suggests most of them are pointing it at the wrong problem.
Proposal teams spend an average of 33 hours per RFP and win 39% of them, yet only 13% say they lose on proposal quality. That gap is the whole story: AI makes proposals faster and more fluent, but faster and more fluent is not why you win. The teams getting real value use AI as a reviewer and analyst rather than just a generator, start from a compliance matrix instead of a blank page, and verify every single claim before submission. Governments have already dismissed bids over unverified AI output, so the verification step is not optional.
Start with the cost, because most people underestimate it badly. Loopio, working with the Association of Proposal Management Professionals, surveyed more than 1,500 teams and found that responding to a single RFP takes an average of 33 hours and involves nine contributors. The average organisation submits 166 RFPs a year.[1]
Thirty-three hours is most of a working week. Per bid. And it varies sharply by company size.
Average hours spent responding to a single RFP, by organisation size. Source: Loopio and APMP, RFP Response Trends and Benchmarks Report, 2026. [1]
Now the win rate. Teams currently win 39% of the RFPs they submit, against a 45% average across 2019 to 2026.[1] So roughly six out of ten of those 33-hour efforts produce nothing.
And the adoption number, which is the fastest-moving of the three: 79% of proposal teams have used generative AI in their RFP process, up from 68% a year earlier, and 84% of those teams use it at least weekly. Sixty-two percent use it to generate specific answers, a 16-point jump from 2024.[1] For context, Gallup found 49% of US employees say they never use AI at work at all.[2] Proposal teams are not average adopters. They are near the front.
Which makes the next statistic the interesting one.
Only 13% of teams say they lose bids because of proposal quality. Price has been the primary stated reason for losses since 2021, with competition close behind at 55%.[1]
Sit with that for a second. The thing AI is best at, producing more polished prose faster, is the cause of roughly one in eight losses. The two things that cause most losses are your pricing and the fact that someone else was a better fit. No language model touches either.
I am not saying quality does not matter. I am saying that if your plan is “we will use AI to write better proposals and therefore win more,” the published data does not support the causal chain you are hoping for. And there is a second-order risk: if every bidder is now using the same tools, fluent writing stops being a differentiator at all. It becomes table stakes, and the differentiators move elsewhere.
So the highest-value use of AI in a proposal function might not be writing at all. It might be triage: helping you decide which of the 166 opportunities are worth 33 hours, and which ones you should politely decline so you can put 50 hours into the three you can actually win. Loopio reports that bandwidth became the number one challenge for proposal teams for the first time in five years, while go/no-go discipline dropped eight points.[1] More volume, less filtering. That is the failure mode AI accelerates if you let it.
There is a supporting-infrastructure problem too. Responsive found that 86% of organisations now see bid and proposal teams as significant revenue contributors, but only 34% have a centralised hub of reusable content.[3] That ordering matters enormously, because an AI pointed at a well-maintained content library produces something accurate and on-brand, while the same AI pointed at nothing produces confident invention.
If you take one process change from this article, take this one. Before anybody writes a sentence, build a compliance matrix.
APMP’s guidance, summarised in an APMP Western Chapter presentation on the technique, defines it as “a checklist both for you and for evaluators to make sure you comply with all RFP requirements,” which “maps the requirements of the RFP down to the location in the response where the requirement is answered.”[4] The instruction on timing is unambiguous: compile it before you start to write, and build it early.[4]
The method is called shredding. Separate every requirement, every “shall,” “will” and “must,” into its own row. Not by paragraph, by requirement. The guidance is explicit on this point: “Resist the urge to save time by shredding RFP requirements only by section or paragraph.”[4] Lumping requirements together is how requirements get missed. Your minimum columns are section number, section title, the page it appears on, the requirement itself, a compliant or partially compliant marker, and a note on where you answered it.
Two details that separate people who do this properly from people who do it as theatre. First, follow the customer’s lead and use their terminology rather than your own preferred phrasing. Second, submit a simplified response matrix with your bid so the evaluator can find your answer to each requirement without hunting. Both appear in APMP’s list of compliance matrix best practices.[4]
It also pays to know what the requirement words mean, because bidders lose points guessing. In the Federal Acquisition Regulation framing that APMP references, “shall” and “must” are interchangeable and denote a genuine requirement, “will” describes a statement of fact rather than something you will be verified against, and “should” is an expected course of action.[4] If the customer uses them loosely, ask a clarification question early rather than guessing late.
Now the AI question, and it is where I would be most careful. Automated shredding tools have existed for years and AI has made them far better, but the whole method depends on catching every requirement, and extraction tools are pattern matchers. Give a model a 60-page RFP and it will pull the numbered requirement list beautifully. It will skip the sentence in the background section that reads “the successful supplier will maintain a UK-based support presence.”
Here is the sequence, with the AI role at each stage made explicit. Notice that the first and last steps involve no generation at all.
The five-stage proposal workflow described in this article, showing where generative AI adds value and where human judgement is required.
Stage one, go or no-go. Paste the RFP and your capability statement, and ask the AI to list every requirement you cannot currently meet, plus every clause that suggests an incumbent. This is a fifteen-minute task that can save you thirty-three hours. It is the best return on AI in the entire process and almost nobody does it.
Stage three, drafting. The instruction that matters is “rewrite this approved content to answer this question” rather than “answer this question.” Responsive’s finding that only a third of organisations have a centralised content hub explains why so many teams skip this: they have nothing to rewrite from.[3] Building that library is unglamorous and it is the highest-leverage thing a proposal function can do before it invests in tooling.
Stage four is where the top performers separate themselves. Loopio found that teams winning more than half their bids are distinguished by using AI for “analyzing proposal quality, verifying accuracy, and interpreting data” rather than purely for generation.[1] Use it as your red team. Feed it the evaluation criteria and the scoring weights from the RFP and ask it to score your own draft against them, section by section, and to name what a competitor could say that you did not.
That reviewer mode is broadly underused. The same pattern shows up in other document-heavy work: our guide to using AI for contract review makes the same argument for reading rather than writing.
In September 2025, the US Government Accountability Office dismissed three bid protests filed by a company called Oready as an abuse of GAO’s protest process. The reason: the company’s filings repeatedly cited decisions that did not exist. GAO wrote that the citations “bear the hallmarks of the use of a large-language model or other artificial intelligence (AI) without adequate verification that the generated results were accurate.”[5]
The company had already been formally warned in an earlier decision three months before, and continued anyway.
Here is the part that should shape your policy, though, because it is more nuanced than the headline. GAO explicitly said: “our decision here is not based on the use of AI as a method of research; it is based on the protester’s repeated reliance on non-existent citations or decisions without verifying their correctness.”[5]
The UK government has landed in exactly the same place from the other direction. Procurement Policy Note 017 states that suppliers’ use of AI “is not prohibited during the commercial process,” and compares it directly to hiring a bid writer. It goes further: where buyers ask whether AI was used, those questions “should not be scored or taken into account when assessing a tender and should be used for information only.”[6]
But the same document carries the warning:
So the rule is not “do not use AI in bids.” Nobody credible is saying that. The rule is that every claim, figure, reference, certification, case study and named client in an AI-assisted proposal must be verified by a human who knows the business. Not skimmed. Verified.
And notice the sting in PPN 017’s tail: a bid that reads better than your company can actually perform invites the buyer to come and check. If AI helps you write a proposal describing capabilities you do not have, the guidance explicitly directs the buyer toward site visits and presentations to find that out. Getting caught later is worse than not bidding.
Practically, this means a named person signs off on a verification pass before submission, working through the compliance matrix row by row. If you want a general method for catching invented detail, our anti-hallucination toolkit covers the techniques that transfer well to bid work.
“Here is an RFP and here is our capability statement. List every mandatory requirement we cannot currently meet, quoting the exact text. Then list any clause that suggests the buyer has an incumbent or a preferred supplier. Then give me three reasons we should not bid. Do not write any proposal content.”
“Read this RFP twice. First pass: list every explicit requirement using shall, will or must, with page numbers. Second pass: list every obligation stated only in narrative prose that is not in the requirements list, for example in background, scope or evaluation sections. Present the second list separately and flag anything that could be a disqualifier.”
The two-pass structure matters. Asking for both in one go reliably produces the numbered list and nothing else.
“You are on the evaluation panel. Here are the evaluation criteria and their weightings, and here is our draft. Score each section against the stated criteria and justify the score in one line. Then tell me what a stronger competitor could credibly claim that we have not.”
“Extract every factual claim in this proposal into a table: the claim, the exact sentence it appears in, and what evidence would be needed to prove it. Include client names, project outcomes, percentages, dates, certifications, team credentials and any named third party. Do not assess whether the claims are true. Just list them so a human can check.”
This is the prompt that prevents the Oready problem. It takes ten minutes and it turns “verify everything” from a vague instruction into a finite checklist. If you adopt nothing else from this article, adopt this.
For a formal RFP, this question is largely already answered for you. APMP’s compliance matrix best practices include following the customer’s lead, and in practice that means mirroring the solicitation’s structure and numbering rather than imposing your own.[4] Creativity in structure is a way to lose points, not win them.
For an unsolicited proposal, where you choose the shape, Proposify’s analysis of 742,137 proposals sent through its platform found that winning proposals average seven sections and eleven pages, while losing ones average thirteen.[7] The seven that recur in won proposals are roughly: cover page, executive summary, approach or scope of work, deliverables and timeline, about us and team, pricing, and terms with next steps.
Two caveats I want to be honest about. That is first-party platform data from a proposal software vendor, not an independent study, and Proposify themselves decline to claim causation on page count. Shorter proposals may win because simpler deals close more often, not because brevity persuades. Treat it as directional colour rather than a benchmark.
The genuinely useful finding on the same page is behavioural: buyers view 93% of the proposals they go on to sign, and they spend around 25 minutes with winners against 16 minutes with the ones they reject.[7] Being read is most of the battle.
One structural point worth making because it contradicts most templates: in that seven-section pattern, “about us” sits fifth. After the problem and after your solution. Almost every proposal I see in workshops opens with company history. Your buyer does not care yet.
Let me end where the data started. Adopting AI in your proposal process is not the decision. Deciding what you are actually trying to fix is. If the answer is “we are drowning in bids we should never have entered,” AI helps enormously and immediately, at the go/no-go stage. If the answer is “our proposals are not persuasive enough,” the numbers suggest that is one in eight losses and you may be optimising the wrong thing.
Pick one bid this month. Build the compliance matrix before anyone writes. Run the claim audit before anyone submits. Then compare how that one felt against the last one. For a broader view of applying this thinking across the business, our guide to AI for strategic planning and the piece on AI for sales enablement content cover the neighbouring workflows.
In UK public procurement, yes and explicitly so. Procurement Policy Note 017 states that suppliers’ use of AI is not prohibited during the commercial process, and compares it to using a bid writer. It also instructs buyers not to score any question about whether AI was used.[6] For private-sector RFPs, check the RFP itself: some contain confidentiality clauses that prohibit uploading the document to third-party tools. The consistent rule across both is that unverified AI output is the problem, not AI itself.
It can if you do not check it. The US Government Accountability Office dismissed three bid protests as an abuse of process after the filer repeatedly cited decisions that did not exist, noting the citations bore “the hallmarks of the use of a large-language model.”[5] GAO was careful to say the sanction was not for using AI to research, but for relying on non-existent citations without verifying them. Run a claim audit before every submission and this risk largely disappears.
Less than the marketing suggests, and the saving tends to get reinvested rather than banked. Loopio and APMP found average response time fell from 35 hours to 33 hours as AI adoption rose to 79%, with teams putting the recovered time into quality rather than reducing effort.[1] Notably, winning teams spend more time per RFP than average, not less. Treat AI as buying you hours to think, not hours to skip.
Three things. Do not let it be the only reader of the RFP, because it reliably extracts numbered requirements and misses obligations buried in narrative prose, which APMP calls hidden requirements.[4] Do not let it produce claims about your capabilities, clients or credentials that a human has not verified. And do not let it decide what to bid on. Go/no-go discipline correlates with winning: 81% of top-performing teams run a formal process.[1]
It is a checklist that maps every requirement in the RFP to the exact place in your response where you answer it, built before writing rather than after. APMP’s guidance is to separate every shall, will and must into its own row, resist shredding only by section or paragraph, follow the customer’s terminology, and submit a simplified response matrix with your bid so evaluators can navigate it.[4] If you respond to formal RFPs at all, yes, you need one.
This article draws on benchmark research from Loopio and APMP, Responsive, Proposify and Gallup, alongside primary guidance from the APMP Body of Knowledge, the UK Cabinet Office and a published US Government Accountability Office decision. Every figure was checked against its original publication. Where a statistic comes from vendor platform data rather than independent research, that is stated in the text.
Weekly tips. Real examples. Practical help for busy professionals.
We care about your data, check out our privacy policy.