Three weeks of questions
The tender went out on Monday. By Wednesday, queries start arriving. One contractor asks about the drainage specification. Another asks the same question in different words. A third finds a discrepancy between the architect's door schedule and the bill. A fourth asks whether the site can be accessed on Saturdays.
Each query needs an answer from someone: the architect, the M&E engineer, the client, or you. Each answer then needs sending to every tenderer, not just the one who asked, so they are all pricing the same thing. Meanwhile the tender return date does not move unless someone decides it should.
Why tender queries get out of hand
- Queries arrive to different people's inboxes, not always the tender address.
- The same question is asked by several contractors in different words.
- Design team members answer by email, sometimes replying only to the contractor who asked.
- Nobody tracks which queries are waiting on which consultant.
- Answers that change the tender documents are not clearly marked as addenda.
What a messy query process costs
Tenderers price on different information, which makes the comparison unreliable. A query answered to only one contractor can raise questions about fairness in the process. Late answers push the tender period. And after contract award, nobody can easily find the answer that explains why an item was priced a certain way.
| Step | What goes wrong | What the log does |
|---|---|---|
| Query received | Lands in a personal inbox | Captured from the tender mailbox and forwarded mail |
| Duplicates | Answered twice, differently | Similar queries grouped for one answer |
| Routing | Nobody sure who should answer | Assigned to a named consultant with a due date |
| Chasing | Done by memory | Reminders sent automatically |
| Issuing | Sent to one tenderer | Issued to all tenderers together |
How we build the log
- A tender mailbox, or a simple web form, receives every query, and staff forward any that arrive elsewhere.
- Each query is logged with its tenderer, date and the documents it refers to. A language model suggests which discipline it concerns and flags likely duplicates.
- The QS confirms the grouping and assigns it to a design team member, who gets a link to answer without needing an account.
- Reminders go to anyone holding an open query as the return date approaches.
- Answers are reviewed by the QS, marked as clarifications or as changes to the tender documents, and issued to every tenderer together as a numbered bulletin.
- The full log, with queries anonymised as your process requires, is kept with the tender and carries into the contract documents.
Whether an answer changes the tender, and whether the return date should move, are decisions for your team and the client. The log records those decisions and makes sure they are communicated consistently.
A tender period with fewer loose ends
The QS sees every open query and who holds it. Design team members get one clear request instead of forwarded chains. Every tenderer receives the same answers at the same time. After award, the answer to 'why was this priced like that' is in the log.
Tender reports benefit too. When you write up the tender for the client, the log shows which queries each contractor raised, which suggests how carefully they read the documents, and which answers changed the scope. That context sits alongside the price comparison rather than being remembered.
The log is also useful before the next tender, because it shows which parts of your documents generated the most questions.
Is this how your tenders run?
- Tender queries arrive in several people's inboxes.
- The same question has been answered differently to two contractors.
- You chase design team members for answers by email.
- Queries answered by one consultant have not reached every tenderer.
- Finding a tender answer after award takes a search.