One shared calendar for weddings, picnics, tours, and fall events, instead of one phone line
A WeddingWire review describes a couple who booked a rehearsal, then found out weeks later, only because their decorator happened to mention it, that the farm had also booked a full wedding for the same time slot. Nobody at the farm caught it or flagged it to them directly. With weddings, company picnics, school and group tours, and fall festival bookings all coming in through the same phone line, that kind of mixup is easy to miss without one shared place every request lands. This shows what changes when every request type checks against the same calendar before it's accepted, and echoes back exactly what's booked instead of relying on separate notes or memory.
What's real: the event types (weddings and rehearsals, company picnics, farm tours, and fall festival bookings) and the double-booking pattern are drawn directly from your cold-email exchange and a public review describing a rehearsal that was booked over by a separate wedding. What's fictional: the sample bookings seeded below, and the illustrative rates shown, are placeholder data built to demonstrate the conflict check, not real reservations or real pricing.
1. Booking request, all event types
Picking an event type and a date checks that date against every other request already on the books, no matter which line it came in on, so a wedding booked over an already-scheduled rehearsal gets caught here instead of surfacing weeks later through a decorator or a guest.
2. Farm calendar, every request type in one place
Every request lands here the moment it's submitted, so whoever picks up the phone for a picnic inquiry can see the wedding and tour calendar too, instead of each event type living in its own notebook or memory.
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 date that already has a confirmed or pending booking in this queue. It doesn't pull from a phone log, a paper calendar, or anywhere else a booking might already live today, so the first real build has to bring every existing reservation into this one place before it can be trusted.
It currently blocks any two events on the same date, across all types. If tours can safely run alongside a wedding on the same day but a second wedding can't, that rule needs to be set explicitly rather than treating every event type the same, this demo shows the mechanism, not your exact scheduling policy.
The confirmation shown here is on-screen only. A real build emails this same event/date summary to the client automatically the moment a request is accepted, which closes the actual gap the review describes: a booking that existed on paper somewhere but wasn't visible to whoever confirmed the next one.
Rates shown are illustrative placeholders. Your real pricing for weddings, picnics, tours, and fall events would replace these before anything goes live.