Most building analytics and fault detection and diagnostics (FDD) RFPs go wrong in the same way. They ask vendors to list features, every vendor ticks every box, and the decision ends up resting on price and presentation. Six months after go-live the platform is raising alerts nobody acts on, and nobody can say with confidence whether a single fault was actually fixed.
A good RFP avoids that by asking questions a vendor cannot answer with a tick. This guide covers what to define before you go to market, what the RFP document should contain, the evaluation questions that separate platforms in practice, the four areas where vendor answers differ most, how to score the responses, and how to run a pilot that tests a platform on your own building data rather than a demo account.
Key takeaways
- Define who will act on alerts before you write the RFP. It is the single biggest predictor of whether a platform delivers value, and it changes which questions matter.
- Ask for evidence, not yes or no answers. Screenshots from live accounts, sample reports, deployment data and references separate platforms that a feature checklist cannot.
- Test the whole loop, not just detection. Most platforms find faults. Far fewer confirm in the data that a fault was actually fixed and stayed fixed.
- Publish your scoring weights up front. A weighted matrix agreed before responses arrive keeps the evaluation honest.
- Finish with a pilot on your own building. Live data, agreed pass criteria and at least one fault taken from alert to verified fix.
What should a building analytics RFP include?
A building analytics RFP should include your portfolio and BMS inventory, the outcomes you want to buy, integration and data requirements, security and data ownership terms, the service model you expect, the commercial structure and a published scoring method. The evaluation questions matter most. They should test how faults are found, prioritised, fixed and verified, not only which features exist.
The rest of this guide works through each of those in order. If you are an engineering or services firm choosing a platform to deliver to your own clients, the questions are different, and we cover them in how engineering firms should choose a building analytics platform.
When do you need a formal RFP for building analytics?
A formal RFP makes sense when you are buying across a portfolio, when procurement rules require competitive tender, or when several stakeholders need to agree the decision. For a single building with a small shortlist, a structured pilot with clear pass criteria can reach a sound decision faster. Many owners combine the two: a short RFP to shortlist, then a pilot to decide.
The investment case is well established. Lawrence Berkeley National Laboratory's Smart Energy Analytics Campaign, which tracked 104 organisations across roughly 6,500 buildings in the US, found that participants using fault detection and diagnostics achieved median energy savings of 9%, with a median simple payback of about two years (Kramer et al., 2020). The same research is clear that savings depend on how findings are acted on, which is exactly what a good RFP should test.
What should you define before issuing the RFP?
Before going to market, document your portfolio and BMS inventory, rank the outcomes you want, decide who will act on alerts, agree how savings will be measured and bring IT, procurement, sustainability and facilities into the process early. Vendors can only answer precisely if you describe your buildings precisely.
Portfolio and BMS inventory. List each building with floor area, building type, BMS vendor and version, communication protocol (BACnet/IP, BACnet MS/TP, Modbus or proprietary), metering and any network constraints. The difference between BACnet/IP and MS/TP alone can add weeks to a deployment, which we explain in BMS point naming, Haystack and Brick: the data layer behind FDD.
Outcomes, ranked. Energy reduction, rating targets such as NABERS, equipment reliability, contractor accountability, tenant comfort and compliance reporting all pull a platform choice in different directions. Rank them. The ranking becomes your scoring weights.
Who will act on alerts. An in-house engineering team, an integrated FM provider, a controls contractor and a mechanical contractor each need different workflows, access and reporting. A platform that suits an in-house team can fail completely when the people fixing faults work for someone else.
How savings will be measured. Agree the baseline period and method before you buy, not after. At minimum, secure twelve months of metered data for each building. Our guide to measurement and verification of energy savings covers the options.
Internal stakeholders. IT and cyber security will want to review network architecture early. Procurement will set the process. Sustainability and facilities teams will be the day-to-day users. Involving all four before release avoids a late veto.
What sections should the RFP document contain?
A clear RFP has nine sections: background, portfolio data, scope, integration requirements, security and data, services, commercials, evaluation method and timeline. Keeping the structure consistent makes responses directly comparable.
| Section | What to include |
|---|---|
| Background and objectives | Who you are, why you are buying and the ranked outcomes you want |
| Portfolio data | Building list, floor areas, BMS vendors, protocols, metering and network notes |
| Scope | Buildings and equipment in scope, phasing, and whether services such as analyst review are included |
| Integration requirements | Data access method, hardware constraints, CMMS or work order integration |
| Security and data | Required certifications, hosting location, data ownership and export requirements |
| Services and support | Onboarding, training, engineering support and response expectations |
| Commercials | Pricing template for vendors to complete, term, and renewal expectations |
| Evaluation method | Scoring weights, the questions below, and pilot requirements |
| Timeline | Clarification window, submission date, shortlisting, pilot and award dates |
Give every vendor the same pricing template. Otherwise one quotes per building, another per square metre and a third per data point, and comparison becomes guesswork.
Which evaluation questions should you ask building analytics vendors?
The most useful evaluation questions ask for evidence of how a platform performs on live buildings: how it integrates, how accurate its faults are, how fixes are verified, how people use it, how savings are measured, how data is secured and what the service model includes. Below are 37 questions across nine categories. Ask vendors to answer each with evidence rather than a yes or no.
1. BMS integration and data
- Which BMS platforms and protocols do you integrate with today, and on how many live sites for each?
- What hardware, if any, must be installed on site, and who supplies, secures and maintains it?
- How are BMS points mapped and normalised? What share is automated, who reviews the result, and do you support Project Haystack or Brick Schema?
- What is your median time from contract signature to live analytics on a site like ours, and what most commonly causes delay?
- Which points and trend intervals do you need for each equipment type, and will you issue a point schedule before installation?
Tagging standards such as Project Haystack and Brick Schema speed up commissioning, but neither is a prerequisite. What matters is whether the vendor can show you a reliable, reviewed mapping process.
2. Fault detection and diagnostic quality
- How many rule templates run by default for our equipment types, and how are they maintained and improved?
- How do you manage false positives? What share of alerts are closed as not a fault, and how do rules clear once a fault is resolved?
- How are faults prioritised? Does each fault carry an estimated cost, and how is that estimate calculated?
- Does an alert identify the likely root cause and a recommended action, or only the symptom?
- Show three examples of faults your platform found that a threshold alarm on a typical BMS would have missed.
The request for three missed faults is the one to watch. The most expensive faults, such as passing valves and overrides left in place, never breach a single threshold, which is why they persist for years. Our analysis of the most common HVAC faults in commercial buildings shows what those look like in the data. The false positive question matters just as much: a platform that floods your team with unreliable alerts recreates the BMS alarm fatigue it was bought to fix.
3. Closing the loop: action, verification and accountability
- When a fault is marked resolved, how does the platform confirm in the data that it is actually fixed?
- Who can mark a fault as closed, and does the platform reopen it automatically if the fault recurs?
- What field evidence can technicians attach, such as photos, readings and comments, and is it time-stamped against the fault record?
- How does the platform report on response times and the share of faults verified as fixed, by contractor and by building?
- How do you detect faults that return after closure, such as an override reapplied or a schedule reverted?
This category is where platforms differ most, and where most RFPs are thinnest. A fault is not fixed when a work order is closed. It is fixed when the data shows the condition has gone across a full operating cycle. In a sample of closed tickets across CIM's portfolio, about 1 in 6 were closed before the building data confirmed the fix, which we unpack in how to verify a contractor actually fixed an HVAC fault. The principle is the same one behind independent building monitoring: nobody should mark their own homework.
4. Workflow and adoption
- Can a technician receive, investigate and close out an alert from a phone while on site?
- Does the platform integrate with our CMMS or work order system, and in which direction does data flow?
- Can our FM provider and contractors have access with appropriate permissions, and is there a per-user charge?
- What training is included, and what share of licensed users are still active after six months?
5. Savings measurement and reporting
- How are energy savings calculated, and is the method aligned with IPMVP or ASHRAE Guideline 14?
- How is the baseline set, and how is it adjusted for weather and occupancy?
- Does your reporting separate estimated fault savings from metered, verified savings?
- Can the platform support the reporting we need for NABERS, GRESB, MEES or other disclosure obligations?
6. Security, data ownership and access
- What independent security certifications do you hold, for example ISO/IEC 27001 or SOC 2 Type II, and can you share the current certificate or report?
- What is the network architecture? Is the connection outbound only, and does the platform ever write to the BMS?
- Who owns the data, where is it hosted, and can we export all raw and processed data in a standard format at any time, including at contract end?
- How do you handle authentication, access control and audit logging?
7. Services and engineering support
- Who supports us day to day: a named engineer with HVAC and controls experience, or a general help desk?
- What is included in onboarding, rule tuning and ongoing analyst review, and what is chargeable?
- What are your support hours and response commitments across our time zones?
8. Commercials
- What is your pricing model (per building, per square metre or square foot, per point or per equipment item), and exactly what is included?
- How does cost scale as we add buildings, and are there volume breaks?
- What one-off costs apply for hardware, integration and onboarding?
- What are the minimum term and renewal terms, and what happens to our data if we leave?
9. References and proof
- Provide two references from portfolios comparable to ours in size, building type and region.
- Share a case study where results were verified with metered data rather than modelled.
- What is your customer retention rate, and what are the most common reasons customers leave?
How do you check whether an analytics vendor is independent of equipment and controls manufacturers?
Ask who owns the vendor, whether the platform recommends specific equipment brands, whether the vendor also sells maintenance or controls services into your market, and whether anyone with a commercial interest reviews its fault rules or savings claims. Ownership is a matter of public record. The incentives it creates are what your RFP should test.
Ownership in this market has been consolidating. Copeland announced its acquisition of the Australian analytics platform Bueno Analytics in January 2026 (ACHR News), and several widely used analytics products are owned by groups that also manufacture plant or controls, or that sell maintenance contracts. That is not disqualifying on its own. It is a fact your evaluation should price in, because it shapes what a platform is likely to recommend and what it is unlikely to flag.
Four questions make the position clear:
- Who owns you, and has that changed in the last three years? If the owner manufactures equipment or controls, how is the analytics business kept separate?
- Does the platform ever recommend a specific manufacturer's equipment, parts or upgrade path? Ask to see the recommendation text for a failing chiller and for an air handling unit.
- Do you sell maintenance, controls or energy services to owners in our market? If so, do you compete with our incumbent contractor, and how is that managed?
- Who reviews the fault rules and the savings method, and does that team report into a business that benefits from the result?
The principle is the one we set out in seven things to know about independent building monitoring: the party being measured should not control the measurement. It applies to platform vendors exactly as it applies to contractors.
What should an RFP require as proof that a fix actually held?
Require the vendor to state in writing what closes a fault: the condition clearing in the building data across a full operating cycle, a named person and timestamp, field evidence attached to the record, automatic reopening if the fault returns, and a monthly report of the share of closures verified that way.
Most RFPs ask whether a platform tracks faults to closure. Every vendor answers yes, because closing a ticket is tracking. The useful requirement is a definition of closure the platform has to meet, written into the specification rather than left to the vendor's own wording. The clauses below are a starting point to adapt with your legal adviser.
Two of these do most of the work. Clause 1 moves closure from a human action to a data condition. Clause 3 stops a fault being closed, reappearing a fortnight later and counting as a fresh find. Together they separate a platform that detects faults from one that resolves them, a distinction we set out in how FDD platforms compare.
What should you ask about poor-quality or incomplete BMS point data?
Ask what the platform does when points are missing, badly named, duplicated or wrongly scaled: which rules still run, how the gaps are shown to you, who fixes the mapping, and whether a point schedule is issued before installation. Most deployments meet imperfect data. The useful question is how a vendor behaves when they do.
Point data on an older building is rarely clean. Naming conventions left with the contractor who set them, sensors drift or fail silently, and the same physical value appears twice under different labels. A platform that quietly drops those points leaves you with analytics on the equipment that happened to be well tagged, which is seldom the equipment costing you the most. The data layer underneath is covered in BMS point naming, Haystack and Brick.
Ask for answers with examples from live sites rather than a methodology slide:
- What share of points is classified automatically on a building like ours, and who checks the result before rules go live?
- When a required point is missing, which rules run in reduced form, which do not run at all, and how is that shown to us rather than hidden?
- How do you detect a sensor that has failed, stuck or drifted, and is that raised as a fault in its own right?
- How are duplicate or conflicting points resolved, and can we see the mapping that was applied?
- Will you issue a point schedule per equipment type before installation, and what happens commercially if the BMS cannot supply those points?
The last question protects your timeline. A vendor that issues a point schedule up front has a repeatable process. One that discovers the gaps after contract signature will pass the delay, and often the cost, back to you.
How do licensing models differ between vendors?
Building analytics is usually licensed per building or site, per unit of floor area, or per data point or equipment item, with onboarding and integration charged separately. None of the three is inherently better. What matters is whether the unit you are charged on grows at the same rate as the value you get, and what happens when it changes.
Comparing quotes is where most evaluations lose their footing, because each model hides a different risk. Ask every vendor to complete the same pricing template, then restate each quote in your own unit, usually cost per building per year, before comparing anything.
Onboarding, integration and any site hardware are normally charged separately from all three models.
Then ask what the model itself does not answer: what triggers a change in the charge, what happens when a building is sold, refurbished or taken off line, whether licences can be reallocated, and whether the renewal uplift is capped. Our Guide to Building Analytics works through how the models compare in practice.
How should you score vendor responses?
Score responses with a weighted matrix agreed and published before the RFP is released. Weight each category by your ranked outcomes, score every question on a defined scale, and treat references as a pass or fail gate rather than a weighted score. Publishing the method tells vendors what matters and keeps the evaluation defensible.
A simple four-point scale works well: 0 for no answer, 1 for a claim without evidence, 2 for a claim supported by documentation, and 3 for a claim demonstrated on live data. Average the scores within each category, then apply the category weight. The example weights below suit an owner focused on energy and contractor accountability. Adjust them to your own priorities.
| Category | Example weight |
|---|---|
| Fault detection and diagnostic quality | 20% |
| BMS integration and data | 15% |
| Closing the loop: verification and accountability | 15% |
| Workflow and adoption | 10% |
| Savings measurement and reporting | 10% |
| Services and engineering support | 10% |
| Commercials | 10% |
| Security, data ownership and access | 10% |
| References and proof | Pass or fail |
On a long list, a quick screen saves time before the full matrix. Tick each question a vendor answers well. Anything below six is unlikely to survive the detailed evaluation.
What are the red flags in vendor responses?
The clearest red flags are unsupported claims: yes to every question without evidence, savings figures with no stated method, and no data on deployment time or false positives. A vendor confident in its platform will show you how it performs on live buildings and agree to a pilot on yours.
Severity reflects how strongly each answer predicts a disappointing deployment, based on the evaluation criteria above.
Two further responses are worth probing rather than dismissing: data export that is restricted, delayed or charged as an extra, and a refusal to name the people who will support you day to day. Neither is fatal on its own, but both tend to appear alongside the red flags above.
How long does a building analytics RFP take?
Allow roughly four to six months from preparation to award if the process includes a pilot, and around two to three months without one. Preparation and the pilot are the stages most often underestimated. The plan below is a starting point to adjust to your procurement rules.
| Stage | Allow |
|---|---|
| Preparation: inventory, outcomes, stakeholders, scoring method | 3 to 4 weeks |
| RFP open, including a clarification window | 3 to 4 weeks |
| Evaluation, clarifications and shortlisting | 2 to 3 weeks |
| Pilot with shortlisted vendors | 6 to 10 weeks |
| Negotiation, security review and award | 2 to 4 weeks |
How do you structure a pilot for building analytics software?
Run the pilot on live data from your own buildings, with pass criteria agreed in writing before it starts. Include time to live data, the number of valid faults found, the false positive rate, and at least one fault taken from alert through to a fix verified in the data. Use your own engineers and contractors, not the vendor's team, to work the alerts.
Choose two buildings if you can: one with known problems, to test detection, and one that is well run, to test how much noise the platform produces. Then agree criteria such as these:
- Live data flowing from agreed equipment within the time the vendor proposed in its response.
- A minimum number of faults confirmed as valid by your own engineers, each with a cost estimate.
- A false positive rate below an agreed threshold.
- At least one fault taken from alert to verified fix, with field evidence attached.
- Active use by the people who will fix faults, including FM and contractor staff.
The strongest test is one your own sceptics run. At a commercial tower in Canary Wharf, two engineers who had challenged the platform hardest took a live alert from their first training session to the plant room and confirmed a £25,000-a-year chilled water valve fault within 98 minutes, with evidence logged on the record. That is the kind of result a pilot should be designed to surface.
Where does CIM's PEAK Platform fit?
If you are issuing an RFP, we would expect CIM's PEAK Platform to be tested against every question above, and we would ask to be tested on your own building data rather than a demo.
PEAK monitors more than 100 million square feet across 700+ commercial buildings in 11 countries. It is BMS-agnostic, reading data from all the major building management systems through a single normalised data model; the full list is on our BMS integrations page. It is built around closed-loop verification: faults are raised with a cost estimate and recommended action, worked by the people responsible for the building, and confirmed as fixed in the data rather than marked complete. PEAK keeps watching after closure, so an override reapplied or a schedule that drifts back is raised again. CIM customers see average energy savings of 19%, and every customer is supported by qualified engineers rather than a general help desk.
For an example of that loop working across a whole building, see how a London headquarters cut electricity use by 14% in its first 11 weeks. To include PEAK in your evaluation or set up a pilot, request a callback.
Frequently asked questions
What should an RFP for building analytics and fault detection software include?
A building analytics or FDD RFP should include your portfolio and BMS inventory, the outcomes you want ranked, integration and data requirements, security and data ownership terms, the service model you expect, a common pricing template and a published scoring method. The evaluation questions matter most: they should test how faults are found, prioritised, fixed and verified in the data.
What should property teams ask vendors when evaluating building analytics platforms?
Ask questions that require evidence across integration, fault quality, verification, workflow, savings measurement, security, support, commercials and references. The most revealing are how false positives are managed, what closes a fault, who owns the vendor and whether it sells services into your market, and how the platform behaves when BMS point data is incomplete.
What building analytics platforms work reliably with poor-quality or incomplete BMS point data?
Judge this by behaviour rather than brand. A platform copes with imperfect point data when it classifies points automatically with engineer review, issues a point schedule per equipment type before installation, states which rules run in reduced form when a point is missing, raises failed or drifting sensors as faults in their own right, and shows you the mapping it applied.
How much does a building analytics platform cost per building or per square foot?
Pricing is usually per building, per unit of floor area, or per data point or equipment item, plus one-off onboarding and integration costs. As a benchmark, Lawrence Berkeley National Laboratory's Smart Energy Analytics Campaign in the US found installation and software costs typically ranged from two to eight cents per square foot depending on system type, with a median simple payback of about two years.
How long does it take to select a building analytics platform?
Allow roughly four to six months from preparation to award if the process includes a pilot, and around two to three months without one. Preparation, including the BMS inventory and scoring method, and the pilot itself are the stages most often underestimated.
Should a building analytics RFP include a pilot?
Yes, for any significant portfolio decision. A pilot on live data from your own buildings, with pass criteria agreed in writing beforehand, tests what an RFP response can only claim: time to live data, fault accuracy, false positive rates, and whether a fault can be taken from alert to a fix verified in the data.
What is closed-loop verification in building analytics?
Closed-loop verification means a platform confirms in the building data that a fault has actually been fixed, rather than treating a closed work order as proof. It also keeps monitoring after closure, so faults that return, such as overrides reapplied or schedules reverted, are raised again. It is the main difference between detecting faults and delivering savings.
Do I need Project Haystack or Brick tagging before issuing an RFP?
No. Haystack tagging and the Brick Schema make commissioning faster, but analytics platforms map raw BMS points to their own normalised model regardless. It is more important to provide an accurate BMS inventory, including vendors, versions and protocols, and to ask each vendor how its point mapping is automated and reviewed.
.avif)
Unlock the power of building analytics. Discover how data-driven insights can optimize building performance, reduce costs, and improve sustainability.
A sceptical engineering team put PEAK to the test during their first training session, and confirmed a live £25,053-a-year chilled water valve fault within 98 minutes.
Read the story →
