Cost · Procurement
Building Automation Procurement Checklist
A procurement checklist for comparing building automation proposals on scope, evidence, lifecycle cost and handover rather than headline price.
Quick answer
A building automation procurement checklist should compare point schedules, integration matrices, sequences of operation, commissioning evidence, training, documentation and lifecycle support. Requiring the same technical package from every bidder makes prices comparable and exposes exclusions before contract award rather than during commissioning.
Define the outcome before the package
Procurement goes wrong when the tender asks for a product instead of an outcome. Write down what the building must do: which systems are controlled, which are monitored, which sequences must run, what evidence proves they run and who operates them after handover. Include the operating model and the reporting the owner expects. A clear outcome statement lets bidders propose different technical solutions while remaining comparable on function. It also gives the evaluation team a basis for rejecting a low bid that quietly omits integration, training or commissioning. The outcome should be written in language the operator can confirm, not only in engineering abbreviations. The outcome statement should also say what is explicitly out of scope, so that bidders do not price different assumptions.
The technical package to request
Ask every bidder for an architecture diagram, a point schedule, an integration matrix, a sequence of operation, a panel schedule and a commissioning plan. Require the protocol and gateway owner for each interface, the controller loading assumptions and the spare capacity offered. Ask for a cybersecurity description covering accounts, network segmentation, remote access and patching. Request sample graphics and a training outline. These documents should be deliverables, not sales attachments; their quality is a reasonable predictor of delivery quality. A bidder who cannot produce a point schedule at tender stage is unlikely to produce one at handover, when it matters most. Ask for the documents in editable format so the evaluation team can compare them line by line.
Compare commercial terms like an engineer
A headline total is not a comparison. Build a table that shows what each bid includes and excludes: field devices, valves and sensors, cabling and containment, integration licences, graphics, training, documentation, spares, warranty and support. Ask for rates for additional points, additional sequences and after-hours work. Check whether software licences are perpetual or subscription, and whether they transfer to the owner. Include the cost of the owner's own team time for reviews and witness testing. The lowest bid is often the one with the most exclusions, not the lowest lifecycle cost. Comparison is a design activity, not a spreadsheet sort. Ask bidders to identify the three largest risks in their own proposal and how they would manage them.
Make acceptance and handover part of the contract
Define factory acceptance, site acceptance, sequence demonstrations, trend requirements and training completion as contractual milestones. State what counts as a defect, how retesting is charged and what documents must be delivered before final payment. Require as-built architecture, point schedules, addresses, credentials in a managed form, spare parts lists and a change-control procedure. A retention or staged payment tied to evidence is normal; paying in full before commissioning removes the owner's main lever. Good procurement is not adversarial; it makes the rules clear before the work starts, so that disputes are resolved by the contract rather than by escalation. A short handover checklist signed by both parties closes the loop.
Items to require from every bidder
7 rows| Item | What to request | Why it matters |
|---|---|---|
| Point schedule | Named points, types, locations and spares | Makes bids comparable and exposes omissions |
| Integration matrix | Systems, protocols, gateway owner and points exchanged | Clarifies responsibility at every interface |
| Sequences of operation | Written control logic with setpoints and overrides | Defines what commissioning must prove |
| Commissioning plan | Tests, witnesses, acceptance criteria and retest rules | Prevents commissioning from becoming a walk-through |
| Cybersecurity description | Accounts, segmentation, remote access and patching | Protects the building network and owner data |
| Training and documentation | Operator training, as-builts, credentials and guides | Enables the owner to run the system without the installer |
| Support and spares | Warranty, response terms, spare parts and licence transfer | Exposes lifecycle cost before award |
Project images
3 images
Frequently asked
01Should we buy on price or on scope?
On scope, then price. A comparable scope lets you see what the price buys. Price alone rewards the bidder who omitted the most.
02Do we need a technical consultant?
For a multi-system building, independent review of the point schedule, sequences and integration matrix is valuable. It reduces the risk of buying an incomplete scope.
03How do we compare software licences?
Ask whether they are perpetual or subscription, what they cover, how they scale and whether they transfer to the owner. Licence cost belongs in the lifecycle comparison.
04What should be in the warranty?
Coverage of hardware, software and configuration support, response times, exclusions and the handover conditions. A warranty that depends on a maintenance contract should say so.
05When should the owner pay?
Against evidence: delivery, factory acceptance, site acceptance, training and documentation. Staged payments tied to milestones protect both sides.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.