--- title: "Proposal Automation: From Request to Draft with AI" description: "Automate your proposal process with an AI agent, not another SaaS tool. From intake to draft, with a real figure: 4 to 45 tenders a year at CIRFOOD." canonical: "https://www.whatsnext-ai.com/blog/proposal-automation-ai" published: "2026-09-01T00:00:00.000Z" updated: "2026-09-01T15:43:23.976Z" --- # Proposal Automation: From Request to Draft with AI Automate your proposal process with an AI agent, not another SaaS tool. From intake to draft, with a real figure: 4 to 45 tenders a year at CIRFOOD. ![Two people signing tender and contract documents by hand at a table](https://fgzcpjbyiakhjifaciaj.supabase.co/storage/v1/object/public/media/proposal-automation-ai-cover.jpg) Proposal automation means using an AI agent, not another SaaS tool, to pull and reconcile data from incoming tender documents into your pricing model. CIRFOOD, a catering company, used it to go from 4 to 45 tenders a year. ### The bottleneck isn't the writing Ask a bid manager where the time goes, and the answer is rarely "writing the proposal". The hours disappear up front. Every tender arrives as 12 to 22 documents in a mix of PDF, Excel, and Word. Before the real work can start, 72 CRM fields and a few hundred calculation inputs have to be re-keyed by hand. That pre-work is the part with the lowest strategic value and the highest cost. It's sorting, retyping, and checking. It doesn't decide whether you win the tender, but it does decide how many tenders you can take on at all. At [CIRFOOD](https://www.whatsnext-ai.com/cases/how-cirfood-scaled-from-4-to-45-tenders-a-year-without-adding-headcount), that turned a growth target into a hiring question. Leadership wanted 50% more tenders submitted with the same team and no drop in win rate. Without a fix for the pre-work, there were only two outcomes: grow the team, or let the win rate fall. Neither was acceptable. ### Why "just buy a proposal tool" doesn't work here The reflex makes sense: there's plenty of proposal software. Tools like Proposify, Qwilr, or the quoting module inside a suite like Teamleader make drafting and sending a clean proposal faster. For a standard service with a fixed price list, that's fine. But a tender isn't a standard proposal. The delay isn't in laying out the document, it's in gathering and recalculating data from source files that arrive in a different shape every time. Proposal software automates the sending. It never touches the real bottleneck, the reading and the recalculating. You keep the retyping, only in a nicer template. On top of that, most of those tools are a subscription. You rent a feature, you own nothing, and your data and workflow stay tied to the vendor. For a process you run for years, that's a fair question to ask: who owns your data, your prompts, and your workflow six months from now? ### And building it yourself in n8n won't hold up The other reflex is: we'll just build it ourselves with a low-code tool. Forums like Reddit are full of complete proposal generators built in n8n around an intake form. For a demo, that works. In production, it breaks. A low-code flow has no protection for an existing calculation model, no auditable trail per field, and it falls over the moment a supplier hands you documents in a slightly different format. Which, on a tender, happens every single time. You build something fragile that needs repairing with every new set of inputs. That isn't automation, it's a second job. We wrote up that trade-off in [why hiring an AI agency beats building it yourself](https://www.whatsnext-ai.com/blog/why-hiring-an-ai-agency-beats-building-it-yourself). ### Our approach: an agent that reads, calculates, and protects your model Our approach is an AI agent that reads the tender documents, extracts the data, and updates your existing calculation model without touching its protected formulas. At CIRFOOD we started by refusing to scope a tool. The ask was capacity, not software. So we treated it as discovery first, build second. First we mapped the actual work. With the bid managers, we walked through three live tenders (Spaarnelanden, Amsterdam VU, Maastricht UM) field by field. That produced a full inventory: which 72 fields, the documents each one lives in, how long each takes to extract by hand, and how it fails when a package is incomplete or formatted unusually. Then we found the calculation bottleneck. The Aanneemsom (contract sum) isn't simple data entry. It's a transformation: gross wages from the previous caterer's staff-handover schedule become all-in hourly rates inside CIRFOOD's own model. Every caterer hands that schedule over in a different column layout. The bottleneck wasn't the maths, it was reconciling shape-shifting inputs with one fixed calculation model. That model holds roughly 230 formula cells the business has trusted for years. Any tool that touches it has to guarantee, mechanically, that those formulas stay intact. So we designed the safety layer (formula protection with a hard fail on mismatch) before we wrote the parser. #### What the agent actually does Phase 1 is live now, with two production tools. - CRM Tender Extraction Tool: a bid manager uploads a ZIP of the full tender package, hits run, and gets back an Excel with 72 structured fields. Each field carries a confidence score, the source document, the page number, and the exact citation. It runs on Claude Sonnet 4.5, deterministic, inside CIRFOOD's own GCP project. - Aanneemsom Calculator: it combines the extraction output with the incumbent caterer's handover schedule and fills the existing calculation workbook. It populates about 80 input cells and never touches the 230 formula cells. If the formula-protection check fails after a run, the program halts hard. Approximated rates are flagged separately for human review. It's deliberately an [AI agent](https://www.whatsnext-ai.com/glossary/ai-agent), not a rule-based macro: it reads unstructured documents, reasons over the content, and returns an auditable answer with its source. That [difference from classic RPA](https://www.whatsnext-ai.com/glossary/rpa) is exactly why a fixed-rule approach would break on a multi-document tender. ### Why we chose owned code over a subscription This asks more than plug-and-play. There was a discovery phase first, and that isn't a detour, it's the reason it works. You can't automate a dossier with 230 protected formulas without first understanding how that model is built. What that choice buys is ownership. The tool runs in a GCP project CIRFOOD owns. The prompts, the extracted data, and the configuration belong to CIRFOOD. The architecture is stateless and reproducible, and every run is auditable. If What's Next disappeared tomorrow, CIRFOOD would still have a working asset, not a dead subscription. And the human stays in charge. Processing only starts on command, low confidence raises a warning, approximations get flagged. The bid manager decides. That's the difference between an agent that replaces judgment and one that hands back hours. ### The result: from 4 to 45 tenders a year Across three measured tenders, the extraction tool pulled 85% of the CRM fields in an average of 128 seconds per tender. The pre-work that used to eat several hours per bid manager now finishes in about two minutes, with an explainable trail per field. The figures that follow from that: - 45 tenders a year, up from 4, with the same team. - About 2 minutes of pre-work per tender, down from 10 days. - 40x more tenders submitted by that same team. - Roughly 400x cheaper per tender: the manual work cost 225 to 300 euros per dossier (3 to 4 hours), the owned stack about 0.55 euros. Across 45 tenders a year, that's 10,000 to 13,500 euros against around 26 euros. That's not 30% cheaper, and it scales the right way: a second tender costs the same minutes as the first. The 50% growth target moved from a hiring conversation to an execution one. Leadership now plans tender volume against team capacity instead of against team hours. “What differentiates them is not only their technical expertise, but also their deep understanding of AI governance and its pitfalls, ensuring that innovation is implemented in a controlled, compliant, and sustainable way. This is not a one-off project, but a long-term partnership built on trust, professionalism, and measurable outcomes.” Stefano Teatini, General Manager, CIRFOOD. ### Does the pattern hold beyond tenders? It does. The same pattern, read messy source documents, pull the right data, return an auditable answer, powers our work for [More2Win](https://www.whatsnext-ai.com/cases/turning-scattered-knowledge-into-an-ai-powered-research-engine), an impact agency with five years of scattered knowledge. There an AI research agent now answers a question in 30 seconds, at roughly 640x lower cost per proposal than the manual search, across 1000+ documents, EU-hosted and with no external model training. Tenders, quotes, proposals, knowledge dossiers: as soon as the bottleneck is "get data out of shifting documents and reuse it reliably", this approach fits. It is a concrete form of [workflow automation](https://www.whatsnext-ai.com/glossary/workflow-automation). Recognise it from your invoices? See how we did it for [invoice automation](https://www.whatsnext-ai.com/blog/ai-invoice-automation), and the wider picture in [business process automation with AI](https://www.whatsnext-ai.com/blog/business-process-automation-with-ai). ### When this isn't your first step To be fair: not every proposal process needs this. If you send a handful of standard quotes a month from a fixed price list, with no shifting source documents and no calculation model to protect, a simple proposal tool is fine. The gain here lives in the opposite case: lots of dossiers, messy input, and a calculation that can't break. If that second case sounds familiar, the first step isn't a tool, it's a conversation about what the pre-work is actually costing you. [Book a free consultation](https://www.whatsnext-ai.com/contact) and we'll look together at where your hours go.