One Device Per Room: Telling Resident, Family, Carer and Visitor Apart
A care home buys one companion device per room, which sounds like a simple deployment until you watch the room. Over a day that unit is spoken to by the resident, by two or three family members at different hours, by the carer on each shift, and by a physiotherapist, a volunteer or a grandchild on a Sunday. Four kinds of person, one microphone.
Most products on the market treat all of it as one speaker. The consequences are not theoretical — they show up as a memory that belongs to nobody, a permissions model that is either too open or useless, and an incident conversation that cannot be attributed during an inspection.
What collapses when the device cannot tell who is talking
Memory becomes a blend. The daughter asks the robot to remind her mother about a doctor's appointment and the unit files that under the household's general preferences. The resident's own request from Tuesday gets outranked by a visitor's joke. Within a quarter the device is speaking to a composite person who lives in that room.
Authority becomes meaningless. A carer needs to log a shift note, set a reminder and check whether the resident slept. A visitor needs to change nothing. If the device cannot separate them, every control is either open to whoever happens to be in the chair, or locked so tightly that the carer stops using it — which is the failure mode staff will tell you about.
Privacy becomes unauditable. When a family asks what the device recorded about their relative, the honest answer in a blended system is "we cannot separate it". That is the answer that loses a tender.
The four profiles that have to exist
- Resident — the only profile whose preferences and memories persist as that person's record, and whose data governs what the device may say back.
- Family — a named contact with a limited scope: what they may set, what they may see, and what they must not see about other residents or other families.
- Carer — task authority tied to a shift and a role, not a lifetime key to a private conversation. When that person leaves the rota, the access ends and the audit trail keeps their entries.
- Unknown — a first-class state, not an error. Unrecognised voices get shared content, no memory write, and a visible note that the device chose not to guess.
The distinction that matters commercially is between the last two and the first two: identity is an access-control mechanism, not a party trick. Enrolment is also where trust is won or lost — the first time a family member is asked to register and nobody explains where the sample goes, you have created a resident who refuses the device.
Where the hard cases actually are
Separating an older resident from a middle-aged daughter is not difficult; the difficult pairs are two sisters with similar voices visiting on the same afternoon, and a carer whose own conversation with a colleague gets attributed to the resident because both were in the room. Those are the moments a demo never shows and an operator lives with, which is why we insist a pilot runs in the actual rooms rather than in a corridor at an exhibition.
One consequence is architectural rather than acoustic: a device needs to hold the fact that a conversation happened with attribution, and be able to discard the audio entirely, so that storage cost and breach exposure both fall. That is how we approach the companion robot hardware and its provisioning, and why the same reasoning shapes a health ring worn by one resident in a shared flat.
What a purchaser should ask for in writing
- Enrolment consent: who signs for a resident with impaired capacity, and how a withdrawn consent is enforced on the device.
- Role scope: which actions each profile can take, and what a carer cannot read.
- Attribution: every stored item carries who said it and when, exportable per resident.
- Deletion: a person's voice feature and their memories go together, including caches.
Those four are also what an institutional buyer writes into acceptance. They change the hardware choice less than the account design, which is why we treat them as part of the OEM and ODM scope conversation rather than an app feature, alongside the Health & Wellness line that a care programme typically bundles. The document set that supports the radio, substance and battery side of that bundle is on the factory and QC page, and the paperwork an importer should expect before a care tender is itemised in the CE RED checklist. How to judge whether a supplier has actually done any of this is covered in how to vet an AI wearable supplier; the full range sits under products and further reading in the journal.
Questions buyers ask
Why does a care home device need to know who is speaking?
Because a resident, a relative, a carer and a visitor are entitled to different things from the same unit. Without separation the conversation log becomes one anonymous pile, and the operator cannot show what was said to whom.
Do carers have to enrol their voice too?
Yes, and the scope matters: a carer profile grants task authority, not access to a resident's private conversations. Two different things get mixed together in most product designs.
What should the device do with a visitor it does not recognise?
Serve shared content and record nothing against the resident's memory. Guessing an identity is how a care record ends up contaminated.
Does this mean storing recordings of staff and families?
No. The design we build to extracts a non-replayable voice feature on the device and keeps no audio after processing, with deletion of a person's feature and memories handled on request.
Related: more on ai companions · buyer guides · customisation tiers