Recurring bookings

Keep repeating appointments consistent.

Check each visit—not just the series rule—when a date, staff member, or cancellation changes.

First checks

Generate real occurrences
Check every proposed date rather than treating the pattern as one endless calendar block.
Choose a conflict outcome
Reject, skip, or resolve unavailable dates before the customer believes they are booked.
Make edit scope explicit
One occurrence, this and future, and the complete series are different changes.
Keep states per visit
Staff, resources, money, messages, and external calendars may differ by occurrence.

Series conflict checker

What should happen when some occurrences are unavailable?

Set the number of visits, list the unavailable occurrence numbers, and choose the business's conflict policy. The result shows the complete occurrence ledger before any real booking is made.

Your result

Resolve conflicts first

Keep the series unconfirmed while 2 unavailable occurrences are moved, replaced, or explicitly skipped.

Total visits: 6
Confirmed now: 0
Ready after resolution: 4
Conflicts: 2

Visit 1Ready

Visit 2Ready

Visit 3Needs resolution

Visit 4Ready

Visit 5Needs resolution

Visit 6Ready

This planning aid does not calculate calendar dates, find alternatives, reserve staff or resources, create payments or events, send notifications, or prove product behavior.

Why a repeat rule is not a confirmed series

One available start time does not make every future date available.

A weekly appointment may fit today but conflict with staff leave, another booking, a closed location, a missing room, a holiday, or an external calendar on a later date. The system must generate the proposed occurrences, check each one, and explain what happens to the exceptions.

The series rule

Safe series = repeat rule + per-date availability + explicit conflict outcome + clear edit scope

A six-visit weekly series has conflicts on visits 3 and 5. The customer should see whether the whole series is rejected, those visits are skipped, or alternatives must be resolved before anything is confirmed.

Follow the complete recurring-booking workflow

A recurring appointment is a set of linked private visits generated from one repeating rule. Each occurrence still needs its own staff, time, place, resources, payment state, calendar event, and later change history.

Keep one repeating rule without losing control of each real appointment it creates.

Define the repeating rule
Record frequency, interval, weekdays, start, end condition, time zone, service, customer, and default staff or resource requirements.
Generate concrete occurrences
Turn the rule into a dated list the customer and staff can review. A pattern alone cannot reveal holidays, leave, or later conflicts.
Validate every date
Check staff, location, service eligibility, resources, buffers, travel, policies, and external-calendar conflicts for each occurrence.
Apply one conflict policy
Reject the whole series, skip unavailable dates, or resolve each exception before confirmation. Never hide the chosen outcome.
Confirm the occurrence ledger
Store the actual dates and their individual states so payments, messages, calendar events, attendance, and later recovery remain traceable.
Ask for scope on every change
Before editing or cancelling, make the operator choose one occurrence, this and future occurrences, or the complete series and preview the effect.

Compare the five recurring-booking concepts

Recurrence rule

Example: every second Tuesday at 10:00 for six visits.

Rule: The rule generates proposed dates; it does not replace the occurrence records or their availability checks.
Watch for: Changing the rule after exceptions exist can silently regenerate dates and lose earlier decisions.

Occurrence

Example: the third Tuesday visit with its own staff member, room, payment, and calendar event.

Rule: Give every occurrence a stable identity and state while preserving its link to the series.
Watch for: Do not make one visit impossible to edit, cancel, attend, refund, or audit independently.

Series exception

Example: visit 3 moves to Wednesday because the employee is away on Tuesday.

Rule: Preserve the exception explicitly so later series edits do not overwrite it without warning.
Watch for: A moved or skipped occurrence should not quietly reappear when the pattern is edited.

Edit scope

Example: change only visit 4, visit 4 and all following visits, or the complete six-visit series.

Rule: Preview which dates, staff, resources, prices, calendars, and messages the chosen scope will change.
Watch for: A vague Save button can update too much, update too little, or split calendars and customer history.

Enrollment or entitlement

Example: access to a six-week class or six redeemable package credits.

Rule: Keep access or credit ownership separate from a private appointment's repeating date rule.
Watch for: A package does not reserve future dates, and class enrollment is not several copies of one private appointment.

Recheck changes and demo failures

Edit one occurrence

Preserve the series and create one visible exception

Recheck the proposed visit, update only its dependent records, and keep future occurrences attached to the original rule.

Edit this and future

Split the series at a clear boundary

Preserve history before the chosen occurrence and generate or revalidate every affected future date under the new rule.

Edit the whole series

Preview every affected occurrence

Show how existing exceptions, completed visits, payments, staff, resources, and calendars will be treated before applying the change.

Cancel one occurrence

Cancel one visit, not the relationship

Apply that visit's message, refund, credit, no-show, and resource-release rules without deleting the customer or remaining series.

Cancel future or complete series

Name the cutoff and reconcile each visit

Keep completed history, cancel only the chosen scope, release future holds, and explain money or credit consequences per occurrence.

Availability changes later

Find impacted future occurrences

Staff leave, room maintenance, location hours, service changes, or external-calendar events should create a review queue rather than silently moving or deleting visits.

Only the first date is checked

The series confirms from one available slot while later occurrences overlap leave, closures, resources, or other bookings.

Unavailable dates disappear

The customer sees a series total but cannot identify which visits were rejected, skipped, moved, or left unresolved.

Edit scope is implicit

A time, staff, or service change updates an unknown portion of the series without a preview of dates and dependent records.

External calendars split the series

Occurrence edits create duplicate, orphaned, or inconsistent third-party events that no longer match the booking system.

Cancellation loses history

Cancelling one or future visits deletes completed occurrences, customer notes, payments, credits, or the evidence needed to explain the account.

Use six weekly visits, conflicts on visits 3 and 5, and three edit scopes.

A recurring-appointments feature name proves little. Give every shortlisted product the same series, force the same exceptions, and inspect the customer, staff, calendar, resource, and money records after each change.

Create a six-occurrence private series with fixed conflicts on occurrences 3 and 5, then record the exact pre-confirmation outcome.
Resolve one conflict, skip the other, and edit one occurrence, this and future, and the whole series while preserving visible history.
Cancel one visit and then the remaining future visits, checking released holds, payments or credits, calendars, and notifications.