Move-in, move-out and the administration nobody plans for

A smart building in a care setting is not a project that finishes. Residents arrive and leave, staff turn over, care needs change, and every one of those events has technical consequences. The buildings where this works are not the ones with the best hardware; they are the ones where somebody owns the administrative process.

This is the least interesting article in this category and quite possibly the most important, because it is the part that determines whether the system is still trustworthy in three years.

Move-in: what has to happen

A new resident needs a working, appropriately configured apartment on day one, and the temptation is to hand over a standard setup and adjust later. Later rarely arrives.

Before they move in

• Reset the apartment to the standard configuration and confirm every device reports. This is also the moment to replace batteries rather than discovering a flat sensor in month two.
• Clear the previous resident's data and settings entirely. Thresholds tuned to someone else are worse than defaults.
• Check the physical basics: bed sensor positioned for the actual bed, call buttons reachable, night lighting aimed at the real route to the bathroom.

On arrival

• Show them what they control, in the apartment, physically. Not a leaflet. Lights, heating, blinds, call button.
• Explain what is sensed and what is not, plainly, and record what they have agreed to.
• Set the monitoring layer to observe only for the first month, generating no alerts, while the pattern establishes.
• Record who the alert contacts are, including family, and what each is contacted about.

After a month

• Set thresholds from the observed data, with the resident and with night staff.
• Review with them whether anything feels intrusive, and remove it if so.

Move-out: the step that gets skipped

Offboarding is where risk accumulates, because nothing visibly breaks when it is done badly.

• Revoke access credentials immediately — the resident's, and any family member or carer who was given app access or a door code.
• Remove family alert contacts. Otherwise a relative continues receiving notifications about a stranger's apartment, which is a data breach as well as distressing.
• Delete or archive the resident's data according to your retention policy, and record that you did.
• Reset device configuration to standard, including thresholds and any automations they asked for.
• Suspend monitoring on the empty apartment, or it will generate alarming silence and train staff to ignore it.

Staff onboarding and offboarding

Care work has high turnover, and access rots faster than anyone expects.

Route by role, not by person. Alerts go to whoever holds the night duty phone; app access is granted to a role account with individual logins. Then a leaver is one deactivation rather than a search through fourteen systems.

Train on the exception, not the interface. Staff do not need to know how to configure a sensor. They need to know what each alert means, what response is expected, and how to acknowledge it. A one-page reference beside the duty phone is worth more than an afternoon's training.

Add system access to the standard leaver checklist, next to keys and the door fob. If it is a separate process it will not happen.

Changing care needs

The most useful thing a review can do is remove things. Monitoring accumulates, because adding is easy and nobody is responsible for taking away. A resident whose mobility has improved may no longer need the night-time rule that fires twice a week.

Conversely, a deterioration is the moment to revisit consent as well as configuration. If capacity has changed, so has the legal basis for monitoring, and that needs the organisation's formal process rather than a settings change. We cover the principle in consent, dignity and who sees the data.

A short quarterly review per resident — what is monitored, what has fired, what led to action, what can be removed — keeps this honest and takes minutes.

Maintenance that actually gets done

Battery devices fail silently, which in this context is the worst possible failure mode.

Alert on silence. Any sensor that has not reported for twenty-four hours generates a maintenance ticket. This is non-negotiable in a care setting.

Batch battery replacement. Replacing every sensor battery in an apartment annually, on a schedule, is cheaper and far more reliable than responding to individual low-battery warnings. Note which devices take unusual cells and keep stock.

Keep a device register. What is installed, where, what battery, when last replaced, what firmware. Unglamorous, and the difference between a maintainable building and a mystery.

Own the firmware question. Decide whether updates are automatic or scheduled. Automatic is usually right for security, but it means occasional unexpected behaviour changes, so know when they happen.

Who owns this?

The honest answer in most small providers is nobody, which is why the checklists above are the ones that lapse. It does not need a technical person and it does not need a full-time role. It needs a named individual — usually a registered manager or a senior support worker — who holds the device register, runs the quarterly reviews, and signs the move-out checklist.

Two arrangements work in practice. In a single building, fold it into an existing coordinator role with an hour a month allocated and written into the job description, because unwritten responsibilities are the first thing dropped in a busy week. Across several buildings, it is usually worth one person holding it centrally, visiting each site quarterly, and maintaining one register rather than five inconsistent ones.

What does not work is leaving it with whoever installed the system, particularly if that was a contractor or an enthusiastic staff member who has since left. Institutional knowledge held by one departed individual is the most common reason a functioning system quietly becomes an unmaintained one.

Documentation to hold, for the regulator and for yourselves

• What is installed in each apartment, and what each device does.
• What each resident has consented to, when, and on what basis where capacity is in question.
• The escalation map: alert type, recipient role, timing, and where it terminates.
• Records of escalation tests, including overnight ones.
• Data retention periods, and evidence of deletion on schedule.
• Who has access to what, and the leaver process that removes it.

An inspector asking about assistive technology will ask for most of that. Having it written before the question arrives is considerably easier than assembling it afterwards.

The minimum viable process

If you do nothing else, do these four things.

1. A move-in checklist that includes reset, consent recording and a month of observation before alerts.
2. A move-out checklist that includes credential revocation and removal of family alert contacts, signed by a named person.
3. Alert on any sensor silent for twenty-four hours.
4. A quarterly per-resident review whose default question is what can be removed.

None of that requires software, budget or a supplier. It requires one person whose job it is, which is the resource that this kind of project most often lacks.