Writing a Fire Alarm Tender Specification That Actually Works

A poorly written fire alarm tender specification does not usually fail obviously — it fails quietly, by producing bids that all look plausible and are not actually comparable, because each bidder has filled in the gaps the specification left open with their own assumptions about category, scope, coverage or what is included in the price. The responsible person, or whoever is evaluating the bids, ends up choosing between apples and oranges while believing they are choosing between competing prices for the same job. This article sets out what a specification needs to state clearly to avoid that, from the engineer's side of either writing or responding to one.

The short version: a specification that leaves the category, scope, standards basis or competence requirements ambiguous will get bids that cannot be fairly compared, and the fix is to state each of these explicitly rather than assume a bidder will infer them correctly.

Who this is for

This is an informational overview for fire alarm and security engineers involved in writing specifications, reviewing them before they go out to tender, or interpreting one as a bidder — as well as responsible persons and their consultants managing a fire alarm procurement. The experience level assumed is competent engineer. It does not cover general procurement law, public sector tendering rules, or contract formation, and is not a template to copy verbatim without applying it to the actual building and project in question.

Why ambiguous specifications produce bad tenders

A specification's job is to define the work precisely enough that different bidders, working independently, would each produce a genuinely comparable proposal for the same job. When a specification is silent on something material — the BS 5839-1 category, whether commissioning documentation is included, how many detection zones are expected — bidders do not all guess the same way; some assume a wider scope and price accordingly, others assume a narrower one and come in cheaper, and the resulting bids differ for reasons that have nothing to do with genuine competitiveness. The responsible person evaluating those bids is then comparing assumptions, not prices, and the eventual contract is likely to surface disagreements about scope once work actually begins.

Performance versus prescriptive specifications

A performance specification states what the system must achieve — category, coverage requirements, standards compliance, interface requirements — without naming specific products, leaving bidders free to propose their own compliant solution; this tends to produce more competitive bids because it does not lock the project to one manufacturer's pricing. A prescriptive specification names specific equipment, panels or manufacturers, which is sometimes genuinely necessary — matching an existing system on the same site, meeting a client's own equipment standard, or a documented technical reason a particular product is required — but narrowing the field this way should be a deliberate, stated decision with a reason behind it, not a default carried over from a previous project without being reconsidered. Mixing the two approaches without being explicit about which parts of the specification are performance-based and which are prescriptive is a common source of confusion for bidders.

Stating the category and design basis

Where the BS 5839-1 category has already been established — from the fire risk assessment, the fire strategy, or Approved Document B's guidance for the building type — the specification should state it explicitly, because category selection drives detection coverage, zoning, and much of what the rest of the design depends on. A specification that omits the category and expects bidders to infer or determine it themselves is asking each bidder to effectively redesign the system to their own judgement before even pricing it, which defeats the purpose of a comparable tender. Where the category genuinely has not yet been formally confirmed at the point of tender, the specification should say so plainly and explain how and when it will be confirmed, rather than leaving a silent gap that reads as an oversight.

Scope: what is actually included

Beyond the category, a specification needs to be explicit about what falls inside and outside the priced scope: design work itself, first and second fix installation, commissioning and witness testing, as-built drawings and cause and effect documentation, initial training and handover, and — where relevant — an initial period of maintenance or warranty cover. Leaving any of these implicit invites the same comparability problem as an undefined category: one bidder prices commissioning documentation as included, another prices it as an extra, and the headline figures are not actually comparable until that gap is found and reconciled, often after contract award rather than before it. Stating scope item by item, even where the answer for a given item is simply "not included," removes that ambiguity.

Standards and legal references to cite correctly

A specification should cite the specific standards it expects the work to meet — typically BS 5839-1 for the fire alarm system itself, and any others genuinely relevant to the project, such as BS 5266 for emergency lighting where that is part of the same package — rather than a vague reference to "current regulations" that names nothing checkable. It is worth being precise about what each reference actually is: BS 5839-1 is a code of practice, Approved Document B is statutory guidance supporting the Building Regulations, and the Regulatory Reform (Fire Safety) Order 2005 is the underlying legal duty — conflating these, or citing a standard incorrectly, undermines the specification's own credibility and can genuinely confuse a bidder about what is actually being required.

Asking for competence evidence properly

A specification that simply asks bidders to confirm they are "competent" or "certified" invites an unverifiable claim, because there is nothing specific for the evaluator to check it against. Naming the actual scheme and module expected — for example BAFE SP203-1 registration for the specific activities being tendered, such as installation and maintenance — and requiring evidence such as a current registration number or reference checkable against the relevant register, turns a vague assurance into something the evaluator can genuinely verify before award, not just take on trust from the bid document itself.

Commissioning, documentation and handover requirements

The specification should state what commissioning evidence is expected — witness testing, a completed cause and effect matrix proven by test with supporting panel event log extracts confirming each induced condition, as-built drawings reflecting what was actually installed rather than only what was designed — and what documentation the responsible person expects at handover, including certification and the fire safety logbook's initial content. Leaving commissioning and handover requirements vague is a common way for a project to be technically "finished" from the contractor's point of view while the responsible person is left without the records BS 5839-1 and ongoing compliance actually depend on.

Evaluation criteria worth stating upfront

Where a specification does not state how bids will actually be evaluated — price alone, or price alongside competence evidence, references, response times and programme — bidders are left guessing what to emphasise, and the eventual evaluation can look arbitrary even where it was not. Stating the evaluation basis upfront, even briefly, sets expectations correctly and tends to produce bids that are easier to compare fairly, because bidders address the criteria that will actually be used rather than whatever they assume matters most.

Pricing structure and whole-life cost

A specification that asks only for a single lump-sum figure encourages bids to be compared on price alone, which can favour a bidder who has priced a narrower interpretation of the scope rather than the one who has genuinely quoted the full requirement. Asking for pricing broken down by stage — design, installation, commissioning, documentation, and an initial maintenance period if included — makes it far easier to spot where one bid differs from another and why, rather than reconciling two very different-looking totals after the fact. It is also worth asking bidders to indicate ongoing maintenance contract pricing alongside the capital cost, since a system that is cheaper to install but expensive to maintain over its working life is not necessarily the better value option, and a specification silent on this leaves the responsible person unable to compare whole-life cost even where they would want to.

Site access, survey provisions and existing-system information

Where a tender covers work on an occupied or partially occupied building, the specification should state what site access bidders can expect for their own pre-tender survey, and share any existing system documentation already held — as-built drawings, cause and effect records, prior fault history — so bidders are pricing from the same starting information rather than each making different assumptions about the existing installation. A specification that assumes bidders will simply "visit site" without arranging access, or that withholds existing documentation on the basis that a survey should reveal it anyway, tends to produce less accurate and less comparable pricing, because bidders without full information hedge their quotes differently. Sharing what is already known, and being clear about how a formal site survey can be arranged before bids are due, removes an avoidable source of pricing variation that has nothing to do with genuine competitiveness.

Variations and change control during the contract

A specification that is precise at the point of tender can still drift once work is underway, if variations to scope — a changed room layout, an additional zone, a device relocated on site — are agreed informally and never reflected back into the contract or the eventual as-built documentation. Stating in the specification how variations will be raised, priced and agreed before work proceeds, and who has authority to approve them, avoids both unauthorised scope creep and unnecessary disputes about what was actually agreed. Any variation that amounts to an engineered solution departing from the standard recommendations needs the same documented justification it would need on any other project, regardless of how the contract itself is structured, and the specification's change-control clause should say so rather than leaving that connection to be assumed.

Referencing panel behaviour and manufacturer requirements correctly

Where a specification is performance-based rather than naming a specific manufacturer, it can still usefully state expected panel behaviour at a functional level — for example how the system should indicate a fault differently from a fire condition, or how zones should be presented — without locking the design to one product range. Where device compatibility genuinely matters, such as extending an existing loop or matching an existing panel's protocol, the specification should say so explicitly and explain why, rather than leaving compatibility as an assumption bidders have to guess at from a site visit alone. Being specific about functional requirements while staying open on the actual product achieves most of what a prescriptive specification is trying to protect, without narrowing competition unnecessarily.

Common engineer mistakes

A frequent mistake is treating a previous project's specification as a template and reusing it without updating the category, scope or standards references for the new building, carrying forward assumptions that may no longer apply. A second is naming a certification requirement in general terms — "third-party certified" — without specifying the scheme and module, leaving room for a bidder to claim certification that does not actually cover the work being tendered. A third is leaving commissioning and documentation requirements implicit, on the assumption that "of course" a competent contractor would provide proper handover documentation, when experience shows this is exactly the kind of scope gap that gets contested after the event. All three are avoidable by being explicit rather than assuming shared understanding.

When not to rely on this alone

When not to use this article: do not use it as a ready-made specification template to copy without adapting it to the specific building, fire strategy and procurement rules involved, and do not use it for guidance on procurement law, contract formation or public sector tendering procedure, which are outside its scope. It sets out what good practice looks like in general terms; the actual specification still needs to be written for the specific project.

Relevant standards

BS 5839-1 is the code of practice a fire alarm tender specification should reference for category selection, design, installation, commissioning and maintenance expectations. Approved Document B provides statutory guidance relevant to the building's fire strategy and, where applicable, to category determination, supporting the Building Regulations in England. The ongoing legal duty to provide and maintain adequate fire precautions in most non-domestic premises sits under the Regulatory Reform (Fire Safety) Order 2005, and a specification citing these references correctly — by name and by what type of document each actually is — supports a tender that bidders can respond to precisely.

Professional disclaimer

This is an educational resource for competent fire alarm and security engineers and the responsible persons and consultants they work with. It does not replace BS 5839-1, project-specific procurement rules, or professional advice on contract formation and tendering procedure.

Related documentation

Use this alongside the building's fire risk assessment and fire strategy, the site survey carried out before design, and — once agreed — the resulting design documentation, cause and effect matrix and commissioning records. A specification is only as good as the design basis behind it; where the category or fire strategy is not yet settled, resolve that first rather than tendering around an assumption.