Shared Product Blueprint

Meeting Room Booking

A read-only Product Blueprint created with IdeaMade.

Meeting room booking

Meeting Room Booking

A small-office meeting room booking app for a 15-person office with three rooms. Signed-in users browse a room directory, view a shared booking calendar, and manage their own bookings. Admins create, edit, and deactivate rooms; deactivating a room keeps its existing bookings but blocks new ones. Bookings have a room, title, start and end time, notes, and a Confirmed or Cancelled status. Backend-enforced rules: only active rooms can be booked, end time must be after start time, a booking can be at most 4 hours long, two active bookings for the same room must never overlap, cancelled bookings free the slot immediately, users can cancel only their own bookings, and other people's bookings reveal only that the time is occupied.

Users and roles

The people who interact with the product.

Signed-in user

An office member who signs in to find a free room, book it, and manage their own bookings.

  • See which rooms exist and whether they are active
  • Check when rooms are occupied
  • Book an active room without conflicts

Admin

An office member with additional rights to manage the room list.

  • Create and edit rooms
  • Deactivate a room so it can no longer be booked while keeping its existing bookings

Key workflows

The main paths users take to reach an outcome.

Sign inSigned-in userCore
1

Sign inAuthenticate through the sign-in page.

Outcome: The user is signed in and can browse rooms, view the calendar, and manage their own bookings.
Find and book a roomSigned-in userCore
1

Browse roomsReview rooms, their location, capacity, and active status.

2

Check availabilityView the booking calendar to see when rooms are occupied; other people's bookings show only as occupied time.

3

Create bookingEnter a title, start and end time, and optional notes. The backend enforces active room, end after start, at most 4 hours, and no overlap.

Outcome: A Confirmed booking exists for an active room with no overlap, or the user sees why the booking was rejected.
Manage my bookingsSigned-in userCore
1

View my bookingsSee the user's own bookings with title, room, time range, notes, and status.

2

Cancel a bookingCancel one of the user's own bookings; the slot frees immediately.

Outcome: The user sees their own bookings with full details and can cancel one, freeing the slot immediately.
Manage roomsAdminCore
1

Create or edit a roomAdd a room or update its name, location, capacity, or active flag.

2

Deactivate a roomMark a room inactive so it keeps existing bookings but blocks new ones.

Outcome: The room list reflects the admin's changes; deactivated rooms keep existing bookings but cannot be booked.

Pages

5 pages in the MVP

Sign inLet users sign in so the app can identify them for booking ownership and admin rights.
Public
Sign in
Room directoryShow all rooms with name, location, capacity, and active status so users can pick a room to book. If no rooms exist yet, explain that an admin must add rooms first.
Signed in
Room directory
NameLocationCapacityActive
Booking calendarShow room occupancy over time and let users start a booking. Other people's bookings appear only as generic occupied blocks with their time range, never with title, notes, or owner.
Signed in
Booking calendar
My bookingsList the signed-in user's own bookings with full details and let them cancel. When there are no bookings, explain how to create one from the booking calendar.
Signed in
My bookings
Manage roomsLet admins create and edit rooms and deactivate a room. Deactivating keeps existing bookings but blocks new bookings for that room.
Signed in
Manage rooms

Product decisions

Choices you can confirm directly in the Blueprint.

Which time constraints should apply when a user creates a booking?ConfirmedWhich time constraints should apply when a user creates a booking?
Future times only, within a single day
On the shared booking calendar, how should other people's bookings appear?ConfirmedOn the shared booking calendar, how should other people's bookings appear?
Generic occupied block

Assumptions

Items that should be verified before implementation.

Booking time constraints are confirmed: a booking's start must be in the future, and the start and end must fall on the same calendar day, in addition to the end-after-start and 4-hour maximum rules.

High impactAccepted

On the shared booking calendar, other people's bookings are confirmed to appear as a generic occupied block showing only the time range, with no title, notes, or owner.

Medium impactAccepted

Version 1 explicitly excludes payments, email or Slack notifications, external calendar sync (Outlook or Google Calendar), check-in kiosks, room displays, desk or floor-plan booking, and analytics.

Medium impactAccepted

Overlap prevention is enforced on the backend, not only in the form. The platform must support server-side validation for this rule; if it does not, the Builder must flag it rather than treat the form check as sufficient.

High impactAccepted