Book It, Change It, Cancel It

Expectation. The resident shall be able to view availability, manage their own bookings, and interact with shared space information through the primary interface — without requiring staff assistance for routine actions.

Required.

• When a space is bookable, the resident can view availability, create a reservation, modify it, and cancel it through the interface. Cancellation takes effect immediately. A cancelled slot is released for other residents without delay.
• The resident can view their booking history — past and upcoming reservations, cancellations, and any charges — for a period not shorter than the current occupancy or 12 months, whichever is longer.
• When the building permits guests in shared spaces, the resident can register guests through the interface as part of the booking process or in advance of a visit. When the space has access control, the guest access method is communicated to the resident at the point of registration. ACC.CO
• The resident can report a condition issue with a shared space — broken equipment, cleanliness problem, safety concern — through the interface. The report is linked to the specific space and enters the building's support system, subject to the same acknowledgment, tracking, and resolution requirements as any support request. SUP.RE

Recommended.

• When a space is fully booked, the resident can join a waitlist. If a slot opens, the next resident on the waitlist is notified.
• The resident can set recurring bookings for spaces they use regularly.
• Household members associated with the resident's unit can view and manage bookings for shared spaces.
• The resident can view what personal data is associated with their space usage and booking history and can request its deletion after a defined period.

In practice.

A resident books the co-working room for Tuesday from 10 AM to 12 PM. On Monday evening, their plans change. They cancel through the interface. The slot is immediately released. Another resident, checking availability Tuesday morning, sees the 10 AM slot open and books it. The cancellation did not require a phone call, an email, or staff approval.

A resident notices a treadmill in the gym is malfunctioning — the belt slips at higher speeds. They open the interface, navigate to the gym, and report: treadmill #3, belt malfunction. The report enters the building's support system linked to the gym. The resident can see the status of their report in the same place they track all support requests — received, assigned, resolved. They did not submit a separate maintenance request through a different channel.

A resident books the rooftop terrace for their birthday and registers four guests. At the point of registration, the interface states: guests will receive a temporary access credential valid for the booking period, issued via the building's guest credentialing system. The resident knows how their guests will get in before the guests arrive.

A resident reviews their booking history to confirm when they last used the private dining room and what deposit was charged. The record shows: booked March 8, used, $200 deposit returned March 10. The history exists because the building retains booking records for the duration of occupancy.

A resident's partner — a household member with their own building credential — books the gym for a Tuesday morning session through the same interface. The booking appears in the household view. Both residents can see and manage bookings associated with their unit.

Failure modes.

Cancellation friction. The resident needs to cancel a gym booking. The interface has no cancel function — only a "request cancellation" form that requires management approval. The approval arrives the next day. The unused slot sat blocked for hours while another resident wanted it.

Released but not available. A resident cancels a booking. The system confirms the cancellation but does not release the slot. The availability calendar still shows the time as reserved. No other resident can book it. The cancellation was processed in the resident's record but not in the availability system.

Invisible condition. Three gym machines have been broken for two weeks. No status appears in the interface. Residents arrive expecting a full gym and find a third of the equipment out of service. The physical condition of the space is not reflected in its digital representation.

Orphaned report. A resident reports a broken sauna heater through the space's page in the interface. The report is logged in the Spaces system but does not enter the building's support workflow. No one is assigned. No status updates appear. The report exists in a system that nobody monitors. The sauna remains broken for weeks. Failure of the condition-report-to-support linkage.

Guest access unknown. A resident books the rooftop terrace and registers three guests. The booking confirms. Nothing indicates how the guests will access the rooftop, which has a credential-controlled entrance. On the evening of the event, the resident stands at the rooftop door, buzzing each guest in individually. The system created the booking and accepted the guest list but never communicated the access method.

Test.

1. Book a space, then cancel. Confirm: the cancellation takes effect immediately and the slot is visible to other residents.
2. View booking history for reservations made more than 6 months ago. Confirm: records are present with dates, spaces, and any associated charges.
3. Register a guest for a booking at an access-controlled space. Confirm: the guest registration is accepted and the guest access method is communicated.
4. Report a condition issue with a shared space. Confirm: the report is accepted, linked to the specific space, and visible in the resident's support request history.