Calendar and bookings

How the host calendar works — blocking dates, instant-book vs request-to-book, conflict handling, message inbox, and overrunning bookings.

The host calendar is where most of your day-to-day work on the platform happens. This page explains the mechanics — what each interaction does, what the platform does on your behalf, and what the implicit rules are.

The calendar view

The calendar opens to the current week, with swims down the rows and time across the columns. Three view modes:

  • Day — hour-by-hour. Useful for the day-of, especially if you have multiple short bookings.
  • Week — the default. Drag-to-block, drag-to-extend, click to inspect a booking.
  • Month — high-level. Read-only on the cells; clicks open a day's details.

The calendar colour-codes each day and booking with a legend you'll see on the page itself: Free, Partially busy, Booked, Closed, and per booking Confirmed–Paid, Pending, Cancelled (swim availability additionally shows Bookable, Limited, Unavailable). There is no "dispute" state on the calendar — disputes are handled in Messages with our team.

Blocking dates

Use Block dates on the calendar to close a time range. A block prevents anglers from booking that span, but doesn't appear in search as "fully booked" — the search just doesn't surface blocked dates.

Common reasons to block:

  • Your own use. You want to fish your own lake. The platform doesn't ask why.
  • Maintenance. Bank rework, weed cut, lake drained, vehicular access works.
  • Fish welfare close season. Some hosts close their lake for 4–8 weeks in late spring to protect spawning carp.
  • Private events. Family use, club matches, paid private rental off-platform.

A block covers the whole lake or just the swims you pick, over the date range you set, with an optional note (shown only to you).

Request to book vs instant confirmation

Booking approval is a lake-level setting (Lake settings → Booking preferences), and the default is manual approval: every booking arrives as a request you confirm or decline. Switch the lake to instant confirmation and bookings confirm automatically the moment the angler pays the booking fee.

Pending requests wait for your decision — there's no automatic timeout — but decide quickly: anglers planning a trip will book another lake rather than wait long for a maybe, and declining always refunds their booking fee automatically.

The case for manual approval:

  • High-value carp lakes where you want to vet anglers (review history, return-visit, party makeup).
  • Specialist waters (large catfish, ancient mirror carp) where the wrong angler is genuinely a risk to the stock.
  • Logistically complex lakes where your acceptance depends on whether you can be on-site.

The case for instant confirmation:

  • Conversion is meaningfully higher. Anglers planning multi-stop trips bail rather than wait for a maybe.
  • Anglers reading two similar lakes pick the instant one. It's not a small bias.
  • Your inbox stays quiet. Manual approval means every booking is hand-managed.

Many hosts start on manual approval to get a feel for the flow, then switch to instant confirmation once they trust their calendar.

Confirming / declining a request

When a booking request comes in, you see it in the calendar (Pending) and on your Bookings page, and you're notified by email.

To confirm, open the booking and hit Confirm. The booking flips to confirmed and the angler is notified.

To decline, use Decline and refund with a reason:

  • "Requested by the angler" — they asked you to cancel it.
  • "Duplicate" — the same session was booked twice.
  • "Other" — free text. The angler sees this text verbatim, so be diplomatic.

Declining refunds the angler's booking fee automatically.

Conflict handling

The platform's calendar is a single source of truth. The cases where you can produce a conflict:

Overlapping blocks. You can layer blocks; the most-restrictive wins. A swim-specific block on top of an all-swims block is redundant but harmless.

Blocks that overlap existing bookings. The block can't take effect while the booking exists; the platform asks if you want to cancel the booking (host-initiated, which incurs the Refund Policy cancellation fee) or skip the conflicting dates.

Bookings that try to overlap a confirmed booking. Not possible — the calendar surfaces the existing booking and the angler can't proceed. Don't worry about double-booking via the platform; you can worry about it if you also take bookings off-platform and forget to mirror them.

Off-platform bookings on the same swim. If you take a booking by phone or in person without entering it as a block, the platform doesn't know. Always mirror off-platform bookings as a block immediately. Most disputes that escalate to us start here.

The message inbox

The inbox is one tab in the dashboard. It contains:

  • Per-booking threads with anglers (the only place messages between host and angler live — there's no DM-the-host-from-the-lake-page feature for anglers without a booking).
  • Platform messages from LakeBooking (verification updates, dispute notifications, policy changes).
  • A unified search bar across all threads.

There's no public response-time score on your listing — but reply speed still decides bookings: an angler whose question sits unanswered for a day usually books another lake. Aim for a substantive first reply within a few hours.

Auto-reply is not supported. We deliberately don't ship one — a canned instant reply doesn't actually answer the angler's question.

A practical tip: keep your 4–6 most common answers (arrival instructions, weather caveat, food on-site, dogs, late arrival) in a note on your phone and paste them in — most questions repeat.

Overrunning bookings

Anglers who stay past their booked end-time are the most common operational headache for hosts. The platform's view:

  • The grace window is 30 minutes by default. Anglers within the grace window aren't billed extra.
  • Beyond 30 minutes, the platform charges the next billing unit. If the angler has a 12h day-ticket and overruns by 2 hours, they're billed another day-ticket. If they overrun a 24h overnighter by 5 hours, same — another overnighter.
  • The default mode is on-site settlement: the host collects the additional balance at the gate, marks it on the booking ("settled on-site, €X"), and the platform notes it.
  • The optional mode is post-hoc Stripe charge: the host requests the platform charges the angler's card for the additional billing unit. Available within 24 hours of the overrun; needs angler acknowledgement in some jurisdictions.

You can also set an overrun rule per swim: "swim 7 overruns past 09:00 cost €25 flat" or "no overrun allowed at all". The rule is shown to the angler at checkout, so they know what they're agreeing to.

Cancellations

Angler-initiated cancellations follow the Refund Policy schedule. The platform handles the refund automatically; you don't have to do anything. The calendar frees up.

Host-initiated cancellations require a reason from a controlled list (force majeure, lake conditions, infrastructure failure, personal emergency, other). The angler is refunded 100% of the booking fee per the Refund Policy. Repeated host cancellations affect your reliability score and, eventually, your listing's visibility.

Both-sides cancellations (you and the angler agree to cancel mutually) work via the "Mutual cancellation" button in the booking thread. The booking fee is refunded; no penalty is applied to either side.

Things to know that aren't obvious

  • The calendar respects DST. Bookings around the spring-forward / fall-back boundary are calculated against actual elapsed hours, not wall clock. A 24h overnighter on a fall-back night is genuinely 24 hours, not 25.
  • The calendar doesn't know about local holidays automatically. If you want Easter weekend pricing, set a date-range override on the relevant billing units. The dashboard won't surprise you on March 31.
  • Refunds to expired cards still work. Stripe routes the refund to the issuing bank, which credits the replacement card. You don't have to chase angler card updates.

See also

Cookie Settings

We use essential cookies for our website's functionality, user authentication, and secure card payment processing. Details in our Cookie Policy.