PropTech for Facilities Management: A Practical Guide

PropTech for facilities management is useful when information from a building leads to a named action. A tenant request should reach the right queue. A sensor alert should identify an asset and response owner. A completed job should leave a work record that another person can understand later.

PropTech is not one product category. The term covers property portals, maintenance systems, building controls, sensors, energy tools, analytics, and digital twins. Buying several of them does not connect the work by itself. The practical question is: which operational gap are you fixing, and which system owns the resulting record?

Treat selection as an operating-design exercise before treating it as a software comparison. Name the event, the decision, the person responsible, and the record that should remain after the work is complete. That gives facilities, IT, security, finance, and vendors the same scenario to evaluate.

Map each technology to an operational job

Start with the job each category should own. Then define the handoff to the next system. A category name alone says little about where a request lands, who can change its status, or what happens when an integration fails.

Technology	Operational job	Required handoff	Question to ask before buying
Tenant or occupant portal	Capture service requests, contact details, location, and updates visible to the requester	Send an accepted request to the work queue and receive status suitable for the requester	Where does the request go after submission, and which status is returned?
CMMS	Manage asset records, work orders, schedules, assignments, and maintenance history	Accept events from portals, controls, or sensors and return work status where needed	Which record becomes the reference for completed work?
BMS	Monitor and control building equipment through configured points, alarms, and schedules	Expose selected events or values without giving another system unintended control	Which points can other systems read or write, and who approves that access?
IoT platform	Collect device data, assess rules, and report device health	Send qualified events with a device, asset, time, value, and rule reference	Which signals require action rather than storage?
Energy management system	Monitor and analyse metered energy use and system performance	Pass a finding or exception to the person or system that can investigate it	Who reviews findings and creates corrective work?
Digital twin	Maintain a synchronized digital representation for selected analysis or simulation	Receive mapped source data and return a finding tied to known building objects	What decision needs the model, and who keeps it current?
Accounting system	Hold financial entries, budgets, invoices, and approved charges	Receive approved cost references and return the financial reference needed for reconciliation	Which costs return to the work record as references?

Do not make every system responsible for the whole workflow. For each state, name one owner. A portal may own what the requester sees while the CMMS owns work status. A BMS may own control commands while an IoT platform evaluates a separate condition rule. The accounting system may own the approved financial entry while the work record keeps its reference.

A useful boundary statement is short: “The portal owns request intake. The CMMS owns assignment and completion. The portal receives approved status updates.” Write one for every cross-system workflow. Conflicting answers expose a design problem before an integration is built.

The U.S. Department of Energy describes energy management information systems as devices, data services, and software that monitor, analyse, and control metered energy use and system performance. Its EMIS guidance also treats site operations as part of implementation. The tool produces information; people still need a process for acting on it.

Put the operating record before advanced analytics

Facilities teams often have data in several places but no stable link between them. An asset has one identifier in the BMS, another in a spreadsheet, and a third in the maintenance system. Alerts arrive without service history. Completed work does not feed back to the team reviewing equipment performance.

An operating record does not require every field to live in one database. It requires stable identity, clear ownership, and traceable links across the systems involved. An operator should be able to move from the source event to the resulting work and back without searching email or rebuilding a timeline.

Record requirement	What to define	Evidence to request
Site, location, and asset identity	Stable identifiers, naming rules, parent-child relationships, and aliases used by other systems	A sample event resolves to the correct asset without manual re-entry
Source and time	Source system, source event ID, event time, received time, time zone, and original value or request	The original event can be found from the work record and compared with the source
Responsibility	Queue, assignee, contractor, escalation owner, and reassignment history	The record shows who accepted responsibility and when ownership changed
State	Allowed statuses, who can change them, and what each status means	A normal job and a reopened job follow documented state changes
Work evidence	Notes, readings, labour, parts, attachments, cause, and corrective action where relevant	A completed sample gives the next technician enough context to understand the work
Exceptions	Unmatched assets, duplicate events, rejected payloads, offline devices, and failed updates	Exceptions appear in a queue or report with a named owner
History and exit	Change history, retention, export fields, attachments, mappings, and configuration	A sample export can be opened and linked back to the correct assets and work

Use one ordinary example to test the record. A leak sensor reports a threshold event. The event identifies the device and mapped asset. A rule creates or updates work. A person accepts the job, records the inspection, and closes or escalates it. Later, another operator can see the source reading, the rule used, the response, and the final decision. If one of those steps depends on a private spreadsheet or personal inbox, the operating record is incomplete.

Asset management and work order management give sensor and portal events operational context. IoT integration is most useful when a threshold can open or update a job for a known asset, rather than adding another alert dashboard.

Treat digital twins as a specific choice

A digital twin is not a required stage in every PropTech plan. NIST’s building digitization work describes a building digital twin as a synchronized representation supported by machine-readable building data. That definition points to the real work: mapping systems, maintaining identifiers, and keeping the representation current.

Use a digital twin when the intended decision benefits from spatial context, simulation, or a synchronized model. Before procurement, answer five questions:

1. Which decision is difficult with the current asset, drawing, BMS, and work data?
2. Which source systems will keep the model synchronized?
3. How will equipment replacement, point changes, and space changes reach the model?
4. Who investigates missing mappings or stale data?
5. Would a simpler asset view, floor plan, or trend report support the same decision?

Do not use the digital-twin label for a static drawing, a dashboard, or an asset list. If the team cannot name who updates the model after equipment changes, the representation will drift from the building. Procurement should include a sample change, such as replacing a pump or renaming a BMS point, and require the vendor to show how that change reaches the model.

Define the integration contract

An integration needs more than an API checkbox. Write the contract in operational terms before implementation. Facilities and IT should be able to review it without reading vendor code.

Contract item	Questions to settle
Source event	What starts the flow? Is it a submitted request, BMS alarm, threshold held for a set period, or a reviewed finding?
Time and units	Which timestamp is authoritative? Which time zone, unit, precision, and quality flag travel with the value?
Identity mapping	How are site, location, asset, device, person, and contractor identifiers matched? Who resolves an unmatched identifier?
Payload and version	Which fields are required? How are schema changes announced, tested, and accepted?
Destination action	Does the event create work, update existing work, attach evidence, or notify a reviewer? What prevents duplicate work?
Authority	Which system may change priority, assignment, status, completion, or a control value? Which changes are one-way only?
Delivery	How are retries, duplicates, delayed messages, and out-of-order events handled? Can a failed event be replayed safely?
Acknowledgement	Does “accepted” mean the destination stored the event, created work, or completed work? Which status returns to the source?
Failure handling	Where do invalid payloads, offline devices, expired credentials, and destination outages appear? Who receives the exception?
Traceability	Which correlation or source ID links the original event, integration log, work record, and status response?
Access and data protection	How is the connection authenticated? What is each account allowed to read or change? Who rotates or revokes access?
Change and exit	How are connector changes tested? Can the organisation export records, attachments, mappings, and relevant configuration?

ASHRAE Standard 135 defines BACnet as a communication protocol for building automation and control networks. BACnet can support exchange between building systems, but protocol support does not settle data meaning, ownership, or response rules. See the ASHRAE BACnet resources when checking a BMS integration.

Turn the contract into acceptance tests. Run a normal event, a duplicate, an event with no asset match, an event during a destination outage, and a recovered event after service returns. Confirm that no test silently disappears and no retry creates unintended work. Record the expected result and the evidence location for each test.

Include security and lifecycle ownership

Connected devices need an owner after installation. Ask how each device is identified, configured, updated, restricted, monitored, and retired. NIST’s IoT device cybersecurity baseline names device identification, configuration, data protection, interface access, software update, and cybersecurity state awareness as core areas to consider.

Split ownership across the lifecycle instead of assigning “IoT security” to an unnamed team.

Lifecycle stage	Ownership questions	Record to keep
Procurement	Who checks product identity, support period, update method, interfaces, data fields, and vendor responsibilities?	Approved model, intended use, support information, data flow, and named owners
Commissioning	Who registers the device, sets credentials, approves the connection, maps the asset, and verifies time settings?	Inventory entry, configuration reference, network placement, and acceptance result
Operation	Who monitors device health, failed messages, access changes, storage use, and unexpected behaviour?	Health history, access review, exception owner, retention rule, and support contact
Update	Who reviews firmware or software updates, tests compatibility, schedules the change, and handles a failed update?	Version history, test result, maintenance window, and recovery procedure
Incident	Who can isolate the device or integration? Who coordinates facilities, IT, security, and vendor response?	Contact route, containment steps, relevant logs, decisions, and return-to-service approval
Retirement	Who removes access, records the last configuration, handles stored data, updates inventory, and replaces dependent workflows?	Retirement date, revoked accounts or keys, data disposition, and replacement reference

Also record the approved network and connection method, account and credential owner, support end date, logging contact, replacement process, data retention, and access roles for each device class. These checks belong in procurement. A low device price can become expensive when updates, replacement, support, or data export are unclear.

Security review should cover the whole path, not only the sensor. A device may send through a gateway, network service, IoT platform, integration service, and maintenance system. Each boundary introduces accounts, logs, data copies, and failure states that need an owner.

Run one workflow as a pilot

Choose a problem the site team already understands. Examples include repeated after-hours equipment alarms, leak alerts with unclear ownership, or tenant requests that require manual re-entry.

Write the pilot as a testable statement: “At this site, when this event occurs for this asset class, this system will create or update this record. This role will accept responsibility. These fields will prove what happened.” Set the time period, included assets, shifts, and exclusions before configuration begins. Keep existing safety and control procedures in place unless the responsible teams formally approve a change.

Set a baseline before the pilot:

• how the event is detected today
• who receives it
• how long it waits for an owner
• how many events lack an asset match
• how much manual entry is required
• which exceptions remain unresolved and where they are tracked
• what the current workflow costs to operate and support

Set each pass rule from the site’s own baseline, risk, and service expectations. There is no universal acceptable alert rate or response time for every building and asset class.

Scorecard area	What to record	Pass rule to define before the pilot
Event coverage	Expected events, received events, missing events, and unexpected events	Which events must be captured, and how will missing events be found?
Asset match	Automatic matches, unmatched events, incorrect matches, and time spent correcting them	Which assets must resolve automatically, and what exception rate can the team support?
Alert quality	Actionable alerts, duplicates, false alerts, and alerts closed without action	What evidence makes an alert useful enough to create work or request review?
Action ownership	Time to acceptance, unassigned work, reassignments, and escalations	Which role accepts each event type, and when does an unaccepted event escalate?
Record quality	Source link, notes, readings, action, completion, and returned status	Which fields and attachments must be present for a job to count as complete?
Operator effort	Manual entries, system switches, corrections, training needs, and workarounds	Which steps should disappear, and which new steps are acceptable?
Failure recovery	Offline periods, queued events, retries, duplicates, and reconciliation work	What must happen during an outage and after service returns?
Lifecycle readiness	Named owners for support, access, updates, incidents, and retirement	Which documents, owners, and support routes must exist before wider use?
Ongoing cost	Software, devices, connectivity, storage, integration, support, and staff time	Which recurring costs are approved, and which changes would require a new decision?

Review each area as pass, conditional, or fail, and attach the evidence. A conditional result needs an owner, correction, and review date. A fail means the workflow does not move to wider use until the issue is resolved or the scope changes.

Then test the complete chain: event received, asset matched, work opened, owner assigned, action recorded, and status returned where needed. Track false alerts, missing events, duplicates, and operator workarounds as carefully as successful events. A dashboard that looks active but does not change a work process is not a successful pilot.

Compare vendors against the same scenario

Give each vendor the same normal scenario and failure scenario. Ask them to show the source event, resulting record, operator decision, exception, recovery, and export. Record each answer as demonstrated, documented, planned, or unavailable. A planned item may matter to a roadmap discussion, but it is not a current capability.

Comparison area	Questions for every vendor	Evidence to keep
Workflow	Can you show the full scenario using the roles and asset structure in our scope? Which steps happen outside your product?	Demo notes, screenshots where permitted, and the agreed workflow
Record ownership	Which system owns status, priority, assignment, completion, and history? How are conflicting updates handled?	Field ownership and state-transition document
Failure path	What happens with no asset match, a duplicate, an outage, an expired credential, or a delayed event?	Failure demonstration and recovery steps
Integration	Which interfaces are available for this flow? Who builds, monitors, tests, and updates the connection?	Interface documentation, responsibility split, and test cases
Access and security	Which roles, service accounts, logs, retention settings, and data locations apply to the proposed scope?	Security documentation and answers reviewed by the responsible team
Device lifecycle	Who owns commissioning, health monitoring, updates, support end, replacement, and retirement?	Lifecycle responsibility table and supported-device information
Implementation	Who cleans asset data, maps identifiers, configures rules, trains operators, and signs off acceptance?	Scope, assumptions, exclusions, acceptance plan, and named owners
Reporting and export	Can we export records, attachments, mappings, configuration, and history in usable formats? Which items require vendor assistance?	Sample export from the proposed workflow
Support	Which team handles device, integration, and application incidents? What information is required when opening a case?	Support routes, coverage, dependencies, and escalation process
Commercial scope	Which charges vary by site, user, asset, device, event volume, storage, connector, environment, or support level?	Itemised proposal, renewal terms, and assumptions

Run reference conversations with the same discipline. Ask how identity mapping, exceptions, updates, and exports work in daily operation. Do not ask only whether a customer is satisfied. Ask what their team still owns manually and what changed after the initial implementation.

Use Infodeck pricing to understand quota-based plan scope, then book a demo with your site, asset, integration, and reporting questions. If the workflow does not fit Infodeck, that should be clear during the review.

PropTech should make the work easier to follow

The useful test is not how many technologies a property has. It is whether a facilities manager can follow a request or signal through action, completion, and proof without rebuilding the story from several systems. IT should also be able to identify every connection and owner, while procurement can see the ongoing cost and exit path.

Start with that chain. Add sensors, analytics, or a digital twin when each one has a defined job, owner, and measurable reason to stay.

Related reading

• BMS vs CMMS vs IoT platform
• Smart building readiness checklist
• Building automation and CMMS integration
• IoT-native vs bolt-on CMMS integration
• CMMS vendor selection guide