A `tender_bidder_action_timetable` is a versioned record of procurement events that can affect the bidder. Each row identifies the event, source wording, actor, required or possible bidder action, trigger, time expression, condition, scope, delivery object or channel, stated consequence, completion evidence, owner, status and recheck rule. The timetable separates actions the bidder must take from buyer actions, information dates and forecasts. It does not resolve contradictory source dates, choose an unstated time zone, calculate legal rights or replace the team's internal response plan.
A buyer timetable often looks like a chronological list, but chronology does not tell a bidder what to do. A request-to-participate deadline requires a delivery. A public opening date may require nothing. A presentation date can be a fixed appointment for invited bidders only. A validity period is a continuing commitment rather than a meeting. A planned award date can move without creating a bidder task. Copying all of these entries into one calendar produces reminders that are noisy at best and unsafe at worst. It can also miss the action before the visible milestone, such as booking a mandatory visit or acknowledging an invitation before a revised tender can be started.
Read the event before the date. A timetable row is ready for a bidder task only when the official material identifies enough of the actor, act, object, condition and scope. Preserve the issued expression and its source before deriving a working instant. Record only the consequence the buyer or applicable procedure states; do not upgrade silence into disqualification. A buyer forecast stays a monitor item. A conditional event stays dormant until its trigger is proved. Agents may extract and classify events, but calendar writes, portal acknowledgements, communications, uploads and submissions require the customer's authorized workflow.
Actionability
A date becomes useful only after the event is identified
Tender packs use the word “deadline” for different events. The TED eForms business terms make several distinctions explicit: receipt of tenders, receipt of requests to participate, receipt of answers, receipt of expressions of interest, public opening and tender validity are separate fields. That vocabulary does not govern every procurement. It does show why a date-only list is too weak for operational use. A row must say what happens and whose action it is.
Start with an event key such as `request_to_participate_receipt`, `site_visit_booking`, `clarification_question_receipt`, `tender_receipt`, `presentation_appointment` or `tender_validity_expiry`. Keep the buyer's label beside the normalized key. The source may call an event “return of selection questionnaire,” “application cutoff” or “deadline for candidatures.” A normalized type supports retrieval; the issued wording keeps the classification open to review.
Actor identification prevents the most common false task. “Opening of tenders: 14:00” describes a buyer or portal event unless the procedure expressly requires bidder attendance or another act. “Expected notification of award” is usually a forecast to monitor. “Submit clarification questions by 12:00” has a bidder actor and a delivery object. Each belongs in the timetable, but only the last is immediately eligible for a bidder action.
Do not infer the actor from the column heading alone. Preserve the full sentence, table headers, footnotes and referenced clause. A row under “supplier dates” can still contain the buyer's answer-publication target. A named buyer event can activate later bidder work. Classification depends on the complete instruction, not its position in a schedule.
| Class | Meaning | Calendar treatment |
|---|---|---|
| action_required_confirmed | The source requires an in-scope bidder act | Create only through the authorized workflow |
| action_required_conditional | A bidder act applies if a stated trigger occurs | Watch the trigger; do not activate early |
| monitor_only | The date may change readiness but requests no present act | Create a check, not a completion task |
| buyer_action_only | The buyer or portal acts | Keep for sequence and monitoring |
| completed_with_evidence | The required act has external or controlled proof | Retain proof and recheck rules |
| scope_unresolved | The relevant bidder, lot or stage is unclear | Block action assignment |
| source_conflict | Comparable official assertions disagree | Route to the date-conflict record |
| time_unresolved | The event is known but its usable instant is not | Route to date and time review |
Evidence boundary
Bind each event to one source version and bidder scope
Create the timetable from a declared evidence set: notice, procurement-specific instructions, data sheet, forms, amendments, clarification log and permitted portal observations. Record inaccessible or expected sources instead of treating their absence as confirmation. The World Bank publishes standard procurement documents, for example, but an individual RFP's Data Sheet supplies procurement-specific dates and can modify the standard instructions where the document permits. A master form is context, not the live timetable.
Each occurrence needs the exact wording, document title, issue or checksum, retrieval time, visible locator and a representation-specific selector. For a PDF, that can be printed page plus text and context. For a workbook, use sheet, table, row and cell or named range. For a portal, record the buyer-visible label, permitted URL or procedure identifier, observation time and safe control identifier. A screenshot may help a reviewer but should not replace the underlying location when it can be preserved.
Scope belongs on the event, not in a note at the end. Record procedure stage, lot, bidder audience, legal entity, consortium role, site, option and invitation status when relevant. UK guidance on competitive flexible procedures illustrates why stage matters: a procedure may have a participation period and several tendering rounds. A direct invitation can start a later tendering period for pre-selected suppliers. The public notice and the private invitation do not address the same audience.
Use `scope_unresolved` when the source says “shortlisted tenderers” but the current bidder's status is not available to the timetable. The row can still be discovered and monitored. It cannot become a bidder task until the audience link is proved. This keeps an agent useful without letting it guess organizational or procedural facts.
| Field | What it records | Failure state |
|---|---|---|
| event_id | Stable identity within the procurement snapshot | event_identity_unresolved |
| source_assertion | Exact wording, source version and dual locator | source_boundary_incomplete |
| audience_scope | Stage, lot, bidder group and condition | scope_unresolved |
| actor_action_object | Who must do what to which thing | action_unresolved |
| time_expression | Raw value and reviewed working representation | time_unresolved |
| consequence | Only the outcome expressly stated in scope | consequence_unstated |
| completion_proof | Evidence that closes the action | evidence_pending |
| expiry_trigger | Change that forces another review | monitor_required |
Time semantics
Preserve the kind of time relationship the buyer issued
A fixed instant states a receipt or appointment time. A bounded window has an opening and closing point. A duration keeps something in force for a period. A relative rule depends on another event. A buyer-triggered action begins only after an invitation or notice. A recurring monitor asks the team to check for a change. Converting all six into timestamps throws away the conditions that make them reliable.
Tender validity shows the problem. TED eForms records tender validity as a duration, while a procurement-specific document may state that the proposal remains valid for a number of days from the submission deadline. Store the raw duration, the named starting event and the source counting rule. Derive an expiry only after the anchor and calendar treatment are proved. A spreadsheet that adds 90 to an uncertain start date does not create an official expiry.
Relative events need explicit dependencies. “Within three working days after invitation” requires the invitation occurrence, delivery time, defined working-day calendar and inclusion rule. Until those inputs exist, keep the event as `action_required_conditional` with `time_unresolved`. Do not substitute publication time for receipt time or use the agent's local holiday calendar.
The final working instant may belong to a separate date-resolution process. AN-035 handles time zones and final timestamp normalization; AN-073 handles contradictory dates. AN-075 consumes their approved outputs. Its job is to keep the action relation, trigger and scope attached so a normalized timestamp never travels without its meaning.
| Type | Example | Required evidence |
|---|---|---|
| fixed_instant | Tenders received by 12:00 on the stated date | Date, time, zone or governing locale treatment |
| bounded_window | Samples accepted between two stated instants | Both bounds and whether each is inclusive |
| exact_appointment | Invited presentation at a named slot | Invitation, attendee scope and slot |
| duration_from_event | Offer valid for 90 days after receipt deadline | Duration, anchor and counting rule |
| buyer_triggered | Revised tender due after a later invitation | Authorized invitation occurrence |
| recurring_monitor | Check the portal for an amendment | Cadence, source and stopping condition |
Operational meaning
Separate the action, its condition and its stated consequence
Write the action as an actor, verb and object. “Supplier submits request to participate through portal X” is usable. “Participation deadline” is not. Add the channel only when the official source identifies it, and link the object to the submission architecture rather than calculating files inside the timetable. AN-072 owns the full response-object graph; the timetable points to the relevant object identifier.
Conditions can change all three parts. A site visit may be optional, mandatory for tender submission, mandatory only for a lot with physical access, or available on request during a booking window. A presentation may apply only after the buyer sends an invitation. An amendment acknowledgement can be required in one solicitation and merely offered by a portal in another. Use the specific wording. Interface presence alone does not create an obligation.
Record consequences with a source and scope. French Code de la commande publique Article R2151-5 states that late offers are eliminated within that legal setting. FAR 52.215-1 describes receipt, modification and amendment acknowledgement for solicitations that include that provision. Neither text establishes the consequence of a missed site visit in an unrelated procurement. If the package is silent, use `consequence_unstated` and send the risk question to the appropriate reviewer.
Do not infer an extension. EU Directive 2014/24 Article 47, German VgV section 20 and French rules address circumstances in which tender periods are set or extended, including certain late information or significant changes. Applicability and effect depend on the procurement. The bidder timetable records a published new deadline only after authoritative change evidence. Until then, the current confirmed event remains visible and any extension question stays separate.
| Part | Supported entry | Unsafe shortcut |
|---|---|---|
| Actor | Invited bidder | Our team |
| Action | Acknowledge receipt of the revised-tender invitation | Handle invitation |
| Object | Invitation identified by procedure and round | Portal item |
| Condition | Only after the buyer issues the invitation to this account | Expected next week |
| Consequence | No consequence stated in the reviewed instruction | Automatic exclusion |
| Proof | Portal status and retained acknowledgement evidence | Task marked done |
Closure
Close an action with proof from the relevant channel
Internal task completion and procurement completion are different facts. A coordinator can mark “submit tender” complete while the portal is still uploading, validating or waiting for the final confirmation. The European Commission eSubmission guide says that nothing is submitted until the Submit button is clicked. Its operator guide describes a submission receipt containing identifiers and the reception timestamp as proof of compliance with the receipt limit in that system. Use the evidence the actual channel supplies.
Define proof before the action begins. A visit booking may close with a buyer confirmation carrying the participant, date and site. Attendance may need a separate sign-in or buyer acknowledgement. A clarification question can have a sent record without proof that the official channel received it. A physical sample needs custody or delivery evidence tied to the package. The timetable can point to the evidence store without exposing sensitive artifacts publicly.
Use `completed_with_evidence` only when the proof matches the event actor, object, scope and required channel. Keep `performed_evidence_pending` when the human reports the act but the expected receipt is unavailable. That distinction gives an agent a useful next action: retrieve the receipt, confirm the booking or escalate the missing proof. It prevents a second submission attempt based solely on uncertainty.
Completion does not erase future obligations. A submitted initial tender can lead to a presentation, negotiation, revised tender, validity-extension request or standstill notice. Preserve the completed row, close its monitor where appropriate and activate downstream events only from their stated triggers.
Fictional case
Build the timetable around bidder decisions, not a pretty chronology
Consider a fictional two-stage procurement for cleaning and servicing a metropolitan rail depot. The invented dates below illustrate the data model; they are not a live opportunity and do not state rules for any jurisdiction. The buyer publishes a participation cutoff, offers two depot-visit slots, sets a clarification cutoff, plans to invite selected bidders later, requires an initial tender, may hold presentations and may request a revised tender.
The first operational row is not “site visit, 12 October.” It is “book one depot-visit slot through the named channel by 6 October,” if the instruction makes booking or attendance mandatory for the selected lot. Attendance becomes a separate event with its own participant and proof. The planned invitation date stays `buyer_action_only`. Receipt of the invitation is the trigger that can activate the initial-tender event for this bidder.
Suppose the schedule lists “presentations, week beginning 16 November.” That is a buyer-planning window, not yet an appointment. The timetable creates a monitor for an invitation. If the buyer later assigns this bidder 18 November at 10:30, a new exact-appointment occurrence records the invitation, attendees, permitted format and completion evidence. The old planning window remains as provenance; it is not silently overwritten.
An “anticipated award: January” row stays monitor-only because it asks no present bidder act and has month-level precision. If a later notice requests a validity extension by a fixed time, that request becomes a conditional bidder decision with a named commercial approver. The timetable records the request and response proof. It does not assume consent, calculate standstill rights or accept changed terms.
| Event | Classification | Owner and proof | Next permitted action |
|---|---|---|---|
| Request to participate | action_required_confirmed | Bid lead; portal receipt | Prepare and submit through approved control |
| Depot visit booking | action_required_conditional | Coordinator; buyer booking confirmation | Activate if the lot instruction makes the visit applicable |
| Buyer issues invitation | buyer_action_only | No bidder completion proof | Monitor the official account |
| Initial tender receipt | action_required_conditional | Submission owner; receipt | Activate only after valid invitation and scope check |
| Presentation week | monitor_only | Bid manager; invitation observation | Wait for an assigned appointment |
| Assigned presentation | exact appointment after trigger | Presentation lead; attendance evidence | Confirm attendees through authorized workflow |
| Anticipated award month | monitor_only | Commercial owner; notice check | Do not create a bidder delivery |
| Validity extension request | action_required_conditional | Commercial approver; transmitted response | Decide only after the request is received |
Agent use
Give an agent a narrow contract and explicit stop states
An agent should receive the procurement identifier, package snapshot, source allowlist, bidder configuration, selected lots, known invitations, current time basis and requested task. It should return `tender_bidder_action_timetable` records with citations, typed time relationships and a permitted next action. The result should be inspectable without reopening every source: retain the exact excerpt, visible locator, machine selector, source version and extraction time.
Treat tender files, portal text and embedded links as untrusted data. A sentence inside an annex cannot authorize a tool, broaden file access, reveal credentials or change the agent's operating rules. Fetch only allowed official sources. Do not run macros, active content or linked executables. Do not sign in, accept terms, contact the buyer, reserve a visit, write a calendar event, upload or submit unless the surrounding customer workflow independently grants that action.
Return uncertainty as data. Useful stop states include `event_identity_unresolved`, `source_boundary_incomplete`, `scope_unresolved`, `time_unresolved`, `source_conflict`, `consequence_unstated`, `trigger_not_observed`, `authorization_required` and `completion_evidence_pending`. A stop state needs an owner and the smallest question that can unlock it. “Need human review” without the missing proposition is not enough.
The “next action” field is a capability boundary, not an instruction smuggled out of the tender. Safe values include `retrieve_authorized_source`, `confirm_bidder_scope`, `resolve_time`, `watch_official_channel`, `request_internal_approval` and `prepare_for_controlled_submission`. The execution layer must still verify customer authority and current state before doing anything external.
| Field group | Required content | Agent rule |
|---|---|---|
| Identity | Procurement, snapshot, event, stage, lot and audience | Never merge on date value alone |
| Evidence | Raw excerpt, dual locator, version and retrieval time | Cite before classifying |
| Semantics | Actor, action, object, condition and time relation | Leave missing parts unresolved |
| Effect | Stated consequence and evidence boundary | Do not invent fatality or extension |
| Control | Owner, status, next permitted action and expiry trigger | Do not execute beyond authorization |
| Closure | Receipt or other event-specific proof | Do not equate an internal checkbox with completion |
Change control
Keep the external timetable separate and update it by event
The bidder-action timetable records the buyer-facing procedure. The internal response calendar records writing, evidence collection, pricing, reviews, approvals, file production and contingency. Link them by event identifier, but never replace a buyer deadline with an earlier internal cutoff. When the official date changes, the external row changes through source evidence; the internal plan can then be recalculated under its own controls.
Invalidate narrowly. An amendment that moves initial tender receipt may affect relative clarification rules, production plans and a validity anchor. It does not automatically change a separately fixed site-visit booking or another lot's sample delivery. Record the amendment relationship and recompute only the dependent event graph. If the change scope is unclear, route it to AN-073 rather than guessing broad effect.
Use clear handoffs. AN-023 reconciles deadline claims across websites. AN-026 verifies lot-level tender deadlines. AN-035 resolves time zones. AN-064 verifies the clarification channel. AN-072 maps submission objects. AN-073 decides date conflicts. AN-077 will extract pass-fail gates. AN-078 will compare versions. AN-117 handles a missed clarification cutoff, and AN-266 owns standstill actions. AN-075 keeps the complete event-to-bidder-action layer between those records.
Release the timetable as `complete_for_action_planning` only when the declared sources have been reviewed and every material event is classified or carries a bounded unresolved state. A timetable with open review items can still be useful as `complete_with_review_items`. It must not answer “what must the bidder do next?” with a confirmed action if the relevant actor, scope, trigger or time remains unresolved.
What good looks like
Useful outcomes from procurement timetable bidder actions
- Every material schedule entry has a stable event identifier and exact source evidence.
- Bidder actions, buyer actions, monitor-only dates and unresolved entries remain visibly distinct.
- Each action names its actor, object, condition, scope, owner and permitted next step.
- Fixed instants, bounded windows, appointments, relative rules and recurring checks keep their different time semantics.
- Only consequences stated by the buyer or the scoped procedure are carried into the timetable.
- Completion means evidence such as a receipt, accepted booking or acknowledged invitation, not a checked box alone.
- Events affected by an amendment, invitation, lot change or source replacement reopen automatically.
- An agent can return the next supported bidder action without pretending that every date is settled.
Operating model
How to run the work
- 01
Declare the procurement snapshot
Name the procedure, stage, lots, bidder configuration, authorized source boundary and package version that the timetable covers.
- 02
Extract events before sorting dates
Capture the complete source sentence, dual locator, actor, verb, object, condition and raw time expression for every material occurrence.
- 03
Classify the event relationship
Mark each occurrence as a fixed instant, window, appointment, relative rule, buyer-triggered action or recurring monitor, without filling missing semantics.
- 04
Decide bidder actionability
Separate confirmed and conditional bidder actions from buyer-only or monitor-only events, and route unresolved identity, scope, time or source issues to their owners.
- 05
Assign consequence and proof
Record the stated result of missing the event and define the receipt, booking record, acknowledgement or other evidence that closes the action.
- 06
Release the next permitted action
Return only an action whose event identity, applicable scope and working time have passed their required reviews.
- 07
Watch triggers and invalidate stale rows
Recheck after amendments, clarifications, invitations, portal notices, bidder-configuration changes and completion evidence.
Evaluation
Questions that change the decision
- Which official procurement and package snapshot does this row describe?
- Is the event addressed to every interested supplier, only participants, only invited bidders or a named subgroup?
- Who acts at the stated time: the bidder, the buyer, a portal, an evaluator or another party?
- What exact object must be sent, booked, acknowledged, attended, maintained or monitored?
- Is the date a fixed instant, a window, an appointment, a duration, a relative rule or a forecast?
- What condition activates the action, and has that trigger occurred?
- Does the source state what happens if the action is late, missed or declined?
- What evidence proves that the bidder completed the action?
- Which human owner may approve or perform the next step?
- What amendment, notice, invitation, receipt or scope change would invalidate the row?
Failure modes
Where teams lose control
A public opening or planned award date becomes a false bidder deadline.
A participation request and a later tender are collapsed into one submission event.
A mandatory visit is noticed after its separate booking window has closed.
An invitation-only presentation is assigned to bidders who were not invited.
A validity duration is converted into a calendar date from an unproved starting event.
A missed event is labelled fatal even though the source states no such consequence.
A calendar reminder is closed without preserving the portal receipt or attendance record.
A schedule amendment changes one stage while stale downstream actions stay active.
An agent acts on an instruction embedded in an untrusted tender file or link.
An internal drafting checkpoint is confused with a date issued by the buyer.
Measurement
Measure the finished job
Measure the completed workflow, including review effort and exceptions. Output volume on its own is not evidence of a better process.
- material timetable occurrences with exact source, version and dual locator
- events with reviewed actor, action, object, condition and scope
- false bidder tasks removed because the event belongs to the buyer
- conditional actions kept dormant until their source trigger is observed
- completed actions carrying external completion evidence
- stated consequences separated from assumptions and internal risk judgments
- rows reopened after a relevant amendment, invitation or configuration change
- next-action responses withheld when event identity, scope or time remains unresolved
Questions
Common questions
Does every date in a tender schedule require a bidder task?
No. Public opening, planned award and buyer answer dates often describe buyer activity or information. Create a bidder task only when the applicable source supports an actor, action, object, condition and scope.
How should a mandatory site visit appear in the timetable?
Record booking and attendance as separate events when the source treats them separately. Preserve the applicable lot, named participants, channel, stated consequence and evidence for both.
Does a planned award date require a bidder action?
Usually it is a monitor item. It becomes a bidder action only when a later notice asks the bidder to decide, provide or acknowledge something, such as a validity extension.
Can the timetable calculate a proposal-validity expiry?
Only after the source proves the duration, anchor event, calendar and counting treatment. Otherwise keep the duration and dependency while returning `time_unresolved`.
Should a bidder assume that a late clarification answer extends the tender deadline?
No. Preserve the current confirmed deadline and monitor for an authoritative change. Route any legal or procedural entitlement question to the responsible reviewer for that procurement.
What closes a submission action?
The evidence defined by the actual channel, commonly a receipt with the submission identity and reception time. An internal “done” status is not enough.
What may an AI agent do with the timetable?
It may extract events, preserve evidence, classify actors and conditions, watch authorized sources and propose the next permitted action. External acts still require the customer's authorization and current-state checks.
When must a timetable row be reviewed again?
After a relevant amendment, clarification, replacement source, invitation, portal notice, lot or bidder-configuration change, new completion evidence or change to the event's trigger.
Sources
Primary references
- TED eForms business terms Publications Office of the European Union
- TED eForms BT-131, Deadline Receipt Tenders Publications Office of the European Union
- Guidance: Time Periods UK Cabinet Office
- Guidance: Competitive Tendering Procedures UK Cabinet Office
- FAR 52.215-1, Instructions to Offerors Acquisition.gov
- World Bank Project Procurement Framework World Bank
- World Bank RFP for consulting services, February 2025 World Bank
- Directive 2014/24/EU, Article 47 EUR-Lex
- VgV section 20, appropriate time limits Federal Ministry of Justice and Federal Office of Justice
- Code de la commande publique, Articles R2151-1 to R2151-11 Légifrance
- European Commission eSubmission quick guide European Commission
- eSubmission Quick Guide for Economic Operators European Commission
About the author
Tony Kim
Tony writes about applied AI, dependable product engineering and the systems that turn complex response work into controlled delivery.
Ziva
Proposal software for source-grounded RFP, RFI, DDQ and questionnaire response work.
Bid, proposal, presales, security and compliance teams. Start with the workflow, constraints and evidence you already have.