A tender submission lives or dies on the quality of its information.
You can have the best design, the best visuals, the best presentation. But if the BIM information is weak, the tender is pushed aside.
Here's the part most practices miss. 'Tender-ready' is not a feeling. It's defined. ISO-19650-2, clause 5.3 lists exactly what a delivery team must produce in response to an invitation to tender. Reviewers on ISO-19650 projects score you against that list.
This manual covers:
- What ISO-19650 requires at tender, clause by clause.
- Why tenders fail technical evaluation.
- The documentation checklist.
- The model standards that pass review.
- The QA layers that protect you.
- The full deliverables package.
It's matter-of-fact on purpose. You should be able to hand it to your team the week a tender lands.
Start with the standard, because everything else hangs off it.
ISO-19650-2 splits the tender stage into two halves:
The seven tender-response activities:
That is the definition. A tender-ready BIM submission is one that answers the EIR with all seven items, backed by a model that proves you can deliver them.
If your submission is missing any one of these, a trained reviewer will notice and then reject your tender.
Most tender submissions fail for these reasons.
1. No response to the EIR
The EIR is the exam question. Teams answer a different question. The one they want to answer. Instant fail.
2. Poor BIM documentation
Missing, inconsistent, or outdated information kills trust. A generic BEP recycled from the last job won't cut it. The reviewer will notice and you'll get sprung. Be specific regarding the current job.
3. A model that doesn't reflect the drawings
Reviewers open the model... Nothing matches the PDF set. This one's common, I see it all the time. Rejection.
4. Missing data fields
A model with no attributes is just geometry. Useless for procurement, useless for cost, useless for carbon.
5. Wrong level of information need
Too little looks incapable. Too much looks like you can't read a brief. Reviewers know over-modelled tender geometry hides thin data.
6. No coordination evidence
Tenders must prove the design works, not just look nice. A clash report, a federation check. Proof the disciplines communicate. Pretty renders with no coordination behind them read as risk.
7. No QA trail
If you can't prove the model was checked, it's assume it wasn't. Record the discipline review and the BIM manager audit. Bundle the reports as evidence.
Tender reviewers are trained to distrust sloppy BIM. Your job is to make the submission bulletproof.
Your tender BIM package needs more than a model. It needs clear, auditable documentation mapped to what the standard asks for.
1. Pre-appointment BEP
The centrepiece. Shorter than a full BEP, but specific:
One rule: every section must respond to 'this' project's EIR. Templates work well, but ensure every item is specific to the current project.
2. Capability and capacity summary
Who owns what, and proof they can deliver it:
3. Mobilisation plan
How you go from appointment to production:
4. Delivery team risk register
Information delivery risks. Not generic project risks:
Each risk with an owner and a mitigation.
5. Naming conventions and standards reference
State the standards you'll follow: ISO-19650 container naming, Uniclass 2015 classification, your object naming register. If naming is inconsistent at tender, reviewers assume the project will be chaotic.
6. CDE workflow overview
Who uploads. Who checks. Who approves. Which status codes. Work-in-progress → shared → published → archived, with the suitability codes you'll apply.
7. Data drop / submission schedule
Your proposed information delivery milestones. The seed of the future Master Information Delivery Plan (MIDP). This is how reviewers compare you to competitors.
A tender without documentation is a red flag. Documentation shows maturity.
A tender-ready model must meet the technical bar. Anything less is amateur.
1. Correct level of information need
The language changed. LOD/LOI has been superseded by 'level of information need' — BS EN 17412-1, now carried forward as ISO 7817-1:2024. It defines information in three parts:
For a tender: enough geometry to prove the design resolves, enough data to populate the schedules the EIR asks for, and nothing more. Model what the decision needs.
2. Correct coordinate setup
Get this wrong and federation fails on day one. Reviewers check it first. Be careful of this one, people always get this wrong, it'll derail your project.
3. Consistent naming — files and content
4. Classification applied
Uniclass 2015 — or whatever the EIR specifies — on every scheduled element. Classification is what lets the reviewer's software join your model to cost and specification. A model without it has no data.
5. No redundant links or imports
Reviewers check for:
Check and purge before you publish.
6. Clean view templates
Consistent graphics = competence. It's shallow. It's also true.
7. Proper workset strategy
Reviewers open the model and look at workset logic, ownership and visibility control within minutes. If it's messy, it's over.
Tender QA isn't optional. A tender-ready model goes through three layers of checking:
Level 1: Self-check (author)
Level 2: Discipline review
Level 3: BIM manager audit
The QA reports go in the tender package as evidence. A check you can't prove is a check that didn't happen.
Reviewers have a checklist. Hit every item.
Deliverable | What it proves | |
|---|---|---|
1 | Native model (RVT/PLN) | Clean, coordinated, stage-appropriate authoring |
2 | IFC export | Open-standard competence, mapped attributes |
3 | Selected sheets (PDF) | Drawings match the model — reviewers check |
4 | Model schedules | The data is real, not promised |
5 | Pre-appointment BEP | You understood the EIR |
6 | Capability + capacity summary | The team can deliver |
7 | Mobilisation plan | You can start without a stumble |
8 | Risk register | You've thought about what breaks |
9 | Clash/coordination evidence | The design works |
10 | QA reports | The model was checked, and there's proof |
Ten items. Every one maps back to ISO-19650-2, clause 5.3, or to the model that supports it.
A 14-person architecture practice came to us 16 days before a framework tender deadline. Healthcare client, ISO-19650 mandated, EIR running to 40 pages.
What we found in the audit:
What changed in two weeks:
Result: shortlisted, and the client's feedback singled out the information management response. The practice scored second on design. They scored first on BIM.
The design didn't change. The information did.
What does 'tender-ready' mean under ISO-19650?
A submission containing the seven tender-response activities of ISO-19650-2 clause 5.3: nominated information managers, a pre-appointment BEP, task team and delivery team capability assessments, a mobilisation plan, a risk register, and the compiled response — supported by a model that meets the EIR.
What is a pre-appointment BEP?
The tender-stage version of the BIM Execution Plan. It sets out your proposed approach to meeting the client's Exchange Information Requirements. It becomes the full delivery BEP after appointment.
Do I still use LOIN at tender?
The current standard is 'level of information need' [LOIN] (BS EN 17412-1, carried into ISO 7817-1:2024). It specifies geometry, alphanumerical information and documentation separately. If the EIR uses LOD language, answer in kind. But know the current framework.
What model deliverables does a BIM tender need?
Native model, IFC export, matching PDF sheets, populated schedules, coordination evidence and QA reports. The documentation package sits alongside: BEP, capability summary, mobilisation plan, risk register.
Why do BIM tenders fail?
The top causes: not answering the EIR, recycled documentation, models that don't match drawings, empty data fields, no coordination evidence and no QA trail.
Before you submit, let Bimcopilot audit your model and documentation against ISO-19650.
You'll get:
Avoid rejection. Submit a tender that gets taken seriously.
→ Talk to BIMcopilot before your next deadline — https://www.bimcopilot.com
Tender-ready is explicit.
ISO-19650-2 clause 5.3 lists what the response must contain. The EIR lists what the information must be. Between them, there is no mystery left in what a reviewer wants. Only the discipline of producing it.
The teams that win tenders aren't modelling more. They're answering the question that was asked: named people, a specific BEP, a tested exchange, a model whose data matches its drawings, and proof it was all checked.
Reviewers are trained to distrust sloppy BIM. Give them nothing to distrust.
That's it.
