A customer books a consultation for 9am. Your calendar shows 8am, the confirmation says 9am and a CRM reminder uses a third version. Before anyone starts moving appointments, you need to establish which time each system means.
This matters before the next UK clock change. GOV.UK confirms that the clocks go back at 2am on Sunday 25 October 2026, returning the UK from British Summer Time to Greenwich Mean Time. A booking journey should handle that change without someone manually adding or subtracting an hour.
For businesses selling appointments, demonstrations, site visits or consultations, the practical task is to follow one booking through the website, calendar, confirmation and reminders. Find the first disagreement, fix its cause and prove that both new and existing appointments still make sense.
First, distinguish a different display from a wrong appointment
Two calendars can show different clock times for the same meeting. Google Calendar explains that events are converted to UTC and displayed in each person’s local time zone. A customer overseas and a member of staff in the UK can therefore see different times and still join together.
Start with one affected booking. Record the appointment date, intended time, location and time zone. Then compare the customer-facing booking page, booking provider’s record, staff calendar, confirmation email, calendar attachment and CRM entry. Include the reminder if one has already arrived.
| First disagreement | What to inspect |
|---|---|
| Booking page and confirmation | The visitor’s selected time zone and the confirmation’s formatting. |
| Provider record and staff calendar | The event’s time zone and the calendar’s display settings. |
| Calendar and CRM | The date-time field passed through the integration. |
| Correct appointment, wrong reminder | The reminder’s scheduling rule and message template. |
This is a diagnostic starting point, not proof that a particular product has a fault. Compare the underlying appointment instant as well as the text people see. Ask your developer to do that comparison if the records expose technical timestamps.
Use a UK location time zone, not a permanent one-hour adjustment
A named regional time zone carries rules for seasonal clock changes. A fixed offset describes a particular difference from UTC. They answer different questions.
For UK opening hours, choose the platform’s location-based London option. Where software accepts IANA identifiers, Europe/London is the regional identifier to check. Do not assume that a standalone UTC+1 setting means UK time throughout the year.
The following example applies the UK clock rules to two separate appointments, both intended for 9am at a UK premises:
| Appointment date | UK appointment time | Equivalent UTC time |
|---|---|---|
| Friday 23 October 2026 | 09:00 BST | 08:00 UTC |
| Monday 26 October 2026 | 09:00 GMT | 09:00 UTC |
These are calculated examples, not booking results. A workflow that always subtracts an hour would treat the second appointment incorrectly. A workflow that treats every UK date as GMT would mishandle the first.
Check each product’s documented choice rather than judging by an abbreviation alone. A location option labelled with a standard-time offset may still apply daylight-saving rules.
Check the booking provider and the customer’s view
Calendly: inspect availability and event-type time zones
Calendly’s current time-zone guidance, updated on 20 August 2026, says it adjusts for daylight saving automatically. It normally displays availability in the invitee’s detected time zone, and invitees can select another zone on the scheduling page.
Check the availability schedule and the individual event type. Calendly allows their time zones to be changed separately. For in-person appointments, its guidance recommends locking the event type to the location’s time zone.
That makes the business decision straightforward: a premises appointment should clearly communicate the venue’s time; an online consultation can use the attendee’s local time. Check what your actual booking page shows before changing anything.
Microsoft Bookings: check business time and visitor time
Microsoft’s Shared Bookings FAQ, updated on 21 May 2026, says working hours use the business time zone. The self-service page can display appointment slots in the visitor’s time zone; the Always show time slots in business time zone option controls that behaviour.
Inspect that choice alongside the staff calendar. Microsoft also says Bookings confirmations contain an ICS calendar attachment. Open the attachment in a test customer’s calendar and compare the resulting appointment with the provider’s record. Checking the email’s visible wording alone misses this part of the journey.
Give your developer the right question about CRM integrations
If the provider’s appointment is correct but the CRM is an hour out, ask what date-time value crosses the connection. The useful question is: “Does this field identify an exact instant, a local appointment time with a zone, or just a piece of text?”
Google’s Calendar API documentation, updated on 3 September 2026, explains explicit offsets, UTC values and named time zones. It also requires a time zone when expanding recurring events. Those distinctions matter when a developer connects booking software to another system.
Our practical recommendation is to retain an unambiguous appointment instant for a confirmed booking and preserve the relevant regional time zone for display and scheduling rules. Weekly opening hours and recurring appointments need their intended local-time rule as well as a date.
Ask the developer to check whether a connection drops the offset, substitutes the server’s time zone, converts the value twice or adds a fixed hour. Also check whether the CRM field represents an appointment date-time or merely a date. These are investigation questions; the booking record should establish which, if any, applies.
For a weekly 9am appointment, ask whether the series must stay at 9am locally across the change. Adding a fixed number of hours to the previous occurrence is a different rule and needs deliberate justification.
Test bookings on both sides of the clock change
Use a test service or controlled appointments with your own contact details. Start from the booking link or embedded tool on the actual website so the test includes the route customers use.
- Book before the change. Choose a suitable appointment before 25 October and compare every destination.
- Book after the change. While still before the change, book an appointment for 26 October or later. This checks a future date under different clock rules.
- Compare customer and staff calendars. Import the calendar attachment or use the normal add-to-calendar route. Confirm that both represent the intended instant.
- Reschedule across the change. Move a controlled booking from one side to the other. Check the updated calendar entry, confirmation and CRM task.
- Check reminders. Verify both the scheduled send time and the appointment time printed in the message. Use a short test reminder where supported, then separately inspect the clock-change case.
- Test another visitor time zone where relevant. For online appointments, deliberately select another zone and verify the conversion. For premises appointments, check that the venue time remains clear.
A reminder sent “24 hours before” and one sent “at 9am on the previous local day” are different rules across a clock change. Decide which behaviour your business needs and have the integration implement it explicitly.
Keep the booking reference, selected zone, expected time, received messages and calendar evidence together. That gives the person fixing the issue something repeatable to work from.
Repair the cause, then check appointments already booked
Correcting a setting or integration does not prove that existing records have been repaired. Take a controlled example first and establish whether the error affects display, the stored appointment time, the reminder or several of them.
If only a CRM display is wrong, changing the original booking could move an otherwise correct appointment. If the stored booking is wrong, use the provider’s supported rescheduling route and check that the customer receives the correct update.
Identify affected future appointments by service, date range and integration route. Check recurring series and exceptions separately. Compare the booking record with staff and customer calendars before making a bulk correction, and retain a record of what changed.
Repeat the original tests after the fix. A successful new booking is useful evidence, but the existing appointment and its replacement reminder must also agree.
Make booking reliability part of routine maintenance
Assign someone responsibility for the booking journey, including calendar connections and CRM reminders. Repeat the checks before spring and autumn clock changes, after replacing a booking tool and after changing an integration.
Keep appointment accuracy and marketing measurement as separate checks. Once times are dependable, our guide to GA4 cross-domain tracking for booking and checkout journeys explains how to investigate measurement gaps when customers move to another website.
If your booking provider, calendar and CRM disagree, BuzzBoost’s workflow automation service can help review the connection. Tell us which systems you use and where the first mismatch appears, and we can discuss the clearest next step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
