How to Handle RFIs During a BMS Tender (And Why Sloppy Logging Costs You Later)

An RFI (Request for Information) during a BMS tender is a formal query raised when tender documents are ambiguous, incomplete, or contradictory — most often around missing points schedules, unclear interface responsibility between trades, or conflicting specification clauses. Every RFI should be logged on a numbered register and tracked against the tender return date, consistent with good-practice tendering procedure such as JCT's Tendering Practice Note 2017. Unanswered RFIs must be carried into the return as a stated assumption or qualification, never priced silently.

We've had estimators eat five-figure sums because nobody wrote a query down. On a recent commercial fit-out tender, the mechanical services spec said "BMS to provide fan coil control" and the electrical spec said "electrical contractor to provide FCU isolation and control wiring" — with no drawing showing where one scope stopped and the other started. Two contractors priced it as "BMS does everything." One raised an RFI. The one who didn't ask ended up either absorbing the extra points and programming days after award, or fighting a variation claim through a contract administrator who wasn't in the room when the assumption was made. Neither is a good place to be six weeks into a project.

That's what a Request for Information exists to prevent — and on BMS tenders specifically, where interface boundaries between mechanical, electrical, fire, and access control are exactly where the money and the disputes both hide, it's one of the most under-used tools on the desk.

What Is an RFI in a BMS Tender?

An RFI is a formal, written query raised by a tenderer during the tender period, asking the client, consultant, or main contractor to clarify something in the tender documents before the return is priced and submitted. It is not a technical query raised during construction (though the same discipline applies there) — it's specifically pre-contract, pre-price. On a BMS package, RFIs typically cover four things: missing or incomplete points schedules, unclear responsibility for interface work (who wires, who programmes, who commissions a given piece of plant), conflicting information between drawings and the written specification, and provisional or undefined sums that need scoping before they can be priced with any confidence.

The distinction matters commercially. A query answered before submission gets priced into the return, in daylight, with everyone competing on the same information. A query raised after award becomes a variation — negotiated one-to-one, usually from a weaker position, and often disputed months after the assumption was actually made.

What Deserves an RFI — and What Should Stay a Qualification?

Not every gap in a spec needs a formal query, and over-RFI-ing a tender slows everyone down and irritates the consultant as much as under-RFI-ing it leaves you pricing a guess. The working rule of thumb: raise an RFI when the answer would change the price or the technical solution; state a qualification when it's a reasonable, statable assumption that wouldn't change either materially. Applied to the items that come up most often on a controls package:

• Testing and commissioning scope — if the spec is genuinely silent on who provides witness attendance at commissioning, that's an RFI, because it changes whose engineering days are in the number. If it's a minor point that doesn't move the price, a stated assumption is enough.
• Software licences — who owns the BMS front-end or graphics licence, who pays for it, and whether it's perpetual or subscription is usually worth an RFI rather than a guess, because getting that wrong is a real recurring cost, not a one-off.
• Graphics scope — how many screens, and what level of bespoke detail versus template, is more often a fair qualification than an RFI, unless the spec is completely silent on it.
• Integration responsibility — which trade wires, programmes and commissions a given interface, the same question that sits behind the FCU-3 scope-boundary scenario used throughout this article, is almost always worth an RFI, because getting the boundary wrong is exactly where variations come from.
• Third-party attendance at witness testing — who needs to be there, and whether the tender price even covers the coordination time to get them there, is worth clarifying formally if the spec doesn't set it out, since it affects both programme and price.
• The witnessing process itself — how tests are witnessed, signed off and recorded is worth the same formal clarification where the spec leaves it open.
• Training days — usually reasonable to qualify with a stated assumption ("priced on the basis of one day's operator training for up to four staff" is defensible), but it should become an RFI the moment the number of days or staff materially changes what's being priced.
• O&M manual format and quantity — normally a fair qualification too, unless the spec demands a format or volume that carries real cost.

How Do You Log and Track RFIs During a BMS Tender?

Every RFI should be logged on a numbered register from the moment it's raised: a unique reference number, the date raised, the specific drawing or spec clause it relates to, the question itself (specific enough that a "yes/no" or a number answers it), who it was sent to, the date a response is needed by, and the date and content of the response when it lands. Vague questions get vague answers — "please confirm BMS scope for the second-floor fan coil units" gets you nothing useful back. "Please confirm whether local isolation and control wiring for FCU-3 falls within Section 3 (BMS) or Section 5 (Electrical) of the specification, as drawing M-204 shows conduit routed from the electrical distribution board with no BMS panel reference" gets you an answer you can actually price against.

The deadline discipline matters as much as the question quality. Work backwards from the tender return date, not forwards from when the query occurred to you. If pricing review and document assembly need three working days before submission, and the controls schedule needs to be locked before that, then RFIs raised inside that window are already too late to change the price safely — they can only change what gets qualified in the return. Good tendering practice — consistent with the approach set out in JCT's Tendering Practice Note 2017 — is to consolidate queries into a single schedule and circulate answers to everyone bidding, so no single contractor gets an informational advantage and the client isn't fielding the same question five times in five different formats.

What a BMS Tender RFI Actually Looks Like

A properly written RFI reads like a short, formal document, not an email aside. Here's a worked example based on the fan coil scope boundary referenced earlier:

RFI Reference: RFI-014
Project: [Project name / reference]
Date Raised: [Date]
Raised By: Alpha Controls (BMS subcontractor)
Drawing/Clause Reference: Drawing M-204; Specification Section 3 (BMS) and Section 5 (Electrical)
Question: Drawing M-204 shows conduit routed to FCU-3 from the electrical distribution board, with no BMS panel reference shown. Specification Section 3 states "BMS to provide fan coil control"; Section 5 states "electrical contractor to provide FCU isolation and control wiring." Please confirm whether local isolation and control wiring for FCU-3 falls within the BMS scope (Section 3) or the electrical contractor's scope (Section 5).
Why This Matters: The answer affects the points count, the interface wiring allowance, and the commissioning sequence priced into this return. A wrong assumption here changes the price by a material amount.
Response Required By: [Date — set against the tender return date, allowing time to reprice if needed]

Once raised, that RFI gets logged. A register entry for it might look like this:

If the response never lands before submission, the register's "Status" column is what proves, months later, that the point was raised in writing and not guessed at.

What Happens If an RFI Goes Unanswered Before Submission?

It happens constantly — a consultant is slow, a client is unreachable, the tender period simply isn't long enough for the query to loop back before the deadline. The rule here is simple and non-negotiable: an unanswered RFI is never priced silently. It gets carried into the return as a stated assumption, qualification, or exclusion, in writing, on the face of the tender. "Priced on the assumption that BMS scope excludes FCU-3 isolation and control wiring, per drawing M-204, pending response to RFI-014" is a defensible position. Pricing it either way and saying nothing is not — it's the single most common way BMS subcontractors end up either underpriced and absorbing cost, or accused of gold-plating a return that a competitor priced leaner by guessing the other way.

This is also where RICS' New Rules of Measurement (NRM2, 2nd edition, October 2021, effective from 1 December 2021) is directly relevant: it requires provisional sums in tender documents to be identified as either defined or undefined, and each label carries its own deemed allowance. Where a provisional sum is given as defined, the contractor is assumed to have made due allowance in their programming, planning and pricing of preliminaries for that work. Where it is undefined, the contractor is assumed not to have made any such allowance. NRM2 also makes clear that if a sum labelled defined isn't accompanied by the supporting information the rules require, it should be construed as a provisional sum for undefined work regardless of how it was described in the bill. The commercial point for a tenderer is that the label — and whether the information behind it is actually there — decides what your price is deemed to include. So if a provisional sum for, say, a plant room extension's controls allowance looks light or is thinly described, that query needs to go in writing: staying quiet leaves the deemed allowance to do the arguing for you, and on a defined sum that argument runs against the contractor.

Why RFI Discipline Matters for Everyone on the Job, Not Just the Contractor

For the M&E consultant or QS running the tender, a clean RFI process is what makes the returns comparable. If one contractor gets a clarification informally over the phone and another doesn't, you're not comparing like-for-like prices anymore — you're comparing who happened to have the consultant's mobile number. For the main contractor managing the tender period, a logged RFI register is the evidence trail that protects the programme later: if a controls package comes in with an interface gap nobody flagged, the register shows whether that gap was ever raised and answered. For the client or FM operator who inherits the building, badly-handled RFIs during tender are the single biggest predictor of "who owns this" disputes at handover — because an interface nobody clarified at tender stage is an interface nobody tests at commissioning either.

What Usually Goes Wrong

The most common failure isn't that RFIs don't get raised — it's that they get raised informally and never logged. An email to a project manager, a comment on a call, a note scribbled on a drawing at a site visit: all of it evaporates the moment the person who said it moves on to the next project. The second most common failure is treating the tender query schedule as optional paperwork rather than the thing that actually protects the price. We've reviewed returns where a contractor's own internal notes clearly show they knew about an interface gap, priced around it privately, and never told the client — which is not a clarification, it's a gamble, and it usually loses. The third is deadline blindness: raising a perfectly good RFI four days before submission, on a job where the consultant's stated response time is ten working days. At that point the question is academic; the answer, if it ever comes, arrives after the tender's already gone in.

What Good Looks Like

A well-run BMS tender treats the RFI register as a live commercial document, not an afterthought. Every query gets a number the day it's raised. Every query is specific enough to generate a specific answer — pointing at a drawing reference or a spec clause, not a vague area of scope. Every query has a "needed by" date set against the tender programme backwards from submission, not forwards from convenience. And every unanswered query at submission is stated as a written assumption on the face of the return, so the client evaluating the tender can see exactly what's been priced and on what basis — rather than finding out three months into the contract that two bidders were pricing two different jobs.

What a Professional BMS Tender Submission Should Contain

Logging RFIs correctly is only half the job — the return they feed into also needs to be structured so the reader can actually evaluate it. This isn't about the technical scope content itself (points schedule, commissioning scope, witness testing, handover deliverables — see the seven red flags that make a return non-compliant for that checklist); it's about how the submission document itself should be put together:

• Covering letter — a short, direct summary of what's being offered and any headline qualifications, so the reader isn't hunting through the pack to understand the shape of the offer.
• Completed pricing schedule — priced against the actual points count and controls schedule, not a lump-sum guess.
• Scope summary — a plain-language statement of what's included, separate from the detailed schedule, so a QS or consultant can sanity-check it against the spec quickly.
• Exclusions — stated explicitly, not implied. If it's not priced, it needs to say so.
• Qualifications and assumptions — every RFI that went unanswered lands here, in writing, as covered above.
• Programme — a realistic timeline for the works, not just the tender return date.
• Lead-time schedule — supplier-confirmed lead times for long-lead equipment, especially relevant on London projects; see our guide to BMS lead times and delivery risk for what needs checking before this goes in.
• Proposed controls manufacturer — named, not left vague, since it affects compatibility with existing plant and future serviceability.
• Panel strategy — new panels, extended existing panels, or a mix, and why.
• Commissioning approach — how testing and witness testing will be run and by whom.
• Training and handover — what's included, for how many staff, in what format.
• Alternatives or value engineering — any genuine cost or performance alternative offered alongside the base price, clearly separated from it.
• Validity period — how long the price stands before it needs re-confirming, which matters given how volatile equipment lead times and pricing have been.
• Payment terms — stated plainly, so there's no ambiguity at contract stage.
• Warranty — what's covered, for how long.
• Supporting accreditations — relevant industry accreditations that give the client confidence in the contractor's competence and safety record.
• Contact details — a named point of contact, not a generic inbox.
• Document revision and submission record — version control on exactly what was submitted and when, which matters if a dispute later arises about which version of the return was actually priced and accepted.

None of this is about padding a return with paperwork — every one of these exists because the alternative is ambiguity that surfaces later, at a worse time, with less goodwill in the room.

When to Bring in a Specialist

If you're a main contractor or consultant running a tender for a project with any meaningful controls interface complexity — multiple services trades feeding into one BMS, phased occupation, an existing legacy system being extended rather than a clean install — get your BMS subcontractor engaged early enough that RFIs can actually be answered inside the programme, not raised as a last-minute scramble against a deadline that's already gone. A controls contractor who's tendered enough of these jobs will flag the interface gaps before they become RFIs at all.

Where RFIs Fit in the Wider Tender Timeline

RFIs don't happen in isolation — they sit inside a bigger sequence of take-off, spec review, subcontractor pricing, controls schedule build and pricing review that every BMS tender goes through, each with its own realistic timescale. The BMS Tender Process walks through that end-to-end process and where RFI review needs to land in the programme so it doesn't get squeezed out.

It's also worth being clear that logging RFIs correctly is only one part of assembling a strong tender pack. For the full picture of what a well-structured, defensible BMS return should contain on the technical side — points schedule detail, commissioning scope stated in engineering days, witness testing provision, handover deliverables, programming hours, and interface assignment — see the seven red flags that make a return non-compliant. And if you're still assembling the base documentation before RFIs even start, what documents a BMS tender needs covers that ground first.

Conclusion

RFIs exist to move ambiguity out of the shadows and onto paper, where it can be priced, evaluated, and defended. On a BMS tender, where interface boundaries between trades are where most disputes actually live, a numbered register, deadline discipline against the return date, and a written assumption for anything left unanswered are the difference between a price that holds up and one that unravels at commissioning. If you're preparing a controls tender and want the interface risks flagged before they become RFIs, get in touch or request a quote.

Frequently Asked Questions

Who answers RFIs during a BMS tender?

Whoever issued the tender documents — usually the M&E consultant, the main contractor's estimator, or the client directly on smaller jobs. On multi-trade projects, an RFI touching interface scope (like fan coil isolation) may need input from more than one design discipline before it can be answered.

Can you submit a BMS tender with unanswered RFIs?

Yes, but only if the unanswered items are stated as written assumptions or qualifications on the face of the return. Pricing an unanswered query silently, in either direction, is what causes disputes later.

How many RFIs is normal on a BMS tender?

It varies hugely with project complexity, but a straightforward single-system install with a complete points schedule might generate none, while a phased refurbishment with an existing legacy system and multiple interfacing trades can easily generate a dozen or more. Volume isn't the concern — unlogged, unanswered volume is.

Do RFIs affect the tender return date?

They shouldn't, if they're raised early enough against the programme. RFIs raised close to the deadline are the ones that either get missed entirely or force a return date extension — which is why deadline discipline against the submission date, not against when the question occurred to you, matters.

What's the difference between an RFI and a variation?

An RFI is a pre-contract clarification that gets priced into the original tender. A variation is a post-award change to agreed scope, priced separately and usually negotiated from a weaker commercial position. Every RFI you skip pre-tender is a variation risk you're carrying into the contract.

What's the difference between an RFI and a tender qualification?

An RFI is a formal question asking someone else to resolve an ambiguity before pricing. A qualification is a statement the tenderer makes themselves — a stated assumption used to price something the spec left unclear, without waiting for an answer. As a working rule: raise an RFI when the answer would materially change the price or technical solution; state a qualification when it's a reasonable assumption that wouldn't.

What should a professional BMS tender submission include?

Beyond the priced schedule itself: a covering letter, scope summary, exclusions, qualifications and assumptions, programme, lead-time schedule, proposed manufacturer, panel strategy, commissioning approach, training and handover detail, any value engineering alternatives, price validity period, payment terms, warranty, relevant accreditations, named contact details, and a document revision record showing exactly what was submitted and when.