Kapazitätsmanagement in Gruppenbuchungssystemen: Modelle, Wartelisten und der Betrieb nach „ausgebucht“

Ausgangspunkt und begrifflicher Rahmen: Das Grundproblem unserer Forschung („es wird voll, wird geschlossen, dennoch bleiben leere Plätze“) ist kein Einzelfehler, sondern eine typische Folge davon, dass Buchung (Registrierung/Ticket) und tatsächliche Teilnahme zwei unterschiedliche Messgrößen sind. Dies ist nicht nur in der Service- (Termin-)Logik sichtbar, sondern auch in der „ticketbasierten“ Welt: Bei Sportveranstaltungen ist die „reported attendance“ oft die Anzahl der ausgegebenen/verkauften Tickets, während die „actual attendance“ die auf Basis von Zutrittsprüfungen (z. B. gescannte Tickets) gemessene Anwesenheit ist; die Differenz zwischen beiden erscheint in der Fachliteratur konkret als „ticket holder no-shows“. [1]

Dasselbe Grundphänomen ist auch in der Terminbuchungsforschung strukturell dokumentiert: No-Shows und späte Stornierungen verursachen Kapazitätsverluste, und die klassische Gegenstrategie von Organisationen ist Overbooking (Überbuchung) sowie ein prädiktiver (wahrscheinlichkeitsbasierter) Ansatz. [2]

Die in unserer Forschung betrachteten Systeme, bei denen das „Nach-Ausbuchung“-Verhalten untersucht werden kann: Bookcessful[4], Eventbrite[4], Calendly[5], Setmore[6], booked4.us[7], Salonic[8], TidyCal[9], HubSpot[10].

Die drei Schlüsselbegriffe (zur Präzisierung der Logik unserer Forschung):

Buchung / Anmeldung (booking/registration): ein administrativer Zustand, der Kapazität reserviert (oder ein Ticket zuweist), aber die Teilnahme nicht garantiert. [11]

Kapazität (capacity): die tatsächlich bedienbare Anzahl an Plätzen/Sitzen/Slots.

Tatsächliche Teilnahme (actual attendance / show-up): die reale Anwesenheit/Zutritt – die von der Anzahl der Buchungen abweichen kann. [11]

Daraus folgt: Ein „Gruppenbuchungssystem“ ist keine bloße Funktionsliste (gibt es ein Sitzlimit), sondern ein Betriebsmodell – insbesondere in dem Moment, in dem die Kapazitätsgrenze erreicht wird. [12]

Warum Plätze leer bleiben, obwohl „ausgebucht“

Typische Ursachen des Paradoxons „ausgebucht → leerer Sitz“ (ergänzt durch Quellen):

Freigewordene Plätze durch Stornierungen und späte Änderungen, die das System nicht schnell genug oder nicht kontrolliert genug nachbesetzt. Wartelisten und Backfill entstehen genau für dieses Problem: Freigewordene Plätze sollen nicht verloren gehen, sondern neu zugewiesen werden. [13]

No-Show als dauerhaftes, planbares Phänomen. Laut einer Synthese zahlreicher Studien liegt die durchschnittliche No-Show-Rate bei etwa 23 % (je nach Bereich und Region), wobei wesentliche Faktoren unter anderem lange Vorlaufzeiten (lead time) und frühere No-Show-Erfahrungen sind. [14] Obwohl dies eine gesundheitsbezogene Metaanalyse ist, ist die strukturelle Erkenntnis identisch: Wenn Buchung und Teilnahme voneinander abweichen, kann Kapazität nicht statisch verwaltet werden.

Auch in Ticket- und Registrierungssystemen ist die Trennung „reported vs actual“ messbar. Ticket-Audits (ausgegebene Tickets vs tatsächlicher Eintritt) sind ein zentrales Instrument zur Messung von No-Shows. [1]

Das Management des Zustands nach Ausbuchung ist oft nicht automatisiert, sondern erfordert organisatorische Arbeit. Die Wartelistenverwaltung von Eventbrite ist ein gutes Beispiel: Das Freigeben von Tickets an die Warteliste erfordert explizite manuelle Schritte (Manage Waitlist → Auswahl → Release). [15]

UI-Entscheidungen des Systems (verschwindende vs als „full“ markierte Slots) verzerren Nachfrage und Auslastung. Beispiel: Im Community-Forum von Calendly wird explizit gefordert, dass ausgebuchte Zeitfenster nicht verschwinden, sondern als „full“ sichtbar bleiben (aus FOMO-/Dringlichkeitsgründen), da „disappearing slots“ eine andere Nutzererfahrung und andere Konversionsdynamik erzeugen. [16]

Kapazitätsmanagement-Modelle und operative Unterschiede

Die drei Modelle unserer Forschung sind eine gute Grundlage, aber in realen Systemen lohnt sich eine Präzisierung: Das Verhalten nach Ausbuchung lässt sich in mehrere Submuster aufteilen, insbesondere je nach Wartelisten- und Nachbesetzungslogik.

Schließungsbasiertes Modell

Das System erreicht das Limit und stoppt einfach (keine Überbuchung, keine strukturierte Warteliste). Das reduziert das Risiko (keine Überbuchung), erhöht aber die Wahrscheinlichkeit leerer Plätze, wenn Stornierungen nicht rechtzeitig neue Teilnehmer finden. [17]

Zeitslot-basiertes Modell

Das Produkt verwaltet primär Zeitfenster (Meeting-Scheduler-Logik), und die Gruppenfunktion ist lediglich eine „multi-invitee per slot“-Erweiterung. Daraus folgt: „Ausgebucht“ ist hier ein Zustand der Verfügbarkeit eines Zeitfensters, nicht ein klassischer Event-Lebenszyklus. [18]

Kapazitäts-Umverteilungsmodell

Der Kern: Das System trennt „freigewordener Platz“ und „öffentliche Wiederfreigabe“. Es öffnet nicht einfach neu, sondern führt Backfill aus: wählt einen Kandidaten, sendet ein Angebot / befördert automatisch, setzt eine Frist und erstellt erst danach eine endgültige Buchung. [19]

Wartelistenmuster, die implizit in unserer Forschung enthalten sind:

Die Warteliste ist kein einheitliches Konzept; mindestens drei grundlegende Verhaltensweisen lassen sich unterscheiden:

„Notify-all“ + first-come-first-served: Wenn ein Platz frei wird, wird die Liste benachrichtigt, und der Schnellste erhält den Platz. Typisches Risiko: Wettbewerb und Fairnessprobleme. [20]

„Temporary hold“: Das System reserviert den Platz temporär für einen Kandidaten. Dieses Muster erscheint auch als Offer backfill in der Bookcessful-Dokumentation. [21]

„Firm booking“ / autopromote: Das System erstellt sofort eine Buchung aus der Warteliste. Vorteil: Geschwindigkeit; Nachteil: geringere Kontrolle der Teilnehmerabsicht. [22]

Diese Muster bilden das Zentrum unserer Forschung: Der Unterschied wird genau dann sichtbar, wenn die Kapazität erreicht ist. [23]

Präzisierung der Aussagen unserer Forschung in Tabellenform

Die Kapazitätslogik und das „Nach-Ausbuchung“-Verhalten der genannten Systeme

Die folgende Tabelle zerlegt gezielt den in unserer Forschung behandelten Wendepunkt (ausgebuchte Veranstaltung): was das System macht, wenn ein Platz frei wird, und wie viel manuelle Arbeit übrig bleibt.

Foren- und Community-Feedback zum „Nach-Ausbuchung“-Betrieb

Eine der expliziten Anforderungen unserer Forschung war es, Meinungen zu zitieren, die unabhängig vom Marketing sind und aus dem „realen Leben“ stammen. Die folgenden Beispiele sind anekdotische Quellen (nicht repräsentativ), zeigen jedoch sehr deutlich, wo der operative Schmerzpunkt nach dem Erreichen der vollen Kapazität liegt.

Eventbrite: die Warteliste ist häufig „halb manuell“

Eine Frage aus der Eventbrite-Community (Reddit) spricht genau die Funktionsweise an, die unsere Forschung als „Angebotsmechanismus“ bezeichnet – und beklagt, dass diese fehlt:

“It’s a bit of a pain having to monitor the waiting list and manually release the tickets at the right time.” [41]

Eine externe, institutionelle Praxisbeschreibung (Handbuch zur Organisation von Workshops) gibt zudem eine konkrete operative Regel vor: Den ausfallenden Teilnehmer nicht sofort stornieren, da dadurch ein Platz entsteht, ohne dass jemand automatisch von der Warteliste nachrückt; stattdessen zuerst „release“ an die Warteliste, und erst danach den Teilnehmer stornieren. Darüber hinaus wird erwähnt, dass der eingeladene Teilnehmer in der Regel etwa einen Tag Zeit hat, den Platz zu „claimen“. [42]

Ein weiterer Reddit-Thread weist auf ein UI-/Edge-Case-Problem hin: In bestimmten Fällen ist die Wartelistenoption in der mobilen App nicht sichtbar, obwohl sie im Browser verfügbar ist, und laut Beitrag konnte auch der Support keine Lösung anbieten. [43]

Diese Rückmeldungen zusammen stützen die Aussage, dass die Warteliste zwar „existiert“, die Nachbefüllung nach Erreichen der vollen Kapazität jedoch nicht zwingend automatisiert ist, und dass es leicht zu einem „lückenhaften“ Zustand kommen kann, wenn kein disziplinierter interner Prozess vorhanden ist. [44]

Calendly: Gruppenslots vorhanden, native Warteliste fehlt

Calendly beschreibt offiziell den Gruppentermin-Typ (Teilnehmerlimit, Anzeige der verbleibenden Plätze usw.). [45] Gleichzeitig wird in der eigenen Community klar festgestellt, dass es keine native „waiting list“-Funktion gibt. [46]

Parallel dazu taucht in der Community-Diskussion auch die Frage „verschwindender Slot vs. als voll angezeigter Slot“ auf, was eines der wichtigsten und häufig unterschätzten UX-Elemente im Verhalten nach Ausbuchung ist. [16]

Setmore: „Gruppierung“ ist oft ein Workaround, keine native Logik

Die offizielle Beschreibung von Setmore für Class Booking definiert ein Sitzlimit und ein Verhalten, bei dem das System im Falle von „voll“ geschlossen wird. [26] Eine Reddit-Frage zeigt jedoch, dass Nutzer häufig genau das Szenario lösen wollen, bei dem mehrere Teilnehmer denselben Slot selbstständig buchen können – und wenn dafür keine elegante Lösung vorhanden ist, wird ein administrativer Workaround (Double Booking) verwendet, was genau die organisatorische Belastung widerspiegelt, die in unserer Forschung kritisiert wird: [35]

“I can’t seem to figure out how to allow two athletes to sign up in each 30min appointment slot… requires the admin (me) to use double booking…” [35]

TidyCal: positives Preis-Leistungs-Verhältnis, aber diskutierte Zuverlässigkeit und Teamfunktionen

Auf der Plattform AppSumo (Nutzerbewertungen) findet man gleichzeitig eine insgesamt positive Wahrnehmung und deutliche Kritik, insbesondere im Zusammenhang mit Teamnutzung und Zuverlässigkeit (z. B. Kalenderkonflikte). [47] Die „group bookings“-Logik ist dokumentiert einfach (der Slot verschwindet bei Erreichen der Kapazität), was eine attraktive Form von Minimalismus darstellt, jedoch die Fairness- und Prioritätslogik nach Ausbuchung nicht von selbst löst. [27]

Salonic: Stimmung aus einem ungarischen Forum – „Rückschritt“ zu einfacheren Lösungen

In einem ungarischsprachigen Reddit-Thread erscheint die praktische Erfahrung, dass ein Nutzer zu einer „einfachen Formularlösung“ zurückgewechselt ist, und formuliert dies konkret mit: „I switched from Salonic…“. [48] Dies ist keine direkte Kritik am Kapazitätsmodell, zeigt jedoch, dass in vielen Fällen die operative Realität (telefonische Abstimmung, manuelle Kontrolle) die Versprechen des Systems überlagert. [48]

HubSpot: die Community signalisiert, dass es kein „Seats-per-slot“-Produkt ist

HubSpot unterstützt Group- und Round-Robin-Scheduling-Seiten (auf Basis der Verfügbarkeit mehrerer Teammitglieder). [37] Gleichzeitig ist in der Community seit Jahren ein wiederkehrender Bedarf sichtbar nach der Möglichkeit, dass mehrere Teilnehmer denselben Slot buchen können („Allow multiple people to book… during the same time“), was darauf hinweist, dass das Produktmodell grundsätzlich nicht auf diese Logik ausgelegt ist. [49]

Erweiterte Studie: Wie sieht ein gut funktionierender „Nach-Ausbuchung“-Betrieb aus

Zur Erweiterung unserer Forschung ist es sinnvoll, den Moment der „Ausbuchung“ nicht als Endzustand, sondern als Zustandswechsel im Lebenszyklus zu betrachten: Ab diesem Punkt besteht die Hauptaufgabe des Systems nicht mehr darin, neue Buchungen zu ermöglichen, sondern die Kapazität (Auslastung) durch kontrollierte Umverteilung zu erhalten, während gleichzeitig die Belastung der Organisatoren und die Frustration der Teilnehmer minimiert werden. [50]

Die „Nach-Ausbuchung“-Zustandsmaschine als Entwurfsgrundlage

In einem funktionierenden Gruppenbuchungssystem existieren typischerweise die folgenden Zustände und Übergänge (Formalisation der Logik unserer Forschung):

Open (buchbar) → (Kapazität erreicht) → Full (ausgebucht)

Vom Zustand „Full“ führen mehrere Wege weiter:

Full → Reopen: Im Falle einer Stornierung wird der Slot wieder öffentlich; wer schnell ist, bekommt ihn. Dies ist die einfachste Lösung, aber problematisch hinsichtlich Fairness und Wettbewerb, und die Konversion ist oft vom Zeitfenster abhängig. Dieses Muster entspricht dem Verhalten mehrerer zeitslot-basierter Produkte. [51]

Full → Waitlist (Warteschlange): Die Nachfrage verschwindet nicht, sondern wird in eine Reihenfolge gebracht. [52]

Waitlist → OfferPending (Angebot in Bearbeitung): Das System wählt einen Kandidaten aus und sendet ein zeitlich begrenztes Angebot. [22]

OfferPending → Booked: Bei Annahme entsteht eine endgültige Buchung; oder OfferPending → Expired/Rejected → nächster Kandidat. [22]

Alternative: Waitlist → Autopromote → Booked (sofortige Beförderung) – schnell, aber geringere Kontrolle über die Teilnehmerabsicht. [22]

In dieser Struktur ist der Angebotsmechanismus keine zusätzliche Funktion, sondern die minimale Voraussetzung für konfliktfreie Umverteilung: Wenn mehrere Personen gleichzeitig den freien Platz sehen, entsteht Wettbewerb; wenn das System „zuteilt“ (offer/hold), gibt es keine parallelen Konflikte. [53]

Kapazitätsstrategie-Auswahl: Welches Modell funktioniert wann

Unsere Forschung ist nützlich, aber es lohnt sich, die Entscheidungsregeln klar zu benennen. Das Modell ist keine Frage von „besser oder schlechter“, sondern von Kontext.

Schließung/Wiederöffnung (reopen) ist ausreichend, wenn: - die No-Show- und Stornierungsrate niedrig ist (oder leere Plätze keine Kosten verursachen), - die Nachfrage nicht außergewöhnlich hoch ist (kein Wettbewerb um frei werdende Plätze entsteht), - keine Fairness-Erwartung besteht (es ist akzeptabel, dass der Schnellste gewinnt). [51]

Warteliste + offer/hold ist erforderlich, wenn: - die Nachfrage dauerhaft größer ist als die Kapazität (Ausbuchung häufig ist), - Stornierungen zeitlich nahe am Ereignis liegen (für die öffentliche Nachbesetzung bleibt wenig Zeit), - Fairness und Kontrolle wichtig sind, - der Organisator nicht kontinuierlich „überwachen und manuell freigeben“ möchte. [54]

Autopromote funktioniert, wenn: - die Teilnehmerbindung hoch ist (z. B. Vorauszahlung, starke Sanktionen), - das Risiko „falscher“ automatischer Buchungen gering ist, - das Ziel maximale Auslastung und minimale Administration ist. [55]

Prädiktives Overbooking (in unserer Forschung nicht enthalten, aber als „vertiefende“ Ergänzung relevant) ist sinnvoll, wenn: - No-Show-Raten hoch und zuverlässig schätzbar sind, - Überlauf (zu viele tatsächlich Erscheinende) geschäftlich handhabbar ist, - Daten (Vergangenheit) vorhanden sind und Bereitschaft zum Risikomanagement besteht. [56]

Prozesse nach ausgebuchten Veranstaltungen: ein „operatives Playbook“

Die folgende Prozessbeschreibung zielt auf das am Ende unserer Forschung erwähnte Phänomen des „Chaos nach Ausbuchung“: wie dieses durch Systemlogik deterministisch gemacht werden kann.

Kommunikatives und operatives Minimum (modellunabhängig): - automatische Erinnerungen und klare Stornierungswege (insbesondere bei langen Vorlaufzeiten, da diese laut Literatur ein Treiber für No-Shows sind). [57] - explizite Regeln: bis wann storniert/geändert werden kann und was danach geschieht (späte Stornierungen sind die teuersten). [58]

Wenn das System auf Warteliste + Angebot basiert:

1. Aufnahme in die Warteliste (Zeitstempel + Präferenzen: Zeitfenster, Termin, Ort). [22] 2. Trigger: Stornierung, Admin-Löschung, Freigabe durch Umplanung. [22] 3. Kandidatenauswahl: Reihenfolge + Filter (z. B. Event-Warteliste zuerst, danach servicebasierte Reserve – Bookcessful-Logik). [22] 4. Angebot (offer): ein Kandidat, feste Ablaufzeit; Schutzmechanismen (keine parallelen Angebote für denselben Platz). [22] 5. Bei Annahme: automatische Buchung; bei Ablehnung/Ablauf: nächster Kandidat. [22] 6. Audit: Status (pending/accepted/rejected/expired) – dies schafft operative Transparenz. [22]

Wenn das System eher manuell ist (Eventbrite-ähnlich), aber Kontrolle gewünscht ist: - Laut Organisationshandbuch: nicht sofort stornieren, sondern zuerst an Warteliste freigeben, dann löschen, um ein Umgehen der Warteliste zu vermeiden. [42] - Claim-Zeitfenster definieren (z. B. 24 Stunden) und internes Monitoring sicherstellen, sonst bleibt der Platz leer. [59]

Was oft in „Gruppenbuchungs“-Funktionen fehlt

Unsere Forschung zeigt korrekt, dass sich unter dem Label „Gruppe“ unterschiedliche Welten verbergen. Für die vertiefte Betrachtung sollten typische Defizite benannt werden:

Fairness und Priorität: Ohne Wartelistenpriorität (oder zumindest seat-hold) wird die Vergabe nach Ausbuchung zu „wer schneller ist, gewinnt“. Dies wird durch Calendly-Diskussionen bestätigt. [60]

Konsistente Backfill-Regeln: Die Belastung entsteht dort, wo Systeme nur Listen liefern, aber keine Logik zur Nachbesetzung. Eventbrite-Beispiele zeigen dies deutlich. [61]

Transparente Status: Eine Warteliste ist kein einzelnes Objekt, sondern eine Abfolge von Zuständen (pending/offer/accepted/expired). Ohne diese entsteht Chaos. Bookcessful behandelt dies explizit als Lebenszyklus. [22]

Die „Multi-Ticket“-Falle: In manchen Systemen erscheint die Warteliste nur, wenn alle Tickettypen ausverkauft sind. Dies ist ein häufiger Edge-Case. [62]

Abschließende, erweiterte Schlussfolgerung auf Basis unserer Forschung

Die wichtigste (und durch Forschung gestützte) Aussage ist: Im Moment der „Ausbuchung“ endet die Buchung nicht – das Kapazitätsmanagement beginnt. [50]

Der reale Unterschied zwischen Systemen liegt daher nicht darin, ob sie eine Warteliste haben, sondern darin:

Ob frei werdende Plätze öffentlich oder kontrolliert vergeben werden (reopen vs offer/hold vs autopromote). [63]

Wie stark der Prozess automatisiert und auditierbar ist oder ob er auf manuelle Kontrolle zurückfällt. [64]

Wie die Teilnehmerabsicht validiert wird (sofortige Buchung vs zeitlich begrenzte Annahme), was direkt mit No-Show- und Stornierungsmanagement zusammenhängt. [65]

In diesem Rahmen ist die Typologie unserer Forschung korrekt, aber die vertiefte Erweiterung besteht darin, das Kapazitäts-Umverteilungsmodell nicht als Feature, sondern als Kombination aus Zustandsmaschine + Regelwerk + operativer Disziplin zu betrachten und Systeme ausschließlich durch diese Linse zu vergleichen. [66]

Literaturverzeichnis

[1] [9] [11] Vorhersage von Ticketinhaber-No-Shows: Untersuchung der Unterschiede zwischen gemeldeter und tatsächlicher Teilnahme bei College-Football-Spielen - Nels Popp, Jason Simmons, Stephen L. Shapiro, Nick Watanabe, 2023

https://journals.sagepub.com/doi/10.32731/SMQ.321.032023.01

[2] [14] [57] [58] No-Shows in der Terminplanung – eine systematische ...

https://www.sciencedirect.com/science/article/abs/pii/S0168851018300459

[3] [30] Funktionen eines Online-Buchungssystems - booked4.us

https://booked4.us/en/functions/

[4] [5] [7] [12] [13] [19] [22] [23] [28] [50] [53] [54] [55] [63] [65] [66] Wartelisten-Automatisierungen | Bookcessful

https://bookcessful.com/en/documentation/waitlist-automations

[6] [56] Entwicklung eines prädiktiven No-Show-Modells für Patienten ... - PMC

https://pmc.ncbi.nlm.nih.gov/articles/PMC4187098/

[8] [17] [26] Kursbuchung | Support - Setmore: Kostenlose Online-Terminplanungssoftware

https://support.setmore.com/en/articles/490889-class-booking

[10] [32] [42] [59] Eventbrite-Warteliste — Die SI Carpentries Handbuch-Dokumentation

https://smithsonianworkshops.github.io/si-carpentries-handbook/eventbrite_waitlist.html

[15] [24] [31] [44] Wie man Tickets an die Warteliste freigibt | Eventbrite Hilfe-Center

https://www.eventbrite.com/help/en-us/articles/817355/how-to-manually-release-tickets-to-the-waitlist/

[16] [60] Können vollständig ausgebuchte Zeitfenster als „voll“ angezeigt werden, anstatt zu verschwinden? | Community

https://community.calendly.com/how-do-i-40/can-completely-booked-time-slots-be-displayed-as-full-instead-of-disappearing-3011

[18] [25] [33] [45] Übersicht zum Gruppentermin-Typ – Hilfe-Center

https://help.calendly.com/hc/en-us/articles/14073282345111-Group-event-type-overview

[20] [21] Warteliste - Booking Activities

https://booking-activities.fr/en/downloads/waiting-list/

[27] [36] [51] Buchungstypen - TidyCal FAQ

https://help.tidycal.com/article/686-booking-type

[29] [37] Erstellen von Terminplanungsseiten mit dem Meetings-Tool

https://knowledge.hubspot.com/meetings-tool/create-and-edit-scheduling-pages

[34] [46] Gibt es eine Möglichkeit, dies als Warteliste zu verwenden?

https://community.calendly.com/how-do-i-40/is-there-any-way-to-use-this-as-a-waitlist-1174

[35] Setmore Hilfe : r/athletictraining

https://www.reddit.com/r/athletictraining/comments/148el5b/setmore_help/

[38] Meetings für mehrere Teilnehmer

https://community.hubspot.com/t5/Sales-Hub-Tools/Meetings-for-multiple-attendees/m-p/36167

[39] [40] Online-Terminbuchung für Trainer, Yogalehrer, ...

https://blog.salonic.hu/online-idopontfoglalo-edzoknek-joga-oktatoknak-mozgasstudioknak/

[41] [61] [64] Tickets an eine Warteliste freigeben : r/Eventbrite

https://www.reddit.com/r/Eventbrite/comments/1kxdi6g/releasing_tickets_to_a_waiting_list/

[43] SOS Wartelistenproblem - zeitkritisch! : r/Eventbrite

https://www.reddit.com/r/Eventbrite/comments/1l0v1o4/sos_waitlist_problem_time_sensitive/

[47] TidyCal Bewertungen 2026: Verifizierte Bewertungen, Vor- und Nachteile

https://appsumo.com/products/tidycal/reviews/?srsltid=AfmBOoqDWjzW4YqQICjVvRO8peRhAkYRaXz5KowkANQbMAL9EoYtJF0M

[48] Terminbuchungssystem : r/programmingHungary

https://www.reddit.com/r/programmingHungary/comments/1n83xk1/id%C5%91pontfoglal%C3%B3_rendszer/?tl=en

[49] Mehrere Personen erlauben, einen Termin zur gleichen Zeit zu buchen ...

https://community.hubspot.com/t5/HubSpot-Ideas/Allow-multiple-people-to-book-a-Meeting-during-the-same-time/idi-p/34662

[52] Best Practices für Buchungs-Wartelisten | Bookcessful

https://bookcessful.com/en/guides/best-practices-for-booking-waitlists

[62] Wie man eine Warteliste erstellt - Wissensdatenbank

https://theeventscalendar.com/knowledgebase/how-to-create-a-waitlist