Public-Tender Monitoring: Alerts by Field Without Promising That No Tender Will Be Missed

Tender monitoring collects notices from sources you name, filters them by field and alerts you. It cannot promise that no tender is missed, because nobody holds a closed list of every publishing body in Israel. So it is designed around three measurable things instead: coverage, latency, and a human review step.

Why "no tender will be missed" is not a promise anyone can keep

To prove nothing was missed you would compare what you collected against a complete list of what was published. No single body holds that list. Government ministries and their auxiliary units publish, and so do government companies, local authorities, water corporations, hospitals, higher-education institutions and more, each on its own channel and its own rhythm.

What you can state is measurable: "the system checks these eleven sources hourly, and the median gap between the publication date the source states and your alert is forty minutes." That is a claim someone can audit afterwards, so it is worth something. The sweeping promise cannot be audited, so all it does is move the blame to you the first time one tender falls between two portals.

The distinction is not semantic. It changes the build: a system that claims completeness does not build a human review queue, and a system that knows it is partial does.

What is your source list, precisely?

Before a line of code, write a table where each row is one publishing body. Without that document the project has no boundary, and nobody can say what it does not cover. Per source, record:

• The publishing body and the exact page or feed you actually read.
• How it updates: an RSS feed, a documented interface, a downloadable file, or a page that changes with no notification mechanism.
• The check frequency you chose, and why you chose it.
• Which procedure types appear there - open tender, prior information request, exempt engagement.
• What is known not to appear there. This is the column people skip, and it is the column that explains every future miss.

The working rule: if a body has an official feed or a documented interface, that is the route. An HTML page is what is left when there is not one. That ordering is worked through in scraping versus an API, and it removes most of a project's maintenance cost before the project is written.

Is data.gov.il a live tender feed?

No. A package_search query against the open catalogue returns only six datasets for the Hebrew term for tenders, and the central one - the tenders dataset, "Tenders Report" from the Government Procurement Administration - is described in the catalogue itself as a consolidated report published once a year covering engagements by government ministries and auxiliary units.

A datastore_search call against its resource returns 14,205 records, and the resource's last modified date is 16 February 2021. The fields returned are, translated from Hebrew: publication number, ministry name, publishing unit, procedure type, procedure number, procedure name, status, publication date, update date, last date for filing objections, last time for filing objections, basket name, winning supplier name, supplier company number, engagement start date, engagement end date, and subjects.

Two practical conclusions follow. First, that dataset is excellent for analysing who won what and from which unit, so it is research to do before bidding - but it will not tell you a tender opened today. Second, its dates are strings shaped 09.06.2009, not ISO, so any date comparison needs explicit normalisation before you filter on it. The status field carries values such as "closed", which is what lets you exclude finished procedures.

The government portal where live procedures are published is a separate channel from the open catalogue, and the Government Procurement Administration storefront is a separate system again. Real monitoring leans on those, and uses the open catalogue for background only.

Sources, update mode and latency

That table doubles as the expectations document for the internal stakeholder. A manager who has seen one row operating on a scale of days is not surprised when a tender arrives late through it.

Filtering by field: why too broad beats too narrow

An over-precise filter is the most common cause of a miss, ahead of any technical failure. Procedure names are written by a person in a publishing unit, working from no shared vocabulary:

• A synonym you did not think of - "information systems development" against "software services" against "system specification and build".
• Acronyms, spelling variants, and a space or a hyphen between words.
• A foreign term transliterated into Hebrew, alongside the same term in Latin letters.
• The real subject appearing only inside the tender documents, not in the title line.
• A subject classification chosen by the publisher that does not match how you describe yourself.

So filter in two layers: a wide layer that admits noise, then a ranking pass that orders what came through. Every rejected item is stored with the rule that rejected it, because that is the only way to discover the filter cut something it should have passed. The same discipline applied to changes in official text is covered in regulation monitoring and change control.

The human review step, and what it receives

Assuming a person will look is part of the design, not an admission of defeat. One daily digest at a fixed hour outperforms an alert per item, because it actually gets read. A digest entry needs the minimum that supports a five-second decision: publishing body, procedure name, procedure type, submission deadline, a link to the source, and the reason the system thought it was relevant.

The step everyone forgets is the decision log: who marked an item relevant, who marked it not, and when. Two months in, that becomes the calibration material for the filters, and it is the difference between a system that improves and a mailing list.

What you measure to know the monitor is alive

• Items read per source per run, retained as a series over time.
• An alarm when a source returns zero items while its own average is above zero - that is nearly always a change at the source, not a quiet market.
• The gap between the publication date the source states and the moment you alerted, as a median and a ninetieth percentile.
• The share of items marked relevant out of everything that passed the filter, broken down by source.
• The count of runs that failed outright, and the last successful run per source.
• A periodic manual spot check: open the source in a browser and compare it against the five most recent items you ingested.

Why a source change breaks a reader at all is covered in why scrapers break and what maintenance covers. In tender monitoring the cost of a silent break is unusually high, because no alerts looks exactly like a week with no suitable tenders.

What automated tender monitoring does

• Watches the sources you care about on a schedule.
• Filters by keyword, category, region, and budget so you only see what fits.
• Alerts you by email or message the moment a match is published.
• Logs everything to a spreadsheet or dashboard with the deadline and link, so nothing is missed.

What it costs

Tender monitoring is a recurring service - a monthly retainer to keep it running and adjust the filters as your business changes. See how much web scraping costs for the tiers. Tell me the sources and the keywords that matter to you and I will set up the watch.

Sources

• data.gov.il - CKAN dataset search
• data.gov.il - Government Procurement Administration tenders report, datastore read
• Government Procurement Administration storefront