Clockworks Analytics

Clockworks Analytics is a focused fault detection and diagnostics platform, and the focus is the point. Where several products in this category bolt FDD onto an energy reporting tool, Clockworks is built around diagnosis: software that plugs into existing building systems and pinpoints performance issues, with an information model, expert system diagnostics, condition based maintenance and an artificial intelligence assistant called Sprocket. Energy optimisation and energy waste reporting are offered, but as outputs of the diagnostic work rather than as a separate energy management product.

The single most commercially useful characteristic is that diagnostics are ranked by avoidable cost. That matters more than it sounds. Most FDD platforms produce long fault lists that overwhelm a small engineering team and get ignored within months, which is the well known failure mode of building analytics deployments. Ranking by the money each fault is costing converts the output into a prioritised work queue, which is what actually drives follow through. The expert system framing, as against purely statistical anomaly detection, means the platform names the likely cause rather than only flagging that something looks unusual, and the condition based maintenance element connects diagnosis to maintenance action.

What Clockworks is not. It is not a utility bill management system. There is no invoice capture, no bill validation, no tariff reconciliation and no cost allocation described, so an organisation whose problem is four hundred monthly invoices should buy EnergyCAP or MRI Energy, not this. It is not an ESG or carbon disclosure suite: no emissions accounting, no Scope 1, 2 and 3 structure and no framework reporting is described, so it will not satisfy a CSRD or CDP obligation. It is not a power monitoring or power quality product. It is not a portfolio benchmarking tool. And it is not a controls platform: it diagnoses, it does not command equipment, so unlike GridPoint it will not act on its own findings. Conflating a fault detection platform with a utility bill management system is the central error in this part of the market, and Clockworks sits firmly on the diagnostic side of that line.

The marketing site is thin on mechanics, but Clockworks publishes a developer guide that closes the most important question. There is a documented Clockworks REST API, with containers for core data and work orders, and a described two way CMMS integration: the CMMS calls POST on workorders/taskrecords to retrieve tasks flagged for work order generation, PATCH to write the work order identifier back to the Clockworks task, and further PATCH calls to keep status in step, with the guide stating that updates to the work order should simultaneously update the Clockworks task until the work order is completed. Task statuses are Open, In Process, Completed, On Hold and Cancelled, and equipment is matched through CMMS reference, site, location and asset identifiers. Authentication is a 32 digit subscription key in an Ocp-Apim-Subscription-Key header. That is a real, documented closed loop from diagnosis to work order and back, which is exactly what the condition based maintenance positioning requires. Two caveats: the guide names no specific CMMS products, so the integration is build it yourself against the API rather than a prebuilt connector to a named system, and no single sign on is documented.

What remains unpublished is protocol support. The vendor says the software plugs into existing building systems but names neither BACnet nor Modbus nor any other protocol, which for a product whose entire function depends on reading building automation data is a real gap. Mobile access is not mentioned. Dashboards are not named as such, although diagnostic views appear in screenshots. No pricing is published and the page directs visitors to request a demo.

Clockworks fits organisations with existing building automation systems, real engineering capacity to act on findings, and a portfolio large enough that prioritisation matters: hospital systems, universities, large office portfolios, government estates and life sciences facilities. The avoidable cost ranking makes it particularly suitable where the engineering team is small relative to the estate, because it answers the question of what to fix first rather than simply producing more information. It suits organisations that have previously tried building analytics and abandoned it because the fault list was unmanageable, since that is precisely the problem the ranking addresses. Commissioning agents, energy service companies and facilities service providers running analytics as a managed service for clients are also a plausible audience.

It works best as one component of a stack rather than the whole stack: Clockworks for diagnosis, a separate product for utility bills and carbon reporting. Organisations should budget on that assumption rather than expecting a single platform.

It is a poor fit for buildings with no building automation system or with very limited instrumentation, since there will be nothing to diagnose from. It is a poor fit where the driver is financial or regulatory rather than operational. It is a poor fit for small single site organisations given the absence of published pricing and the enterprise orientation. Two questions remain that the vendor does not publish: which protocols and building automation systems are supported, and the pricing basis, whether per building, per point or per square foot. Get both in writing. On the CMMS question, the published developer guide confirms a documented REST API and a two way task to work order integration with status synchronisation, so the closed loop exists, but it names no specific CMMS product. Budget integration effort against your own work order system, or confirm that Clockworks or your CMMS vendor has already built that connector, rather than assuming it ships ready made.