Skip to content

Sliding-window search (search length vs booking duration)

Two numbers control how the search engine finds bookable slots:

SettingMeaning
Booking durationHow long the appointment actually is on the calendar.
Search lengthThe width of the window the search engine walks across the resource’s schedule.

Most of the time they’re equal. When they’re not, the difference is intentional and useful.

Conceptually:

  1. The search engine takes the appointment type’s resources (one or more).
  2. For each resource, it walks the resource’s schedule from the search start time forward.
  3. At each position it checks: is the next search-length of time fully inside an available, unblocked window with enough parallel-booking capacity?
  4. If yes — emit that position as a bookable slot. Advance the window.
  5. If no — advance the window and try again.

The booking duration determines how long the actual booking occupies the calendar once made. The search length determines how the search filters slots.

This is the common case. A 60-minute “Probetraining — Minis” with a 60-minute search length emits a bookable slot every time it finds 60 free minutes.

This builds a buffer into the schedule.

Example: an “Online Beratung” lasts 30 minutes but the coach needs 10 minutes between calls to reset. Set:

  • Booking duration: 30 min
  • Search length: 40 min

Now the search only emits a slot when 40 free minutes are available, but the booking itself only occupies 30 minutes. The remaining 10 minutes is implicit padding.

You can also use this to enforce minimum gaps between similar appointments without modeling the gap explicitly.

Rare but supported. Useful when you want bookings to be allowed to overflow an availability window — e.g. a 90-minute course that’s bookable as long as the first 60 minutes are free. Most operators never need this.

If the same appointment type runs at different durations on different days (a 30-minute Minis class on Tuesday, a 60-minute Minis class on Thursday), neither the booking duration nor the search length can hold the truth. The current workaround is to model each variant as its own resource + appointment-type pair — see Variable-length courses.

A planned feature will let an appointment type “inherit” its booking duration from the resource slot — meaning a single appointment type can serve variable-length slots without duplication. Not built yet.

Debugging “the search returns no slots”

Section titled “Debugging “the search returns no slots””

When the public form or the internal booking flow returns no slots:

  1. Für Interessenten buchbar on the slots? See the dedicated article. 95% of cases.
  2. Is the appointment type’s search length > the available resource slots? If you set a 90-minute search length but every slot in the schedule is 60 minutes long, the engine will find nothing.
  3. Are the resource slots in the future? Past slots don’t count.
  4. Is the resource you’d expect to serve the appointment type actually mapped to it?