TenderAI journey guide
Follow a bid from Triage to Won (example team)
This guide walks the full TenderAI path using one illustrative story, not a customer case study. Harrow & Vale Building Services is a fictional regional contractor with a small sales team that writes formal tenders alongside the day job and has no bid department. The story is told mainly through Femi, the bid manager, who decides what to pursue and who writes it. You’ll see what each hub is for, why it exists, and how this example team would use it.
In this example, Harrow & Vale bids for contracts with local authorities, NHS trusts and housing associations. Before TenderAI, writing a response meant someone on the sales team blocking out an evening, starting from nothing, and hoping they remembered every certification the business holds. Femi had no clear view of which bids were in progress, who owned them, or whether they were worth the effort. TenderAI is where that response gets written, checked and submitted. If the team also uses BidRadar, qualified tenders arrive in Triage automatically. If not, Femi adds them herself.
→ The big metaphor: a workspace, not a document
A word processor tells you nothing about whether your answer is complete, compliant, or even true to your certifications. TenderAI gives every bid a real position — Triage, Drafting, Internal Review, Ready to Submit, Submitted, Won or Lost — and the position always tells you what to do next, with a workspace built for the job at each stage.
Dashboard
Where the bid manager sees what’s due, what’s stuck and what’s worth pursuing.
Pipeline
Where every bid’s status lives. Seven stages, visible to the whole team.
Bid Foundry
Where a single bid is written, opened from Opportunities. Requirements on the left, the draft in the middle, sources and comments on the right.
Knowledge Base
Where every draft is grounded: policies, past bids, certifications and CVs. It’s held in the UK and used only for your own bids.
Sign in, then read the workspace as four hubs
Every screen in TenderAI sits inside the same shell, and the navigation has four hubs. The Dashboard shows what needs you next. The Pipeline shows every bid’s status. The Knowledge Base holds your reference library. Opportunities opens a single bid in the Bid Foundry, where the response is written. A bid is never re-typed as it moves between them.
The Dashboard is the first thing you see after sign-in — a multitasker's view of what's due soon and what still needs a decision, not a wall of every bid ever opened.
Before trusting an AI draft on any bid, confirm the certifications, CVs and past bids you'll actually need are already uploaded — an empty Knowledge Base drafts nothing meaningfully.
The Pipeline shows where a bid is, and the Bid Foundry is where it gets written. Dashboard is neither — it's the summary both feed into. Knowledge Base is the one hub that isn't about a single bid at all — it's the shared material every bid draws from, so a busy Tuesday drafting session never has to hunt for a certification that already exists somewhere else.
A bid lands in Triage
New opportunities start in the Triage column. You can add one yourself, or connect BidRadar so that qualified tenders post straight in with the buyer, value and closing date already filled in. Either way, the first question in Triage is who owns the bid, not whether it exists.
Femi checks Triage first thing on Monday. In this example the team uses BidRadar, so whatever was qualified on Friday is already waiting, with no details to chase separately.
1 Triage, then assign
If a bid came from BidRadar, it has already passed a relevance check. If it was added by hand, this is where you give it a quick first look. Either way, decide who owns it.
With a small team doing this alongside sales work, assigning early means the deadline belongs to somebody from day one, not a surprise in the week it’s due.
Once assigned, a bid moves through all seven pipeline stages — see Seven stages.
Seven stages, from Triage to Won or Lost
Every bid moves Triage → Drafting → Internal Review → Ready to Submit → Submitted, and finally Won or Lost. It's visible as a drag-and-drop Kanban board or a sortable list — whichever view a role actually prefers to work from.
- Stage is whatever the last person typed in a cell
- No visibility into who owns what without asking
- A stalled bid looks identical to a healthy one
- Every bid has one real stage, always current
- Owner, deadline and progress visible at a glance
- Drag a card and the status is the drag — no separate step
Priti checks the list view sorted by deadline every morning; the team looks at the Kanban board together on Mondays to see the whole week's shape at once.
Requirements, drafting, and context — side by side
Opening a bid moves you from ledger to workspace: requirement navigation down the left, a rich-text editor for the current question in the middle, and a context panel on the right for sources, comments, suggestions and revision history.
Jumping between requirements and email attachments is how a section gets answered twice and another gets missed entirely. Keeping the question list, the answer, and its sources in one screen means nothing about the bid lives anywhere else while you write it.
A grounded first answer, streamed live
Each requirement generates its own AI draft, streamed in as it's written, grounded in the Knowledge Base rather than a generic model guessing at your certifications. You review, edit, accept, or reject before anything counts as the real answer.
Nadia works question by question — generates a draft, checks it against what she knows the business actually does, and edits the parts that need a human’s judgement. In this example, it’s usually a tightening pass rather than a rewrite.
1 Generate, then judge, not just accept
Question-level generation means the methodology answer draws on your process documentation while the pricing answer draws on your commercial policy — not one answer blending both.
Nothing generated becomes the answer of record until someone reviews it — the workflow assumes editing is normal, not a sign the AI got it wrong.
Caught before the buyer catches it
Compliance checks flag issues at three levels — critical, warning and suggestion — covering missing mandatory clauses, word or character limit breaches, and gaps against the evaluation weighting. They run before submission, not after rejection.
Priti runs the compliance check before every submission. A missing insurance clause caught here takes minutes to fix. If the buyer catches the same gap, it can cost you the bid. A bid with an unresolved critical flag can’t move to Ready to Submit.
Multi-user editing, without the version drift
Inline comments and accept/reject text suggestions let more than one person work a bid without emailing tracked-changes documents back and forth. Every answer's revision history tracks its source — human-written, AI-generated, restored, or imported.
Priti leaves comments on Nadia's drafts rather than rewriting them directly — a suggestion Nadia can accept or reject keeps the authorship clear, and the revision history means nobody has to remember which version was "the good one."
A rejected suggestion simply disappears; an accepted one becomes part of the answer, tracked in revision history with its source marked as a suggestion, not silently absorbed.
The one library every draft actually reads from
Six categories hold everything a draft might need to cite: Policies, Past Bids, Certifications, CVs, Project Documentation and SRS. This is what makes a generated answer specific to your organisation instead of generically plausible.
Your Knowledge Base is held in the UK. The documents you upload are used only to draft your own organisation’s bids, never to train shared models.
The Knowledge Base doesn't just seed drafts — it's also where outcome learning writes back to. See Won, Lost & outcome learning.
In this example, Priti uploads the team’s certifications, key CVs and a few of their strongest past bids before the first draft — and that material is what later drafts are grounded in.
A pursue or decline call, before you commit a team
The Dashboard is the bid manager’s view. It shows deadlines and stage counts at a glance, plus win analysis with probability scoring and a pursue or decline recommendation, so you can decide before a small team spends its limited hours on a bid.
With only a few people writing bids, a low pursue score is often the difference between chasing a long shot and giving a stronger opportunity the full attention it needs.
A closed bid teaches the next one something
Once a bid closes Won or Lost, the reasons get captured and feed straight back into the Knowledge Base — a win becomes a stronger past-bid example, a loss becomes a lesson the next draft can avoid repeating.
Say a bid comes back Won and the evaluator’s feedback praises the case study section. Priti records that as the reason. If a later bid is Lost on price, that reason goes in too. Both notes then sit in the Knowledge Base, where later drafts can draw on them.
A Won with no reason recorded teaches the system nothing it can reuse. The habit of writing one sentence on why is what makes outcome learning useful over time, not just a scoreboard.
Harrow & Vale, end to end (illustrative)
Every stage of the journey, in the order a bid moves through it, for this example team.
- 1Review Triage — bids from BidRadar arrive qualified, and bids added by hand get a first look here.
- 2Check the Dashboard’s pursue or decline score, then assign the bid to whoever has capacity this week.
- 3Generate a draft per question in the Bid Foundry, grounded in the Knowledge Base.
- 4Review, edit, accept or reject — a human signs off every answer.
- 5Comment and suggest rather than overwrite when a second person weighs in.
- 6Run compliance checks before moving to Ready to Submit.
- 7Submit, then wait — the pipeline card carries the status for the whole team.
- 8Log the outcome, Won or Lost, with the reason — not just the result.
- 9Keep the Knowledge Base current so every future draft starts stronger.
Frequently asked
Do opportunities have to come from BidRadar?
No. TenderAI works on its own, and you can add opportunities to the pipeline yourself. BidRadar is the recommended pairing, because it posts qualified tenders straight into Triage with the details already filled in.
What's the difference between the seven pipeline stages?
Triage (just arrived), Drafting (being written), Internal Review (being checked), Ready to Submit (compliance-clean), Submitted (with the buyer), and finally Won or Lost — the same bid, one stage at a time.
Does the AI ever submit an answer without review?
No. Every AI-drafted answer requires a human to review, edit, accept or reject it before it counts as the answer of record — trust but verify is a core product principle, not an option.
What happens if a compliance check finds a critical issue?
The bid can't move to Ready to Submit with an unresolved critical flag — it stays in Internal Review until the issue is fixed, so a missing mandatory clause can't slip through by accident.
Where does the AI draft's grounding actually come from?
Your company Knowledge Base — Policies, Past Bids, Certifications, CVs, Project Documentation and SRS. The engine cites and draws from what you've uploaded, not general knowledge about your industry.
What happens after a bid is marked Won or Lost?
You record the outcome and the reason. That reason feeds back into the Knowledge Base, so future drafts can draw on what actually worked and what didn’t.
Is Harrow & Vale a real customer?
No. Harrow & Vale Building Services, and Femi, Nadia and Priti, are an illustrative example used in this guide and on the TenderAI and BidRadar sites.
Where is our data held?
In the UK. Your Knowledge Base, drafts and bid records are held in the UK.
Is our content used to train AI models?
No. The documents you upload are used only to draft your own organisation’s bids, never to train shared models.
How much does TenderAI cost?
Pricing depends on your team and how you’ll use it. Request a demo and we’ll walk you through the product and share pricing.
Do we need a demo to start?
No. You can sign up and start by uploading your Knowledge Base. If you’d rather see it first, request a demo with the Quantum Foundry team.