Start with the outcomes.
A smart building platform should support an agreed strategy. Start with the experience or operating outcome you want, then define how the application, source systems, permissions and support will work together. Use demonstrations to explore the possibilities and the brief to specify what must be delivered.
Build the evaluation around your building. Who will use the information? What should it help them do? Which useful systems are already installed? Who can approve each connection? These questions turn a broad ambition into requirements suppliers can answer.
For an owner considering a refurbishment, the immediate decision may be what to retain and what to fund. For an occupier, it may be how employees and visitors will use the workplace. For an operating team, it may be how to investigate recurring exceptions. These situations need different briefs. Agree the first decisions and the people who can make them before assembling a long feature list.
Describe the experience you want to deliver.
Take room availability. It may sound like a single feature, but it could mean showing reservations, detecting presence, automatically releasing a booking or helping a visitor find the room. Those behaviours depend on different sources and operating rules.
For each use case, name the user, trigger, information and expected result. Include the ordinary exceptions: how should a room appear when its occupancy feed stops, and who is notified when a booking is released? Agree these behaviours before asking suppliers to demonstrate them.
Arrival: an invitation must become the right permission.
A useful scenario follows a visitor from invitation and any parking reservation to reception, the controlled entrance and the meeting room. Identify who approves the visit, which system issues the credential, where it is accepted and when it expires. Include an early arrival, a cancelled meeting and a visitor without a compatible phone. Reception needs an agreed alternative, not simply a failed screen.
Smart Spaces describes visitor pre-registration, invitations, host notifications and physical-access connections . Those advertised functions are relevant starting points. The project still needs confirmation of the chosen access equipment, licences, permissions and exception handling.
Room availability: agree what the screen is actually saying.
A calendar booking, a presence signal and a headcount answer different questions. Decide which source governs a room’s displayed status, when any automatic release is permitted and how delayed information is shown. Smart Spaces lists Outlook calendar integration and connections between room booking and visitor management ; a specific combination should be demonstrated against the client’s room names, rules and source systems.
Resource use: a pattern should lead to an investigation.
Consider electricity demand that remains high after observed occupancy falls. The platform needs aligned timestamps, a known meter boundary, appropriate occupancy coverage and a way to show missing information. The output should help an identified operator investigate schedules or loads. It is not proof of waste or savings. The same discipline applies to water exceptions and indoor conditions: define the question, the information and the person responsible for the next action.
Map the complete service.
Workplace applications may combine access, visitor and booking functions. Building integration technologies may connect controls and other systems. Those capabilities occupy different layers, even where a supplier offers several together.
Map the service from source to destination: identity provider, application, integration service, network and field system. For each connection, record the owner, supplier, permissions, licences and support responsibility. Ask suppliers to confirm how their advertised integrations will work within that arrangement.
Distinguish four roles in the proposed arrangement.
- The workplace application presents services to people: finding a room, inviting a visitor, opening an authorised entrance or reporting an issue.
- The building platform brings selected information and workflows together for the agreed audiences. Its value depends on the systems it can actually reach and the actions its users are allowed to take.
- The integration layer connects sources and destinations, translating identifiers, units and status where necessary. It may include gateways, software connectors and integration controllers.
- The building management and specialist systems perform their appointed operational roles. A new screen does not, by itself, replace the controls, access system or specialist responsibilities beneath it.
These roles may be delivered by one supplier or several; map the responsibilities before choosing products. Smart Spaces’ workplace offering illustrates the user-facing services, while its Smart Building OS description covers a cloud platform interfacing with building systems. Separately, Tridium identifies JACE as a hardware platform for Niagara . A JACE is therefore an integration/control component to evaluate where relevant, rather than another name for a workplace app or a requirement for every project.
Asset identities, shared definitions and message formats also need an agreed approach. Our comparison of Brick, Haystack and Digital Buildings explains how model selection connects to naming, points schedules and the delivered information.
Ask what “connected” means for this project.
Write an interface requirement that someone can demonstrate. Name the source and destination, the exact information exchanged, its direction, update frequency and permissions. Distinguish reading a value from changing a setting. Record who maintains the room or asset identifiers and how the receiving service behaves when a source stops reporting.
An open protocol is valuable evidence, but it is not a complete integration brief. BACnet International explains that BACnet systems still require configuration and that a device’s PICS records its supported capabilities . Request the relevant capabilities and the exact model/version, alongside its BTL product listing or certification . Product testing supports a selection; it does not demonstrate the project’s finished workflow.
The boundary matters in access control too. SIA describes OSDP as communication between access-control panels and peripheral devices such as readers . It is not the phone-to-reader credential itself or the platform’s application interface. Ask the security specialist to confirm the whole credential and permission path, including the specified use of Secure Channel where applicable.
For Niagara, identify the required driver, its supplier, supported versions and maintenance arrangements. Tridium explicitly notes that it has not tested all third-party Niagara drivers and does not certify their conformance . A marketplace listing should therefore lead to relevant evidence, not an assumption that any two installed systems will work together.
Agree ownership, security and privacy early.
Assign a client decision owner and an operating owner for each use case. Then agree who provides the source-system access, connector, network permission, mapping, test evidence and ongoing support. An interface assigned to “others” is an unresolved dependency until the other party accepts it. In a multi-tenant building, distinguish landlord, occupier and shared-service responsibilities.
Bring the authorised IT, cyber-security and specialist system teams into the brief before procurement. NCSC guidance calls for documented OT connections, their business need and dependencies . A useful project record identifies approved data flows and keeps viewing information distinct from issuing control commands. Good Buildings can help clarify the requirements and decisions alongside the appointed specialists. Engineering and security design remain with the responsible teams.
For a cloud service, ask how users and service identities are authenticated, how permissions change when someone leaves, and who can recover administrative access. These questions follow the NCSC’s identity and authentication principle . Agree who owns credentials and renewals rather than leaving them tied to an installer’s personal account.
Where information relates to identifiable people, involve the client’s privacy lead. ICO guidance on monitoring workers addresses purpose, transparency, lawful basis and impact assessment. Do not assume that a supplier’s compliance statement settles the client’s use of access or occupancy information. Establish whether aggregated or non-identifying information can answer the question, who can see the records and how long they are needed.
Compare delivery and lifetime commitments.
Give suppliers the same outcome-led specification and ask them to price an equivalent scope. Include source-system access, mapping, configuration, testing, subscriptions, support and future change. Make exclusions visible so the client can compare the complete commitment.
CBRE’s European Office Occupier Sentiment Survey 2026 identifies a gap between occupiers’ ambitions for better workplaces and the capital committed to transforming them. For a platform brief, the practical response is to separate essential requirements from later enhancements. Show the cost, dependencies and operating commitment of each phase so the client can choose a service it can fund and sustain.
Choose an arrangement the operating team can sustain. A configurable system needs the skills to maintain it; a hosted service brings connectivity and subscription commitments. Assess those trade-offs against the building, the team and the intended service.
Use a common comparison period and record the basis of each allowance. Check what increases with the number of sites, users, devices, data points or transactions. Include connectivity, connector licences, implementation, training, software maintenance and replacements where relevant. Separate confirmed quotations from estimates and exclusions. A useful comparison makes the uncertainty visible, including work still required from incumbent suppliers.
Demonstrate the agreed requirements.
Build the demonstration around the agreed scenario. Record the product versions, sources and configuration, then show the expected result, a relevant exception and the information available to the operator. This gives the client evidence against the specification.
Where a pilot is justified, agree what would support a decision to proceed. Record coverage, operating conditions and limitations. A successful room pilot may establish a useful fact without proving that every floor or tenant can be deployed in the same way.
Agree the evidence before the test: the requirement being checked, the result expected, who witnesses it and what constitutes a pass. Include delayed or missing data, loss of connectivity, a revoked permission and restoration of service where relevant. Record what continued locally, what stopped, which notification appeared and who could investigate. Specialist teams should determine and approve any test affecting security, controls or building operation.
Prepare for support and future change.
Agree how an operator reports an incident and who investigates a fault spanning several suppliers. Distinguish response time from restoration time. Ask which party monitors connections, maintains software and certificates, communicates changes and supports the service outside normal hours. Record supported versions and the notice given before a component reaches the end of support.
Discuss exit while there is still a choice. What information and configuration can the client retrieve, in which documented formats and at what cost? Who can administer the system if the original supplier changes? Ask about the transition period, assistance, retained records and secure deletion. Exporting a spreadsheet may preserve historical values without preserving workflows or making another platform a straightforward replacement.
These questions should produce a practical handover and service schedule, not just an assurance that the platform is “open”. Where an answer is commercially sensitive or unconfirmed, record the condition in the decision rather than silently treating it as included.
Test the exit while the project is still choosing. If the supplier were unavailable in five years, which records, configuration and operating knowledge would the client still control? Ask for an example export and have the receiving team read it. A successful export demonstrates retrieval; the contract still needs to establish the client’s rights.
The UK Government’s Technology Code of Practice brings user needs, integration and purchasing strategy into the same technology decision. Apply that discipline to the platform review: have the operating, technical and commercial teams described the same service, including its support and eventual replacement?
Leave with a decision record.
Present a clear recommendation: the preferred option, its connection to the strategy, the alternatives considered and the supporting evidence. Name the next decision owner, outstanding conditions and commitments needed from other parties.
Carry the decision record into procurement, delivery and change control. It should explain why the platform was selected, how its requirements will be checked and how the service will enter everyday use. The strategy remains the reference point as the project develops.
For Good Buildings, that is the advisory contribution: a clear brief, comparable options, explicit dependencies and evidence that supports the client’s next decision. The scope can then follow the relevant stages of the engagement framework , alongside the appointed designers, integrators, installers and operators. The client should be able to explain both why an option was selected and what remains to be resolved before it can work as intended.
Sources and further reading.
- CBRE — European Office Occupier Sentiment Survey 2026. European occupier research on workplace ambitions, investment constraints and portfolio priorities; context for sequencing a funded technology brief.
- Government Digital Service — the Technology Code of Practice. A cross-government buying framework connecting user needs, integration, open standards, security and purchasing strategy. Its lifecycle questions are relevant when preparing a building-platform brief.
- Smart Spaces — workplace application services and Smart Building OS — building-system integration and information .
- Smart Spaces — visitor invitations, notifications and access connections ; meeting-room booking and calendar integration .
- Tridium — the role of the JACE controller ; Niagara drivers and third-party testing limitations .
- BACnet International — configuration, supported capabilities and the PICS ; independent BTL product testing and certification .
- Security Industry Association — OSDP’s reader-to-panel role and Secure Channel .
- NCSC — documenting operational-technology connectivity and dependencies ; cloud identity, authentication and credential lifecycles .
- ICO — data protection and monitoring workers . The ICO marks this guidance as under review following the Data (Use and Access) Act; check the current guidance and obtain advice for the proposed processing and jurisdiction.