Product area
Operations
Where an operating day actually goes. Service requests, parcels, notifications and announcements, each with its state visible rather than held in whoever last spoke to the trade.
From the running build
The screens.
Captures of the build as it stands. The data in them is a demo dataset, not an operator's.
Service requests
Maintenance and resident requests with their state visible, which is where coordination work goes to hide.
Amenities and bookings
Bookable spaces and the rules around them, so amenity coordination stops living in messages.
Communications
Announcements and resident notifications, drafted and released by a person.
Operating analytics
Occupancy, arrears, amenity usage and access trends over a period, assembled rather than rebuilt.
Status
What is built in Operations, and what is not.
Three states, from the same capability map the platform is governed by. The middle one is the one worth reading.
Shipped
Built, and working in the running build.
- Parcel logging
- Service requests with category and status tracking
- Operator notifications, in-app and push
- Community announcements
- Resident feedback
Partial
Built underneath, and not reachable end to end yet.
- Amenity booking has atomic capacity claims and a filtered unique index underneath it, but no user-facing path calls them, so an operator makes the booking
Roadmap
Not built. Named here so it cannot be implied elsewhere.
- Resident-initiated booking
- Vendor and contractor workflow coordination
- Escalation and service-level tracking
The rest of the platform