research
Csoportos foglalási rendszerek kapacitáskezelése: modellek, várólisták és a teltház utáni működés
2026. március 29.
Kutatásunk bemutatja, hogyan kezeljük a csoportos foglalási rendszerek kapacitását teltház után: modellek, várólisták, backfill és operációs döntési szabályok
Kiindulópont és fogalmi keret
Kutatásunk alapproblémája („betelik, lezár, mégis üres hely marad”) nem egyedi hiba, hanem tipikus következmény abból, hogy a foglalás (regisztráció/jegy) és a tényleges részvétel két külön mérőszám. Ezt nem csak a szolgáltatás- (időpont) logikában látni, hanem „jegyalapú” világban is: sporteseményeknél a „reported attendance” sokszor a kiosztott/értékesített jegyek száma, míg az „actual attendance” a beléptetési (pl. szkennelt ticket) audit alapján mért jelenlét; a kettő közti eltérés konkrétan „ticket holder no-shows” néven jelenik meg a szakirodalomban. [1]
Ugyanez az alapjelenség az időpontfoglalás-kutatásban is strukturálisan dokumentált: a no-show és a késői lemondás kapacitásveszteséget okoz, és a szervezetek klasszikus ellenstratégiája az overbooking (túlfoglalás), illetve a prediktív (valószínűségi) megközelítés. [2]
Kutatásunkban szereplő rendszerek, amelyeknél a „teltház utáni” működés vizsgálható: Bookcessful[4] , Eventbrite[4] , Calendly[5] , Setmore[6] , booked4.us[7] , Salonic[8] , TidyCal[9] , HubSpot[10] .
A három kulcsfogalom (kutatásunk logikáját pontosítva):
Foglalás / jelentkezés (booking/registration): adminisztratív állapot, ami kapacitást foglal le (vagy jegyet rendel), de nem garantálja a megjelenést. [11]
Kapacitás (capacity): a ténylegesen kiszolgálható férőhely/szék/slot.
Tényleges megjelenés (actual attendance / show-up): a valós beléptetés/jelenlét – ami eltérhet a foglalásszámtól. [11]
Ebből következik: a „csoportos foglalási rendszer” nem puszta funkciólista (van-e seat limit), hanem működési modell – főleg abban a pillanatban, amikor elérjük a kapacitás plafonját. [12]
Miért marad üres hely akkor is, ha „betelt”
A „teltház → üres szék” paradoxon tipikus okai (kutatásunk állításait kiegészítve, forrásokkal megtámasztva):
Lemondás és késői módosítás miatti felszabadulás, amit a rendszer nem tölt vissza elég gyorsan vagy elég kontrolláltan. A várólista és a visszatöltés (backfill) pont erre a problémára jön létre: a felszabaduló helyeket nem elveszíteni akarja, hanem újra kiosztani. [13]
No-show mint tartós, tervezendő jelenség. Az időpontfoglalási irodalomban nagyszámú vizsgálat szintézise szerint a no-show átlagos nagyságrendje kb. 23% körüli (szakterülettől és régiótól függően), és a meghatározó tényezők közt gyakran megjelenik a hosszú előjegyzési idő (lead time) és a korábbi no-show előzmény. [14] Ez ugyan egészségügyi fókuszú metaszintézis, de kutatásunk szempontjából a szerkezeti tanulság azonos: ha a foglalás és a megjelenés különbözik, akkor a kapacitást nem lehet statikusan kezelni.
Jegy- és regisztrációs rendszerekben a „reported vs actual” különválása szintén mérhető. A ticket audit alapú összevetés (jegy kiadva vs belépés megtörtént) kimondottan a no-show mérésének egyik központi esete. [1]
A „teltház utáni” állapotkezelés gyakran nem automatizált, hanem szervezői munkát igényel. Az Eventbrite várólistakezelése jó példa: a jegyek „waitlistre” történő kiadása explicit kezelői lépéseket feltételez (Manage Waitlist → kiválasztás → release). [15]
A rendszer UI-döntései (eltűnő vs „full” jelzésű slotok) torzítják a keresletet és a kitöltést. Példa: a Calendly közösségi fórumában konkrét igényként jelenik meg, hogy a betelt idősávok ne tűnjenek el, hanem „full”-ként látszódjanak (FOMO/urgency célból), mert a „disappearing slots” más user-élményt és más konverziós dinamikát hoz. [16]
Kapacitáskezelési modellek és működési különbségek
Kutatásunk három modellje jó irány, de a valós rendszerekben érdemes pontosítani: a „teltház utáni” működés valójában több al-mintázatra bontható, főleg a várólista és az újraosztás módja szerint.
Lezárás-alapú modell
A rendszer eléri a limitet, és egyszerűen leáll (nincs túljelentkezés, nincs strukturált várólista). Ez csökkenti a kockázatot (nem lesz overbook), de növeli az üres helyek esélyét, ha a lemondások a „külső világban” már nem találnak új jelentkezőt időben. [17]
Idősáv-alapú modell
A termék elsődlegesen idősávokat kezel (meeting-scheduler logika), a csoportos működés csak egy „multi-invitee per slot” kiterjesztés. Ennek következménye: a „teltház” itt egy időpont foglalhatósági állapota, nem egy klasszikus esemény-életciklus. [18]
Kapacitás-újraelosztási modell
A lényeg: a rendszer külön kezeli a „felszabadult hely” és a „publikus újranyitás” kérdését. Nem pusztán újranyit, hanem backfill-t futtat: kiválaszt egy jelöltet, ajánlatot küld / automatikusan előléptet, időkorlátot ad, és csak ezután hoz létre végleges foglalást. [19]
Várólista-minták, amelyek kutatásunkban implicit módon benne vannak
A várólista nem egy dolog; legalább három alap viselkedés különül el a gyakorlatban:
„Notify-all” (értesíts mindenkit) + first-come-first-served: amikor hely nyílik, a lista kap egy értesítést, és az kapja meg a helyet, aki előbb kattint/fizet. Ennek tipikus kockázata a versenyhelyzet és az igazságossági vita. Egy esemény-várólista add-on például explicit módon leírja azt a módot, amikor egyszerre több várólistás kap értesítést, és „first come, first served” alapon dől el. [20]
„Temporary hold” (ideiglenes foglalás/seat-hold): a rendszer blokkolja a felszabadult helyet egy jelölt számára, korlátos ideig. Ugyanez a minta „Offer backfill” formában is megjelenik a Bookcessful dokumentációjában (lejárati idő, egyszerre futó ajánlati folyamat védelme). [21]
„Firm booking” / autopromote (automatikus előléptetés): a rendszer azonnal foglalást hoz létre a várólistáról. Ennek előnye a gyors kitöltés, hátránya a résztvevői szándék (acceptance) gyengébb kontrollja. A Bookcessful „legacy/autopromote” módja ezt a logikát írja le. [22]
Ezek a minták adják kutatásunk szívét: a különbség akkor válik operatívan láthatóvá, amikor betelik a kapacitás. [23]
Kutatásunk állításainak pontosítása táblázatban
| Állítás (röviden) | Pontosítás / kutatási kiegészítés | Forrás(ok) |
|---|---|---|
| „A foglalás ≠ részvétel, mégis sok rendszer úgy kezeli.” | Eseményeknél is mérhető a „reported vs actual” különbség; ticket auditokkal kimutatható ticket-holder no-show. | [1] |
| „No-show-k, lemondások torzítanak.” | No-show determinánsok nagy mintán (lead time, előzmény) és átlagos nagyságrendek szisztematikus áttekintésben. | [14] |
| „A teltház-pillanat a valódi töréspont.” | UI-szinten is megjelenik: „eltűnő” vs „full” slot vita, ami konverziót és elvárást befolyásol. | [16] |
| „Eventbrite: várólista létezik, de nem központi; felszabadulásnál manuális elem.” | Dokumentáltan kezelői lépés a waitlistre jegy kiadása; egy külső handbook még azt is leírja, hogy nem érdemes azonnal cancel-elni, mert nem történik automatikus „upgrade”. | [24] |
| „Calendly: group event = idősáv + limit; nincs várólista/prioritás.” | A hivatalos group event leírás limitet ad (akár 9,999); a Calendly közösségi fórum szerint nincs natív „waiting list” funkció. | [25] |
| „Setmore: class booking seat limit, de nincs automatizált túl-jelentkezés.” | A Setmore leírás szerint seat limit + full esetén a booking page leáll; várólistáról nem esik szó a funkcióleírásban. | [26] |
| „TidyCal: group bookings = slot eltűnik teltháznál; cancellation után visszajön.” | A TidyCal dokumentáció explicit: capacity elérésekor a slot „disappears”. | [27] |
| „Bookcessful: strukturált várólista + ajánlati mechanizmus.” | Konkrétan négy mód: manual, legacy/autopromote, offer, splitter (multi-event balancing). | [28] |
| „HubSpot / hasonlók: inkább időpont-egyeztetés, nem csoportos kapacitás.” | A Meetings tool csoport/round-robin oldalakat tud (több host), de a közösségben visszatérő igény a „multiple people same time slot / capacity” jelleg (ami nem ugyanaz, mint team availability). | [29] |
| „booked4.us: csoportos események, de a várólista/automatizmus nem tiszta.” | Nyilvános feature-oldalon szerepel a „Courses & Events” és a „Limit participants”, de nyilvános, könnyen ellenőrizhető várólista-automatizmus leírása nem került elő. | [30] |
Az említett rendszerek kapacitáslogikája és „teltház utáni” viselkedése
Az alábbi táblázat kifejezetten kutatásunk által tárgyalt töréspontot (betelt esemény) bontja szét: mit csinál a rendszer, ha hely felszabadul, és mennyi kézi munka marad.
| Rendszer | Domináns modell | Csoportos kapacitás | Várólista | Teltház után, ha hely felszabadul | Operatív következmény |
|---|---|---|---|---|---|
| Bookcessful | Kapacitás-újraelosztás | Igen (event/service szinten) | Igen, több mód | Offer mód: jelölt kiválasztás → ajánlat → lejárat → elfogadáskor foglalás; autopromote módban azonnali előléptetés; splitter módban több esemény között egyensúlyoz. [22] | Erős automatizáció, de a választott mód (autopromote vs offer) kockázat/gyorsaság trade-off. [22] |
| Eventbrite | Jegyalapú, részben manuális | Igen (ticket inventory) | Igen (feature) | Waitlist kezelése explicit admin-művelet: „release tickets” a waitlistre; külső gyakorlatleírás szerint a cancel és a waitlist „upgrade” nincs automatikusan összekötve. [31] | A kitöltés minősége a szervező reakcióidején és rutinján múlik; hibázás esetén „lyuk” maradhat. [32] |
| Calendly | Idősáv-alapú | Igen (invitee limit per slot) | Nincs natív (közösség szerint) | A limit beállítható; waitlist nincs, így teltház után tipikusan „újra foglalhatóvá válik”, ha kapacitás felszabadul (vagy a slot eltűnik és visszajön). [33] | Jó meeting-schedulerre, de teltház utáni kereslet-újraosztás fairness/priority nélkül marad. [34] |
| Setmore | Lezárás + seat limit (class booking) | Igen (seats) | Nem dokumentált a class booking leírásban | „Full” esetén a booking page nem fogad több foglalást; a dokumentáció a backfill/waitlist automatizmust nem tárgyalja. [26] | A rendszer „hard cap” jellegű; teltház után a szervező tipikusan külső listával/folyamatokkal dolgozik. [35] |
| TidyCal | Lezárás + idősávos csoportos limit | Igen (max attendees per slot) | Nincs natív várólista a group booking leírásában | Dokumentáltan: ha eléri a kapacitást, a slot eltűnik; így felszabaduláskor visszatérhet a foglalható idősáv. [27] | Egyszerű, de a „ki kapja meg az újranyíló helyet?” kérdés nincs strukturálva. [36] |
| HubSpot (Meetings) | Idősáv-alapú (CRM meeting link) | Több host (group scheduling page), nem „seats” | Nincs klasszikus várólista | A „group scheduling” azt jelenti, hogy több csapattag egy időpontban elérhető legyen; nem azt, hogy sok résztvevő ugyanarra a slotra „beül”. [37] | A közösségben ismétlődő igény a valódi „multi-attendee/capacity” funkció, ami jelzi a modell korlátját. [38] |
| Salonic | Szolgáltatás-/órarend-orientált (csoportos órák) | Igen (csoportos órára jelentkezés) | A publikus leírások inkább „újranyitásról” beszélnek | A Salonic blog egyértelműen azt írja le, hogy ha valaki visszamond egy csoportos órát, a felszabadult időpont újra elérhető lesz (állapotváltás). [39] | Tipikusan „reopen” modell: gyors, de fairness/prioritás nélküli. [40] |
| booked4.us | Vegyes: „Courses & Events” + limit | Igen (limit participants a Courses & Events alatt) | Nem találtam nyilvános, ellenőrizhető várólista-automatizmus leírást | Nyilvánosan: csoportos esemény + résztvevő limit; a teltház utáni automata visszatöltés dokumentációja nem volt egyértelműen elérhető. [30] | Áaacute;llítás („részben strukturált”) itt úgy pontosítható: a limit igen, a waitlist/backfill automatizmus nyilvános forrásból nem igazolható. [30] |
Fórum- és közösségi visszajelzések a „teltház utáni” működésről
Kutatásunk egyik kérése kifejezetten a marketingtől független, „való életből” jövő vélemények idézése. Az alábbiak anekdotikus források (nem reprezentatívak), viszont nagyon jól mutatják, hol fáj a teltház utáni operáció.
Eventbrite: a várólista gyakran „félig kézi”
Egy Eventbrite-közösségi (Reddit) kérdés pontosan azt a működést kéri számon, amit amit kutatásunk „ajánlati mechanizmusnak” nevez – és azt panaszolja, hogy ez hiányzik:
“It’s a bit of a pain having to monitor the waiting list and manually release the tickets at the right time.” [41]
Egy külső, intézményi gyakorlatleírás (workshop-szervezési kézikönyv) ráadásul konkrét operációs szabályt ad: ne cancel-eld azonnal a kiesőt, mert azzal nyílik egy hely anélkül, hogy bárki automatikusan feljebb lépne a várólistáról; előbb „release” a waitlistre, majd cancel – és az is szerepel, hogy az ajánlott résztvevőnek jellemzően 1 napja van „claim”-elni. [42]
Egy másik Reddit-thread pedig UI/edge-case problémát jelez: bizonyos esetben a mobil appban nem látszik a waitlist opció, hiába elérhető böngészőben, és a poszt szerint az ügyfélszolgálat sem tudott megoldást. [43]
Ezek a visszajelzések együtt azt támasztják alá, hogy a waitlist „létezik”, de a teltház utáni kitöltés nem feltétlenül automata, és könnyű „lyukas” állapotba kerülni, ha nincs fegyelmezett belső folyamat. [44]
Calendly: csoportos slot van, natív waitlist nincs
A Calendly hivatalosan részletezi a group event-et (invitee limit, remaining spots kijelzés, stb.). [45] Viszont a saját közösségi fórumában egyértelmű állításként szerepel, hogy nincs „waiting list” feature. [46]
Eközben a közösségi diskurzusban előkerül a „slot eltűnés” kontra „full kijelzés” kérdés is (a teltház utáni UX egyik legfontosabb, gyakran alábecsült eleme). [16]
Setmore: a „csoportosítás” sokszor workaround, nem natív logika
A Setmore hivatalos leírása a class bookingról seat-limites és full esetén lezáró működést ír le. [26] Egy Reddit-kérdés viszont azt mutatja, hogy a felhasználók gyakran pont a „több résztvevő ugyanarra a slotra, önkiszolgáló módon” igényt akarják megoldani – és ha erre nincs elegáns mód, admin double-booking workaround lesz, ami pont kutatásunk által kritizált szervezői teher visszacsorgása: [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: érték/ár pozitív, de megbízhatóság és csapat-funkciók vitatottak
Az AppSumo felületén (felhasználói review-k) egyszerre találni pozitív összképet és kemény kritikát – például csapatos használatnál és megbízhatóság (naptár-konfliktusok) témában. [47] A „group bookings” dokumentáltan egyszerű (slot eltűnik), ami vonzó minimalizmus, de a teltház utáni fairness/priority logikát nem oldja meg önmagában. [27]
Salonic: magyar fórumhangulat – „visszalépés” egyszerűbb megoldások felé
Egy magyar nyelvű Reddit-szálban megjelenik az a gyakorlati tapasztalat, hogy valaki „egyszerű form megoldásra” váltott, és konkrétan azt írja: „I switched from Salonic…”. [48] Ez nem a kapacitásmodell közvetlen kritikája, de jelzi: sok szolgáltatónál az operációs valóság (telefonos egyeztetés, manuális kontroll) felülírja a rendszerígéreteket. [48]
HubSpot: a community jelzi, hogy nem „seats-per-slot” termék
A HubSpot tud group és round-robin scheduling page-et (több csapattag elérhetőségére épít). [37] De a community-ben évek óta visszatérő igényként látszik a „több résztvevő ugyanarra a slotra” képesség („Allow multiple people to book… during the same time”), ami jelzi, hogy a termék modellje alapvetően nem erre van huzalozva. [49]
Kibővített tanulmány: hogyan néz ki egy jól működő „teltház utáni” operáció
Kutatásunk bővítéséhez érdemes a „teltház” pillanatát nem végállapotnak, hanem életciklus-váltásnak tekinteni: innentől a rendszer fő feladata nem az új foglalás engedése, hanem a kapacitás megtartása (utilization) kontrollált újraosztással, miközben minimalizálja a szervezői terhelést és a résztvevői frusztrációt. [50]
A „teltház utáni” állapotgép mint tervezési alap
Egy működő csoportos foglalási rendszerben tipikusan ezek az állapotok és átmenetek léteznek (kutatásunk logikáját formalizálva):
Open (foglalható) → (kapacitás elérve) → Full (betelt)
Full állapotból több út van:
Full → Reopen: lemondás esetén slot újra publikus (aki gyors, elviszi). Ez a legegyszerűbb, de fairness és „verseny” problémás, és a konverzió gyakran időablak-függő. Ezt a mintát írja le több „idősávos” termék viselkedése. [51]
Full → Waitlist (queue): a kereslet nem esik le a térképről, hanem sorba rendeződik. [52]
Waitlist → OfferPending (ajánlat folyamatban): a rendszer kiválaszt egy jelöltet, és időkorlátos ajánlatot küld. [22]
OfferPending → Booked: elfogadással végleges foglalás; vagy OfferPending → Expired/Rejected → következő jelölt. [22]
Alternatíva: Waitlist → Autopromote → Booked (azonnali előléptetés) – gyors, de „szándék” kontroll gyengébb. [22]
E szerkezetben kutatásunk „ajánlati mechanizmusa” nem extra feature, hanem a konfliktusmentes újraosztás minimális feltétele: ha egyszerre több ember látja a felszabadult helyet, verseny lesz; ha a rendszer „kioszt” (offer/hold), akkor nincs párhuzamos ütközés. [53]
Kapacitásstratégia-választó: melyik modell mikor működik
Kutatásunk hasznos, de érdemes kimondanunk a döntési szabályokat. A modell nem „jobb-rosszabb” kérdés, hanem kontextus.
Lezárás/újranyitás (reopen) akkor elég, ha: - alacsony a no-show és a lemondás (vagy nincs költsége az üres széknek), - a kereslet nem kiugróan nagy (nincs tömeg a felszabaduló helyre), - nincs fairness-elvárás (nem baj, ha a leggyorsabb nyer). [51]
Várólista + offer/hold akkor kell, ha: - a kereslet tartósan > kapacitás (teltház gyakori), - a lemondások időben közel esnek az eseményhez (a kitöltéshez kevés a publikus piac), - fontos az igazságosság és a kontroll, - a szervező nem akar folyamatosan „monitorozni és kézzel release-elni”. [54]
Autopromote akkor működik, ha: - a résztvevői elköteleződés magas (pl. előre fizetett, erős szankciók), - a „téves” automatikus foglalás kockázata alacsony, - a cél a maximális occupancy és a minimális admin. [55]
Prediktív overbooking (kutatásunkban nem szerepel, de „mélységi” kiegészítésként ide tartozik) akkor releváns, ha: - a no-show ráták magasak és stabilan becsülhetők, - a túlcsordulás (túl sok megjelenő) kezelhető üzletileg, - van adat (előzmények) és van kockázatkezelési akarat. [56]
Betelt események utáni folyamatok: egy „operációs playbook”
Az alábbi folyamatleírás kutatásunk végén említett „teltház utáni káosz” jelenséget célozza: hogyan lehet ezt rendszerlogikával determinisztikussá tenni.
Kommunikációs és operációs minimum (modellfüggetlen): - automatikus emlékeztetők és egyértelmű lemondási útvonalak (különösen nagy lead time esetén, mert az irodalom szerint ez no-show driver). [57] - explicit szabály: meddig lehet lemondani/módosítani, és mi történik utána (a „késői lemondás” a legdrágább). [58]
Ha a rendszer waitlist + offer alapú: 1. Waitlist-entry felvétel (timestamp + preferenciák: időablak, alkalom, helyszín). [22] 2. Trigger: lemondás, admin törlés, reschedule miatti felszabadulás. [22] 3. Jelöltválasztás: sorrend + szűrők (pl. esemény waitlist előbb, utána service-level reserve list – Bookcessful logika). [22] 4. Ajánlat (offer): egy jelölt, fix lejárattal; védelmek (ne fusson párhuzamosan több ajánlat ugyanarra a helyre). [22] 5. Elfogadás esetén: automatikus foglalás létrejön; elutasítás/lejárat esetén léptetés a következőre. [22] 6. Audit: offer státuszok (pending/accepted/rejected/expired) – ez adja az operációs átláthatóságot. [22]
Ha a rendszer inkább manuális (Eventbrite-szerű) és mégis kontrollt akarsz: - A külső szervezési kézikönyv logikája szerint: ne cancel-eléssel nyiss „lyukat”, hanem előbb várólistára release-elj, majd csak utána töröld a kiesőt, hogy ne csússzon be a waitlist megkerülése. [42] - Állíts be és kommunikálj claim időablakot (pl. 24 óra), és legyen belső „SLA” a monitorozásra, különben az üres hely „ott marad”. [59]
Mi hiányzik gyakran a „csoportos foglalás” funkcióból
Kutatásunk helyesen érzékelteti, hogy „csoportos” címke alatt külön világok vannak. A mélységi kibővítéshez érdemes kimondani a tipikus hiányokat:
Fairness és prioritás: ha nincs waitlist-prioritás (vagy legalább seat-hold), a teltház utáni helyek kiosztása „aki gyorsabb, nyer” lesz. Ezt a Calendly-s „full vs disappearing” vita és a waitlist igények is jelzik. [60]
Konzisztens backfill-szabályok: a szervezői teher ott csapódik le, ahol a rendszer „csak listát” ad, de nem írja le és nem automatizálja a teltház utáni kitöltést. Az Eventbrite-s közösségi panaszok ezt pontosan leírják. [61]
Átlátható státuszok: a várólista nem „egy lista”, hanem állapotok sorozata (pending/offer/accepted/expired). Ha ez nincs, akkor operációban káosz lesz. A Bookcessful dokumentáció ezt explicit életciklus-ként kezeli. [22]
A „multi-ticket / több jegytípus” csapda: van olyan várólista-implementáció, ahol a waitlist csak akkor jelenik meg, ha minden ticket/RSVP típus betelt. Ez kutatásunkban nem szerepel, de a valóságban gyakori edge-case, és félreérthető „miért nincs waitlist?” helyzetet okoz. [62]
Záró, kibővített következtetés kutatásunk logikájára építve
Kutatásunk legfontosabb (és kutatással alátámasztható) mély állítása az, hogy a „teltház” pillanatában nem a foglalás ér véget, hanem a kapacitásmenedzsment kezdődik. [50]
A rendszerek közti valódi különbség ezért nem abban áll, hogy „van-e várólista”, hanem abban, hogy:
A felszabaduló hely publikus-e vagy irányítottan kiosztott (reopen vs offer/hold vs autopromote). [63]
A folyamat mennyire automatizált és auditálható, vagy visszacsorog-e a szervezőre kézi monitorozásként. [64]
A résztvevői szándék hogyan kerül validálásra (azonnali foglalás vs időkorlátos elfogadás), ami közvetlenül kapcsolódik a no-show és késői lemondás kezeléséhez. [65]
Ebben a keretben kutatásunk tipológiája helytálló, de a mélységi kibővítés kulcsa az, hogy a „kapacitás-újraelosztás” modellt nem egy funkcióként, hanem egy állapotgép + szabályrendszer + operációs fegyelem kombinációjaként érdemes kezelni, és a rendszereket kizárólag ezen a szemüvegen keresztül összehasonlítani. [66]
Hivatkozásjegyzék
[1] [9] [11] Predicting Ticket Holder No-Shows: Examining Differences between Reported and Actual Attendance at College Football Games - 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 appointment scheduling – a systematic ...
https://www.sciencedirect.com/science/article/abs/pii/S0168851018300459
[3] [30] Online booking system features - booked4.us
https://booked4.us/en/functions/
[4] [5] [7] [12] [13] [19] [22] [23] [28] [50] [53] [54] [55] [63] [65] [66] Waitlist Automations | Bookcessful
https://bookcessful.com/en/documentation/waitlist-automations
[6] [56] Patient No-Show Predictive Model Development using ... - PMC
https://pmc.ncbi.nlm.nih.gov/articles/PMC4187098/
[8] [17] [26] Class Booking | Support - Setmore: Free Online Appointment Scheduling Software
https://support.setmore.com/en/articles/490889-class-booking
[10] [32] [42] [59] Eventbrite Waitlist — The SI Carpentries Handbook documentation
https://smithsonianworkshops.github.io/si-carpentries-handbook/eventbrite_waitlist.html
[15] [24] [31] [44] How to release tickets to the waitlist | Eventbrite Help Center
https://www.eventbrite.com/help/en-us/articles/817355/how-to-manually-release-tickets-to-the-waitlist/
[16] [60] Can completely booked time slots be displayed as full instead of disappearing? | 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] Group event type overview – Help Center
https://help.calendly.com/hc/en-us/articles/14073282345111-Group-event-type-overview
[20] [21] Waiting List - Booking Activities
https://booking-activities.fr/en/downloads/waiting-list/
[27] [36] [51] Booking Types - TidyCal FAQ
https://help.tidycal.com/article/686-booking-type
[29] [37] Create scheduling pages with the meetings tool
https://knowledge.hubspot.com/meetings-tool/create-and-edit-scheduling-pages
[34] [46] Is there any way to use this as a waitlist?
https://community.calendly.com/how-do-i-40/is-there-any-way-to-use-this-as-a-waitlist-1174
[35] Setmore Help : r/athletictraining
https://www.reddit.com/r/athletictraining/comments/148el5b/setmore_help/
[38] Meetings for multiple attendees
https://community.hubspot.com/t5/Sales-Hub-Tools/Meetings-for-multiple-attendees/m-p/36167
[39] [40] Online időpontfoglaló edzőknek, jóga oktatóknak, ...
https://blog.salonic.hu/online-idopontfoglalo-edzoknek-joga-oktatoknak-mozgasstudioknak/
[41] [61] [64] Releasing tickets to a waiting list : r/Eventbrite
https://www.reddit.com/r/Eventbrite/comments/1kxdi6g/releasing_tickets_to_a_waiting_list/
[43] SOS Waitlist problem - time sensitive! : r/Eventbrite
https://www.reddit.com/r/Eventbrite/comments/1l0v1o4/sos_waitlist_problem_time_sensitive/
[47] TidyCal Reviews 2026: Verified Ratings, Pros & Cons
https://appsumo.com/products/tidycal/reviews/?srsltid=AfmBOoqDWjzW4YqQICjVvRO8peRhAkYRaXz5KowkANQbMAL9EoYtJF0M
[48] Appointment booking system : r/programmingHungary
https://www.reddit.com/r/programmingHungary/comments/1n83xk1/id%C5%91pontfoglal%C3%B3_rendszer/?tl=en
[49] Allow multiple people to book a Meeting during the same ...
https://community.hubspot.com/t5/HubSpot-Ideas/Allow-multiple-people-to-book-a-Meeting-during-the-same-time/idi-p/34662
[52] Best practices for booking waitlists | Bookcessful
https://bookcessful.com/en/guides/best-practices-for-booking-waitlists
[62] How to Create a Waitlist - Knowledgebase
https://theeventscalendar.com/knowledgebase/how-to-create-a-waitlist