How I Would Build a Public Tender Qualification System

Direct Answer

A public tender qualification system is a pipeline of contracts you could actually win, built by monitoring procurement portals, scoring each notice against what a company genuinely does, and extracting what each one demands. Tell it what you sell, get four contracts worth bidding for and the requirements behind each. This is a designed system, not a deployed build. It comes from the Shopify Your Industry lab and has never been sold to or validated with a customer.

Key Takeaways

• The product is not a search engine. It is a shortlist someone will actually read.
• The product is the coordination layer: discovery, qualification, requirement extraction, bid assembly, deadlines.
• The bottleneck is qualification precision. Two bad shortlists and the customer stops opening the email.
• Portal coverage is uneven. Structured data at the EU level does not mean structured data at every national portal.
• This is a model, like the freight booking system. The system I have actually built is the CRM follow-up loop.

What problem does this system actually own?

Tenders sit across portals in inconsistent formats. Finding the three worth bidding for costs more attention than writing the bids, so most firms find none of them.

Today the path usually runs like this:

1. Someone checks a portal on a Friday, when there is time.
2. Search terms match the wrong contracts, or miss the right ones under a different code.
3. A promising notice turns out to be a hundred pages, of which four matter.
4. By the time the requirements are understood, the clarification deadline has passed.
5. The same company details, certificates, and references are retyped for the fourth time this year.
6. A contract the firm could have won closes without anyone seeing it.

None of that is bid writing. It is information moving between a buyer, a portal, a bid owner, and whoever holds the certificates, each with one piece of it. That is the coordination layer, and it is the product.

The existing workflow I would map first

Before any model call, I would sit with the person who writes the bids and walk the last two: one won, one abandoned.

If that table is wrong, the system is wrong. I would rather spend a week on the table than a month on the wrong build.

How the system would run

Tender discovery

The system monitors sources continuously rather than on a Friday. TED, the EU’s notice supplement, publishes structured data and offers an API, so coverage there is dependable. Many national and regional portals do not, and coverage there means scraping, email alerts, or a person. I would show source coverage in the interface rather than implying the pipeline is complete. Above the EU thresholds publication is harmonised; below them, national rules and local portals apply, and that boundary is where most of the missed contracts live.

Qualification against capability

Each notice is scored against a capability profile: what the company actually delivers, where it can deliver, what it can staff, and what it can prove. Classification codes are a starting signal, not the answer, because buyers code the same work differently. The output is a fit judgement with the reasoning and the disqualifying facts visible, so the bid owner can overrule it in one glance. Precision matters more than recall here, and that is a deliberate trade-off: I would rather miss a marginal contract than spend a customer’s week on a bad one.

Requirement extraction

From the document pack, the system pulls what a bidder has to satisfy: eligibility, turnover and reference thresholds, certificates, staffing, lot structure, award criteria and weightings, submission format, and every date. Each extracted item carries a pointer back to the clause it came from. A requirement without a source reference is a guess, and a guess in a tender is expensive.

Bid assembly

Reusable components — company profile, references, certificates, method statements, standard annexes — are held once and versioned. The system prepares a draft against the extracted structure and marks what is genuinely new work versus what is reused. The lab card calls this a bid that starts at seventy percent. That is a design target, not a measured result, and I would not repeat it as evidence until something has actually been built and counted.

Deadline tracking

Clarification windows, submission deadlines, site visits, and validity periods become dated items with escalation. Missing a clarification deadline is a silent failure: the bid still goes in, just weaker. The system flags those separately from the submission date, because they are the ones people lose.

What stays under human control?

• The decision to bid.
• Every eligibility and self-declaration statement, which is a legal declaration by the company.
• Pricing.
• Final content of the technical response.
• Submission itself. Nothing is filed by a machine.

The system prepares, a person signs. That is the same rule I follow in the CRM build, and Anthropic’s note on building effective agents makes the same argument: keep the workflow simple and inspectable before adding autonomy.

How I would measure the path

Baselines first, and only baselines, because nothing has been built:

• Notices reviewed per month, and hours spent reviewing them.
• Contracts the firm later learned it had missed.
• Share of opened notices abandoned after reading, and how many hours in.
• Bids submitted per quarter, and how many were disqualified on eligibility rather than lost on merit.
• Days between notice publication and the decision to bid.

Self-learning here means usage signals, bid-owner corrections to fit scoring, and evaluation of qualification decisions against what the customer actually pursued — reviewed by a person. It does not mean the system quietly widening its own filter to look busy.

When this is the wrong build

• Qualification cannot be made precise. This is the bottleneck. If fit depends on relationships, local knowledge, or judgement the customer cannot articulate, the shortlist will be wrong and it will be abandoned.
• The firm does not want public work. Public contracts carry administration, payment terms, and audit exposure that not every business wants. Discovery does not change that.
• Bid capacity is the real constraint. If the firm can only write two bids a quarter and already finds four, a bigger pipeline is not the problem.
• The relevant portals are closed. Where notices arrive by post, by association mailing list, or through a portal with no usable interface, coverage is a person, and the economics change.
• Nobody owns the pipeline. Without a named bid owner, a qualified shortlist is another unread report.

How this connects to the engagement

This case is one of the models on Shopify Your Industry. The freight teardown has the same shape and a different wall: there the supply side, here the false positive. The monitoring and extraction pattern is closest to the Deal Database, which scans continuously and lets a person decide. The one system on this site that is actually running is the CRM follow-up loop.

If this coordination layer already exists in your company as a Friday portal check, the operating starting point is AI workflow automation. If you want it looked at honestly, describe the bottleneck. If you only want the next teardown, the newsletter is enough.

Summary

The abstraction is one line: tell us what you sell, and here are the contracts worth bidding for. The output is a shortlist worth reading and a bid that does not start from an empty page. Between those sits a boring coordination layer moving information between a buyer, a portal, and the person who has to sign the response. This is a model. It stays a model until someone who bids for a living describes where the qualification actually breaks.