Building analytics software promises to find faults before occupants notice them, but the vendors approach the problem very differently. Some lean on rules written by engineers, some on machine learning, and some bundle analytics into a wider operations platform. Choosing well depends on your data, your staffing and how findings become repairs. This comparison covers Clockworks, SkySpark, Facilio, Aquicore, KGS and KODE, and explains why the work order that follows a finding matters as much as the finding itself.
Building Analytics Platform Comparison: 6 Vendors Compared
Compare analytics method, data integration and the path from fault to fix, then decide how findings will reach your technicians.
First, a note on the vendor list
Six names, five companies
KGS Buildings is the former name of Clockworks Analytics, which rebranded around its flagship product. Searches for "Clockworks vs KGS" therefore compare a company with its own earlier name. This page treats them as one vendor and gives you a sixth evaluation lens instead: your own requirements.
Check before you shortlist
Vendor products, ownership and integrations change. Treat the profiles below as starting points for questions, and confirm current capabilities in writing during your RFP.
Rules, machine learning or both
Rules-based fault detection
- Engineers define what a fault looks like, such as simultaneous heating and cooling
- Findings are explainable and easy to audit
- Coverage depends on the rule library and tuning
Machine learning approaches
- Models learn normal behavior and flag deviations
- Can surface patterns no one wrote a rule for
- Needs clean history and clear explanations to earn technician trust
Hybrid platforms
- Rules for known faults, models for anomalies
- Often more flexible, sometimes harder to compare in a bid
- Ask which findings come from which method
Vendor profiles
Turn analytics findings into tracked repairs
Whatever platform you choose, a finding only saves money when someone fixes it. Oxmaint manages the work orders, assets and PM schedules that close the loop.
Side-by-side evaluation criteria
| Criterion | Why it matters | What to request from each vendor |
|---|---|---|
| Analytics method | Determines explainability and tuning effort | List of fault types with the method behind each |
| Data integration | Poor point mapping produces false findings | Supported protocols, mapping process and time estimate |
| Data model | Affects portability and multi-building rollout | Tagging or ontology approach and export options |
| Finding prioritization | Technicians ignore long unranked lists | How cost, comfort and risk influence ranking |
| Work order handoff | Findings without action create no value | Integration or export method to your maintenance system |
| Service model | Someone must review and tune findings | What is included, what is charged and who staffs it |
| Security and IT review | Building networks are sensitive | Architecture, access controls and data ownership terms |
Weighted RFP scorecard
About these weights
The weights are a starting suggestion, not an industry standard. Adjust them to your portfolio, then lock them before vendors present so demos do not steer the scoring.
Common ways analytics projects stall
Bad point mapping
Mislabeled sensors create false faults, and technicians stop trusting the output after the first wasted trip.
No owner for findings
Reports are generated but nobody is accountable for reviewing and assigning them each week.
Findings outside the work system
Items live in a separate portal and never reach the planner, so they miss scheduling and cost tracking.
Savings claims without baselines
Without a documented starting point, benefits are hard to prove at renewal time.
From analytics alert to maintenance action
Detect
Analytics flags a fault on an air handler.
Validate
An engineer confirms it is real and sets priority.
Create work
A corrective work order is raised against that asset.
Repair
A technician fixes it and records cause and action.
Learn
History informs PM tasks and future rule tuning.
Where Oxmaint fits
Oxmaint is maintenance management software, not a fault detection engine. It provides asset records, corrective and preventive work orders, inspections, mobile workflows and reporting so analytics findings become tracked work. Confirm integration options with the team during a demo.
Data readiness: fix these before any vendor goes live
Analytics quality is limited by the data underneath it. Teams that budget time for cleanup before go-live usually see fewer false findings and faster trust from technicians.
Point naming and mapping
Inconsistent names for the same sensor across buildings make rules unreliable. Agree a naming convention and map points to equipment before analytics begins.
Sensor calibration
A drifting temperature or pressure sensor produces convincing but wrong findings. Spot check critical sensors against a reference reading.
Equipment register accuracy
Findings must point to a real asset. If the register lists equipment that was replaced years ago, work orders will land on the wrong record.
Control sequences documented
Rules assume how a system is supposed to operate. Undocumented overrides and seasonal changes create alerts that are really design intent.
Network and access approval
Involve IT early. Remote access to building networks usually needs security review, and delays here push back the whole project.
Baseline period defined
Record energy, comfort complaints and corrective work before go-live so improvement can be shown later with evidence.
How to run a fair pilot
Pick two sites
Choose one clean building and one difficult one to test the range.
Set success tests
Agree the findings, accuracy and response times that count as a pass.
Run in parallel
Give each vendor the same data window and the same equipment.
Validate in the field
Send technicians to confirm a sample of findings and record true versus false.
Score and compare
Use the weighted scorecard from your RFP, not impressions from demos.
Track false positives honestly
The most useful pilot measure is the share of findings that technicians confirm on site. A platform that finds fewer issues but gets them right can be worth more than one that floods the team with alerts nobody trusts.
Pricing and contract questions to settle early
| Topic | Question to ask | Why it matters |
|---|---|---|
| Pricing basis | Is cost per building, per square foot, per point or per user? | Changes how cost grows as you add sites or sensors |
| Implementation fees | What is included in onboarding and point mapping? | One-time charges can exceed first-year subscription |
| Support and tuning | Who reviews findings and adjusts rules, and how often? | Unowned tuning leads to alert fatigue |
| Data ownership | Can you export history and models if you leave? | Prevents lock-in and protects your records |
| Contract term | Is there a pilot clause or an exit option? | Reduces risk if results disappoint |
| Performance claims | What evidence supports quoted savings, and on what building types? | Savings vary widely by building and baseline |
Who should own the findings
In-house engineers
- Best knowledge of the buildings and their history
- Can validate and prioritize quickly
- Needs protected time each week to review
Service contractors
- Can fold findings into scheduled service visits
- Requires clear contract language on response
- Check incentives so fixes are not delayed for billing reasons
Vendor-managed review
- Reduces internal workload at the start
- Depends on vendor knowledge of your sites
- Keep final prioritization with your own team
Measuring value after go-live
| Measure | Source | What good looks like |
|---|---|---|
| Findings confirmed in the field | Technician notes on work orders | High confirmation rate and falling false positives |
| Time from finding to work order | Analytics log and CMMS timestamps | Short, consistent handoff |
| Time from work order to repair | CMMS work order history | Within service targets for each priority |
| Repeat faults on the same asset | Failure and cause codes | Declining as root causes are fixed |
| Comfort complaints and emergency calls | Request and work order records | Downward trend against the baseline period |
Be careful with savings claims
Energy and cost savings depend on the baseline, weather, occupancy and the speed of repair. Credit analytics only for improvements you can trace to a specific finding and a completed work order.
Three ways to connect analytics to maintenance
Manual review and entry
- An engineer reads the findings and raises work orders by hand
- Low setup cost and full human judgment
- Does not scale well across many buildings
Scheduled export or email
- Weekly summaries are sent to a planner who creates the work
- Easy to start and simple to audit
- Findings can age while waiting for the next cycle
Direct system integration
- Validated findings create work orders automatically
- Fastest path from fault to technician
- Needs agreed rules so duplicates and noise stay controlled
Start simple, then automate
Many teams begin with a weekly review and manual work orders, then automate the handoff once the findings are trusted. Whichever route you pick, require a consistent asset reference so each work order links to the equipment that triggered it, and so repair history can feed back into the analytics review.
Decide who clears duplicates
Analytics can raise the same fault many times. Name one person or rule that merges repeats into a single work order, otherwise planners lose trust in the queue and technicians start ignoring new requests. Review the merge rule monthly during the first quarter after go-live, and record every override so you can see which findings keep returning and why.
Frequently asked questions
Are Clockworks and KGS different vendors?
No. KGS Buildings is the former name of Clockworks Analytics. Treat them as one vendor when building your shortlist.
Is rules-based or machine learning analytics better?
Neither wins in every case. Rules are easier to explain, while models can catch unexpected patterns, so ask each vendor which faults use which method.
What should a building analytics RFP include?
Fault coverage, integration effort, prioritization, work order handoff, service model and security review. Score them with weights set before vendor demos.
Does analytics replace a CMMS?
No. Analytics finds issues, while a CMMS like Oxmaint plans, assigns and records the repair work.
How do I connect findings to maintenance?
Decide the handoff before purchase and test it in a pilot. You can book a demo to discuss the work order side.
Close the gap between a fault and a fix
Pick the analytics platform that suits your data, then give technicians a clear work order to act on. Oxmaint helps teams track the repairs that analytics uncover.
