Module M3
RunningBookings
Guest flat, sauna, communal room, laundry, parking bay and EV charging. The rules sit on the resource, and the database decides who gets the slot.
Wired end to end against a real database and in use in the product.
What shapes this module
Two residents cannot take the same slot, and that is settled by a constraint in the database rather than a check in the code. Two simultaneous bookings run in separate transactions and neither can see the other’s uncommitted row, so a check in the application answers "free" to both. The slot grid is also produced from the same rules that refuse a booking, which is why a time you can see is always a time you can take.
For residents
- A slot grid per resource and day
- Book and cancel without asking anyone
- Your own bookings in one place
- The resource's rules visible before you book, not after
For the manager
- Bookable resources with rules and opening hours per resource
- Cancel on behalf of a resident who rings
- Mark a slot as a no-show or as taken
What you configure yourselves
- Per resource: slot length, opening hours, how far ahead bookings open, quota per flat, and whether the resource is active
Not built
A queue when a slot is taken, blocked periods beyond opening hours, the day-before reminder and iCal export are not built. The reminder needs something that fires on a clock rather than on a visit, and the product has nothing like that yet.
Contact
Tell us how a repair report is handled with you today.
Write a few lines about the portfolio you manage and where the time goes today. We will reply with how that looks in the system, and book a call if it seems worthwhile.