Research note

Why Are Companies Still Hiring Proposal Freelancers When AI Can Read The Entire RFP?

An evidence-led examination of why companies continue to hire proposal freelancers even as AI can read RFPs, retrieve evidence, draft responses, and check compliance. It argues that workflow orchestration and authoritative business decisions may be a harder bottleneck than proposal writing itself.

What freelance demand may reveal about the real bottleneck in proposal work

I started this investigation with what seemed like a simple contradiction.

Companies are still hiring freelance proposal writers, RFP researchers and proofreaders. Some of these engagements are ongoing, involve substantial weekly hours, and sit directly inside workflows that modern AI appears increasingly capable of performing. At the same time, today's AI can read hundreds of documents, retrieve relevant evidence, compare requirements against previous responses, draft answers, identify inconsistencies and perform multiple rounds of review.

So why hire a freelancer?

The deeper I went, the less convincing the usual answer became: “Because proposals still require human judgment.” That may be true in some situations, but it is too broad to explain what I was seeing.

I now think there is a more interesting hypothesis. These freelance jobs may not primarily demonstrate work that AI cannot do. They may demonstrate proposal processes that companies have not yet converted into reliable automated operating systems.

That distinction matters.

1. The Practitioner Reality Behind The Question

Proposal work rarely starts with a clean database and a perfectly defined problem.

A solicitation arrives. Requirements sit across a main RFP, appendices, pricing sheets and amendments. Relevant company information may be scattered across old proposals, SharePoint folders, project documents, case studies, resumes, sales material and the heads of technical SMEs. Some information is current; some is stale; some contradicts something else.

Then there is a deadline.

This operating reality is visible in several freelance postings I examined.

One technology consultancy wanted a technical proposal writer to analyse government solicitations, develop compliance matrices, write technical and management approaches, coordinate with solution architects and cybersecurity specialists, maintain reusable content and participate in formal proposal reviews. The advertised rate was only $3–$4 per hour, but the role covered proposals reportedly worth $500,000 to $50 million or more. More importantly, the posting explicitly listed Microsoft Copilot as preferred experience alongside Loopio, RFPIO and GovWin. Technical Proposal Writer – Government RFP/RFQ Response, Upwork

Another firm, specialising in ERP implementations for public-sector organisations, offered $15–$30 per hour for more than 30 hours a week. The freelancer was expected to review municipal ERP RFPs, coordinate SME inputs, develop implementation methodologies, create staffing plans and project schedules, maintain a proposal library and improve win themes. ERP Proposal Writer / RFP Response Specialist, Upwork

A third buyer wanted someone simply to research government opportunities, determine which ones genuinely aligned with the firm's capabilities and summarise the important details—not merely produce a list of search results. RFP & Government Opportunity Research Specialist, Upwork

A fourth hired proposal proofreaders at $18–$25 per hour. The buyer specifically wanted someone to detect wrong client names, inconsistent numbers, mismatched dates, broken cross-references and solicitation requirements that had not actually been answered. The posting received 20–50 proposals and had already resulted in two hires when I captured it. RFP Proposal Proofreader, Upwork

These are very different jobs. But they share an important characteristic: the client wants part of the proposal burden to disappear.

2. The Equal-Information Test

My first instinct was that the freelancer must possess judgment that AI lacks.

But consider the ERP proposal writer. A new freelancer does not automatically know which employees are available for a project, what implementation architecture the company will propose, which reference customers can be named or whether delivery can contractually commit to a particular schedule.

The freelancer has to find out.

That leads to what I now call the equal-information test:

If the freelancer and a sufficiently capable AI system are given access to exactly the same information, what can the freelancer reliably determine that the AI cannot?

For a surprising amount of proposal work, I am no longer convinced that the answer is very much.

Suppose an RFP asks a bidder to explain its migration approach while maintaining business continuity and satisfying the municipality's security requirements. A modern AI system can search historical proposals, architecture documents, security policies, case studies and project records; identify the most relevant material; cite its sources; detect conflicting claims; and construct an initial response.

It can also divide the problem further.

What does the buyer appear to value? Which evaluation criteria matter most? Where is our available evidence strong or weak? What claims require verification? Which historical examples are genuinely comparable? What unanswered question should be sent to the architect?

Those are difficult questions. But difficulty alone does not make them uniquely human. Many can be decomposed into smaller questions, investigated independently and recombined.

That is especially important because a sophisticated AI workflow need not consist of one giant prompt. It can use separate agents or stages for ingestion, requirements analysis, retrieval, drafting, compliance, numerical checking, factual verification and adversarial review.

3. Messy Data Is A Problem—But Perhaps Not The Moat

One possible explanation is that company data is simply too large and unstructured.

There is clearly truth in this. Proposal teams often work with fragmented content of uneven quality.

But the current product landscape makes me cautious about treating document organisation itself as the enduring problem.

Loopio says its platform can connect proposal work with dozens of organisational sources while maintaining governed, vetted answer content. Loopio Platform Its product positioning also emphasises confidence, content freshness and validation rather than generation alone. Loopio – Confident Answers

Responsive already supports document ingestion, AI-generated responses, source selection, SME assignment and answer evaluation around attributes such as accuracy, relevance and traceability. Responsive – Response Projects

GovDash goes further within its federal-government niche, combining opportunity intelligence with solicitation analysis, compliance workflows and source-grounded proposal generation against a contractor's own data. GovDash comparison and product discussion

Booma focuses heavily on requirements-intensive technical work, including extraction and structuring of requirements from documents that engineers would otherwise need to process manually. Booma – Use Cases

These companies do not prove that messy enterprise knowledge has been “solved.” They do show that “AI that reads lots of unstructured proposal documents” is already an actively developed product capability rather than obvious untouched whitespace.

4. The Harder Boundary: Unknown Truth

A more useful distinction may be between known organisational truth and truth that has not yet been decided.

Imagine that a new RFP requires implementation within 120 days.

An old proposal promises 180 days. Another describes 150. A marketing deck says the company can implement “in as little as 90 days.” Internal project material suggests that staffing conditions have since changed.

A strong AI system should be able to uncover all four pieces of evidence. It should probably identify the conflict and conclude that the company's current commitment cannot be established confidently.

What it cannot legitimately do is invent the decision:

“Yes, we will contractually commit to 120 days.”

Delivery leadership must decide that.

But critically, the freelance proposal writer cannot decide it either.

The freelancer normally becomes an intermediary: understand the requirement, investigate the evidence, recognise the unresolved issue, ask the appropriate SME, capture the answer and incorporate it into the proposal.

That suggests that a large portion of what appears to be “human proposal expertise” may actually be human orchestration.

And orchestration is increasingly automatable.

5. From Proposal Writer To Proposal Operator

This changed the way I interpret the freelance market.

The opportunity researcher is not necessarily selling uniquely human research capability. The buyer is delegating the repeated process of searching portals, comparing opportunities against company capabilities and deciding what deserves attention.

The proofreader is not necessarily doing something machines fundamentally cannot do. In fact, numerical consistency, entity checking, requirement coverage and cross-document comparison are tasks where machines could eventually have an advantage because they do not become tired after reading eighty pages.

The technical proposal writer may similarly spend substantial time moving information between the RFP, historical material and SMEs rather than creating genuinely novel insight.

Even the ERP specialist's work can be reframed. Creating an implementation methodology, staffing plan or project schedule is harder because the response may require bid-specific solution decisions. But those decisions still originate with delivery, engineering or management—not with the external proposal writer.

The potentially automatable role is therefore broader than “writer.”

It is the proposal operator sitting between the solicitation, company knowledge and the people authorised to make new commitments.

6. The Scarce Resource May Be SME Attention

This leads to the most interesting hypothesis from the research so far.

Perhaps the objective of proposal automation should not be “generate 80% of the proposal automatically.”

Perhaps it should be:

Minimise the amount of qualified human attention required to produce a defensible proposal.

Imagine that an infrastructure requirement demands an RTO of four hours. The company's previous material contains an eight-hour commitment in one proposal, a four-hour architecture in another document and no explicit commitment in the current service description.

Instead of assigning the whole question to an engineer, an AI system could produce a targeted escalation:

The solicitation requires RTO ≤4 hours. Our 2025 County proposal committed to eight hours, while the current DR architecture indicates four hours. Can we contractually commit to ≤4 hours for this deployment?

That is very different from sending an SME an RFP section and asking, “Please provide your disaster-recovery approach.”

The machine has already performed the reading, retrieval, reconciliation and question formulation. The human contributes only what the machine cannot obtain elsewhere: authoritative business truth.

If that model works, the relevant productivity metric becomes something like SME minutes per proposal, not words generated per hour.

7. Why Doesn't Everyone Already Do This?

This remains unresolved.

The existence of a technically possible workflow does not mean an individual company has implemented it.

To replace a $20-per-hour freelancer, a company may need to connect internal systems, establish permissions, identify authoritative sources, design escalation rules, handle document formats, create verification stages and maintain the workflow. A small technical business may reasonably decide that hiring someone on Upwork is easier.

In other words, the freelancer may be competing not with "$50 of AI usage," but with:

"$50 of AI usage plus the organisational effort required to make it dependable."

That is an implementation and adoption problem rather than necessarily an AI-capability problem.

The government technical-writing posting is particularly revealing because the buyer explicitly mentions Copilot and proposal platforms. At least in that example, “they simply do not know AI exists” is not a satisfactory explanation.

8. This Does Not Mean Fully Autonomous Proposals Are Solved

There is an important limit to this argument.

I would not assume that chaining multiple agents together makes a proposal workflow 99.9% reliable. Errors can propagate between stages; automated reviewers can share assumptions with the model that produced the original answer; and success on structured tasks does not automatically translate into reliable performance across messy professional workflows.

METR's research on AI task-completion horizons similarly cautions against equating benchmark progress with autonomous performance on arbitrary high-context professional work, particularly where tasks are messy and evaluation is difficult. METR – Measuring AI Ability to Complete Long Tasks

But this does not automatically preserve the traditional freelancer's role either.

The commercial comparison is not necessarily:

perfect AI versus perfect human.

It may be:

an AI workflow with targeted SME escalation versus a relatively unfamiliar external freelancer who must perform the same investigation manually.

That is a much lower technical bar.

9. What I Think These Freelance Jobs Are Really Telling Us

I therefore no longer see Upwork proposal jobs primarily as a catalogue of skills that AI cannot reproduce.

I see them as a catalogue of workflows that businesses have already demonstrated a willingness to pay to remove from their internal workload.

That is valuable market evidence, but it needs to be interpreted carefully.

Some workflows may already be disappearing into Loopio, Responsive, GovDash, Booma and similar platforms. Some may persist because software implementation is more difficult than hiring a contractor. Others may depend on bid-specific decisions that genuinely require internal authority, even if everything surrounding those decisions can be automated.

The research question I am now most interested in is therefore much narrower:

Where, between receipt of a complex RFP and submission of the final response, does current software still require a proposal professional to manually connect information, recognise uncertainty, obtain decisions and verify the result?

And, perhaps more importantly:

Can software reduce that person's role to a small set of explicit exceptions requiring authorised human decisions?

I do not yet have enough evidence to conclude where the strongest commercial niche sits. It may differ significantly between federal contracting, municipal ERP, cybersecurity, engineering, Singapore public-sector tenders and other technical markets.

But I think this reframing gives practitioners and software researchers a more useful place to disagree.

The question is no longer whether AI can write proposals.

Increasingly, it can.

The question is how much proposal operation can disappear before the remaining work consists almost entirely of decisions that only the bidder itself has the authority to make.

That is the boundary I want to understand next.

A question for the research

Work with complex tenders?

If your team repeatedly runs into a tender or proposal bottleneck that deserves closer attention, I'd be interested to hear about it. You do not need to share confidential information.

Continue reading

More research notes