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, 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 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 |
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.
- Every question answered yes, with no screenshots, documents or examples.
- No median deployment time, or an answer of "it depends" with no range.
- No figures on false positives, and no explanation of how alerts clear.
- Savings claims with no baseline, method or distinction between estimated and metered results.
- Fault closure that means a work order was closed, with no check in the data.
- Data export that is restricted, delayed or charged as an extra.
- A pilot declined, or offered only on a demonstration dataset.
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 600+ 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 is a building analytics RFP?
A building analytics RFP (request for proposal) is a formal document an owner or operator issues to compare analytics or fault detection and diagnostics vendors on the same terms. It describes the portfolio and BMS estate, the outcomes wanted, integration, security and service requirements, a pricing template and the method used to score responses.
What questions should I ask a building analytics vendor?
Ask questions that require evidence across nine areas: BMS integration and data, fault detection quality, how fixes are verified, workflow and adoption, savings measurement, security and data ownership, engineering support, commercials, and references. The most revealing ask how false positives are managed, how the platform confirms a fault is actually fixed, and how savings are calculated.
How much does building analytics software cost?
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 →
