Choose a holiday-let calendar by what it allows the guest to do. A display shows dates; a request form asks the owner to review a stay; a booking engine checks a proposed stay and takes the guest through its reservation process. Decide which you need before selecting a calendar widget.
If the accommodation is also listed elsewhere, establish how each system learns about new bookings and blocked nights. A calendar that looks current on your website can still be waiting for an update from another sales channel.
Separate the three jobs in the brief
A displayed calendar can help guests avoid asking about obviously unavailable periods. Pair it with an honest explanation of what they must do next. If the dates are subject to confirmation, the page and form acknowledgement should say so.
A request form collects a proposed arrival, departure and guest party for review. Define who replies, where the request is recorded and when a stay becomes confirmed under your actual process. Submitting the form should not leave someone thinking they have reserved the property.
A booking engine handles the guest’s stay selection and the configured reservation rules. A channel manager or property-management system may also distribute availability to external listings. Ask the provider to identify those roles in your proposed setup; several products can sit behind one “Book” button.
For example, a property website may link to a hosted booking page while the operator manages dates in separate accommodation software. Record the property identifier and destination for that link so a later website edit does not send guests to a different unit.
Specify nights, arrivals and departures
An accommodation stay spans nights rather than an ordinary appointment slot. Ask how the calendar represents arrival, occupied nights and departure, particularly when a new guest may arrive on the day another leaves.
Use a clearly labelled illustrative example in the supplier demonstration: a guest arrives on Friday and leaves on Monday. Check which nights are occupied, whether a Monday arrival is permitted and how cleaning or preparation changes that result. The answer must follow the property’s actual changeover arrangements.
Give the provider the rules you intend to run: allowed arrival days, minimum and maximum stays, advance notice, closures and any required gap between stays. A date may be unoccupied but still fail a permitted stay combination.
If you have several properties, test each unit and any shared restriction separately. A clear calendar for one cottage does not establish how a whole-building reservation interacts with individual rooms or linked accommodation.
Treat imported calendar feeds as a connection with limits
An iCalendar feed uses a calendar address, commonly ending in .ics, to pass calendar information between services. Import and export are separate directions. Drawing a simple map of who reads whose calendar makes it easier to spot a missing return connection.
Airbnb’s calendar-sync guidance currently says its imported calendars refresh automatically every three hours; changes exported to another website depend on that website’s settings. It also warns that some nights manually blocked elsewhere, including preparation or advance-notice blocks, may not carry over in the same way.
Those are Airbnb’s documented behaviours, not a refresh promise for every website or booking product. Ask each supplier which types of block transfer, how quickly they are read and how to recognise a failed or stale connection. Do not describe a feed-based display as real-time inventory unless the proposed system actually supports that claim.
There can be a gap between a reservation on one channel and its appearance on another. For a business accepting bookings in several places, ask the accommodation-software provider to demonstrate the available integration and explain its failure handling. Avoid buying an attractive website calendar while leaving that operational question unanswered.
Keep requests and confirmed stays distinguishable
Agree where a provisional enquiry belongs. Does it leave the dates open, create a temporary hold or require a manual block? If a hold expires, who can see that it has ended? Put the chosen behaviour into the website brief and operator instructions.
A telephone booking needs the same attention. Identify the system where staff enter it and the steps that stop the dates being offered elsewhere. Do the same for owner visits, repairs and a cancelled stay that should reopen availability.
Keep guest-facing messages aligned with those states. A message confirming receipt of an enquiry should explain that it is being reviewed. A reservation confirmation should identify the property and dates according to the booking service’s process.
If the website has a problem loading its booking connection, provide a useful contact alternative. Do not replace a failed live calendar with invented availability or a stale screenshot presented as current.
Check whether guests can use the date controls
Use separate, clearly named arrival and departure controls, with a visible explanation of the requested dates. W3C’s form-label guidance explains why labels must identify controls and be associated with them in the page structure.
Review the actual booking interface on a phone and with a keyboard, including any hosted page or embed supplied by another company. Can a guest move between months, understand unavailable nights, correct the departure date and return from an error without losing everything?
Check enlarged text, longer property names and the message shown when a stay breaks a restriction. A generic “invalid selection” leaves the guest without an actionable correction. Our website accessibility check gives a wider first-pass review for the surrounding website.
Keep personal reservation details out of the public calendar. The guest needs to understand availability, not see other visitors’ names or an operator’s private diary notes.
Rehearse changes before the booking route goes live
Agree a controlled test method with the provider so checks do not take real inventory, charge a card or send messages to customers. Use the proposed account and integration rather than a sales demonstration with different features.
- Try an allowed stay and an unavailable period for the correct property.
- Check a changeover day, a minimum-stay failure and any preparation gap.
- Enter a controlled manual block and confirm what each connected route receives.
- Review the documented change, cancellation and reopening process.
- Confirm who notices a broken feed or booking link and how guests can still make contact.
Record the observed results and any manual work required. If an essential case fails, revise the setup before enabling the guest booking route.
For the surrounding pages, use our holiday-let website planning guide. To discuss an accommodation website in Formby, Freshfield or L37, contact Formby Web Design with the current property listings, booking software and the exact date-handling problem.
