Explore Gbeya

For your Manchester coaching practice

Offer a time you can keep, not just a gap in the diary.

Protect the time around the appointment, and make the same moment clear to clients in different timezones.

Start with your situation

A client chooses a time, makes room for the conversation and expects you to be ready. The calendar is making a promise on your behalf. A slot can look available while its preparation time, travel or another commitment makes it a poor choice.

For your Manchester practice, start with the week you can responsibly deliver. Then check how that week appears to a UK client and someone in New York. A reliable setup needs more than correct-looking labels: the saved appointment, confirmation and later changes must describe the same moment.

Use this guide to define the calendar promise your practice needs. Working hours, blocked dates and preparation gaps are only part of it. Before relying on external calendar sync in Gbeya, ask for a demonstrated connection: the 30 October 2026 review did not establish a working integration. Until that is resolved, maintain your commitments in one place and use an explicit confirmation process.

Rehearse one appointment from both sides

Rehearse in a separate test calendar before opening the schedule. Keep real client appointments and payments out of the rehearsal.

  1. Write working hours, exceptions, lead time and booking horizon in ordinary language.
  2. Compare a chosen instant in practice and client timezones across the relevant clock changes.
  3. Try adjacent services with different before/after buffers.
  4. Test required busy calendars and an unavailable provider.
  5. Rehearse competing requests, cancellation and a failed reschedule, then compare confirmations with the saved appointments.

Publish the booking promise that the observed workflow supports. Use a clear manual confirmation route where a critical control remains unverified.

A successful rehearsal covers the cases checked; it is not a promise that no conflict can ever occur.

A protected appointment needs more than an empty slot
  1. Step 1

    10:00–11:00 · Session

    One hour with your client.

  2. Step 2

    11:00–11:15 · Close and record

    Fifteen minutes after the first session.

  3. Step 3

    11:15–11:30 · Prepare

    Fifteen minutes before the next session.

  4. Step 4

    11:30 · Next possible start

    Subject to working hours, other commitments and the start grid.

Stated planning inputs: two fifteen-minute buffers create a thirty-minute gap. The timeline does not override other conflicts.

1. Start with the week you can actually deliver

Separate coaching hours from the hours you work. Preparation, notes, business administration and travel do not disappear because the booking page shows an opening. Choose a repeatable window, then add dated exceptions for days you cannot offer.

Write down how much notice you need and how far ahead clients may book. A twelve-hour lead time answers a different question from a three-week booking window. Treat those as settings to check, not proof that alternating weeks, daily limits or different service windows are covered.

Why this matters
Weekly rules describe a repeatable pattern; exceptions change a particular date. Lead time keeps an appointment from appearing too soon, while the booking window limits how far ahead people can choose. They answer different questions.
Work through the example
Suppose Tuesday mornings are coaching time but one Tuesday includes travel. Keep the usual pattern and block that date. In a test calendar, check the earliest allowed appointment and the last available date before opening the schedule to clients.
When the approach changes
If your schedule changes every week, a fixed weekday template may be a poor fit. Agree a dated availability process or request the missing scheduling control before offering the appointments.
Your decision
Publish only hours you can deliver. Verify alternating weeks, daily limits and service-specific windows before describing them as available.

2. Make the timezone part of the appointment

Use a named timezone such as Europe/London for the practice, rather than treating a fixed offset as a year-round rule. Show the date and relevant zone clearly. A label such as “10:00” alone is not enough for a client in another country.

In 2026 the UK moved its clocks back on 25 October, while the US seasonal change occurs on 1 November in places that observe it. That mismatch is a useful test case for your New York appointments. Do not copy an assumed time difference into every confirmation.

Why this matters
An appointment must identify one moment even when two people describe it in different local times. Check the practice display, the client display and the confirmation together. Do not assume the client sees their local timezone merely because yours is correct.
Work through the example
For a late-October appointment, compare the saved instant with its display in Europe/London and America/New_York using the actual date. Repeat after 1 November. Ask a colleague to explain which timezone the booking screen is showing without your help.
When the approach changes
A local-only practice still needs seasonal-clock correctness, but it may not need a visitor timezone selector. Clear practice-time display can be appropriate if the client is explicitly told what it means.
Your decision
Verify each dated instant and its labels. Do not promise that the visitor automatically sees local time unless that behaviour has been demonstrated.

3. Protect the work around the conversation

A session’s advertised duration and its effect on your diary are not identical. You may need time before it to prepare and time afterwards for notes or a break. Choose those periods from your actual service, and explain any effect on available start times.

Check how the calendar combines the gap after an existing session with the preparation before the next one. Setting fifteen minutes in both places may reserve thirty minutes between sessions. Rehearse adjacent appointments using the values you intend to keep.

Why this matters
A buffer extends the interval treated as occupied. Existing after-time and a new session’s before-time both matter to the overlap calculation. The visible start-time grid may then round the next offered appointment later.
Work through the example
Suppose a session runs 10:00–11:00 with fifteen minutes after it, and the next service needs fifteen minutes beforehand. Its start must be no earlier than 11:30 under this overlap model. Check the configured slot grid as well as that boundary.
When the approach changes
An in-person visit may need more travel time than an online session. A short administrative call may need a different pattern. There is no universal buffer that research can choose for your practice.
Your decision
Test the combined gap with each service pair. Use research as a reason to consider breaks, not as a claim that a particular number of minutes guarantees better outcomes.

4. Treat a calendar connection as something to verify

List which calendars contain commitments that must block bookings. Check busy versus free events, all-day events and recurring meetings. A connection label is not evidence that every relevant event is being read or that a recent change has arrived.

A calendar check needs to distinguish two answers: no conflicting event was found, and the calendar could not be checked. If both look like an empty diary, you cannot tell whether the opening is trustworthy. Agree what happens when a connection is unavailable: pause those bookings or require a person to confirm them.

For Gbeya, external calendar connectivity and its failure response remain requirements to demonstrate before you rely on them. The current review does not confirm a working connection. This is a scope limit, not a claim that a client has been double-booked.

Why this matters
Availability is only as complete as the conflict information supplied to it. When a provider fails, the operating process needs an explicit decision: pause affected bookings, require review or show another safe route. Silently treating uncertainty as availability cannot prove protection.
Work through the example
Ask the setup team to demonstrate a busy event in a separate test calendar, an unavailable connection and a changed occurrence of a recurring meeting. Check both the offered times and the warning shown to you. Use test records rather than real client appointments.
When the approach changes
If you deliberately operate from one maintained internal calendar and have no external commitments, an external feed may be unnecessary. Document that arrangement rather than connecting unused accounts for appearances.
Your decision
Rely on the connection only after the calendars you use, their event types, update timing and failure response have been demonstrated.

5. Test the race and the change, not only the happy path

Two people may choose the same opening before either finishes. A calendar that removes already saved bookings can still need stronger protection at the moment of creation. Test the final write and any payment handover before saying double bookings are impossible.

Also rehearse cancellation and rescheduling. The old appointment should stop occupying time only under the intended rule, the new time should be checked again, and the client should receive a clear outcome. A cancelled appointment is not, by itself, proof that money was refunded or a package credit restored.

Why this matters
A screen can show a free slot just before somebody else takes it. The final booking step must settle that conflict safely, rather than accepting both requests because both people saw an earlier opening.
Work through the example
Ask the setup team to test two people requesting the same appointment at once. Only the intended booking should be confirmed. Then test a valid move and a rejected move: the client must receive the outcome that was actually saved.
When the approach changes
A low-volume practice may choose manual confirmation while stronger automation is being verified. That is a service decision which must be communicated clearly, not presented as instant guaranteed booking.
Your decision
Open the workflow when competing requests and appointment changes have a demonstrated safe result. Give unresolved cases a named person and a clear temporary process.

    Make the calendar understandable before making it busier

    The official clock sources establish dated seasonal differences; they do not validate any application’s conversion. Calendar documentation illustrates event and display behaviour in one supplier’s system. These are useful test inputs, not proof that Gbeya has identical features.

    Workload guidance supports keeping demands compatible with agreed hours. A small supplier-run study examined fourteen people in video meetings with and without meditation breaks. It gives a reason to consider recovery time, but does not prescribe your coaching buffer or prove a client outcome. The public research report is not independent product validation.

    For this practice, choose understandable hours and tested conflict boundaries. The opposing case is a deliberately limited calendar with manual confirmation: it can be preferable to a broad automated promise that has not survived the difficult cases. Direct client and operator feedback remains necessary to refine the setup.

    Medium confidence in the operating recommendation; High confidence only in the cited dated clock facts, arithmetic and narrow source observations.

    No live booking, payment or calendar outage was used for this review. The guidance does not replace a demonstration of your configured calendar.

    Adjacent-session calculation with stated assumptions

    Two fifteen-minute buffers can create a thirty-minute gap

    Suppose the first appointment runs from 10:00 to 11:00 and its after-buffer is fifteen minutes. Its protected interval ends at 11:15. The next service needs fifteen minutes before its start, so a start at 11:30 places that preparation at 11:15. With an assumed thirty-minute start grid, 11:30 is a compatible boundary. These are the assumed preparation intervals for this example. Your calendar still needs to demonstrate the same result.

    11:00 + 15 minutes after-buffer + 15 minutes before-buffer = 11:30 earliest next start, before other availability checks.

    An external busy event, longer preparation requirement or different start grid can push the offered time later. Do not infer a guaranteed slot from the arithmetic alone.

    Calculate the protected intervals, then verify the actual picker and saved appointment.

    Assumptions worth checking

    The times look correct today, so the timezone setup is finished.

    A dated clock-change case and the client’s confirmation can reveal a different problem. Test the specific moments you promise.

    A connected calendar proves that unavailable times always stay blocked.

    Coverage, freshness and provider failure handling need their own evidence.

    An experienced coach only needs to add a buffer to the new service.

    Existing booking buffers also affect the next available start. Test the combination.

    Your next 30 days

    1. Days 1–7

      Write the calendar promise

      Define the practice timezone, delivery hours, service durations, preparation needs and exceptions.

      Ready for the next step: A colleague can explain what times should be offered.

    2. Days 8–14

      Configure and compare

      Set the demonstrated controls and inspect adjacent bookings plus dated timezone cases.

      Ready for the next step: Expected and observed times agree, with missing controls listed.

    3. Days 15–21

      Test conflict boundaries

      Use seeded tests for external provider failure, recurring events and competing requests.

      Ready for the next step: Each critical failure has a safe result or an explicit temporary operating process.

    4. Days 22–30

      Check changes and release

      Rehearse cancellation, rescheduling and confirmation before opening a bounded window.

      Ready for the next step: The public promise matches the verified journey; thirty days is not a forced launch deadline.

    Questions before you proceed

    Can I block a particular date?

    Blocked dates belong in your availability plan. Confirm that the date you choose disappears from the client-facing calendar in the intended timezone before relying on it.

    Are alternating weeks and daily caps available?

    The 30 October 2026 review did not establish those controls. If your practice needs them, include them explicitly in the setup requirements and request a demonstration before opening that schedule.

    Will clients see their own timezone automatically?

    Do not assume automatic conversion. Ask a person in the client timezone to check a dated appointment and its confirmation. The current review did not establish client-local conversion in Gbeya.

    Do buffers prevent every calendar conflict?

    No. Buffers reserve preparation and recovery time. Calendar coverage, unavailable connections and simultaneous requests need separate protection.

    Does an external calendar failure block bookings?

    A working external calendar connection and a safe failure response were not established in the 30 October 2026 Gbeya review. Agree and demonstrate both before relying on external commitments to block appointments.

    Does cancellation automatically refund a client?

    Appointment, payment and package-credit outcomes are separate. Verify each relevant workflow rather than inferring them from a cancelled status.

    Sources and further reading

    Prepared by Gbeya · Sources reviewed 30 October 2026.