.png)
Amazon Mapped 26 Operational Functions Before Deploying FDD to Prevent Analytics from Overwhelming Site Teams
Amazon's smart building team decided to map every operational task required to run an FDD program before deploying analytics across its portfolio.
Kelly Burke, a Smart Building Consultant at JLL supporting Amazon, said the team documented 26 operational functions needed to operate the program—spanning data integration, rule validation, ticket creation, prioritization, and engineering coordination.
This function mapping addressed a common failure pattern in FDD deployments: too many alerts and no clear process for acting on them.
"Sometimes we're over-relying on tools like AI insights and plug-and-play rules," Burke said. "It ends up being a dashboard with a thousand alerts."
Amazon's portfolio—more than 500 buildings across different geographies, BMS systems, and ownership models—made that risk more acute.
Instead of building a new organization around the pilot, the team condensed those 26 functions into a smaller set of operational workflows designed to fit existing site-team SOPs. Vendors handled data integration, rule validation, and fault prioritization, while site engineers focused on what they do best, resolving field issues.
The approach allowed Amazon to launch a three-month FDD pilot across three representative buildings without overwhelming already-busy site teams.
Two sites, running a SkySpark FDD pilot, ultimately yielded 219 resolved faults and about 18% energy savings, validating the workflow model despite one site having unusable BMS data.
For operators considering a condition-based maintenance playbook, Amazon's pilot provides a prime example of the importance of establishing CBM roles & responsibilities early in the process.
If engineers don't have a clear path from alert to remediation, the insights rarely translate into fixes.
Register for the next Nexus Labs event
Sign up for the newsletter to get 5 stories like this per week:
Amazon's smart building team decided to map every operational task required to run an FDD program before deploying analytics across its portfolio.
Kelly Burke, a Smart Building Consultant at JLL supporting Amazon, said the team documented 26 operational functions needed to operate the program—spanning data integration, rule validation, ticket creation, prioritization, and engineering coordination.
This function mapping addressed a common failure pattern in FDD deployments: too many alerts and no clear process for acting on them.
"Sometimes we're over-relying on tools like AI insights and plug-and-play rules," Burke said. "It ends up being a dashboard with a thousand alerts."
Amazon's portfolio—more than 500 buildings across different geographies, BMS systems, and ownership models—made that risk more acute.
Instead of building a new organization around the pilot, the team condensed those 26 functions into a smaller set of operational workflows designed to fit existing site-team SOPs. Vendors handled data integration, rule validation, and fault prioritization, while site engineers focused on what they do best, resolving field issues.
The approach allowed Amazon to launch a three-month FDD pilot across three representative buildings without overwhelming already-busy site teams.
Two sites, running a SkySpark FDD pilot, ultimately yielded 219 resolved faults and about 18% energy savings, validating the workflow model despite one site having unusable BMS data.
For operators considering a condition-based maintenance playbook, Amazon's pilot provides a prime example of the importance of establishing CBM roles & responsibilities early in the process.
If engineers don't have a clear path from alert to remediation, the insights rarely translate into fixes.
Register for the next Nexus Labs event
Sign up for the newsletter to get 5 stories like this per week:
This is a great piece!
I agree.