How long does it take to get a building live on analytics?

Ask a building analytics vendor how long deployment takes and you will usually get an answer about connectivity: which protocols they speak, whether they need a gateway, how quickly data starts arriving. That answer is close to useless, because connecting a building was never the hard part.

This article is for engineering firms, commissioning providers and property teams who are being asked to commit to a deployment date. It sets out the four stages of getting a building live on analytics, which of them actually consumes the time, and why the same platform category can take a month or the better part of a year depending on one decision you make at purchase.

Key takeaways

• Connection is days, not months. Getting a read-only data feed out of a modern BMS is routine engineering. Where it drags, the cause is usually IT and network approval, not the analytics platform.
• Writing the rule library is the long pole. Authoring the analytics that turn raw trend data into actionable faults is a substantial engineering project, and it is the stage that separates a one-month deployment from a multi-month one.
• Point naming quality decides the middle stage. A building whose BMS points were named consistently normalises in days. One with twenty years of accumulated naming conventions takes considerably longer.
• Ask about time to first verified fault, not time to first dashboard. Data arriving on a screen is not a result. A fault that an engineer has confirmed is worth fixing is.
• On PEAK, buildings are typically live within about 30 days, because the 5,000+ engineering rules already exist and are tuned to the site rather than written from scratch.

How long does it take to get a building live on analytics?

For a single commercial building, expect days to connect the BMS, days to weeks to normalise the point data, and anywhere from weeks to many months to produce useful analytics. The spread sits almost entirely in that last stage. If the rule library already exists, a building can be productive within about 30 days. If you are authoring the rules yourself, plan in quarters.

Building analytics deployment is the process of connecting a building's control and metering systems to an analytics platform, mapping its data to a consistent model, running fault detection rules against it, and tuning the output until the faults it raises are worth acting on. Only the last two steps produce value, and only the third is genuinely variable.

That variability is why deployment timelines quoted in sales conversations are so unreliable. Two vendors can both say "we can connect you in a week" and be telling the truth, while one of them delivers a confirmed fault in month one and the other in month seven.

What are the four stages of an analytics deployment, and which one is slow?

Deployment runs through connect, normalise, write the rules, and tune and verify. The first two are predictable engineering tasks with known durations. The third is where months disappear, because writing analytics that detect real faults without drowning the team in false positives is specialist work. The fourth never entirely finishes.

Why does connecting the BMS take days and writing the rules take months?

Connection is a solved problem with standard protocols and a finite scope: open a read-only path, confirm the points, start the feed. Rule authoring has no fixed scope. Every plant type, sequence and seasonal behaviour needs its own logic, and each rule has to be tested against real data before it can be trusted.

A chilled water system alone can justify dozens of rules: valve position against command, approach temperature, staging behaviour, simultaneous heating and cooling, pump pressure control, reset schedules. Each of those has to express what correct operation looks like, tolerate legitimate variation, and avoid firing on every transient. Write it too loosely and the team stops reading the alerts. Write it too tightly and real faults go unseen. The Smart Energy Analytics Campaign, which tracked analytics deployments across a large sample of US buildings, found the same pattern: the technology is rarely the constraint, the engineering process around it is.

This is the work that fault detection and diagnostics actually consists of, and it is why a platform's rule library is a far better predictor of deployment speed than its protocol list. Standards such as ASHRAE Guideline 36 give you a reference for correct sequences, but turning a sequence into a tested, tuned, low-noise analytic is still engineering effort per plant type.

What changes when the rule library already exists?

The slow stage largely disappears. Instead of authoring analytics, the deployment becomes mapping this building's plant onto rules that have already been written, tested and tuned across hundreds of other buildings. The engineering work still happened, but it happened once and is amortised rather than repeated per customer.

This is the structural difference between the two models on the market. One sells you a toolkit: a rules engine, a data model and an editor, with the analytics left to you or to an integrator. The other sells you the analytics already written. SkyFoundry's SkySpark is the best known example of the first model, and its own product documentation describes authoring sparks and rules in its Axon language as core to how the product is used. Neither model is wrong, but they produce very different deployment timelines, and they put the engineering cost in different places.

Both models are legitimate. The difference is where the engineering effort sits and who pays for it.

On a toolkit platform, authoring the library is a project in its own right, measured in months of engineering per plant type rather than days. That cost is real whether you pay it in your own engineers' time or in integrator fees, and it recurs whenever you meet plant you have not modelled before.

What does a platform need from your BMS before day one?

A read-only network path, a point list, and enough naming consistency to tell what each point measures. Nothing needs replacing. Analytics platforms worth considering are vendor-agnostic and read from the controls you already have, so the preparation is access and documentation rather than capital works.

The part that varies is naming. A BMS commissioned with a consistent convention can be mapped quickly. One where three contractors over twenty years each used their own abbreviations needs interpretation before any rule can run, because a rule written for "supply air temperature" has to know which of forty differently named points that is in this building. We covered how this works, and how Project Haystack and Brick tackle it, in BMS point naming, Haystack and Brick.

This is the single most useful thing a property team can do before procurement: get the point list exported and look at it. It tells you more about your deployment timeline than any vendor conversation will.

How fast does a portfolio roll out compared with a single building?

Faster per building, and increasingly so. The first building of a given plant type carries the mapping and tuning effort. The tenth building with similar plant inherits almost all of it. Portfolio rollouts are therefore front-loaded, and a vendor quoting a flat per-building duration across a portfolio has not thought about it properly.

The practical consequence is that the sequence matters. Starting with the most representative buildings rather than the most troublesome ones gets the portfolio moving faster, because the patterns established early are the ones reused. Starting with an outlier teaches you about the outlier.

It also means portfolio deployment is a poor place for a per-building fixed fee on either side. Firms running this as a service model usually price the first sites differently from the rest, a point we go into in how to structure an analytics-backed maintenance contract.

When do you see the first verified result, not the first dashboard?

A dashboard can appear in week one and mean nothing. The milestone worth contracting on is the first fault an engineer has confirmed, costed and sent to someone to fix. Ask every vendor for that date specifically, and ask what happens between the alert being raised and an engineer agreeing it is real.

The gap between those two milestones is where most disappointment with building analytics comes from. Platforms that raise alerts without triage hand the triage problem to the customer, and a team that spends three months dismissing false positives will conclude the technology does not work. The alternative is a platform where engineers triage and validate faults before they reach you.

It is also worth asking how the loop closes. In a CIM sample, about 1 in 6 closed fault tickets were closed before the data confirmed the fix, which is a reminder that "resolved" in a work order system and "fixed" in the plant are different claims. Verifying that a fault was actually fixed is the part that makes the deployment worth anything.

What should you ask a vendor to commit to on deployment time?

Five questions: how many rules ship with the platform; who writes any that are missing; what the point list needs to look like; the date of the first engineer-verified fault, not the first data feed; and what the second building costs in time once the first is live. Vague answers to the first two predict a slow deployment.

Our building analytics RFP guide sets these out alongside the commercial and security questions worth asking at the same time.

Where does CIM's PEAK Platform fit?

PEAK is a vendor-agnostic analytics platform that arrives with its rule library already written. More than 5,000 engineering rules run against the plant it connects to, which is why buildings are typically live within about 30 days rather than after a rule-authoring project.

PEAK reads from existing controls over standard protocols, with no rip-and-replace, and currently runs across 700+ commercial buildings and more than 100 million square feet. Faults are triaged by CIM engineers before they reach the customer, assigned as actions, and verified against the data once work is reported complete. More than 20 engineering and service partners deliver analytics to their own clients on the platform rather than building one, which is the same decision set out above viewed from the supplier side.

For engineering firms weighing a toolkit against a library, the honest framing is in our comparison of FDD and building analytics platforms, and the independence question is covered in 7 things to know about independent building monitoring. If you are scoping a deployment now, The Building Performance Engineer's FDD Playbook covers what to put in the first 90 days. You can also see how firms run the delivery model in how engineering firms run RCx, MBCx and data-driven maintenance on FDD, or look at the fault detection and diagnostics solution and the PEAK Platform overview.

Frequently asked questions

How long does it take to deploy building analytics across a portfolio and see results?

The first buildings of each plant type carry the mapping and tuning effort, and later buildings inherit most of it. On a platform whose rule library already exists, individual buildings are typically live within about 30 days and a portfolio rolls out progressively faster. Where the analytics must be written first, plan in quarters rather than weeks.

What are the alternatives to SkySpark for engineering firms that don't want to build their own analytics rules?

Firms that do not want to author analytics themselves should look at platforms that ship a tested rule library rather than a rules engine and editor. The practical test is to ask how many rules come as standard, which plant types they cover, and who writes any that are missing. CIM's PEAK Platform, Clockworks and CopperTree all sit in that category.

How long does it take to connect a single building to an analytics platform?

Usually days. Opening a read-only path out of a modern BMS over BACnet, Niagara, Modbus or an existing historian is routine engineering. Where connection takes longer, the delay is almost always IT and network approval or missing documentation rather than anything about the analytics platform itself.

Do you need new sensors or hardware to deploy building analytics?

Generally no. A credible analytics platform is vendor-agnostic and reads from the controls and meters already installed, so there is no rip-and-replace. What it needs is a read-only network path, an exported point list, and enough naming consistency to identify what each point measures.

What slows a building analytics deployment down the most?

Writing the analytics rules. Authoring logic that detects real faults across every plant type, tolerates legitimate variation and avoids false positives is specialist engineering work, and it has no fixed scope. Inconsistent BMS point naming is the second largest factor, because rules cannot run until points are mapped to a consistent model.

How many fault detection rules should a building analytics platform have?

The count matters less than the coverage. Ask for a breakdown by plant type and check that your chillers, air handling units, boilers and meters are included. A large number with no plant-type detail tells you nothing. For reference, CIM's PEAK Platform runs more than 5,000 engineering rules.

What is the difference between time to first data and time to first verified fault?

Time to first data is when readings appear on a screen, which can happen in week one and means little. Time to first verified fault is when an engineer has confirmed a specific problem is real and worth fixing. Only the second milestone represents value, and it is the one worth writing into a contract.

Is the second building faster to deploy than the first?

Yes, usually substantially. The first building of a given plant type carries the point mapping and rule tuning. Buildings with similar plant reuse that work, so marginal effort falls sharply. The ratio between the first and second building is a useful question to put to any vendor during procurement.