Automating public RFP responses, one step at a time

Background

The client, a firm of roughly a hundred billable specialists, responds to public tenders as a steady part of its sales work. Every response was handled manually end to end. Someone finds the tender, reads the requirements, digs up matching CVs and reference cases from SharePoint and personal folders, drafts the response documents, and then walks the package through review. All in all, twelve to fifteen hours of working time, per response.

The question we were brought in with was the familiar one: can AI automate this? It can. What actually decides the scope of the build is something more specific, namely which parts of the process pay for their own automation.

Approach

Any repeated process can be broken into discrete steps, and each step can be automated independently, with its own build effort, its own risk, and its own payoff. So that is where we started. We mapped the response workflow into seven steps, from searching the national procurement portal all the way to final submission, and for each one we estimated what an AI agent could do and what it would save per run.

Two things jump out of the map. First, the biggest single sink is not the searching or the admin. It is writing the first draft. Four to five hours of it, in fact, which an agent grounded in past proposals and reference data can compress to about an hour of review-and-refine. Second, some steps should stay manual on purpose. Final submission through the procurement portal involves authentication and legal verification, and automating it would buy fifteen minutes at the price of the riskiest integration in the whole system. Not a good trade.

Three scenarios

Instead of proposing one grand system, we bundled the steps into three scenarios and put them side by side: what each costs to build, and what each saves per response.

• Internal tool only. Automate the four steps that touch only internal data: exploring requirements, gathering references, packaging reviews, applying feedback. Four to seven weeks of build, about two hours saved per response, no external integrations.
• Best sprint value. Add tender filtering and document pre-filling. Nine to fourteen weeks, about six and a half hours saved. The biggest sink, manual drafting, is captured while submission stays under human control.
• End-to-end. The full workflow with the agent as control point. Thirteen to twenty weeks, about nine hours saved. A response drops from roughly twelve hours to under three.

Recommendation

Our recommendation was to build the first scenario and expand only on observed value. Why start so small? For one, the internal steps are the most repeatable part of the process. The SharePoint connectors built for them are reused by every later step, so the investment compounds instead of being spent twice. Skipping external portal integration up front also avoids the authentication and browser-automation complexity entirely. And a working pilot, testable after about two weeks of development, produces the one thing no scoping estimate ever can: real usage data to decide whether the remaining steps are worth their build cost.