Clockworks Analytics Alternatives for Portfolios Running Fault Detection at Scale

Why building teams start shopping for an alternative

Fault detection software gets bought in a moment of optimism and re-examined in a moment of arithmetic. The optimism is real: you connect the building automation system, diagnostics start firing, and within a fortnight you have evidence of simultaneous heating and cooling, stuck dampers, valves leaking by, and schedules that never went back to night setback after a public holiday. The arithmetic arrives at renewal, when someone in finance asks how many of those faults were actually corrected, and the honest answer is a fraction of them.

That gap drives most of these searches. It is rarely a claim that the diagnostics are wrong. It is that findings accumulate faster than a maintenance team can clear them, the list sits apart from the work order queue technicians actually live in, and the savings case that justified the subscription is hard to prove twelve months later. The second driver is coverage. You signed for a handful of flagship buildings, the portfolio grew, and extending diagnostics to older sites with thin controls data costs more than those sites could plausibly return.

What Clockworks Analytics is genuinely good at

Be fair about this before you shop, because the build advocates in your organisation usually are not. Rule based diagnostics on HVAC equipment is a body of applied engineering, not a feature. Knowing that a particular relationship between mixed air, return air and outside air temperature points at an economizer problem, and encoding that so it survives noisy sensors, odd sequences of operation and a controller that reports in the wrong units, represents years of work you would otherwise repeat badly.

Clockworks also does the thing many analytics products skip: it attaches a cost estimate to a fault, so a facilities director can argue for a repair in language a finance committee accepts. A pile of anomalies is not a business case. A ranked list with dollars next to it is. The analyst review model, where software output is filtered by people who read buildings for a living before it reaches your team, is also the right shape for an organisation without an in house energy engineer. If that describes you, the package is hard to beat and harder to rebuild.

Where the model actually strains

Three places, and none of them is a knock on the product itself.

The first is point mapping. Diagnostics only run where the underlying data has been identified: which point is the discharge air temperature, on which unit, in which building, under which naming convention. On a portfolio assembled by a dozen controls contractors over twenty years, that normalisation is the real project, and it never finishes. Every retrofit, every controller swap, every renamed point risks silently breaking a rule set, and silent breakage in analytics is worse than a visible outage because nobody notices the missing faults. You own that burden whether or not you own the software.

The second is the last mile. Analytics produce recommendations. Repairs happen in a maintenance system, on a technician phone, against a budget code, with a supervisor deciding what is worth a truck roll this week. If the fault list and the work order queue meet through a weekly export, the loop stays open, and an open loop is exactly where the return leaks away. The useful questions are: who closes a fault, what evidence proves it was fixed, and does the diagnostic automatically re-test after the repair. Programmes that cannot answer those three underperform regardless of vendor.

The third is fit to your own reporting. Building analytics platforms carry their own view of your estate: their equipment hierarchy, their savings methodology, their idea of a site. When your sustainability disclosure, your capital plan and your tenant recharges all need to speak one language, having a critical dataset shaped by a vendor model and reachable mainly through their dashboards becomes a constraint on everything downstream of it.

Your realistic options, including staying

Option one is to stay and close the loop instead of changing software. This is the cheapest fix and the one most teams skip. Wire faults into the maintenance system properly, assign an owner per building, agree a weekly triage with the controls contractor, and measure corrected faults rather than detected faults. If your programme is underperforming because nobody owns the backlog, switching vendors changes nothing except the invoice.

Option two is another platform. SkySpark is the common move for teams who want a rules engine they can extend themselves and have the technical appetite to run it. Switch Automation and Facilio approach the same problem from the operations side. The major controls manufacturers sell analytics layered on their own systems, which is convenient if your estate is single vendor and constraining if it is not. Switching is a genuine option, but recognise that you are buying a different rule library and a different data model, and you will redo the point mapping either way.

Option three is building your own analytics layer on an open stack: a time series store, tagged data using an open building model, your own rules, your own dashboards. This is a real engineering project and it only makes sense for specific buyers, which is the next section.

When a custom build pays back

Four signals, and you want at least two of them. You run a portfolio large enough that per building licensing has become a line item leadership questions annually, and the marginal cost of adding a site to your own platform is close to zero. You already operate a data platform, so building telemetry belongs next to your meter data, your occupancy data and your capital plan rather than in a separate portal. Your diagnostics are unusual: district energy, laboratory pressurisation, process cooling, or equipment that no generic rule library covers well, so you are paying for a library you barely use and writing custom logic anyway. Or, most persuasive of all, you sell this as a service. If you are an energy services company, a facilities management provider or a controls integrator putting analytics in front of your own clients, the tool is your product, and renting your product from a competitor is a strategic problem, not a cost problem.

Do not build to save money on a small estate. Below roughly a dozen buildings, the licence is not your problem and a build will not repay the engineering time.

Migration reality: the data moves, the rules do not

Plan for this honestly. You cannot export a vendor rule library, and you should not expect to. What you can take with you is your point mapping and equipment hierarchy, which is the expensive part, plus historical trend data and fault history if the platform gives you a bulk export. Ask for the export format before you sign anything anywhere, and check whether you get raw trends or only aggregated results.

Then run in parallel, and run longer than you want to. Building diagnostics behave differently in a January cold snap, an August peak and a mild shoulder week, so a fortnight of parallel running proves almost nothing. Cover at least one full changeover of seasons before you retire the incumbent. Expect a period where the new system produces more false positives than the old one, because tuning thresholds to a specific building is precisely the work the incumbent already did for you. Budget for retraining too: technicians who learned to trust one prioritisation will ignore a new one if the first fortnight of alerts wastes their time.

Cost bands

Commercial analytics platforms in this category are quote based and generally scale with how many buildings and how much equipment you connect, so your cost curve tracks your portfolio growth. A build changes that shape. Based on what Digital Heroes typically delivers, a focused analytics layer, meaning ingestion from your controls systems, a normalised equipment model, a rules engine, a prioritised fault queue and integration with your maintenance system, runs $60k to $150k over 12 to 20 weeks. A full portfolio platform with energy modelling, measurement and verification, client facing dashboards and multi tenant access runs $180k to $400k. Add ongoing engineering for rule maintenance, because rules decay as buildings change.

The honest recommendation

Stay on Clockworks Analytics if the diagnostics are working and the bottleneck is downstream of the software, if your estate is modest, or if the analyst review layer is doing work you have no one to replace. Switch platforms if you want an extensible rules engine and have the technical staff to wield it. Build when the analytics are part of what you sell, when your estate is large enough that per building pricing is strategic, or when this data has to live in your own platform beside everything else. And if you are genuinely in the middle, do the cheap thing first: close the fault to work order loop with what you already own, measure corrected faults for two quarters, and then decide with evidence rather than frustration.