plinth
Safety2026-06-10 · 7 min read

Society Gate Intercom App: Replacing Wired Intercom with Phone Approval

P
Plinth
Plinth

The gate intercom, without the wiring

Most societies over fifteen years old have a wired intercom system, and most of those systems are partly dead. Handsets fail one flat at a time, the cabling in a wing gets cut during a renovation, the exchange is out of production and spares come from a grey market. Nobody wants to spend six lakhs replacing it, so the gate ends up running on the guard's personal phone and a paper list of resident numbers.

That workaround has real costs. The guard's number is not the society's, so the call history leaves when the guard does. Residents screen unknown numbers. There is no record of who was asked about which visitor. And a resident who is at work simply cannot be reached at the gate at all.

An app-based intercom moves the call onto the network the society already pays for. This page covers how it works, what it genuinely improves, and — importantly — what it does not solve.

How an app intercom call works

The flow is deliberately close to the old one, because guards should not need retraining:

  1. A visitor arrives. The guard finds the flat in the app and places a call.
  2. The resident's phone rings with a notification identifying the society, the gate, and the visitor.
  3. The resident answers, sees or hears who is at the gate, and approves or denies entry.
  4. The decision is recorded against the visitor entry, with a timestamp and who made it.
  5. The guard sees the outcome on their screen and admits or turns away the visitor.

The call itself is peer-to-peer audio (or video, where the gate device supports it), which is why it works without any cabling between the gate and the flat.

The states that matter

A wired intercom has two outcomes: someone picks up, or it rings out. An app intercom distinguishes more, and the distinctions are operationally useful:

StateWhat it means at the gate
RingingResident's device received the call and is alerting
ConnectedTalking
DeclinedResident actively rejected the call — do not keep trying
MissedRang out with no answer — fall back
FailedCould not reach the device at all: no network, notifications off, logged out

Declined and missed are different signals, and treating them the same is a common design mistake. A declined call means the resident made a decision. A missed call means you have not reached them yet. A failed call means the resident may not even know the system exists on their phone anymore — that is a maintenance problem the committee should be able to see.

The fallback rule is the whole feature

Every society that deploys an app intercom eventually discovers that the important question is not "how does the call work" but "what happens when it does not."

Residents are in meetings. Phones are on silent. The elderly resident on the fourth floor has not opened the app since it was installed. If your process has no defined answer for the unanswered call, the guard invents one — and the invented answer is usually "let them in," which defeats the purpose.

Write the ladder down and brief the gate on it:

  1. App call to the primary resident.
  2. If missed or failed, app call to the second registered occupant.
  3. If still unanswered, a normal phone call to the flat's registered mobile.
  4. If still unanswered: the visitor waits. Deliveries are held at the gate. Unexpected visitors are not admitted. Expected visitors with a pre-approved pass are admitted per the pass.
  5. Log the outcome regardless.

Step 4 is the one committees flinch from, and it is the one that determines whether the gate means anything.

Where an app intercom genuinely wins

  • Reachability away from home. The single biggest gain. A resident at the office can approve a courier or turn away a salesman.
  • A record. Every call and decision is attached to the visitor entry. When there is a dispute about who let someone in, there is an answer.
  • No per-flat hardware. New flats and new tenants are added by adding a person, not by pulling cable.
  • The guard's personal number stays personal. Staff turnover no longer takes the call history with it.
  • Multiple recipients. Both spouses can be rung, rather than whichever handset is in the hall.

Where it does not, and be honest about this

  • It depends on the resident's phone and data. Wired intercom worked in a power cut on its own battery backup. Do not remove the last physical fallback until you are confident.
  • Notification permissions decay. Phone upgrades, battery-optimisation settings and app updates silently break delivery. Expect to re-check periodically.
  • Older residents. Some will not use it. Keep a phone-call path for those flats permanently, and do not treat it as a failure.
  • Gate network coverage. If the gate has weak signal, put a dedicated connection there. Calls failing at the gate destroys trust in the system within a week.
  • It is not a door-release system. Approving a call is a decision, not a lock opening, unless you have separately integrated an access controller.

Rolling it out

Run the app intercom in parallel with whatever you have for at least a month. Instrument it: what share of calls connect, what share are missed, what share fail outright.

A connect rate below about 70% in month one usually points to notification permissions rather than the software, and it is fixable — a short helpdesk session at the society office where residents hand over their phone for two minutes will do more than three reminder notices.

Only once the connect rate is stable should you consider retiring the wired handsets, and even then keep a written phone-call fallback for the flats that need it.

How this works on Plinth

The guard places a call to a flat from the gate screen. The resident receives it on their device, and the call moves through explicit states — ringing, connected, ended — or resolves as declined, missed or failed, so the gate always knows where it stands rather than guessing.

The call is set up peer-to-peer, so audio and video do not route through a server, and the call record attaches to the visitor entry it was raised for. Calls are scoped to your society, and the outcome is recorded whether or not the resident answered — which means the committee can see the connect rate rather than relying on impressions.

Frequently asked questions

Do we have to remove our existing intercom? No, and you should not immediately. Run both until the app's connect rate is proven. The wired system is your power-cut fallback.

Does it work without internet at the flat? The resident's device needs a connection — mobile data or Wi-Fi. Where there is neither, the fallback is a normal phone call, which is why the ladder above matters.

Can the guard see resident phone numbers? They do not need to. The point of calling in-app is that the guard reaches the flat without holding a list of personal numbers. Keep numbers restricted to the roles that genuinely require them.

What about video — can the resident see the visitor? Where the gate device has a camera, yes. Audio-only still covers the majority of cases, and it is far more tolerant of a weak connection at the gate.

Is the conversation recorded? The call metadata — who called, which flat, when, and the outcome — is recorded. Recording the audio itself raises consent obligations; do not enable it casually.

Step-by-step guides


Related: visitor gate management · Emergency SOS panic button · household help gate access

Get Plinth in your inbox

Monthly digest of governance tips and product updates.