One large RFP eats several person-days before anyone even thinks about the price.
A mid-sized company in mechanical and plant engineering receives a request. Sometimes it is a two-line email from a long-standing customer, sometimes a full tender pack from a portal: dozens of pages of specifications plus an Excel requirement list. Someone in inside sales has to read all of it and turn it into a list.
What follows is assembly work. Answers get copied together from old bids on the network drive, from product data in the ERP, and from whatever two colleagues happen to remember. The costing is done under time pressure, often the evening before submission, with list prices that may or may not be current.
The deadlines live in someone’s head or in a calendar entry. The clarification-question window is missed more often than the submission date. And after handing in, only whoever remembers follows up. The expensive part is not the writing. It is the searching: which of the last forty bids fits, which passage was approved by legal, which surcharge is current.
We start from the quote archive, not from an empty writing assistant.
The start is not a software workshop but one real tender, walked through page by page with inside sales and costing. The last twenty submitted bids already contain the answer structure, it was just never written down. And the strongest objection from sales becomes the specification: every one of our quotes is unique. True, which is why the AI employee does not write the unique part.
- Process mapping along one real RFP: Where the request landed, who read what, which documents were opened, where the hours went, and which deadline nearly slipped.
- Index the quote archive: Past bids, spec sheets, approved reference texts, and certificates become building blocks, each traceable to its source document.
- Prototype on real documents: Within days a working screen: upload the RFP, see the extracted requirements, review the matched blocks and the open gaps. Feedback came from real tenders, not from slides.
- Deliberately small start: Intake and requirement extraction first. Answer drafting followed once the team trusted the extraction. Calculation input came last, because it touches the ERP.
80 percent is done by the AI employee. The human decides at two points.
The AI employee picks up the request from email or a tender portal and reads the documents: PDF specifications, Excel requirement lists, scanned annexes, and captioned drawings. That becomes one structured list, separated into mandatory criteria, technical requirements, commercial terms, and formal submission rules. The submission date and the clarification-question window land automatically on a deadline board.
Then it matches every requirement against two sources: the indexed quote archive and your product and price data in CRM and ERP. Every proposed building block carries a source reference, so you see which past bid and which price list version it came from. Requirements without a match are not invented, they are routed as open points to engineering, purchasing, or legal. Sales reviews the requirement list and later releases the price. Everything stays a draft until a person signs it off.
Tender documents from a plant builder for a conveyor-technology component, specifications as PDF plus an Excel requirement list, downloaded from a procurement portal.
One field is flagged for review: the tender demands proof that no previous bid ever covered. The AI employee does not guess a wording, it names the point and who has to decide.
That was before, this is today.
This is how bid work ran before, and this is how it runs today with the AI employee. Conservatively calculated, the effort per large bid drops by about two thirds.
| Before | Today | |
|---|---|---|
| Effort per large RFP | Several person-days of groundwork | Less than one day of reviewing and deciding |
| Requirement list | Read by hand, noted in Excel | Extracted automatically, mandatory and optional split |
| Answer draft | Copied together from old bids | Building blocks with a source reference per paragraph |
| Costing | The evening before submission, prices often stale | Prefilled from the ERP, assumptions listed at the top |
| Deadlines | In one person’s head, clarification window missed | On a board, with early warning |
| Follow-up | Only when somebody remembers | Scheduled, response logged in the CRM |
* Savings conservatively calculated: one large RFP previously tied up several person-days of groundwork across inside sales, engineering, and costing, calculated here with three person-days. Today the requirement review and the price release remain, together under one person-day. That is about two thirds less per bid. At 15 to 30 large tenders per year, two saved person-days per bid add up to 30 to 60 person-days, or 6 to 12 working weeks. The baseline figures come from process mappings in bid teams in the technical Mittelstand, not from stopwatch measurement.
How do you build an AI employee like this, technically?
The knowledge from projects like this to take away, whether you build with us or on your own:
Pulling requirements from PDFs: language models instead of keyword search
GPT from OpenAI and Claude from Anthropic read the specification directly, including tables and captioned drawings, and produce a structured list instead of a summary. What matters is that every requirement stays anchored to its origin: document name, page, and the sentence it came from. That is what makes the list checkable.
Scanned tenders: read them cleanly first, then understand them
Many tender packs arrive as a scan or as a photocopy of a photocopy. Mistral OCR turns such documents into clean text with the table structure intact, before the language model extracts the requirements. Without that step, exactly the rows that make up the requirement matrix get lost.
The quote archive becomes the knowledge base
Past bids are not copied, they are stored as indexed building blocks: company presentation, quality certificate, reference project, technical description. Every block carries metadata, so you see which bid it came from and when it was last approved. Every proposal shows its source reference. The classic failure, where the previous customer’s name stays in paragraph four, can no longer happen.
Deadlines and exclusion criteria: fixed rules, not AI
Submission date, clarification window, and early warning are rules, not judgment calls. Exclusion criteria are checked first as a separate, hard category against what the company can demonstrably provide. Prices and lead times come live from the ERP, not from the model. A tender that fails one exclusion criterion should be dropped in the first hour.
UX: the interface decides adoption
The draft shows the source for every paragraph, clickable through to the original document. The price fields stay empty until a human releases them, so no number ends up in a bid by accident. And a deadline board shows every running tender with its remaining time. Exactly these three things turned skepticism into approval.
What does it cost in comparison?
Superkind charges per use case. The price grows with the number of tenders, not with headcount. Here is the honest comparison:
| Inside sales | CPQ software | Superkind AI employee | |
|---|---|---|---|
| Cost | 55,000 to 85,000 € per year and position | Often 20,000 € and up for the rollout, plus licenses | Price per use case, a fraction of a full-time position |
| What is included | The whole process, by hand | Configuration and pricing rules for products | Reading requirements, matching blocks, preparing the costing, watching deadlines |
| Free-text answers | Written from scratch | Barely covered, built for line items | Drafted per requirement, with source and marked gaps |
| Scales with | More staff | Product catalog | Number of tenders, without new positions |
| Exceptions | Human does everything | Fall out of the configuration | Flagged and sent to a human |
| Rollout | Recruiting and onboarding | A multi-month project | 2 to 3 weeks to the first productive version |
The honest comparison is the full cost of the current process: the person-days of groundwork, the bids never submitted because the deadline was too tight, and the quotes that go cold because nobody followed up.
What we learned about bid and tender work.
The quote archive is the most underrated data asset in the German Mittelstand. Companies invest in CRM dashboards while three hundred bids sit unindexed on a network drive. Each one holds approved wording, tested arguments, and real prices. Nobody searches them because searching is harder than rewriting. Making that archive searchable pays off on its own, even without an AI employee on top.
And a blunt observation: deadline discipline saves more deals than better prose. In our experience, more bids are lost by arriving late, by missing an annex, or by never being chased after submission than by a competitor writing more elegantly. The unglamorous parts of bid work are where the return comes fastest.
What it is not suited for: If you write a handful of quotes a year, the groundwork is not your bottleneck. If a quote is just a line-item list with no written argument, CPQ software solves that more cheaply. And if past bids sit scattered across personal drives and mailboxes, the first step is collecting them, not automating.
