This case study is anonymised. We build internal systems, so we describe the kind of system and why it was built, not who it was for.
The situation
The client is a trading company for which public procurement is one of several sales channels. Public bodies publish tenders every day, and some of them match what the company sells.
The difficulty is not a lack of tenders. They appear on several different portals, in different formats, and most of them are irrelevant to any given company. Finding the relevant ones meant someone opening portal after portal, reading titles, opening details, checking deadlines and copying promising tenders into a list. It was slow, and a tender on a portal nobody checked that day was easy to miss.
What we built
A self-hosted n8n workflow that runs every morning and does the reading. The results go into the database the team already uses for its sales records, so nobody has to learn another tool.
The pipeline, in order:
- Collect. The workflow pulls new tenders from several public tender portals and aggregators. Where a portal offers structured data, it is read directly; scraping is the fallback, not the default.
- Normalise and deduplicate. Each source has its own format, so every record is converted into one common shape. The same tender often appears on more than one portal; those copies are merged into a single record that keeps all the links.
- Hard filters. Value range, category and deadline are checked with plain rules before any AI is involved, so nothing is spent on tenders that cannot fit.
- Cheap pre-screen. An inexpensive language model scores each remaining tender against the company's range of products. Most tenders stop here.
- Deeper analysis. Tenders above a threshold go to a stronger model, which reads the notice and, where available, the tender documents, and summarises fit, requirements and possible obstacles.
- Record. Each relevant tender becomes a record with its score, the reasoning, the deadline and links to its sources.
Early notices that announce a future tender are tracked too, and the record is updated when the real tender opens instead of creating a duplicate.
How it works day to day
The team starts the day with a short list of new opportunities, already scored and explained. Old records nobody has acted on are cleaned up regularly, using a strict list of statuses that may be removed, so nothing someone is working on disappears. A simple switch lets the team pause the creation of new records without touching the workflow itself.
Nobody opens portals one by one any more. The team spends its time deciding which tenders are worth a bid, not finding them.
What we learned
Use rules first and models second. Anything that can be decided by a plain rule, such as value, category or deadline, should be. Language models are good at reading and judging text, and that is where they earn their cost.
Silent loss is worse than a crash. In any loop that processes items one by one, make sure skipped items are still accounted for. A workflow that reports success while quietly dropping the rest of the list is the hardest kind of failure to notice.
Never trust the shape of a model's answer. Parse model output defensively and fall back to a safe default, so one oddly formatted response cannot stop a whole run.
Read the source documents when they matter. Notices are summaries. When a field such as a delivery date matters, extract it from the actual documents, quote where it came from and mark anything that is only an estimate.
Choose models on your own data. Before picking or changing a model, run candidates over real examples the team has already judged. Price per token says little about how a model handles your particular text.
Which service this is
This is AI automation built on n8n: deterministic steps wherever the data allows, language models only where reading and judging text is the actual work, and results delivered into the tool the team already uses. A related example is Supplier Sourcing and Deadline Alerts in n8n.
