Context Travels, Not Residents
Expectation. The building shall ensure that when a support request involves multiple parties, handoffs, or stages, the full record travels with the request — so the resident is never the carrier of context.
Required.
- When a request is reassigned or handed off, the receiving party has access to the complete record: original description, images, prior notes, previous resolution attempts, and all communication.
- When a request requires an external contractor or vendor, the scope and history of the request are communicated to them. The resident does not re-describe the issue to each new party.
- When the same issue is reported by multiple residents, all reports are linked to a single resolution record. Each resident sees status updates for the shared issue.
- A recurring issue — the same problem reported and resolved more than once — is identifiable as recurring within the resident's request history.
Recommended.
- When a resident's request relates to a building-wide issue already under resolution, the system links the request to the existing record automatically and informs the resident.
- When a contractor or vendor visit is scheduled, the resident sees who is coming and for what purpose — not a generic appointment notification.
In practice.
A resident reports a persistent leak above their bathroom ceiling. A technician visits and notes: source appears to be from the unit above, plumbing contractor needed. The plumbing contractor arrives the following week. They open the work record and see: original report with photos, technician's note identifying the source, unit access requirements. The resident does not explain the problem again.
Three residents on the 6th floor report low water pressure on the same morning. Each receives acknowledgment. The system links all three to a single resolution record: building-wide water pressure issue, floors 5–7. Each resident sees the shared status. When pressure is restored, all three receive resolution notification from the same record.
A resident's dishwasher was repaired two months ago. The same fault recurs. They submit a new request. The interface shows this request alongside the previous one, linked. The assigned technician sees the prior resolution — motor replaced — and investigates further rather than repeating the same repair.
Failure modes.
Orphaned handoff. A request is reassigned from the in-house team to an external contractor. The contractor receives a work order number but no history. They contact the resident to ask what the problem is. The handoff transferred responsibility but not context.
Duplicate isolation. Twelve residents report the same elevator malfunction. Twelve independent records are created. Each progresses at a different pace. Some are closed when the elevator is repaired; others remain open because no one links them. Three residents receive resolution notification. Nine do not.
Recurrence amnesia. A resident reports a recurring drainage issue for the third time. Each previous report was resolved independently. The new request contains no reference to the prior two. The assigned technician approaches it as a first occurrence, applies the same temporary fix, and closes it. The system has no mechanism to flag repeated patterns.
Test.
- Reassign a request to a different team or contractor. Confirm: the receiving party can view the complete history without the resident re-describing the issue.
- Submit the same building-wide issue from two different resident accounts. Confirm: both are linked to a shared resolution record.
- Submit a request for an issue previously reported and resolved. Confirm: the prior request is visible in the history and identifiable as a related occurrence.