Working example, built for Arkansas Wedding Barn

One calendar across all four rental spaces that refuses to double-book

A WeddingWire review from December 27, 2025 describes showing up for a booked guest house rental and finding it not ready, then being told the booking "didn't have it marked down" even though there was a confirmation. A 2017 review on The Knot describes almost the same thing: the guest house double-booked while the owner was out of town. This shows what changes when the barn, the micro chapel, the stables, and the guest house all share one request queue that blocks a conflicting date before it's accepted, and echoes back exactly what's reserved instead of relying on memory or a notebook.

What's real: the four rental spaces and their starting prices (the barn from $1,200, the micro chapel from $200, the stables from $600, the guest house at $250 a night) are copied from your own site today. What's fictional: the sample bookings seeded below, including the illustrative guest house conflict, are placeholder data built to demonstrate the double-booking check, not real reservations. That gap between "a confirmation existed" and "the date wasn't actually marked down anywhere staff could see it" is exactly what this replaces.

1. Booking request, all four spaces

Picking a space and a date checks that date against every other request already on the books for that same space before it can be submitted, so a second booking for an already-reserved guest house night gets caught here instead of at the door.

2. Reservation book, across all four spaces

Every request lands here the moment it's submitted, so whoever is answering the phone or the DMs can see the whole calendar at once, instead of the one memory or notebook the venue is running on today.

What I'd flag before you roll this out

This is a request-and-conflict-check queue, not a synced calendar app. It blocks a second request for a space that already has a confirmed or pending date in this queue. It doesn't pull from Google Calendar, a wedding-planning app, or anywhere else a booking might already live, so the first real build has to bring every existing reservation into this one place before it can be trusted.
Prices shown are your own published starting rates. The barn, chapel, and stables are flat per-event rates on your site; the guest house is per night. If any of these change or a rate depends on guest count or season, that logic needs to be added before this goes live.
The confirmation shown here is on-screen only. A real build emails this same space/date/price summary to the client automatically the moment a request is accepted, which is the actual gap both reviews describe: a confirmation that existed but wasn't visible to whoever was checking the day of.
Space names and prices are copied from your own site today. If a rate or space changes, this needs a one-line update to match, it won't drift out of sync on its own.