What should a smart building tender specification include?

A smart building tender should tell bidders exactly what they are pricing: the outcomes required, the systems to connect, the data to exchange, who is responsible for what, and the evidence that will prove the work is done. Settle those points before anyone is asked to price a platform, and you have a fair basis for comparing bids and for holding the winner to its offer. Leave interfaces and acceptance criteria open, and each bidder fills the gaps with its own assumptions. That is where variations and disputes begin.

Start from outcomes you can test

Begin with a use-case schedule. For each outcome it names the user, what triggers the function, the data it needs, what it does, what happens in the awkward cases and how acceptance will be shown. Keep the contracted handover scope apart from the supplier's roadmap. A roadmap is easy to mistake for a deliverable.

Be equally clear about where advice ends and control begins. An application that recommends an action needs a named person to review it. One that commands equipment needs stated conditions, an override arrangement and an owner of the control responsibility. Bidders price the two very differently.

Tell bidders what is already there

Give bidders a verified inventory of the existing estate wherever one exists: equipment, controller and software versions, available interfaces, network constraints, licences and known restrictions, with anything unverified marked as such. If the inventory is incomplete, offer a structured survey and clarification route so that no bidder is left to guess.

In an occupied building, describe the working conditions as well: access hours, which services must keep running, restrictions in occupied areas, permitted shutdowns and how changes will be rolled back. Enabling works, such as network changes or additional meters, need assigning to a named contract. Enabling works with no owner often become integration delays.

Write the interfaces down

An interface schedule is the heart of the specification. For each connection it should record:

Where BACnet is specified, ask for evidence that relates to the proposed products and the functions they must perform. The BACnet Testing Laboratories (BTL) programme lists products independently tested for compliance and interoperability against the industry's standard test package. That is useful evidence, but it does not show that your chosen equipment will run your sequence; only a project test does.

APIs need the same scrutiny, because "API available" tells you very little. Ask bidders to identify the operations exposed, the access conditions, version support, rate limits and any additional fees. Where a critical interface is uncertain, ask for a representative exchange to be demonstrated early.

Decide who owns the data, and the cleaning of it

Every use case depends on asset identifiers, locations, naming rules, units, timestamps and quality flags. Define them, name the system that is authoritative for each, and say who resolves conflicting identifiers when equipment is replaced. Data cleaning is real work. Give it an owner and a price, or it will become everyone's assumption and nobody's task.

Information requirements belong here too: what information is needed, by whom, when and in what form. So do your own rights of access and export: use by third parties you appoint, export of historical data, interface documentation and help with transition. Ask bidders to disclose any restriction or charge. These are terms to settle in the agreement, not rights to assume because a system is described as open.

Price security and resilience as work, not as a claim

NIST's guide to OT security (SP 800-82) treats building automation as operational technology, where security sits alongside reliability and safety. It is a sound basis for the project's requirements, though it does not replace an assessment of the specific building.

Ask the design to show system boundaries, who may connect and how, the remote-support arrangements and the named administrator. Then ask for a failure schedule. It should cover what happens when the external connection drops, an application is unavailable or an interface fails, and how service is restored. The schedule matters because it forces a decision, agreed with your operations team, about what state the building should be in when things go wrong.

Ongoing security work needs pricing as well, and the specification should say how a supplier's access ends when its appointment does. The fact sheet on third-party integrators that CISA and the FBI published in September 2026 is a useful checklist for the contract terms: data storage and protection, remote access, the integrator's security programme, change and patch management, hardening of installed equipment, a list of authorised personnel, arrangements for local engineering support, and an inventory of all the hardware and software supplied.

Make integration somebody's job

A responsibility matrix should show, for each interface and use case, who supplies the source data, who configures the receiving system, who arranges access, who runs the test, who witnesses it and who closes defects. Appoint an integration lead where the scope needs one, but do not let that appointment blur the obligations of the individual system suppliers.

Acceptance has to cover the whole workflow. An integrator can prove that a message left its system while another supplier controls whether the destination does anything with it.

Write the acceptance tests before the bids arrive

Draft the acceptance plan alongside the specification. For each use case it sets out the preconditions, inputs, expected behaviour, timing, the evidence to keep and the pass or fail criteria, including abnormal conditions and recovery. Writing it early is the quickest way to find vague requirements while they can still be fixed. Useful checks confirm that:

Staging helps: a representative interface before rollout, integrated testing before handover, and checks once the building is occupied. A system that looks finished is no reason to accept an untested promise.

Treat handover and support as deliverables

Handover should include what the operator needs to run the delivered scope: architecture, interface schedules, asset mappings, configuration records, backups, licence details, test evidence and operating instructions, with the version of any required information standard stated. Training should follow real tasks for named roles; a good test is to ask the operator to carry out an agreed workflow using only the handover material. Support terms should distinguish response from restoration and say who makes later configuration changes.

Make prices comparable

Ask for a common pricing schedule covering design, equipment, interfaces, licences, installation, testing, training and recurring support over a stated period, with options priced separately so that a low headline cannot hide a thin base scope. A clause-by-clause response showing compliance, qualifications and exclusions makes bids comparable. Give technical fit and delivery evidence real weight: a bidder who admits a genuine interface limitation may be worth more than one who accepts every sentence without saying how.