Files
holiday-property-booking/06-admin-console.md

2.2 KiB

06. Admin Console

Purpose

Define the back office screens and admin actions needed to run the business.

Scope

  • Secure admin login.
  • Property management.
  • Image management.
  • Amenity management.
  • Pricing management.
  • Availability management.
  • Booking management.
  • Payment record view.
  • Enquiry management.
  • Content page management.
  • Testimonial management.
  • Site settings.

Proposed Admin Structure

Core Admin Areas

  • Dashboard / overview
  • Properties
  • Availability and pricing
  • Bookings
  • Payments
  • Enquiries
  • Content pages
  • Testimonials
  • Site settings

Admin Actions

  • Create, edit, publish, unpublish, and archive properties.
  • Upload, reorder, and remove property images.
  • Add and assign amenities.
  • Set and override pricing rules.
  • Add availability blocks and exceptions.
  • Review bookings and payment records.
  • Read and manage enquiries.
  • Edit static pages and testimonials.
  • Update site-wide settings and defaults.

Admin Guardrails

  • Admin login is required for all back office actions.
  • Sensitive changes should be scoped by role or privilege if roles are added later.
  • The admin cannot silently break the booking/payment truth model.

What Needs to Be Done

  • Define the admin navigation and main screens.
  • Define CRUD operations for each managed entity.
  • Define admin permissions and safe defaults.
  • Define which screens need audit or status history.
  • Define what the admin can override and what they cannot.
  • Define which booking/payment states are editable versus read-only.
  • Define whether audit history is required for important admin changes.

Acceptance Criteria

  • Every admin requirement from the spec is mapped to a screen or action.
  • The admin surface is grouped in a way that matches day-to-day usage.
  • Sensitive changes have clear rules and boundaries.
  • The admin plan supports future implementation without redesigning the workflow.
  • The admin model does not conflict with booking, payment, or availability rules.

Dependencies

  • Content architecture and data model.
  • Booking, availability, and pricing.
  • Payments and notifications.

Notes

  • Any admin override needs a clear rule to avoid conflict with booking or payment state.