Lunda — sportlétesítmény szoftver, bemutatás
A Lunda nem egy újabb webshop-modul. Vertikális SaaS, amely egyetlen integrált rendszerben kezeli azt, amit egy uszoda, fürdő, sportcsarnok vagy edzőterem napi szinten csinál: jegyet ad el, beengedi a vendéget, kiosztja a szekrényt, lezárja a kasszát. Magyar piacon több uszoda és termálfürdő üzemeltetője használja élesben.
A négy tipikus felhasználói szerep
Egy közepes méretű létesítményben négy szerep dolgozik napi szinten a rendszerben:
- Pénztáros — jegyet és bérletet ad el, készpénzt és kártyát kezel, számlát nyomtat. Egy átlagos szombati napon 200–400 tranzakciót zár.
- Recepciós — bérlet aktiválás, fotó készítés, panaszkezelés, telefon. Sokszor ugyanaz, mint a pénztáros, kisebb helyeken.
- Biztonsági / beléptetős — kapunál áll, a forgóvillát figyeli, a fail-secure helyzeteket oldja meg (lemerült chip, eltört bérlet).
- Üzemeltetés — napi zárás, kasszariport, NTAK feladás, takarítási műszak ütemezése, szekrény-revízió.
Mind a négy szerep ugyanazt a Lunda backendet látja, csak más jogosultsággal. Nem négy különálló szoftver — egy.
A napi flow
Reggel 6:00 — nyitás. A pénztáros bejelentkezik, a kasszafiók megnyílik, a tegnapi záróállapot átveszi a maival. A beléptetős a turnstile-szervert resetteli (vagy automatikusan újraindul). A bérlet-listák szinkronizálódnak a kapuhoz.
Reggel 6:15 — első vendég. Bérletes, kapuhoz lép, kártyát húz. 280 ms alatt zöld jelzés, forgóvilla nyit. A backend logolja: ki, mikor, melyik kapun ment be. Ez nem opcionális — uszodánál törvényi előírás (élet- és balesetbiztonsági nyomon követés).
Reggel 7:30 — pénztár-csúcs. A pénztáros 8 percig nem ér rá kávét inni. A POS válaszidő végig 100 ms alatt marad, mert a frontend lokális cache-t használ az árlistára (a háttérben async szinkronizál).
Délelőtt 10:00 — szekrény-revízió. Üzemeltetés lekéri: hány szekrény foglalt jelenleg, melyek vannak túlfoglalva (vendég kiment, de a chip még aktív — gyakori bug, ha a kijárati pont nem reset-eli). 4 ilyen szekrényt találtak, manuálisan reset-elnek.
Délután 16:00 — váltás. A délutános pénztáros átveszi a kasszát. A rendszer kasszariportot generál: készpénz, kártya, voucher, online jegy. 1500 Ft eltérés, megkeresik a hibát (a vendég pluszban fizetett uszoda + szauna kombóért, de csak uszoda lett rögzítve).
Este 21:30 — zárás. Az utolsó vendég kiment, a pénztár lezár, az NTAK adat 22:00-ig automatikusan feladódik. Hibás adatfeladás esetén Slack-riasztás megy az üzemeltetőhöz.
Miért egy rendszer, nem négy
A legtöbb létesítmény, amelyet auditáltunk, négy különálló szoftverrel kezdte:
- jegyértékesítő rendszer (gyakran táblázat vagy egyedi PHP-alkalmazás),
- beléptető rendszer (a turnstile gyártójának saját szoftvere),
- szekrény-rendszer (RFID-zár gyártójának saját szoftvere),
- kasszarendszer (általános POS, pl. egy könyvelőcég ajánlásából).
A gond mindig ugyanaz: a négy rendszer nem beszél egymással. A bérletes vendég bemegy, fizet egy felárat szaunáért, a pénztári rendszer rögzíti — de a beléptető nem tud róla, és a szekrény sem. Vagy fordítva: a bérletet a recepciós felfüggesztette (betegség miatt), de a kapu még beengedi, mert a beléptető szoftvere nem szinkronizál.
A Lunda integrált adatmodellel oldja meg: a bérlet, a jegy, a szekrény-foglalás, a tranzakció ugyanahhoz a vendég-profilhoz tartozik. Egy kép, négy mozgás.
Tanulság
Egy uszoda vagy fürdő rendszerbeszerzésénél a fő kérdés nem az, hogy melyik modul a legjobb külön-külön, hanem hogy a négy működés integrálható-e. A Lunda ezt az integrációt nem utólag oldja meg — ez az alapja.