Using AI for
tenders and bids

Start with the work

Uploading previous bids and asking for a winning response leaves too much unresolved. Which bid is current? Did the old answer describe an existing capability or a promise for that contract? Has a clarification changed the buyer's requirement? The model may produce plausible wording without resolving any of these questions.

Longer prompts and larger document uploads do not establish that every relevant passage has been read or used correctly. The team needs to control the information available at each stage and check what the system actually retrieved. Anthropic's guidance on context engineering makes the distinction between writing instructions and managing the information a model works with.

All tender text, records, outputs and review results in this guide are fictional teaching examples. The outputs are written illustrations, not a recorded test of any named model. No client documents or performance claims are used.

Set up the tender pack

Before using the tender in an AI tool, the bid owner should confirm permission to use the documents in that environment. A publicly accessible notice does not make every accompanying file unrestricted. Treat pricing, personal information, customer references and confidential attachments according to their actual restrictions.

• Check the buyer's instructions. Read the confidentiality terms, AI conditions and any disclosure questions. Record the answer to those questions accurately. Where a condition is unclear, use the prescribed clarification route before proceeding.
• Confirm the workspace. Have the organisation's responsible owner verify the exact product, plan, retention settings, sharing controls and connected services. A product name alone is insufficient approval.
• Limit access. Give contributors only the documents they are entitled to use. Avoid broad connections to a library containing other clients' bids. Microsoft notes that Copilot follows existing user permissions; excessive permissions still need attention.
• Assign responsibility. Name the bid owner, evidence owners, delivery approver and commercial signatory. Agree who checks privacy or contractual questions where needed.

Keep a short record of the approved use: what information may be processed, by which tool, for what purpose, and who checks the output. Decide how long working files and logs will be kept, following your organisation's policy and the procurement requirements.

Treat text inside retrieved documents as evidence to read, not authority to operate the system. A document might contain instructions to ignore controls, reveal another file or contact an external address. Keep those instructions from triggering actions. Where automation is used, restrict its tools and require explicit human approval for external messages, file sharing and submission.

Download and register the full set of documents, including schedules, amendments and clarification responses. Preserve the originals. Give every file a reference and version date, and record what it supersedes. Establish the buyer's stated order of precedence; do not ask the model to invent one when documents conflict.

Decide whether to bid

Before allocating the writing team, ask whether this is a bid the business should pursue. Give AI the current tender pack, approved experience records, capacity plan and cost assumptions. Ask for a reasoned assessment with source references and unresolved questions. The commercial owner makes the decision.

PQQ: check the evidence behind eligibility

A pre-qualification questionnaire can fail before anyone reads the quality response. In this fictional PQQ, the buyer requires €2 million professional indemnity cover at submission. PQ1 expired on 30 September 2026; PQ2 shows €2 million with expiry on 30 September 2027.

Completed review entry: replace PQ1 with PQ2; insurance owner to confirm the insured entity, activity and conditions against the exact requirement. PQ3 lists E1 and E4 as the two experience references. Status: evidence located, verification pending. These are example buyer conditions, not universal insurance or procurement rules.

Build the requirements register

Build a requirements register before drafting. For each requirement, record its exact wording and source location, whether it is mandatory or scored, the limit or required format, the person responsible and the evidence needed. Include submission instructions and attachments as well as narrative questions.

Human checkpoint: open each cited passage. Check tables, footnotes and scanned pages visually, especially symbols, dates and numbers. A citation is a place to investigate, not proof that the extraction is correct. The bid owner signs off the register before it becomes the drafting brief.

Find the right evidence

Context management means deciding what the system needs for this particular task, whether that information is current and how the reader can trace it. Keep the master evidence library separate from the smaller bundle used to answer a question.

For Q4.2, that bundle contains the current requirement and clarification, the relevant scoring description, approved delivery arrangements and a comparable performance record. It also contains an explicit list of gaps. An old bid may help with structure, but its claims need reapproval before reuse.

Make retrieval inspectable

If the tool searches a document library, ask it to show the passages and source versions it selected before drafting. Check whether a table was split from its heading or a qualifying sentence was omitted. When it retrieves the wrong material, correct the selection or metadata. Rewriting the prompt alone may not address the cause.

Maintain a brief handover note when starting a fresh session: current requirement versions, approved decisions, unresolved issues and links to evidence. Keep that note checked against the originals. A summary can lose a qualification just as a draft can.

Compare the tender documents

Cross-document comparison can reveal work that is missing from a quotation, a response based on an old specification or a programme that assumes a decision too early. Give the system a bounded comparison task and ask for both sides of each potential mismatch, with document versions and locations.

Construction: what changed, and what could it cost us?

A contractor preparing a fictional office refurbishment tender receives revised documents while subcontractor prices are arriving. The estimator needs to know which changes could affect scope, allowances or the programme. Comparing the current specification with a quotation alone would miss dependencies elsewhere in the pack.

The team registers the documents below and checks revision status before asking AI to identify potential mismatches. These short excerpts are fictional teaching material. Actual drawings need visual review: a text extraction can miss a symbol, note or revision cloud.

Discrepancy register after review

AI prepares candidate entries. The statuses below show what the fictional team records after checking the originals. They are illustrative review outcomes, not results from a tested model.

1. C-D01 · Powered operators excluded. CS1 §6.3 and CC1 answer 2 require operators; CQ1 excludes them. Commercial implication: obtain a revised quotation covering the operators and clarify responsibility for interfaces and electrical work. Owner: package estimator, with electrical estimator. Status: scope mismatch confirmed; cost impact open. No allowance is approved until the revised scope and price are checked.
2. C-D02 · Current BOQ describes manual doors. CB1 item 6.10 differs from CS1 §6.3; CC1 says pricing instructions will follow. Commercial implication: the team needs the buyer's permitted pricing treatment before completing the schedule. Owner: tender QS. Status: document discrepancy confirmed; clarification pending. Retain both versions and record the response through the tender's clarification process.
3. C-D03 · Lead time and access assumptions need checking. CQ1 allows six weeks after approval; CP1 schedules approval at week 3 and installation from week 7. CC1 answer 5 restricts working access. Commercial implication: investigate delivery feasibility, weekend labour and possible programme changes. Owner: planner and estimator. Status: candidate programme risk, awaiting subcontractor confirmation and checked calendar dates. AI has not established a delay or priced acceleration.
4. C-D04 · Apparent two-door omission. AI flags twelve quoted sets against fourteen door references in CD1. Commercial implication: check whether any replacement scope is missing. Owner: QS. Status: resolved after human review. CD1 note 8 and CB1 item 6.11 show that D13 and D14 are retained, with signage only. The reviewer closes the replacement-door concern and leaves the signage item for normal pricing verification.

The useful output is a short, referenced queue for the estimating team. The QS still verifies quantities, units and pricing scope; the estimator checks rates and exclusions; the planner checks dates and dependencies. Any resulting amendment must also reach the technical response, pricing schedule and assumptions register. Close an entry only when the responsible person records the evidence and decision.

Assign the work and tools

Routing means assigning each task to a suitable tool or person. The bid manager can do this manually.

• Read a scanUse document extraction or OCR, then compare important passages with the rendered original. Escalate unclear text to a person.
• Find evidenceSearch the approved library and inspect the retrieved passages. Restrict retrieval to the relevant permissions and current versions.
• Develop an answerUse an approved language model with the question-specific evidence bundle. Keep missing evidence visible.
• Check numbersUse a spreadsheet or tested calculation. Ask a reviewer to verify inputs, units and assumptions. Do not rely on generated arithmetic.
• Challenge a draftRun a separate review against the original question and evidence, followed by a subject expert. A second model can repeat the same error.
• Approve a promiseRoute service levels, staffing and pricing to the responsible human approver. Keep submission under an authorised person's control.

Choosing between ChatGPT, Copilot and Claude

Choose the approved environment first, then test the actual task. Compare how reliably the available configuration extracts requirements, finds evidence and follows the required format. Include reviewer effort in that comparison. A model that drafts quickly may create more checking work.

For work already in Microsoft 365, verify the relevant permissions and what the selected Copilot experience can access. For a ChatGPT or Claude workspace using uploaded sources, verify the files available to that task and inspect the references returned. Connected tools and account features vary; check the deployed setup rather than assuming a brand name guarantees access or protection.

Define a fallback: if the source is missing, extraction fails or two records conflict, stop that task and route it to the evidence owner. Quietly switching to an unapproved account or supplying a plausible answer would defeat the control.

Draft and resolve the gaps

Prepare an answer plan before full prose. Map each part of the question to the proposed response and its evidence. Mark a statement as an established fact, a proposed commitment needing approval, or an unresolved gap. This helps reviewers see where their decision is needed.

This draft exposes an unresolved decision. A claim about what the supplier will do needs approval; a claim about what it has done needs evidence.

If delivery approval is refused, change the proposed solution or reconsider the bid. Do not prompt the model to write around the refusal.

Test your bid workflow

Tuning begins with the instructions, evidence selection and review process. Define the output you need, provide approved examples, test difficult cases and examine the failures. This can be done without changing the underlying model.

Create a small set of representative questions with human-reviewed expected findings. Include a superseded service level, missing evidence, an attractive but irrelevant case study and a scanned table. Keep some cases aside so that you can test a revised setup on material it was not tuned against.

• Requirement coverage: how many required elements did the system extract, and which did it miss? Report mandatory omissions separately.
• Claim support: can the reviewer locate evidence that actually supports each factual assertion? A valid file link alone does not count.
• Approval discipline: did the workflow keep unresolved commitments open, or silently turn them into promises?
• Total effort: measure preparation, drafting, checking and rework against a comparable manual task.

In the worked example, use four concrete checks: it must apply C1's target, preserve business hours, distinguish acknowledgement from resolution, and leave G1 open until A1 is supplied. Run the same tests after a model, prompt or retrieval change. Repeat representative tests to see whether results are consistent.

Where fine-tuning fits

Model fine-tuning changes model behaviour through training. It may merit investigation for a stable, repeated task with enough authorised examples and a clear evaluation set. It is not the default way to supply changing tender documents or current company facts. Confirm availability, data rights, costs and evaluation requirements with the chosen platform before commissioning it.

Review the complete response

Review the answer against the buyer's actual criteria. Check whether each part is answered directly, supported appropriately and specific enough to assess. Separate mandatory compliance from the quality of a scored answer. An elegant narrative cannot cure a missing mandatory attachment.

Use the findings as a work list for the reviewer. Models can invent objections as well as invent support. Check each proposed correction against the tender and evidence before accepting it. A review in a fresh session can reduce carry-over from drafting, but it is still not independent assurance.

Read across the whole bid after reviewing individual answers. Check that the service hours, staffing assumptions and delivery dates agree with the pricing schedule and contract departures. Assign a person to resolve differences; do not let a model silently choose whichever wording appears most often.

Approve and submit

The bid owner needs a controlled final version and a completed approval record. Freeze the evidence references used for the submission, resolve every open issue and check that approved edits survived assembly into the final document or portal fields.

Independent review checklist

Give a reviewer who did not draft the answers the current tender pack, complete response and approval records. Ask them to record Pass, Hold or Not applicable for each check, with the source, owner and resolution. In the example, pricing approval is a Hold because G2 is still open.

• Every mandatory requirement and attachment is accounted for against the current tender documents.
• Factual claims, case studies and certifications have current evidence and permission for use.
• Delivery commitments, pricing and contractual positions have the required human approval.
• Any required AI-use declaration accurately describes what the team did.
• Word limits, file formats, filenames and portal instructions have been checked in the final output.
• Internal source notes, draft warnings and editing comments have been handled deliberately; no unresolved placeholder remains.
• An authorised person submits before the deadline and retains the portal receipt or other required confirmation.

Keep the submitted version and its supporting approvals according to the applicable retention policy. After the outcome, compare feedback with the original response. Winning or losing a bid has many causes; do not attribute the result to AI without evidence.

Build a repeatable bid process

Start with one completed, authorised tender or a fictional example. Choose a question where an experienced reviewer can establish the correct requirements and evidence. Agree the permitted tool and success criteria before beginning.

Run the full sequence through to review, including an intentionally missing document or conflicting figure. Record whether the process notices the problem and routes it to the right person. A system that performs well only when the source material is perfect has not been tested against normal bid work.

How the work can develop

• Assisted preparationStaff use an approved workspace to analyse a defined pack, locate evidence and prepare drafts. The bid manager maintains the registers and checks each output.
• Repeatable workflowsThe team reuses a checked evidence library, standard registers and review stages. Track the time spent assembling packs and correcting answers, alongside omissions and approval failures.
• Integrated operationsWhere volume justifies the cost, automation can collect permitted documents, detect a new clarification, prepare an impact list and route issues to owners. Approved changes can then feed assembled review documents.

An agent can perform several permitted steps across connected systems. For example, it might notice C1, find responses that still say 60 minutes, create review tasks for their owners and prepare proposed amendments. The team should first prove that the same sequence works manually. Anthropic's workflow guidance distinguishes predefined workflows from agents that choose their next steps.

Give each automated step a limited document scope and allowed actions. Keep an audit trail, prevent duplicate updates, and stop when a source is missing or versions conflict. Human approval must still control evidence release, commercial changes and submission. Test those stops as carefully as the successful path.

Before adding integration, compare its setup and maintenance cost with the recurring work it removes. Measure reviewer effort too. A small team with occasional bids may get enough benefit from a well-maintained workbook and approved AI workspace.

Related reading: AI governance, workflow consulting and the recorded fictional document-analysis test on AIatWork. That test illustrates source-checking problems; it is not a tender-writing benchmark.