Strategy, Costs & Procurement
How much does a smart building system cost?
The cost lines that make up a smart building budget, why price benchmarks mislead, and how to make supplier quotations comparable.
Judge the product and the integrator as two different things, on evidence the whole team can see.

The first rule is to compare them separately, because you are judging two different things. A vendor sells a product; an integrator sells the ability to design, install, configure, document and support a working system. Products are tested on functional fit, openness, security and how long they will be supported. Integrators are tested on relevant experience, the people who will actually do the work, their delivery and testing methods, their own security practices and how they will support you after handover. In both cases the criteria, weightings and pass-or-fail conditions should be fixed before proposals arrive, claims should be verified against evidence rather than brochures, and demonstrations should follow scripts built from your own scenarios.
A good product badly integrated produces a poor system, and even a strong integrator cannot fully compensate for a closed or insecure product. Some suppliers do both jobs, but the two roles should still be evaluated separately when one company bids for both. It also helps to know whether an integrator is independent or tied to particular manufacturers, because that shapes what it will propose.
| Criterion | What to ask for | Evidence that counts |
|---|---|---|
| Functional fit | Performance against your use cases | Scripted demonstration using your scenarios |
| Open standards | Which protocols and data models are supported, in which versions | Certification listings, published interface documentation |
| Data access | How you can read, export and reuse all your data | Documented export formats and APIs, tested in the demonstration |
| Security | Default settings, authentication, logging, update process, vulnerability handling | Manufacturer documentation; answers to the questions below |
| Support period | How long security updates will be provided | Stated end-of-support date |
| Commercial model | Licences, subscriptions, what happens if you stop paying | Contract terms |
For BACnet products, the BACnet Testing Laboratories (BTL) certification programme lists products independently tested against the standard test package. The listing should match the product model and firmware version actually being offered.
Security claims need the same scrutiny. CISA's Secure by Demand guidance for owners of operational technology suggests questions to put to manufacturers: whether default passwords have been eliminated; whether older, insecure protocols are disabled by default; whether the product logs logins and changes; whether multi-factor authentication comes in the baseline version; whether a software bill of materials is available; whether the manufacturer publishes end-of-life dates; and whether the product supports open standards that make replacing or adding products simpler. ISASecure runs certification schemes against parts of the ISA/IEC 62443 series for components, systems and development practices. A certificate is useful evidence, but check exactly what it covers.
Ask for each product's support end date as well. The EU Cyber Resilience Act will make manufacturers state it at the time of purchase from December 2027, but there is no reason to wait.
| Criterion | What to ask for | Evidence that counts |
|---|---|---|
| Relevant experience | Projects of similar type, size and integration complexity | References you can call; anonymised deliverables |
| Named team | Who will design, program, commission and support | CVs and commitment that key people will stay on the project |
| Method | How they handle point naming, interface schedules, testing and documentation | Sample test scripts, as-built documents, naming conventions |
| Security practice | Remote access, credentials, change and patch management, their own network security | Written description; willingness to accept contract requirements |
| Support | Response arrangements, local presence, escalation, spares | Proposed service levels and staffing |
| Independence | Commercial relationships with manufacturers | Declaration of partnerships and incentives |
The contract topics in the September 2026 CISA and FBI fact sheet on third-party integrators of industrial control systems make good interview questions, not just contract clauses. Ask each bidder how it controls remote access, manages changes and patches, decides who may work on your systems, and how you would operate and recover without it. The fact sheet is written for critical infrastructure, but the answers reveal an integrator's working maturity more clearly than any policy document.
Some criteria should be gates, not scores: data export, minimum security requirements and compliance with the specification are pass or fail, and no low price should compensate for failing one. The remaining criteria need weighting before bids are opened, with the balance between quality and price agreed and written down in advance. Prices then have to be normalised so that like is compared with like over the same period, including recurring costs and exclusions.
Demonstrations are most revealing when every bidder works through the same scenarios, ideally with a sample of your own data, and is asked to run the export in front of the panel. References deserve more than a courtesy call: ask referees about problems, how they were handled and whether the named people really did the work. And the reasons for the decision should be recorded, which protects it and makes the next procurement easier.
Flawed comparisons fail in familiar ways. They evaluate feature lists and never test how products perform the owner's own tasks. They accept "open" and "secure" as self-descriptions without evidence. They compare first costs while recurring costs differ. And they allow the integrator who wrote the specification to bid against it.
Pagin Consulting's part, as a Vendor Agnostic adviser, comes early: the criteria, the gates and the demonstration scenarios, settled in writing and sent to every bidder alike, and then the evaluation run against them. Each of the mistakes above is avoided at that stage, long before anyone reaches the evaluation room.
This article connects to our work on Our services.
We can discuss how this subject fits the project brief.
Contact Pagin Consulting