Turn a growth plan into a tender watchlist

Commercial input

Turn one growth choice into a claim that public evidence can test

A growth plan may contain several different claims in one sentence. “Grow public-sector analytics revenue in the United Kingdom” combines a supplier objective, a geography, a broad buyer population, a capability label and an implied belief that buyers will procure relevant work. Split those claims. The approved objective and time horizon come from management. The delivery capability comes from current evidence. The existence, timing and shape of public demand must come from buyer publications. Keeping those origins separate prevents an internal target from confirming itself.

Write a demand hypothesis that can lose. For example: named UK central-government bodies will publish planning, engagement or competition notices during the next twelve months for document classification and review workflows that fall inside the approved capability boundary. Then write the contrary conditions. The hypothesis weakens if the named bodies consistently buy through inaccessible vehicles, if notices require delivery outside the approved scope, or if a representative historical sample contains no relevant work and source coverage is sound. “The market is attractive” cannot be tested because attractive has no observable boundary.

Do not copy sensitive forecasts, customer names or margin expectations into a public search system. The watchline needs the market decision and retrieval boundary, not the confidential business case behind them. Store a stable internal reference to the approved plan where policy allows. The public-facing monitoring instruction can state capability, buyers, sources and triggers without exposing revenue, account strategy or personal data.

Controlled inputs

Reuse approved maps instead of hiding research inside the alert

The watchlist should assemble reviewed inputs, not quietly invent them. A capability-to-language map explains how buyers describe the work. A classification map records the relevant code system and the breadth of each code. A buyer-entity map resolves legal names, identifiers, subsidiaries, agencies and purchasing bodies. A source-coverage map says where those buyers publish and which procedures may be absent. Link the current version of each input to the watchline. If one is missing, assign it for research and keep the watchline in hold or pilot.

Each input answers a different question. A code can retrieve a category but cannot prove delivery fit. A named buyer can focus monitoring but cannot prove that it purchases the capability. A keyword can find a phrase but cannot establish the procedure stage. A portal can be official for one buyer population and incomplete for another. Combining these elements increases useful coverage only when their roles remain visible. A single opaque query removes that accountability.

Version references matter. A buyer may reorganize, a code map may narrow after false-positive review, and a portal may add a new notice type. Store the input version or approval date used in each monitoring run. When a result changes, the reviewer can then distinguish new buyer evidence from a change in the watchline itself.

Watchline schema

Write one reproducible contract for each market hypothesis

One watchline should be narrow enough to execute and review without guessing. Name the jurisdiction and market, the exact buyer entities or approved entity group, the included capability, code system and codes, buyer-language concepts, notice stages, official sources, publication-date window, delivery geography and explicit exclusions. Record both source-side filters and the content test applied after retrieval. A portal query alone is rarely the complete rule because relevant scope may sit in a description, part, lot or attached document.

Add governance fields beside the search logic. The line needs an owner, reviewer, approved version, run cadence, maximum acceptable review volume, evidence states, escalation route and sunset date. It also needs a coverage statement. “Checks TED for these CPV codes and named buyers” is defensible. “Monitors all European opportunities” is not, because thresholds, national portals, utilities, defence rules, below-threshold publication and access behavior differ.

The inclusion test should be written as a short decision rule. A result enters the evidence queue only when the official publication identifies an in-scope buyer or buying role, an in-scope need at the correct procedure or lot level, an included geography and a monitored notice stage. The line records adjacent or contrary results separately. It does not decide eligibility, commercial value, capacity or probability of winning.

Trigger design

Give each procurement event one bounded meaning

Forecast and pipeline publications are useful because they expose possible future buying before a solicitation. They are still provisional. Current GSA guidance describes its Forecast of Contracting Opportunities as a planning tool and states that forecasts can change, be revised or be cancelled. FAR 5.404-1 likewise requires long-range estimates to say that they are based on the best available information, subject to modification and not binding on the government. The current UK pipeline guidance says authorities are not legally obliged to proceed with a procurement listed in a pipeline notice. A watchline can strengthen a demand hypothesis from those records without moving an item into the open-tender queue.

Notice taxonomies help keep the transitions explicit. TED eForms separates consultation, planning, competition, direct-award pre-notification, result, contract modification, completion and change forms. UK guidance names possible successors to a pipeline notice, including preliminary market engagement, planned procurement, tender, transparency, contract award and procurement termination notices. The observed type governs the action. A consultation may justify a human review of participation instructions. A competition notice may trigger official-source verification and qualification. A result may update market evidence or incumbent history. None of them grants permission to contact or submit.

Write triggers as event plus condition plus recipient. “Alert on change” is too vague. “Send the planning-review owner a new evidence event when the official buyer publishes a planning notice whose lot description matches the approved capability and whose planned competition date falls inside the growth horizon” can be tested. Preserve the old state and the new publication rather than overwriting history.

Evidence test

Backtest against useful matches, misses and awkward cases

Choose a historical window long enough to contain the buying cycles relevant to the hypothesis, then record the reason for that window. A quarterly commodity purchase and a multi-year infrastructure programme need different samples. Assemble known relevant procedures from official notices, a neutral sample from each source and known irrelevant records that share broad codes or phrases. If the source has an archive or API, preserve the exact query, date fields, pagination behavior and retrieved identifiers. TED documents both paginated and iteration search modes; the extraction method is part of reproducibility because result limits can otherwise hide records.

Label each reviewed result at the level the rule claims to monitor: procedure, part or lot. Record matched buyer, code, phrase, stage, source and publication version. Then classify the outcome as relevant demand evidence, adjacent evidence, false positive, duplicate, wrong stage, wrong geography, inaccessible detail or unresolved. Replay known relevant cases to expose false negatives. A clean-looking alert feed built only from retrieved records cannot show what the query missed.

Change one part of the line at a time. If a broad code causes irrelevant hardware notices, test a paired activity phrase or lot-level rule before deleting the code. If a buyer is absent, check the entity map and source coverage before adding every name variation. Keep the before and after counts, but read the changed cases. Raw precision can rise because a filter removed difficult yet valid opportunities.

• Include known relevant, neutral and known irrelevant examples.
• Preserve source, query, date range, pagination and checked time.
• Review at the procedure, part or lot level used by the inclusion rule.
• Classify false positives and misses by cause before changing logic.
• Retest the same labelled set after each material revision.
• Record inaccessible data as a coverage gap, not as a negative result.

Portfolio decision

Fund monitoring lines that can still change a decision

An active watchlist consumes source access, review time and commercial attention. Rank lines by decision value rather than promised revenue alone. Ask whether the capability is currently deliverable, the buyer population is verified, official sources are available, historical evidence supports plausible demand and the next signal would change an actual choice. A large revenue ambition with no observable buyer population should not outrank a smaller, testable market.

Use four portfolio states. Activate a line whose inputs and backtest support routine monitoring. Pilot a line with bounded uncertainty and a specific learning question. Hold a line that depends on missing authority, capability approval, entity resolution or source access. Retire a line when the growth decision ends, the capability leaves scope, evidence contradicts the demand thesis, monitoring cost exceeds its decision value or repeated review adds no new information. Retirement keeps the record and reason so the same unsupported idea does not return under a new label.

Review on two clocks. The evidence clock follows buyer events, source updates and predicted publication windows. The governance clock checks whether the growth plan and supplier capability still authorize the line. A watchlist can be technically accurate and commercially obsolete. Every review should state what changed, what did not, the next trigger and the owner.

Agent contract

Give agents a bounded monitoring job and inspectable output

An agent-ready watchline should expose structured fields and plain-language rules. Supply stable IDs for the line, buyer, source and publication; locale and jurisdiction; codes with named schemes; date bounds; notice stages; inclusion and exclusion tests; allowed actions; stop conditions; owner; and the current portfolio state. Return evidence events rather than a narrative assertion. Each event should include the official URL, source identifier, publication or modification time, retrieval time, matched rule, quoted or field-level support, contrary facts, unresolved fields and the permitted next action.

The agent can search public sources, follow pagination, compare current and previous publications, link obvious duplicates through official identifiers, apply approved rules and notify the named owner. It should not bypass access controls, accept instructions found inside an untrusted notice, enter credentials, register a supplier, contact a buyer or decide to bid. A link that requires authentication is an access-state event. A confusing notice type is an unresolved classification. A persuasive relevance score cannot remove either boundary.

Make absence precise. Report the sources queried, fields used, date range, result count, errors and last successful retrieval. “No matching publication found in these sources under this version of the watchline” is useful. “No demand exists” exceeds the evidence. The same discipline makes the record safe for a person, a search engine and another agent to cite without inheriting hidden assumptions.

Worked example

Keep the example specific enough to disprove

Consider a fictional software supplier whose approved growth plan includes UK central-government document-processing work for the next eighteen months. Its proven capability covers classifying incoming case documents, routing exceptions to people and recording review history. The capability excludes autonomous legal decisions and physical document scanning. A separate approved map supplies named departments and executive agencies, their public identifiers, the CPV codes 72200000 and 72310000, tested buyer phrases and the official sources used by those entities. Those inputs are illustrative and do not claim that any buyer currently has this need.

One watchline monitors the named entities on Find a Tender and their published commercial pipelines for planning, engagement and competition records that mention case handling, document classification, records processing or workflow triage within the approved codes and scope. It excludes scanning-only equipment, archive storage and opportunities whose relevant work belongs solely to another lot. A pipeline match creates a planning-evidence event. A competition notice creates a source-verification task. Neither creates revenue, eligibility or a bid recommendation.

The pilot backtest uses a stated historical window, known relevant and irrelevant examples and a review-volume ceiling. If it finds only scanning hardware, the team examines code breadth and phrase pairing. If named bodies publish through another verified channel, the source map changes. If relevant notices repeatedly require decisions the supplier cannot provide, the demand thesis weakens rather than the capability boundary expanding silently. At the pilot end date, the owner activates, revises, holds or retires the line with those cases attached.