Tenant turnover, records and who owns the administrator account

A managed building accumulates technology the way it accumulates paperwork: gradually, from several sources, with no single person holding the whole picture. Five years after the first sensor was fitted, the common state of affairs is a system that half works, credentials nobody can account for, and an installer who has moved on.

This final article is about the unglamorous administration that determines whether any of the preceding six articles still deliver value in five years. It is the part that costs least and is skipped most.

The register: what exists and where

Start here, because everything else depends on it. For each building, record:

• Every device — what it is, where it is, what it does, what battery it takes, when that was last changed, what firmware it runs.
• Every credential — which fob or code, issued to which apartment and named person, on what date, and whether it has been revoked.
• Every system — supplier, contract, renewal date, support arrangement, and who holds the administrator account.
• Every network detail — where the hub is, what it is connected to, what the addresses are.

A spreadsheet is entirely sufficient. What matters is that it exists, is kept current, and is stored where the next person will find it rather than on one employee's laptop.

Tenant turnover, which is the recurring event

Turnover is the routine moment when a managed building's technical hygiene is either maintained or degraded.

At tenancy end

• Revoke every credential issued to the outgoing household, including any given to a cleaner or family member at their request.
• Remove them from any alert or notification list. Otherwise a former tenant continues receiving alerts about a stranger's flat, which is a data breach.
• Reset in-apartment devices to standard configuration and clear personal settings and history.
• Handle their data according to your retention policy, and record that you did.
• Read and record meters.

At tenancy start

• Issue credentials against the register, recording who received what.
• Check every device in the flat reports, and replace batteries rather than discovering a flat sensor in month three.
• Explain what exists and what it measures, in writing, as part of the tenancy pack.
• Give them access to their own consumption data if you provide it.

Both lists belong on the standard checklist that somebody signs, not in anybody's memory. The single most common failure in managed buildings is credentials outliving the tenancy they belonged to.

Maintenance that survives staff changes

Alert on silence. Any device that has not reported for twenty-four hours generates a maintenance item. Without this, a system degrades invisibly and everybody assumes it is fine because nothing is alarming.

Batch battery replacement annually rather than responding to individual warnings. Cheaper, more reliable, and it fits a planned visit.

Decide the firmware policy. Automatic updates are usually right for security; they occasionally change behaviour, so know when they happen.

Test what matters, on a schedule, and record it. Leak sensors physically with a damp cloth. Escalation paths by triggering them deliberately, including out of hours. Emergency lighting per your regulatory obligation. The records are what turn a claim of diligence into evidence of it.

Data protection, in practical terms

A managed building holds personal data about residents through access logs, consumption data and sometimes cameras. A few decisions cover most of the obligation.

Write down what you collect and why, in one page per system. This is both a legal expectation and genuinely useful internally.

Set retention periods and delete on schedule. Indefinite retention is the default behaviour of most systems and the wrong answer.

Restrict access to named individuals with a business need, and remove it when they leave. Offboarding staff from building systems belongs on the HR leaver checklist.

Publish a resident-facing notice explaining what is recorded, for what purpose, how long it is kept and how to ask about it. Transparency prevents most of the suspicion that otherwise attaches to building technology.

Be ready for a subject access request. A resident is entitled to ask what data you hold about them. Knowing in advance how you would answer for each system is considerably easier than working it out under a deadline.

Avoiding supplier lock-in

Buildings outlive suppliers, and a managed portfolio changes agent. Four questions to settle before signing anything.

Who owns the hardware at the end of the contract, and does it keep working?

Can you export the data, in what format, including history?

Is the hardware proprietary, and can a discontinued sensor be replaced with a standard equivalent?

Who holds the administrator account? It must be the organisation, not an individual and not the installer. This one catches people out constantly: an installer who set everything up under their own account and has since ceased trading leaves a building with equipment nobody can administer.

Standardising across a portfolio

For anyone managing several buildings, standardisation is worth more than optimising any single site.

One product per function across the portfolio. Staff learn one system, spares are interchangeable, and a problem solved once is solved everywhere.

One register format, so a colleague covering another building can find what they need.

One escalation model with the same tiers and the same acknowledgement expectations.

Central rather than per-building administration where the systems allow it, because per-building administration is what fails when someone is on holiday.

The temptation is to buy the best available product for each new building. The result after five years is six systems, no institutional knowledge, and a staff member who can only cover their own site.

Handover between agents

The moment a managed building changes agent is when technical knowledge is most often lost entirely, and it is worth preparing for even when no change is contemplated.

A handover pack should contain the register, every administrator credential transferred to the new organisation rather than shared, all supplier contracts with renewal dates, the resident-facing data notice, and the test records. Where an outgoing agent cannot produce these, the incoming agent’s first task is reconstruction — which in practice means re-surveying the building and re-issuing credentials, at real cost to residents.

Being the agent who can hand over cleanly is also a commercial advantage worth having, and it is a direct consequence of keeping the register current rather than a separate exercise.

Naming an owner

Everything above requires one person whose job includes it. Not a technical specialist — a named role with an hour or two a month written into their responsibilities, holding the register, running the checks, and signing the turnover checklists.

Where that does not exist, systems degrade quietly regardless of how well they were specified. Where it does, quite ordinary equipment stays useful for a decade. Of everything across these six articles, that is the single most reliable predictor of whether a building's technology is still working in five years.

A minimum viable administration

1. Build the register — devices, credentials, systems, accounts.
2. Add credential revocation and device reset to the tenancy-end checklist, signed.
3. Turn on silence alerts for every device.
4. Schedule annual battery replacement and testing, with records.
5. Write the one-page data notice for residents and the internal record of what you hold.
6. Confirm the organisation holds every administrator account.
7. Name the owner, with time allocated in writing.

None of it requires budget, procurement or a supplier. It requires somebody deciding it matters, which is why it is both the cheapest item in this category and the one most often missing.