Smart Building Readiness Checklist for Facility Teams

A smart building is ready for a pilot when a signal can reach a named person, trigger a defined response, and leave a useful work record. Network coverage and sensors matter, but they are only part of the test.

Use this checklist for one use case at one site. A building can be ready for leak detection in a plant room and unready for occupancy analytics across every floor. Readiness is specific to the problem, equipment, data, and team involved.

Score readiness before procurement

Score each area from 0 to 2. This is a local screening aid, not an industry certification or a substitute for technical, safety, security, or privacy approval.

A score of 12 to 14 identifies a candidate for a limited pilot. A score of 8 to 11 means close the named gaps before installation. A score below 8 means the operating design is not ready. A zero in safety, security, privacy, access control, or response ownership is a pause condition regardless of the total. Do not let a strong network score cancel an unresolved security or operating risk.

1. Define the use case and owner

Before choosing devices, write down:

• the problem or decision the pilot addresses
• the equipment, zone, or people affected
• the event that should trigger action
• the person or role that receives the event
• the expected response and escalation path
• the record that shows the issue was reviewed and closed
• the baseline used to judge the pilot

“Install temperature sensors” is not a use case. “Alert the refrigeration technician when a monitored cabinet moves outside its approved range, then record investigation and closure against the asset” is specific enough to test.

Keep the pilot brief to one page. Include scope, exclusions, rule source, response window, after-hours route, dates, and the person who can change or pause the rule. Record how the baseline was collected and whether it covers seasonal load, production cycles, or occupied hours.

Ready: The owner, response, and baseline are named.

Needs work: The team has selected technology but cannot describe who acts on its output.

2. Check asset and work data

A sensor reading needs context. Confirm that each pilot asset has:

• a stable identifier
• site and physical location
• equipment type and model where relevant
• owner or responsible team
• current operating range or rule source
• maintenance history available to the reviewer
• a process for updating the record after replacement or relocation

Do not wait for a perfect asset register. Clean the records needed for the pilot, then document who maintains them. Asset management holds equipment context, while work order management records investigation and corrective work.

Also define the alert record. It should show the source device, asset, reading or event, time, rule, action owner, and final disposition. Free-text notifications without an asset match are difficult to route and compare.

Use a small data dictionary before integration work starts:

Test a sample export before installation. Check duplicate asset IDs, missing locations, mixed units, retired equipment, inconsistent time zones, and unclear device names. Decide which system owns each field when a name, location, or status changes.

Ready: Pilot devices can be mapped to known assets and resulting work can be closed on a named record.

Needs work: Device names, asset names, and maintenance records cannot be matched reliably.

3. Survey connectivity and power at the equipment

Test the proposed device where it will operate. Office Wi-Fi results say little about a basement plant room, roof, riser, cold room, or concrete enclosure.

For each location, record:

• available connection types
• measured signal quality or wired access
• expected transmission interval and data volume
• gateway location and power
• battery access and replacement method
• behaviour during an outage
• time synchronization source
• environmental limits such as heat, water, dust, or vibration

Avoid copying a universal signal threshold or device-per-floor figure. The device vendor, network owner, and site survey should define acceptance criteria for the actual installation.

Create one survey row for every device and gateway location. Record hardware, firmware, mounting position, enclosure, nearby equipment, connection result, power, date, and reviewer. Test with plant running and doors or cabinets in their normal position where practical.

The site survey should also answer four failure questions:

1. Does the device buffer readings when the link is unavailable, and what happens when that buffer fills?
2. Does recovery preserve event order and timestamps, or does it create a new burst with receipt times only?
3. Who is notified when a device or gateway stops reporting, and after what site-approved interval?
4. Can the team replace a battery, gateway, or device without losing the asset mapping and maintenance history?

Record a pass, condition, or fail for each location. Conditions need an owner and due date, such as moving a gateway, adding protected power, changing the enclosure, or selecting another connection method.

Ready: The team has tested the actual locations and documented offline behaviour.

Needs work: Connectivity is assumed from drawings, vendor claims, or tests in a different area.

4. Complete the IoT security review

Connected building devices need lifecycle controls. NIST’s IoT device cybersecurity baseline identifies device identification, configuration, data protection, interface access, software update, and cybersecurity state awareness as core areas to consider.

Ask the vendor and IT owner:

• How is each device uniquely identified?
• Which default services and interfaces can be disabled?
• How are credentials issued, rotated, and revoked?
• How are firmware updates authenticated and delivered?
• How long will the device receive security support?
• What logs or alerts indicate a security problem?
• Can the device be isolated from business networks?
• What is the process for secure removal and disposal?

Do not accept “encrypted” or “secure by design” as a complete answer. Ask which data is protected, where, by which controls, and who operates them.

Build an access register for the pilot. Include every human account, service account, device credential, vendor support path, API key, and gateway administrator account. For each entry, record the owner, permitted actions, approval source, issue date, storage method, logging available, review date, and removal trigger. Shared accounts without an accountable owner make investigation and offboarding harder.

Check remote support separately. Define who can enable it, whether access can be limited by time and scope, what activity is logged, and who reviews that log. Confirm how access is removed when a contractor leaves, a device is replaced, or the support agreement ends. If occupancy, location, image, audio, or identity data is involved, document the approved purpose, retention, access group, and deletion process before collection starts.

Treat end of support as an operating event, not a future procurement detail. The asset record should identify firmware version, support contact, expected support end if the vendor provides one, and the owner who decides whether to update, isolate, replace, or retire the device.

Ready: IT has approved the architecture and named the device, credential, update, and incident owners.

Needs work: No one owns updates, logs, or end-of-support decisions.

5. Test integration and failure handling

A BMS, IoT platform, and CMMS have different responsibilities. ASHRAE Standard 135 defines BACnet as a protocol for communication between building automation and control devices. See the ASHRAE BACnet resources when checking controls integration, but remember that protocol support does not define the operational workflow.

Document:

1. source system and event
2. site and asset identifier mapping
3. rule owner and threshold source
4. destination system and action
5. duplicate-event handling
6. retry and outage behaviour
7. acknowledgment and closure flow
8. export and vendor-exit method

Infodeck IoT integration connects sensor rules with operational workflows. Compare that boundary with the BMS, CMMS, and IoT platform guide before deciding which system should own each step.

Run the same test pack after material changes to firmware, gateways, rules, mappings, or destination systems. A useful minimum set is:

For every test, save the input, expected result, actual result, timestamps, relevant log reference, resulting work record, reviewer, and disposition. A screenshot of a successful alert is not enough to prove retry, deduplication, closure, or recovery.

Ready: The team can trace a test event through assignment, action, and closure, including a failed delivery.

Needs work: The normal demo works, but duplicate, missing, delayed, or unmatched events have no owner.

6. Prepare the operating team

The pilot will create new work even when the technology works correctly. Someone must install devices, review alerts, tune rules, replace batteries, handle exceptions, and explain results.

Confirm:

• operator and supervisor training
• pilot support contact and response window
• time allocated for tuning and review
• change control for thresholds and automations
• contractor access where needed
• privacy review for occupancy, location, image, or identity data
• a process for pausing an unsafe or noisy automation
• a decision date for stop, revise, or expand

Assign one accountable owner and one backup for device inventory, network and gateway health, rule changes, alert triage, work assignment, work closure, security events, vendor support, data review, and device retirement. Use actual names or duty roles in the pilot runbook. “Facilities,” “IT,” or “the vendor” is too broad when an alert arrives after the project meeting has ended.

The runbook should state support hours, handover steps, contact order, manual fallback, escalation time, evidence to retain, and who can suppress a noisy rule. Suppression needs a reason, start time, reviewer, and expiry. Otherwise a temporary workaround can quietly become the permanent operating state.

Review staffing with the supervisors who schedule the work. Estimate alert review, tuning, device checks, exception investigation, and reporting time. Record the assumption, then measure actual operator time.

Ready: Named people have time, access, and authority to operate the pilot.

Needs work: The project assumes normal maintenance staffing will absorb all new tasks.

7. Set pilot acceptance criteria

Use measures tied to the chosen problem. Examples include:

• percentage of expected readings received
• unmatched asset or device events
• false alerts and missed events
• time from alert to named owner
• work orders opened, closed, and left unresolved
• operator time spent reviewing alerts
• device, gateway, or battery failures
• change in the chosen site outcome against baseline

Do not hide poor alert quality behind a savings estimate. A pilot that creates many false alerts may cost more operator time than it saves, even if the dashboard looks active.

Write every threshold as a complete acceptance statement: measure, population, calculation, period, target, evidence, owner, and failure action. “At least [site-approved target] of expected readings arrive during the review period, excluding approved maintenance windows” can be tested.

Use these default governance gates unless the site approves stricter ones:

• every installed pilot device is mapped to one in-scope asset, location, and operating owner
• every planned failure scenario is executed and recorded
• no test event disappears without a visible success, failure, quarantine, or expiry state
• no critical security, privacy, safety, or access finding remains open at acceptance
• every production alert has a named triage route and manual fallback
• rule changes, suppressions, and device replacements are traceable

Set numeric performance thresholds from the site baseline and risk tolerance. That includes expected-reading receipt, false-alert limit, missed-event limit, response time, unresolved work, operator review time, device availability, and the chosen operational outcome. For an alert the site classifies as safety-critical, an unexplained missed test event should pause acceptance until the cause and corrective action are reviewed. These are project decision rules, not a claim that one threshold fits every building.

The U.S. Department of Energy’s energy management information systems resources include procurement and field-evaluation material for building monitoring and diagnostic tools. The useful principle applies beyond energy: define how the technology will be evaluated before rollout.

Decide whether to proceed

Use a simple result for each section:

• Green: owner and evidence are in place
• Amber: gap has an owner and can be closed during the pilot
• Red: no owner, approval, or workable failure path exists

Proceed with a limited pilot when there are no red items affecting safety, security, privacy, data ownership, or response. Do not average a serious red item into a high total score.

Use the score and the evidence together:

The decision record should name who approved it, evidence reviewed, open conditions, expiry date, and next review. A conditional go is not permission for portfolio rollout.

When comparing commercial options, review Infodeck pricing against your site, asset, IoT device, and workflow volume. Book a demo with one normal event and one failure event, and ask to see both through closure.

Readiness means the team can act

The strongest smart building plan is not the one with the most sensors. It is the one where devices have owners, readings have context, alerts have a response path, and failures do not erase the work record.

Fix red items first. Pilot one useful chain. Expand only when the site team can operate it without guesswork.

Related reading

• PropTech for facilities management guide
• Building automation and CMMS integration
• IoT sensors and predictive maintenance
• CMMS data quality and governance
• CMMS vendor selection guide