No Request Lost
Expectation. The building shall receive, confirm receipt of, and progress every reported issue to a defined resolution, without silent loss at any stage.
Required.
- Every request submitted through the interface receives confirmation of receipt within a defined timeframe. No request is silently absorbed.
- Every request progresses through defined states — received, acknowledged, assigned, in progress, resolved — and each transition is recorded.
- A request cannot be marked resolved without the resident being informed.
- A request cannot be removed from the resident's view while it remains unresolved.
- The interface is available for request submission at all hours. A request submitted outside staffed hours is received and acknowledged with the same confirmation as one submitted during staffed hours.
Recommended.
- When a building system fault is detected, a record exists before the first resident report.
- When multiple residents report the same building-wide issue, each receives confirmation of receipt and is linked to a single resolution record.
In practice.
A resident submits a request about a leaking pipe at 11 PM. Within the defined timeframe, a confirmation appears: the issue is received, categorized, and queued. The resident sees this immediately. The next morning, the status updates to assigned. At no point does the request disappear or require re-submission.
The elevator in tower B stops functioning at 7 AM. The building's monitoring system detects the fault and creates a record. By the time the first resident reports it, the record already exists. The resident's report is linked to the existing record and they see: issue identified, technician dispatched.
The building's support system undergoes a scheduled migration overnight. A resident submits a request at 6 AM during the transition window. The request is queued locally. When the migration completes at 7 AM, the request appears in the resident's list with its original submission time and an acknowledgment. The migration did not create a gap in which requests could be lost.
Failure modes.
Queue-entry mirage. The system displays a confirmation screen after submission, but the request does not appear in the resident's active request list. The resident believes the request was received. It was displayed but not recorded. The gap between confirmation UI and actual persistence means the request exists nowhere.
Status freeze. A request is acknowledged and assigned within hours. It then remains in "assigned" state for weeks. The system does not escalate, does not notify the resident of delay, and does not distinguish between a request assigned today and one assigned thirty days ago. The status is technically accurate — it is assigned — but operationally meaningless.
Silent closure. A request is marked resolved on the backend. The resident receives no notification. They check the interface days later and find the request closed. They do not know when it was closed, what was done, or whether the issue was actually addressed. The system completed its workflow. The resident's experience of the issue is unchanged.
Test.
- Submit a request. Confirm: confirmation of receipt appears within the defined timeframe.
- Submit a request outside staffed hours. Confirm: the same confirmation of receipt process applies.
- View the resident's active request list immediately after submission. Confirm: the request is present and visible.
- Attempt to close a request from the management side. Confirm: the resident receives notification of closure.