Hogyan lett egy vasárnapi kutyaiskolából szerepkör-orientált várólista motor

Nem volt roadmap, nem volt pitch deck, és nem volt nagy SaaS-álom sem. Volt viszont egy nagyon is földszagú probléma. Olyan, amit addigra már túl sokszor láttam különböző formákban: az ember próbál korrekt lenni, és a rendszer nem segít neki ebben.

Ez a történet innen indul. Egyetlen szereplővel: Julival.

Juli, a kutyakiképző – és a papírcetli

Juli kutyakiképző. Egyedül viszi a kutyaiskoláját. Nincs asszisztens, nincs admin, nincs „majd valaki megoldja”. Vasárnaponként tart órákat. Fix kapacitással: 7 kutya. Soha több. Ez nem kényelmi döntés, hanem szakmai felelősség. Ha többen vannak, romlik a minőség, sérül a figyelem, szétesik az óra.

A jelentkezési rend is kialakult:

• Péntek este 6-ig lehet jelentkezni.

• Szombaton Juli véglegesíti a beosztást.

• Vasárnap megtartja az órákat.

Az online időpontfoglalót, amit akkor használt - nevezzük most OIF-nak - technikai értelemben működött. Üzleti értelemben nem.

Az OIF nem tudott várólistát rendelni egy eseményhez.

Ez elsőre apróságnak tűnik. A gyakorlatban viszont ez mindent borított.

A workaround, ami elárul mindent

Juli ezért kitalált egy kerülőutat. Minden vasárnapra két eseményt hozott létre ugyanarra az időpontra:

1. Az „óra” – 7 fős kapacitással

2. Egy másik esemény, „várólista” néven – gyakorlatilag korlátlanul

Mindenkinek elküldte az óra és a várólista publikus URL-jét is, és mindenki oda foglalt, ahova ő jónak gondolta. Sőt, Juli kifejezetten kérte is:

„Ha nem vagy 100%-ig biztos, inkább a várólistára foglalj.”

Ez fontos. Nem technikai, hanem emberi logika.

Szombaton Juli megnézte a számokat. Tipikusan így:

• Óra: 7 fő

• Várólista: 3 fő

Ekkor kezdődött az, amit egyetlen rendszer sem látott át önmagától.

Az SMS-lánc és az élő döntések

Juli ilyenkor visszafelé indult el az órára jelentkezettek között. A legkésőbb foglalt két embernek SMS-t írt:

„Ha lenne egy másik időpont vasárnap, el tudnál jönni?”

A másik időpont nem ütközött az eredetivel, jellemzően az óra elé volt betéve.

Ha mind az öten (a 3 várólistás + a 2 „áthelyezett”) igent mondtak, Juli egy papírcetlire felírta az új időpontot, a neveket, és kész.

Eredmény:

• Eredeti óra: 5 fő

• Új időpont: 5 fő

Sehol nem lépték túl a 7 fős határt. Mindenki jól járt.

Amikor nem válaszolnak

De az élet nem ilyen tiszta.

Volt, hogy valaki:

• nem ért rá,

• nem válaszolt,

• későn reagált,

• bizonytalan volt.

Ilyenkor Juli várt kb. egy órát, majd ment tovább visszafelé az SMS-listán. Ugyanazzal a kérdéssel. Addig ismételte, amíg össze nem jött az új időpont megfelelő létszáma.

A végén még egy megerősítő SMS ment ki azoknak, akik maradtak az eredeti órán:

„Minden rendben, változás nincs, jöhetsz az eredeti időpontra.”

A végállapot mindig ugyanaz volt:
Juli kezében egy cetli. Két időpont. Nevek. Létszámok. Kontroll.

És ekkor hangzott el az a mondat, ami mindent elindított:

„Ezt biztosan lehetne automatizálni.”

Itt született meg a valódi igény

Nem egy „foglalj időpontot” problémáról volt szó. Hanem erről:

• hogyan marad igazságos a kiosztás,

• hogyan nem dönt Juli önkényesen,

• hogyan nem kell neki emlékezni arra, kinek mikor mit írt,

• hogyan nem ég ki szombat estére.

Ez már nem naptár. Ez döntéstámogatás.

És itt jött képbe az overflow splitter algoritmus (vagy egyszerű nevén: splitter).

Mit jelent valójában a splitter algoritmus? Mit csinál?

Amikor először leírtuk ezt az igényt, én is leegyszerűsítettem:

„Terítse el egyenletesen a foglalásokat a gyökéresemény (eredeti időpont) és a testvér események (pl. az új időpont vasárnapra) között.”

Ez technikailag igaz. Üzletileg viszont kevés.

A splitter üzleti célja nem az elosztás.
Hanem a döntési teher levétele az ember válláról.

Mit jelent ez a gyakorlatban?

• Van egy root (gyökér) esemény (az eredeti óra).

• Vannak testvér események (újonnan nyíló időpontok).

• Van egy várólista, ami nem parkoló, hanem potenciál.

• Van egy paraméter, a movables=true , ami azt jelenti, hogy a gyökér időpontról szabad elmozgatni foglalásokat, de nem azt jelenti, hogy „bárki bárhova átmehet”.

• Azt jelenti: csak annyian mozoghatnak, amennyien az egyensúlyhoz kellenek.

• A másik fontos beállítás a round_robin ("utolsó pár előre fuss") elosztás itt nem a méltányosságról szól, hanem azt jelenti, hogy ez egy konzervatív terheléskiegyenlítés (körkörösen osztja el a mozgathatókat a cél események között). 

Pont úgy, ahogy Juli csinálta fejben és SMS-ben.

Automatizálás, de nem ész nélkül

Juli nem azt akarta, hogy „mindenki átfoglalhasson”.

Pont ellenkezőleg.

Az automatizálási elképzelés így szólt:

• Amikor túlcsordul a létszám a várólistára,

• menjen ki értesítés azoknak, akik érintettek,

• megnyílt egy új időpont,

• de ne mindenki tudjon átfoglalni,

• a várólista mérete dinamikusan igazodjon az összlétszám kb. feléhez.

Ez nem marketing logika. Ez üzemi logika.

Innen lett szerepkör-orientált rendszer

Ezen a ponton vált világossá számomra, hogy a rendszer nem lehet „mindenkinek ugyanaz”.

Juli:

• erőforrás is,

• döntéshozó is,

• felelős is.

A résztvevők:

• nem adminok,

• nem „ügyfelek” klasszikus értelemben,

• hanem emberek bizonytalansággal, rugalmassággal, válaszidővel.

Ezért lett a rendszer szerepkör-orientált:

• mást lát az admin,

• mást kap a várólistás,

• mást az, aki már fix helyen van.

És ezért lett a várólista aktív elem, nem mellékes funkció, vagy nem létező, kerülőúton létrehozandó objektum.

Ami végül megszületett

Ami ebből az egészből lett, az ma a Bookcessful.com egyik alapgondolata.

Nem az, hogy „lehessen foglalni”.
Hanem az, hogy ne kelljen embernek rossz döntéseket hoznia egy rossz rendszer miatt.

A splitter nem okos.
A round_robin nem zseniális.
A movables=true nem varázslat.

Csak leképez egy valós, kipróbált, emberi működést.

Egy vasárnapi kutyaiskola logikáját.

És számomra innen vált egyértelművé:
nem egy időpontfoglalót építünk,
hanem egy terhelést elbíró, felelősséget tiszteletben tartó döntési rendszert.

Ez volt az első igazi ügyféligény.

Minden más csak következmény és ma már történelem.