Before the Analytics Demo: What to Ask an FDD Vendor

Most analytics demos follow the same script. A dashboard loads, a heat map of the portfolio lights up in amber and red, someone clicks into an air handler with a simultaneous heating and cooling fault, and the presenter explains what that one fault is costing per year. It is a good show. It also tells you almost nothing about what owning the platform will feel like eighteen months later, when the novelty is gone and someone on your team has to decide which of 400 open faults deserve a truck roll.

The demo data has been curated. Those buildings were onboarded by the vendor's best engineers, the point names were cleaned up, and the rules were tuned until the fault list looked credible. Your buildings will not arrive like that. So the useful work happens before the demo, in the questions you send ahead and insist on getting answered in writing.

Start With Who Owns the Data

This sounds like a legal question, and partly it is, but the practical version is simpler: can you get your raw trend data back out, at full resolution, without asking permission or paying a fee? Some platforms keep only derived results after a retention window, so the fifteen-minute trends behind last year's findings are gone. Others keep everything but only expose summaries through the interface.

Then ask about the connection itself. Does the platform read from the BMS over BACnet/IP through an on-site gateway, pull from an existing historian, or require its own hardware? A gateway the vendor owns and manages is convenient until you want to point a second tool at the same data. Find out whether data collection can run independently and feed the analytics layer, or whether the two are welded together.

How the Rules Get Written and Tuned

Every FDD platform ships with a rule library. The number of rules on the slide is meaningless. What matters is how a rule gets adapted to a specific piece of equipment, and who does the adapting.

Take a basic economizer rule: the outdoor air damper should be at minimum position when outdoor air temperature is above the changeover setpoint. Simple. But the changeover setpoint varies by unit, some units use enthalpy rather than dry bulb, the damper feedback point may not exist, and the minimum position on a unit serving a lab is not the same as one serving offices. A rule that does not know those things will fire constantly, or never.

Ask the vendor to show you, live, how a threshold is changed for one unit without changing it across the fleet. Ask to see the rule logic itself, not just its output. Can your own engineers write a custom rule, and in what language or interface? If the answer is that their analytics team handles all rule changes through a ticket, find out the typical turnaround. Two weeks per change adds up fast during the first months.

Semantic Tagging Is Where the Effort Hides

Rules run against tagged points. If the platform uses Project Haystack or Brick Schema, ask whether tagging is automated, semi-automated with human review, or manual, and who does the reviewing. A supply air sensor that is actually reading mixed air, mislabeled in the original BMS programming fifteen years ago, will produce faults that look real and are not. Somebody has to catch that. It is usually not the software.

False Positives Are an Operating Cost

Here is the question most buyers skip and later regret: when the platform flags a fault that turns out to be wrong, who investigates it, and what happens next?

In the first few months, a large share of flagged faults on a typical building will be noise, data quality problems, or legitimate operating decisions the software does not understand. A night setback that looks like a failed sensor. A unit deliberately locked out during a tenant fit-out. If your facility team has to triage all of that, the tool becomes another inbox they ignore within a quarter. I have watched that happen more than once.

Pin down the service model. Is there an analyst on the vendor side who reviews faults before they reach your team? Is that included, or a separate tier? When a false positive is identified, does the rule get suppressed for that unit, retuned, or does it keep firing? And can you see a history of those decisions, so the next person knows why a fault was muted?

Onboarding Effort, Per Building, In Hours

Ask for an estimate of onboarding effort per building, broken down by task, along with the assumptions behind it. A newer building with a clean BACnet network and consistent naming might come online in days. A campus with three generations of controllers, a few proprietary trunks behind gateways, and point names like AHU1_SAT_2_OLD can take weeks of engineering.

The breakdown you want looks something like this:

• Network access and gateway installation, including IT security review
• Point discovery and trend configuration
• Tagging and equipment modeling
• Rule configuration and initial tuning
• Review of first results with the site team

Then ask who pays for each line. Many contracts quote a subscription per building or per point, with onboarding bundled up to some limit. Exceed that limit on a messy site and the change orders begin.

Exports, Exit, and the Day You Leave

Nobody likes negotiating the divorce during the courtship. Do it anyway.

Ask what you can export: raw trends as CSV or through an API, the tagged equipment model in Haystack or Brick format, the fault history with timestamps and resolution notes, and any custom rules your team wrote. The tagged model is easy to overlook and expensive to recreate. If you paid for months of tagging work, you should be able to take the result with you and load it into whatever comes next.

Then ask the blunt version. If we cancel, what do we receive, in what format, within how many days, and when is our data deleted? Get the answer into the contract, not an email from the account manager.

How to Run a Pilot That Tells You Something

A pilot only helps if it is designed to produce a decision. Too many are open-ended trials where the vendor picks the building, the vendor does the setup, and everyone reconvenes in three months to admire a nice report.

Pick the buildings yourself. Include at least one easy site and one that is genuinely difficult. If you are comparing two platforms, give them the same buildings and the same data access, ideally from the same trend source.

Define success before you start. Useful measures include how many hours of your staff time onboarding consumed, what fraction of flagged faults your team confirmed as real after review, how long it took to suppress or retune a bad rule, and whether at least a few findings led to an actual repair or setpoint change. Savings estimates produced by the platform are interesting, but treat them as the vendor's claim until a meter backs them up.

Run the pilot across a season change if you can. Plenty of rules look sensible in mild weather and fall apart in the first week of heating. Three months is a reasonable minimum. Shorter than that and you are mostly evaluating the onboarding team.

Keep your own log throughout: every fault your technicians investigated, how long it took, and whether it was real. At the end, that log will tell you more than any dashboard.

And save one question for the final meeting: if we sign, will the engineers who onboarded the pilot be the same people who onboard the rest of our portfolio?