How Much Of The RFP Process Can AI Actually Automate?

An Exploration Of Procurement Scale, Proposal-Team Pain, Market Fragmentation, And What A Serious AI Company Would Need To Get Right.

I started this research with what sounded like a simple question:

How big is the market for automating RFPs, tenders and proposals?

The more I looked, the less useful that question became.

The money involved is enormous. The US federal government obligated about US$793 billion through contracts in FY2025. Canada awarded C$66.9 billion in federal contracts in 2024–25. Australia reported roughly A$105 billion in procurement contracts in 2024–25. Singapore's government has historically awarded about S$26 billion per year, averaging roughly S$2 billion in ICT contracts and S$24 billion in non-ICT contracts in the three years reported by the Ministry of Finance. (GAO)

But none of these numbers tells me how large the proposal-automation market is.

A S$100 million contract does not imply that S$100,000—or 0.1%, or any fixed percentage—will be spent preparing the proposal. Nor does a larger procurement market automatically create an equally large software opportunity.

The more useful question became:

Where do organisations repeatedly compete for valuable work through sufficiently complex proposal processes that better software could materially help the people doing that work?

That puts proposal managers, bid managers, business-development teams and technical subject-matter experts at the centre of the analysis—not AI.

1. Singapore Is Small. Its Procurement Markets Are Not.

Singapore was my natural starting point.

GovTech projected S$3.3 billion of government ICT procurement opportunities in FY2024, including approximately S$2.1 billion for ICT infrastructure and S$1.2 billion for applications. The infrastructure spending included modernisation intended partly to address cybersecurity requirements. In FY2023, the Government also identified approximately S$1 billion of applications being developed on cloud infrastructure. (GovTech Singapore)

Construction is dramatically larger. BCA projected S$47–53 billion of construction contracts for 2025, although this number includes both public and private construction and therefore should not be compared directly with government ICT procurement. (Building and Construction Authority)

That distinction matters. Earlier in this exploration, I was surprised that construction appeared more than ten times larger than ICT. Some of that difference is real; construction is extraordinarily capital-intensive. But some came from comparing different measurement scopes.

Nevertheless, the underlying observation survives:

Singapore contains several procurement ecosystems large enough that a software company does not necessarily need to begin by serving “all RFPs”.

An ICT-focused company could study systems integration, cloud, cybersecurity and digital services. Another could focus entirely on construction and engineering tenders. A third could concentrate on facilities management, transportation or professional services.

Singapore is also trying to reduce procurement friction for smaller suppliers. Tender Lite began for tenders up to S$1 million and has subsequently expanded into construction and, from April 2026, ICT. MOF says that together, Quotations and Tender Lite will give around 90% of government procurement opportunities simpler contract conditions. (Ministry of Finance (MOF))

That creates an interesting possibility: the economically attractive customer may not always be a giant enterprise with a large proposal department. It may also be a smaller technical company that bids often enough to feel substantial proposal pain but cannot justify building a large internal proposal-operations function.

2. The Problem Is Probably Not “Writing The Proposal”

This is where I think software builders can misunderstand the profession.

A proposal team does not simply receive an RFP, press a button labelled Write, and wait for 100 pages to appear.

A difficult response can involve deciding whether the opportunity should be pursued at all, interpreting ambiguous requirements, building a compliance structure, determining what the buyer is really evaluating, finding historical evidence, identifying which old answers remain valid, asking the right questions of SMEs, coordinating technical and commercial inputs, managing dependencies, reviewing commitments, handling multiple versions, checking compliance and finally producing something that is both accurate and persuasive.

The writing is only one layer.

From this perspective, the most interesting AI opportunities appear to be around judgment-assisted workflow, not generic text generation.

For example, software may reasonably help extract and structure requirements, compare tender versions, identify unanswered requirements, retrieve historical content, trace claims to approved sources, suggest SME questions, create initial drafts, identify inconsistencies, maintain compliance matrices and prepare review packages.

But I would be much more cautious about allowing software to independently make bid/no-bid decisions, commit an organisation to technical capabilities, invent project assumptions, choose pricing, interpret genuinely ambiguous buyer intent, or perform the engineering work underlying a technical solution.

The distinction I am interested in is therefore not:

Human versus AI.

It is:

Which portions of proposal work are repetitive and information-heavy enough for machines to carry more of the load, while humans retain responsibility for strategy, judgment and commitments?

I suspect experienced proposal professionals can draw that boundary much more accurately than software developers can.

3. The Market Appears Fragmented Twice: By Sector And By Country

This became one of the strongest findings from the research.

At first, a global RFP platform sounds obvious. RFPs exist everywhere. Large language models work across languages and documents. Why not build once and sell globally?

Because the underlying process is only partly universal.

The general lifecycle may remain recognisable:

opportunity → qualification → requirements → strategy → evidence → SME input → drafting → review → submission → reuse.

But the environment around it changes.

A US federal contractor encounters acquisition vehicles, IDIQs, task orders, federal compliance requirements and agency-specific practices. The US government alone obligated US$793 billion in FY2025, with civilian agencies recording an 89% competition rate and defence approximately 52%. Importantly, that percentage means the proportion of contract dollars obligated through competitive procedures—not the number of bidders. (GAO Files)

The UK has a different framework-heavy public-procurement ecosystem. Its public sector spends approximately £26 billion annually on digital and data, including around £21 billion with third parties; £14.5 billion alone was estimated to go to contractors, managed-service providers and IT consultants. (GOV.UK)

Australia's category data illustrates another market structure. In 2024–25 it reported approximately A$14.25 billion of professional engineering services, A$10.40 billion of construction-related services, A$4.53 billion of computer services and A$1.31 billion of software contracts. (Department of Finance)

Canada awarded C$66.9 billion in federal contracts in 2024–25, but its ready-made category aggregation is less convenient for this particular analysis. (Canada)

Singapore has GeBIZ, BCA procurement structures, its own supplier qualification systems and country-specific practices.

The implication I currently favour is:

One proposal-intelligence engine + sector modules + country/procurement adapters.

The core technology could remain common.

The Singapore ICT module would understand Singapore procurement terminology, GeBIZ information and recurring ICT workflows. A construction module would need a different understanding of technical submissions, project experience, key personnel, methodologies and qualification structures. A future UK adapter might understand frameworks and further competitions. A US federal adapter would become considerably deeper.

That looks more plausible to me than either extreme: building five completely separate products or assuming one generic AI proposal writer can understand every procurement environment equally well.

4. Construction Deserves More Attention Than I Initially Gave It

I initially leaned toward ICT.

I still think ICT is an unusually attractive environment for automation because its proposals often combine large amounts of structured and unstructured information: requirements, architecture, cybersecurity, implementation methodology, migration, SLAs, project teams, resumes, compliance, previous experience and technical evidence.

But dismissing construction would be a mistake.

Singapore's construction contract pool is enormous. More importantly, construction procurement is not necessarily determined on price alone. Technical quality, methodology, team capability, relevant experience, risk, programme and many other factors can matter.

The challenge is that a larger portion of the differentiated value may live outside the proposal document itself: engineering calculations, BIM, drawings, quantity take-offs, project schedules, site constraints, subcontractor inputs and specialist professional judgment.

That does not make construction unsuitable for AI.

It changes the product boundary.

The useful software may not “write construction bids”. It may help the bid team understand requirements, retrieve evidence, coordinate technical contributors, maintain compliance, reuse project credentials, manage personnel records, compare previous submissions, identify gaps and support technical reviews.

Whether those problems are painful enough to support a specialised Singapore construction-proposal platform remains an empirical question.

I would rather ask construction bid professionals than decide it from the software side.

5. Existing Companies Prove Both The Opportunity And The Difficulty

The market is not empty.

Responsive, formerly RFPIO, reported close to 2,000 customers and more than US$500 billion of opportunities managed through its platform by 2024. Its positioning has expanded beyond conventional RFP writing into broader “Strategic Response Management”. (Responsive)

Loopio had already reached 1,000+ customers when it received a US$200 million strategic investment in 2021—well before the current generative-AI wave. (Loopio)

AutogenAI represents the newer AI-native approach. It had raised US$65.3 million by late 2023 and reported more than 250 enterprise customers across the UK, US and APAC by January 2026. Its customers span areas including construction, infrastructure, professional services, defence and government contracting. (AutogenAI)

GovDash demonstrates a different strategy: go much deeper into one procurement ecosystem. Its focus is US government contracting rather than generic proposals. In January 2026 it raised a US$30 million Series B after reporting revenue growth of 16× since its Series A and nearly 200 customer companies. Its customers collectively secured more than US$5 billion in government contract awards during 2025. (GovDash)

Stotles provides another useful example. It is deeply oriented around selling into the UK public sector—market intelligence, opportunity discovery, qualification and bidding—and raised a US$13 million Series A in 2025. (Stotles)

I do not interpret these companies as evidence that proposal automation is already “solved”.

I interpret them as evidence of multiple viable product boundaries.

Responsive and Loopio show that response management itself can sustain substantial software businesses. AutogenAI tests a broad AI-first approach. GovDash tests deep jurisdictional specialisation. Stotles combines public-procurement intelligence with the commercial process surrounding bids.

The fact that all of these approaches coexist suggests that the market may be too fragmented for one simple winner-takes-all product.

6. What Could A Singapore-First Company Actually Become?

Here I think it is important not to make the mistake I initially made.

Taking 0.1% of a S$20 billion procurement market and declaring a S$20 million software TAM is not serious market sizing.

Contract value and proposal-software expenditure are different quantities.

A better model starts from customers.

Suppose a specialised platform could eventually charge somewhere around S$10,000–S$25,000 per organisation per year, depending on usage and sophistication.

Then the economics look like this:

The biggest uncertainty isn't multiplication.

It is whether Singapore contains 100, 500 or 1,000 organisations with sufficiently frequent, painful and valuable proposal workflows to retain such a product.

I do not yet know the answer.

But importantly, the company does not need to capture fractions of Singapore's procurement dollars directly. It needs enough organisations to repeatedly find the software worth paying for.

Valuation should be treated just as cautiously.

At the beginning of 2025, SaaS Capital's public SaaS index had a median valuation around 7× run-rate revenue, while more recent 2026 private transaction data show how widely multiples can move as market conditions and business quality change. (SaaS Capital)

So if I use 4–7× ARR merely as an illustrative range, not a forecast:

A fast-growing, highly defensible company could be valued above that. A slow-growing, services-heavy or easily replaceable product could be worth much less.

The valuation is therefore downstream of the real questions: retention, growth, gross margin, customer concentration, defensibility and how deeply the software becomes embedded in the revenue workflow.

7. Singapore's Open Data Helps—But Does Not Answer The Hardest Question

Singapore has an unusual research advantage: much of its public procurement activity is visible.

MOF's open GeBIZ procurement dataset currently contains about 18,500 rows covering April 2021 to March 2026, including tender numbers, descriptions, agencies, award dates, suppliers and awarded amounts. (data.gov.sg)

That sounds perfect until one looks closely.

A row is not necessarily one tender. The dataset includes awards “to suppliers”, awards “by items” and other structures. Multi-supplier arrangements can appear many times. Some framework-style records contain amounts that cannot sensibly be interpreted as the total economic value of the procurement.

Therefore simply searching for “cybersecurity” or “construction” and summing the award column would produce misleading results.

A serious sector map requires deduplication, classification, treatment of framework and item awards, manual checking of high-value records and probably additional sources.

More importantly, the dataset mostly tells us who won.

The software opportunity depends just as much on companies that repeatedly bid and lose.

A company submitting 30 meaningful proposals per year and winning five may have much greater proposal pain than an incumbent submitting three renewals and winning all three.

So the next level of market research cannot come from procurement data alone.

It has to come from proposal teams.

8. What I Would Want Proposal Professionals To Challenge

At this point I have several hypotheses, but I would rather have experienced practitioners break them than make them sound more certain than they are.

In particular, I would value corrections on four questions:

• Where does proposal work actually consume the most expensive human attention today—interpretation, strategy, content retrieval, SME coordination, drafting, compliance, review, or somewhere else entirely?
• Which parts already work well with existing tools, and where do current AI products create more checking work than they save?
• How much does the workflow genuinely change between ICT, engineering and construction—and between Singapore, the US, UK, Australia and Canada?
• What would software need to do before an experienced proposal manager would trust it inside a high-stakes live bid?

Those answers matter more than another model benchmark.

9. My Current Conclusion

I began by asking whether there was enough money in RFPs and tenders to justify building specialised AI software.

There clearly is enough money flowing through procurement.

That is no longer the interesting question.

The harder—and much more useful—question is whether software can remove a meaningful portion of the recurring operational burden without weakening the professional judgment that makes a proposal credible.

My current view is that ICT, systems integration, engineering and construction are all worth investigating, particularly in Singapore. ICT may offer the cleanest starting point because so much of its proposal work is knowledge- and document-intensive. Construction may contain an even larger economic opportunity, but also more project-specific work that sits outside the proposal-management layer.

I also increasingly doubt that the final market will be won simply by having the best general-purpose language model.

The stronger product may be the one that understands:

this organisation's knowledge, this sector's proposal workflow, this country's procurement environment, and exactly where humans need to remain responsible.

That is why I am currently more interested in proposal intelligence than automated proposal writing.

And I consider this research incomplete by design.

The next corrections should not primarily come from software founders.

They should come from the people already responsible for winning these bids: proposal managers, bid managers, capture and business-development leaders, commercial teams and the technical SMEs whose expertise ultimately has to survive the journey from an ambiguous tender document into a credible submission.

If their experience contradicts any of the assumptions above, that is exactly what I would want to learn next.