Bérletkezelés és beléptetés egy rendszerben
A több telephellyel működő sportközpontok 70%-ánál a bérletek egy rendszerben vannak, a beléptetés egy másikban, és a kettő reggel és este szinkronizálódik. Ez napi szintű csalási rés és működési költség. Hogyan néz ki, ha a kettőt egy rendszer kezeli?
A bérlet és a beléptetés nem két modul — egyetlen adat-objektum két oldala.
Egy 4 telephelyes uszoda-lánc vagy egy 6 fittnesszközpontot üzemeltető cég tipikusan így működik: a bérleteket egy CRM jellegű rendszerben tartják (Excel, vagy valami régebbi szoftver), a beléptetéshez pedig egy turnstile-szállító saját szoftverét használják. Reggel 6:00-kor a CRM kiexportál egy bérletes listát, a turnstile-rendszer beolvassa. Aki délután 14:00-kor vesz új bérletet, az este 22:00-ig nem tud bemenni vele a turnstile-on. A recepciós manuálisan engedi be — vagy a vendég vár 4 órát. Ez nem feature-hiány, hanem architekturális rés.
A megoldás nem "gyakoribb szinkron" — hanem egyetlen rendszer, ami a bérlet eladásától a kapu kinyitásáig egyetlen adatfolyamot kezel.
Mit nyer egy multi-site operátor egyetlen rendszerrel?
- Azonnali bérleterősítés — a vásárlás után 3 másodperccel a kapu beengedi az ügyfelet.
- Megosztott bérletek a hálózat egészén — a fittnesz-bérlet bármelyik telephelyen érvényes, automatikusan elszámolva.
- Egyetlen ügyfél-rekord — egy ügyfél éves bérlete, családtag-kiegészítése, csoportos órái mind ugyanahhoz az emberhez tartoznak.
- Konszolidált jelentések — hányan jártak az X telephelyen az Y bérlettel: lekérdezés helyett dashboard.
- Csalási rés szűkítése — bérlet-kölcsönzés (egy bérlet, három haver) láthatóvá válik a beléptetési mintázatból.
Architektúra: egy bérlet, sok kapu
A Lunda architektúrában a bérlet egyetlen rekord a központi adatbázisban, telephely-kódokkal annotálva, hogy hol érvényes. A kapuk nem kérnek le naponta export-listát — minden belépési kísérletnél real-time lekérdezést indítanak: "a 4711-es kártya érvényes-e itt és most?". A válasz 100 milliszekundum alatt jön (Redis cache + Postgres fallback), a kapu kinyit, az esemény elmentődik. Ha a hálózati kapcsolat megszakad, a kapu local fallback üzemmódba vált (az utolsó 24 órás listát használja, és minden eseményt queue-zol a központnak), így nem fagy le a beléptetés egy WiFi probléma miatt.
Adatvédelem és jogosultságok
A beléptetési naplók személyes adatok, így a tárolásukra és a hozzáférésükre szigorú szabályok vonatkoznak (GDPR, hazai infotörvény). Egy egységes rendszer előnye, hogy egyetlen helyen kezelhetők a megőrzési határidők (jellemzően 6-12 hónap), az anonimizálási lépcsők, és a szerepkör-alapú hozzáférés (recepciós lát mai eseményeket; ügyvezető lát havi aggregátumot; senki sem lát "Kovács János X órakor mit csinált"-szerű részleteket). Két különálló rendszerrel ezt párhuzamosan kell megoldani, és minden audit-kérdéssel kétszer kell megküzdeni.
Mit kérdezzen meg, mielőtt vásárol?
- A bérlet vásárlásától mennyi idő múlva érvényes a kapun? (Várt válasz: < 5 másodperc.)
- Ha leszakad a hálózati kapcsolat, a kapu beengedi-e a meglévő bérleteket? (Várt: igen, local fallback.)
- Egy bérletes ügyfélnek mennyi időbe telik egy másik telephelyen belépnie? (Várt: azonnal, ha a bérlet érvényes oda.)
- A pass-sharing detektálás benne van-e? (Várt: igen, gyanús belépési mintákat jelez.)
- Hány külön rendszert kell üzemeltetnem a recepción a bérlet, jegy, és kapu kezelésére? (Várt: 1.)
A "naponta szinkronizálunk" mondat ma azt jelenti, hogy a csalási rés egy nap. Holnap pedig azt, hogy az ügyfél máshova jár.
A Lunda egyesített bérlet- és beléptető funkcióiról itt olvashat: /ai-termekek/lunda