Cost and procurement
Building Automation Cost: Points, Area and Pricing Logic
What drives building automation cost: point counts, area density, controllers, engineering and commissioning, and how to compare quotes without relying on a single price per square metre.
Quick answer
Building automation cost is driven mainly by the number and type of points, the engineering and commissioning behind them, and the plant and integration scope. Area is a useful cross-check for density, not a quotation basis; two buildings of the same size can need very different systems.
Why points and area both appear in pricing
Building automation is labour-heavy and device-heavy at the same time. Each point needs a sensor or actuator, an input or output, wiring, engineering, configuration and commissioning. The number of points therefore correlates with cost more closely than any other single variable. Area appears in quotations because it is easy to measure and because larger buildings usually contain more points, more zones and more plant. But area is a proxy, not a cause. Two buildings of the same size can differ substantially: one may have a central plant, variable air volume and full metering; the other may have packaged units and local controls. A price per square metre is useful for an early sanity check and dangerous as a commitment. The defensible basis is a point schedule and a scope matrix. Both measures belong in a budget discussion, provided the assumptions behind them are written down. The same discipline applies to retrofit: an existing building may need more integration effort than its floor area suggests. The useful comparison is not cost per square metre but cost per delivered function, with the function defined in the scope. A simple packaged plant may reasonably cost less per square metre than a laboratory, and that difference is information, not error.
- Points correlate with devices and labour
- Area is a density proxy, not a cause
- Same area can hide different scope
- Budget from point schedule and scope matrix
What counts as a point
A point is a single signal that the system reads or writes. Analog inputs measure temperature, pressure, flow or humidity. Analog outputs drive modulating valves or dampers. Digital inputs report status, alarms or occupancy. Digital outputs switch pumps, fans, contactors or valves. Software points, sometimes called virtual points, are calculated or logical: a setpoint, an average temperature, an occupancy state or a runtime total. They still need engineering and testing. Counting rules matter more than the total. Does a point include its alarm? Is a valve with feedback one point or two? Are spare points included? Is a meter pulse one point or several? A point schedule that states these rules can be compared; a headline number cannot. Spare capacity should be explicit rather than hidden in a contingency. A point schedule that cannot be counted consistently cannot be priced consistently. The point count is also a design statement: every point should have a purpose, a name and an owner. Counting rules should be agreed before the tender, because two suppliers who count differently cannot be compared, even if both are honest. The schedule should also state which points are mandatory for safety and which are optional for reporting.
- Analog and digital inputs and outputs
- Software and calculated points
- Counting rules for status, alarms and spares
- Every point named and owned
How area changes the number
Area affects point count through density and complexity. A warehouse may need relatively few points per square metre; a laboratory, hospital or hotel may need many. Ceiling height, zoning, plant location and the number of tenants also change the design. A building with a central plant and long distribution runs needs more sensors and valves than one served by packaged rooftop units. Refurbishment can be denser than new build because existing services must be monitored and coordinated. Area is most useful when it is paired with a building type and a services list. A quick estimate can be built from points per zone or points per room, but it should be replaced by a point schedule before a contract is signed. Area-based estimates should be labelled as preliminary and replaced as soon as the design allows. The estimate should show its assumptions, so that a change in scope produces a change in number rather than a dispute. A single rate applied to a mixed-use building is almost always wrong for at least one of its parts. A change of use can change the density without changing the area, which is why the schedule must follow the services. Parking, plant rooms and back-of-house areas often have a different density from the occupied floors.
- Density varies by building type
- Zoning and plant layout change the count
- Refurbishment can be denser than new build
- Replace area estimates with a schedule
Cost elements beyond the point count
The point count is only one line in the commercial model. Field devices, controllers, I/O modules, panels, power supplies, gateways, cabling and containment all scale with the design. Engineering covers sequences, graphics, network design and documentation. Configuration covers function blocks, schedules, users and alarms. Commissioning covers factory testing, point checks, sequence testing and witness tests. Training, spare parts, warranties, support and project management complete the picture. Site logistics, import duties, currency and payment terms can change the total without changing the technology. A proposal that quotes a single number without a scope matrix is difficult to compare and easy to misunderstand. The useful question is not only what the system costs, but what is included, what is excluded and who carries each risk. Lifecycle costs, including support and future changes, belong in the same conversation as the capital cost. Each element should have an owner in the commercial documents, so that a missing item is visible before installation. A useful proposal separates what is fixed, what is measured and what is provisional, so the client can see where the uncertainty sits. Warranty terms and response times belong in the same table as the hardware, not in an appendix.
- Devices, controllers, panels and cabling
- Engineering, graphics and documentation
- Commissioning, training and support
- Logistics, duties and currency
How quotes are structured
Quotations follow different commercial models. A lump sum transfers defined scope and risk to the supplier. An open-book or measured model exposes labour and material and is common where scope is still developing. A design-only fee may be separate from installation and configuration. Software licences may be perpetual or subscription-based, and support may be included for a period or sold annually. Provisional sums are sometimes used for integration work that cannot be defined until the existing systems are surveyed. Change control is essential: a written process for scope changes, with an impact on price and programme, prevents the disputes that appear at handover. Spare parts and spare capacity should be priced explicitly, not treated as goodwill. The commercial structure should match the maturity of the design. A cheap quote with vague inclusions is usually more expensive than a clear quote with a higher headline price. Payment milestones should be tied to documented deliverables rather than to calendar dates alone. A quote is a description of a project, and the description matters as much as the number. The payment schedule should not front-load the contract so heavily that the supplier has no incentive to finish commissioning. A retention or a final milestone tied to handover keeps the end of the project visible.
- Lump sum versus open book
- Design, hardware, software and installation separated
- Provisional sums for unknown integration
- Written change control and explicit spares
Comparing quotes line by line
To compare proposals, normalise them. Put each offer against the same point schedule, the same scope matrix and the same exclusions. Check the controller and gateway count, the spare capacity, the commissioning scope, the training and the support term. Ask what happens to the price if the point count changes by a defined percentage. Compare lifecycle cost, not only capital cost: a system that cannot be maintained locally may cost more over time. Budget in phases if the project is large, but complete and document each phase before starting the next. Treat any savings claim as a hypothesis to be tested against metering and operating hours, not as a guaranteed outcome. The most useful budget is one that shows its assumptions and can be updated when the design changes. A clear basis of comparison is a commercial asset; a single lowest number is not. A short list of questions sent with the tender usually improves the quality of every response. Normalisation also means comparing the same currency, the same tax basis and the same delivery terms. A comparison sheet with one row per cost element is more useful than a meeting where two totals are read aloud.
- Same point schedule and scope matrix
- Spares, commissioning and support compared
- Lifecycle cost alongside capital cost
- Savings claims tested, not assumed
Budgeting, phasing and contingency
Budgeting is not the same as pricing. A budget is an allowance with stated assumptions, a stated confidence level and a stated review date. It should separate the base building, the tenancy work and any optional integration, so that a scope reduction can be made without renegotiating everything. Contingency should be visible and tied to identified risks: an unsurveyed existing system, an unknown protocol, a late design change. Phasing is a legitimate way to manage both cost and risk, provided each phase leaves the building complete and documented for its current use. Deferring a phase is cheaper than stopping half-way through a system. The budget should also include the owner's costs: training, spares, support, network changes and staff time. A budget that covers only the panels and the programming is not a project budget. Review it when the design changes, and record why the number moved. A budget that is never revised is either very lucky or not being used. Contingency should be released by a named person against a defined trigger, not spent quietly as the project drifts. A phase that is deferred should still have a documented interface, so the next phase can connect without rework. The common failures are a budget without exclusions, a contingency treated as a discount, and a phase started before the previous one was documented.
- Assumptions, confidence and review date stated
- Base building, tenancy and options separated
- Contingency tied to identified risks
- Owner costs included in the project budget
Procurement questions and how to request pricing
Pricing is a scope exercise, not a price list. We do not publish amounts, because the same building type can differ by an order of magnitude in points, protocols and site conditions. To receive a meaningful proposal, send the drawings, the system list, the point schedule if one exists, the required protocols, the programme and the site constraints. State whether you need a budget indication, a technical review or a firm offer, and which standards or tender clauses apply. We will respond with a scope matrix, the assumptions behind the number and the exclusions. If the design is not ready, the honest answer may be a paid survey or a design phase before a price. Contact us through the contact page or the enquiry form with the building type and the systems in scope, and we will tell you what is needed to price the work. Pricing on request is not evasion; it is the only way to keep the number comparable. A published rate would be wrong for most projects and useful for none. A short enquiry with the building type, the systems and the point count if known will get a more useful reply than a request for a price per square metre. If a tender requires a lump sum before the design is complete, the assumptions and qualifications should be visible in the offer.
- Send drawings, system list, point schedule and protocols
- State whether you need a budget, review or firm offer
- Expect a scope matrix, assumptions and exclusions
- Contact us for pricing rather than a published rate
Cost elements and the questions that expose them
17 rows| Cost element | What drives it | How it is measured | Question to ask | Risk if unclear |
|---|---|---|---|---|
| Field devices | Sensor and actuator count and type | Device schedule | Who supplies and installs? | Devices missing from the price |
| I/O modules | Point count and mix | Point schedule | Is spare capacity included? | Hidden spare or no spare |
| Controllers | Sequences, zones and capacity | Controller schedule | What is local and what is supervisory? | Control placed in the wrong layer |
| Control panels | I/O count, location and ingress protection | Panel drawings | Is factory testing included? | Panels built but untested |
| Gateways | Protocol and device count | Interface matrix | Who owns the configuration? | An unowned single point of failure |
| Cabling and containment | Topology and distance | Cable schedule | Is containment included? | A late electrical variation |
| Engineering | Sequences, graphics and network design | Engineering hours or scope | What is the design deliverable? | Design billed but not documented |
| Configuration | Function blocks, schedules and users | Configuration scope | Who can edit after handover? | Owner locked out of the system |
| Graphics | Screens and navigation | Screen list | Who approves the design? | Unlimited screen revisions |
| Commissioning | Device and point count | Commissioning plan | Is site acceptance testing included? | Handover without proof |
| Training | Roles and sessions | Training plan | Is documentation included? | Operators trained on slides only |
| Support | Response time and term | Service agreement | What is excluded? | Support that ends at the first fault |
| Licences | Software and engineering tools | Licence schedule | Perpetual or subscription? | A future renewal that stops the system |
| Spare capacity | Future points and expansion | Point and panel schedule | How much spare is priced? | Expansion blocked by a full panel |
| Documentation | Drawings, backups and records | Document register | Who owns the files? | A system nobody can maintain |
| Project management | Coordination and reporting | Project plan | Who coordinates third parties? | Delays with no owner |
| Logistics and duties | Location, import and currency | Commercial terms | Who bears currency risk? | A total that moves before delivery |
Project images
3 images
Frequently asked
01How much does building automation cost?
There is no single figure, and we do not publish one. Cost depends on point count and mix, plant complexity, integration scope, engineering, commissioning and local market conditions. A useful budget starts from a point schedule and a scope matrix, not from a price per square metre. Contact us with the building type and systems in scope, and we will explain what is needed to prepare a comparable proposal.
02What is cost per point?
It is total system cost divided by the number of points, but it is only meaningful when the point definition, scope and exclusions are identical. It is most useful for comparing similar proposals, not for estimating a new building from scratch. We do not publish a per-point rate, because a rate without the scope behind it would mislead more than it helps.
03Is price per square metre reliable?
As a preliminary cross-check, yes. As a quotation basis, no. Services density, zoning, plant type and integration scope can vary widely between buildings of the same area, so the figure should be replaced by a point schedule. If a supplier will not move beyond a square-metre rate, the scope is probably not defined well enough to compare.
04What is usually excluded from a quote?
Common exclusions include cabling and containment, power distribution, plant repairs, civil works, permits, taxes, duties and some third-party licences. The exclusions matter as much as the price, so they should be listed explicitly. An exclusion that is not written down is usually discovered as a variation, which is the most expensive way to buy it.
05Why do two quotes for the same building differ?
They may count points differently, include different spare capacity, assume different integration effort, or exclude different items. Comparing totals without normalising the scope hides those differences. Use the same point schedule and scope matrix. A difference in price is not a problem by itself; an unexplained difference is.
06How can cost be reduced without losing function?
Standardise room templates, phase the scope, reuse serviceable infrastructure, reduce unnecessary monitoring and keep the point schedule disciplined. Avoid cutting commissioning or documentation, because those savings usually reappear as operational cost. The cheapest saving is usually a smaller scope that is completely delivered, not a larger scope that is partially tested.
07Does a lower capital price mean a lower lifetime cost?
Not necessarily. A system that is poorly documented, hard to maintain or dependent on one supplier may cost more over its life. Compare support, spares, documentation and the ability to change the system, not only the initial price. A low price that locks the owner into one service route is a financing decision disguised as a bargain.
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.