When the Doorbell Becomes a Door: Engineering IP Intercoms for UK Multi-Tenant Schemes
Photo: IP video intercom panel at entrance of modern UK apartment building, via simitech.in
When a visitor presses the call button at a UK apartment block, the expectation is simple: a handset rings, a door releases and the visitor walks in. Behind that moment sits a chain of SIP registrations, network address translation, lock power, fire-alarm interfaces and building-management permissions. For trade buyers, the practical lesson is that an IP video intercom is no longer a doorbell accessory. It is an access-control integration project with a user interface.
Start with the call path, not the panel
The specification often begins with screen size, camera resolution and finish. Those choices matter, but they are secondary to the call path. If the intercom cannot reach the right handset, the right concierge position or the right mobile device, the installation will be judged on call-fail, not on image quality.
Most IP intercoms use SIP, but SIP is a protocol, not a routing plan. The tender should define the registrar or proxy, the tenant handset profile, the concierge softphone or desk phone, and any mobile-app destination. It should also state what happens when the primary route is unavailable. A call that hunts to a second destination after eight seconds is a different product from a call that simply fails.
Useful questions at design stage include: does each apartment have a primary and backup destination; are calls to the concierge desk queued or hunted; what happens if the building broadband or SIP registrar fails; is there a local fallback for door release; and are codec, DTMF and early-media behaviour compatible across the chosen devices. For UK mixed-use schemes, the same panel may need to serve residential tenants, office occupiers and a concierge team with different hours. The routing table should reflect that reality before hardware is ordered.
Lock logic: fail-safe, fail-secure and the fire strategy
The door-release circuit is where intercom projects most often become access-control disputes. A relay that releases a maglock is not automatically a compliant door release. The building fire strategy, the door's role as an escape route and the lock type all need to be agreed before commissioning.
Fail-safe locks unlock on power loss. They are commonly used on escape doors because a power failure should not trap occupants. Fail-secure locks remain locked on power loss and are used where security is the priority, but they need an emergency release, break-glass or fire-alarm interface. The intercom should not be the only release mechanism. In most UK multi-tenant buildings, the intercom should signal an access-control controller or door controller rather than switch a lock directly.
The lock-fail checklist should cover: which doors are escape doors and what the fire strategy requires; whether the lock is fail-safe or fail-secure; what happens on mains failure and whether a UPS is fitted; whether the intercom relay is switching the lock or signalling a controller; whether there is a break-glass or emergency release; and whether the release has been tested with the fire alarm. A monitored power supply is not a luxury; it is the difference between a controlled release and an unexplained one.
Segregate the network and document the cyber hygiene
IP intercoms are networked devices with firmware, credentials and, often, remote access. They should not sit on the same flat network as tenant Wi-Fi or office PCs. A dedicated VLAN, controlled firewall rules and documented DHCP reservations reduce both cyber risk and troubleshooting time. Where the intercom uses a mobile app or cloud service, the route out should be intentional, not an accidental any-to-any rule.
For trade buyers, the tender should ask for the network design, the firmware support period, unique credentials, certificate handling and a patching route. Quality of service matters for video calls, but so does time synchronisation, because call logs and event records are only useful if the timestamps are consistent.
Concierge handover: the operational handshake
Many intercom disputes are not technical faults. They are handover failures. A concierge team changes shift, a tenant moves out, a managing agent changes the call group, or a mobile app remains active on a former resident's phone. The system may be working exactly as configured, but the building's operations have moved on.
The handover checklist should identify who updates tenant names and call groups, under what service level, and how changes are authorised. It should also cover visitor call records and retention, mobile-app credential revocation, building-specific as-built documentation and an administration guide. The concierge team should test daytime, nighttime and overflow call handling, not just a single call to reception.
Commissioning proof, not assumption
Commissioning should be a test matrix, not a walk-through. Test each apartment handset, each entrance panel, each door release, each concierge position and each fallback route. Simulate a network failure, a power failure and a fire-alarm release. Record the results and hand them over with the as-built drawings.
For UK trade buyers, the intercom is part of the building's access-control handshake. Specify the call path, prove the lock logic and plan the operational handover. The panel may be the visible element, but the integration is what keeps the door working.
