Hat kérdés, egy jogosultsági szűrő és egy rangsor, amit a megrendelő a saját szakmai szabályai szerint állít. Mögötte leadkezelés, CRM-kapcsolat, e-mailes utókövetés és egy AI tartalomkezelés, ami emberi jóváhagyás nélkül semmit nem tesz élesre.
Az OkosanBankolok Agárdi József független pénzügyi közvetítő bankszámla-ajánló oldala. 2026 júniusában kezdtük el, júliusban állt élesbe, és azóta a megrendelő igényei szerint bővül. A látogató néhány perc alatt megtudja, melyik díjmentes vagy részben díjmentes számlacsomagra jogosult, és nagyjából mennyit fizet most a saját bankjában. A közvetítő pedig olyan érdeklődőket kap, akikről a visszahívás előtt már tudja, mennyi a havi jóváírásuk, hogyan nyitnának számlát, és mi a fontos nekik.
Az oldal a látogatót nem a bank számlanyitó oldalára küldi tovább, hanem a közvetítőhöz. A cél a beszélgetés, mert a számlanyitásnál sokszor az dönt, melyik igénylési útvonalon indul el valaki, és ezt egy táblázat nem tudja elmondani.
Egy bankszámla-összehasonlító táblázatban majdnem minden sorban 0 Ft áll. A díjmentesség viszont szinte mindig feltételekhez kötött: minimális havi jóváíráshoz, gyakran ahhoz is, hogy a jóváírás munkabér vagy nyugdíj legyen és egy összegben érkezzen, és van, ahol a nyitási bónusz csak online nyitásnál jár. Aki ezt nem látja előre, a bankfiókban szembesül vele, és onnantól a közvetítőnek sem hisz.
A megrendelő ezért olyan ajánlót kért, ami úgy gondolkodik, ahogy ő egy telefonos beszélgetésben: előbb kiszűri, ami nem jöhet szóba, és csak utána mondja meg, mi a legjobb a maradékból.
A kalkulátor első lépése a jelenlegi bank, vagy az, hogy a látogatónak még nincs számlája. Utána hat kérdés jön: foglalkoztatási helyzet, havi jóváírás hét sávban, hány részletben érkezik a pénz, online vagy személyesen nyitna számlát, mi a jóváírás jogcíme, és mi a legfontosabb neki. Ez utóbbira öt válasz van: teljes díjmentesség, minél nagyobb bónusz, gyors online nyitás, személyes ügyintézés vagy egyszerű bankváltás. Az egész körülbelül két perc.
A jövedelmi sávok egyik határa a nettó minimálbér. Ha a minimálbér változik, a határt egyetlen parancs frissíti, a kódhoz nem kell hozzányúlni.
Ez a rendszer lelke, és itt változott a legtöbb az első specifikációhoz képest. Abban még négy kérdéses, pontozásos kvíz szerepelt: minden válasz pontot ad, és a legtöbb pontot kapó számla nyer. Pontozásnál viszont egy nagy bónusz vagy a többi szempontban jó egyezés kiegyenlíthet egy nem teljesülő feltételt, egy bankszámlánál pedig a feltétel nem mérlegelhető: vagy teljesül, vagy nem. A megrendelő szakmai anyagai alapján ezért két külön lépés lett belőle.
A találati lista annyi elemből áll, ahány ajánlat tényleg illik. Nem töltjük fel háromra, mert egy olyan harmadik ajánlat, ami nem jöhet szóba, rosszabb, mint a semmi. Ha egyik sem jó, a látogató egy visszahíváskérő oldalra kerül, mert az ő esete pont az, amiről beszélni kell.
Két határesetet külön kezel a rendszer. Van ajánlat, ami egy promóciós küszöb fölött feltételesen, figyelmeztető szöveggel jelenik meg. És van, amelyiknél a nyitási bónusz csak online nyitásnál jár, ezért aki személyes ügyintézést választott, annak 0 Ft bónuszt mutatunk, nem a hirdetett összeget.
A júliusi szakmai leírás 25 helyzetet sorol fel arról, kinek mit kell kapnia. Ebből a 25 esetből automatikus teszt lett, ami minden fejlesztés után lefut, tehát ha egy kódmódosítás elrontaná valamelyik esetet, az a fejlesztői gépen derül ki, nem élesben. Érdekes mellékeredmény, hogy a 25 esetből 21 magától helyesen jön ki a szűrésből és az alap rangsorból, külön szabály csak négyhez kellett.
A kalkulátor becslést ad arra is, mennyibe kerül most a látogató számlája. A számítás egy átlagos felhasználói profilból indul ki (havi 300 000 Ft forgalom, 150 000 Ft átutalás, 100 000 Ft készpénzfelvétel), és a jelenlegi csomag második évtől érvényes havi díjával számol, éves szinten. A nyitási bónuszokat külön mutatjuk, nem keverjük bele a megtakarításba: a bónusz egyszeri, a számlavezetési díj évről évre visszatér.
Az utolsó kérdés után a látogató egy űrlapot lát: név, e-mail cím, telefonszám és adatkezelési hozzájárulás. Az űrlap fölött már ott áll, hány ajánlat illik hozzá, tehát tudja, hogy nem egy üres oldalért adja meg az adatait. A kéretlen beküldések ellen rejtett csapdamező, a telefonszám valószerűségének ellenőrzése és korlátozott beküldési gyakoriság véd, mert egy kitalált telefonszám a közvetítőnek elvesztegetett hívás.
Az eredményoldalon az első három ajánlat részletes kártyát kap kategóriajelöléssel, a többi rövidebbet. Az első hármat táblázatban is össze lehet hasonlítani, az egészet PDF-be lehet menteni, és minden ajánlatnál két gomb van: „Ezt kérem” és „Kérdésem van”. Mindkettő a közvetítőhöz visz.
Élesítés után jött a kérés a megrendelőtől: vannak, akik végigmennek a kalkulátoron, de telefonon nem érhetők el. Nekik e-mailes utókövetést építettünk. A látogató levélben is megkapja a személyre szabott ajánlatait, mindegyik mellett egy kattintással használható gombbal, amivel választhat vagy visszahívást kérhet. Három nap múlva emlékeztető megy, kilenc nap múlva egy bemutatkozó levél. A sorozat magától leáll, ha a látogató választott, visszahívást kért, vagy megváltozott az ügye státusza, így senki nem kap emlékeztetőt azután, hogy már beszéltek vele. A megnyitásokat és a kattintásokat mérjük, a levélben lévő linkek csak a saját domainre irányítanak át, és minden levélben van leiratkozási link.
A megrendelő Brevóból küld hírlevelet, és azt kérte, hogy a levélből egy kattintással lehessen visszahívást kérni, a leadből pedig derüljön ki, melyik kampányból és melyik ajánlatra kattintott az illető. Itt volt egy csapda: sok céges levelezőrendszer biztonsági szűrője automatikusan megnyitja a levelekben lévő linkeket. Ha már a link megnyitása rögzítené a kérést, a közvetítő olyan visszahíváskéréseket kapna, amiket senki nem küldött el.
Ezért a link csak egy megerősítő oldalt nyit meg, a kérést a gomb megnyomása rögzíti. Ekkor a szerver eseményt küld a Brevónak is, sütiktől függetlenül, tehát akkor is megérkezik, ha a látogató elutasította a mérést, és ugyanattól a címzettől legfeljebb 24 óránként egyszer.
A megrendelő a leadeket saját CRM-ben kezeli, ezért minden beküldés oda is megy, a kalkulátor által ajánlott első három számlával együtt. A küldés sorba állított háttérfeladat: ha a CRM épp nem válaszol, a rendszer ötször próbálkozik újra, egyre hosszabb szünetekkel, ha viszont a CRM kifejezetten elutasítja az adatot, nem erőlteti tovább. Minden beküldés állandó azonosítót kap, így egy újrapróbálkozásból sem lesz dupla lead, a korábbi leadeket pedig utólag is át lehet küldeni. Minden leadhez elmentjük azt is, melyik kampányból és hirdetésből jött, így látszik, melyik hirdetés hoz megkeresést, és melyik csak kattintást.
A banki ajánlatok havonta változnak: új bónusz, lejáró akció, módosuló feltétel. Az admin felületen a megrendelő maga kezeli a bankokat, az ajánlatokat és a feltételeiket, húzással rendezi az alap rangsort, szcenáriónként külön sorrendet állít, és karbantartja a jelenlegi bankok költségeit is, amiből a megtakarítás számol. Az ajánlatok JSON-ban exportálhatók és visszatölthetők, a havi frissítés lépései pedig egy, az adminba épített kézikönyvben vannak leírva.
Ugyanitt kezeli a leadeket (státusz, felelős, CSV export, az utókövetés leállítása vagy újraküldése), látja a kalkulátor munkameneteit, és visszakeresheti a kiküldött leveleket és a visszahíváskéréseket. Az oldalak blokkokból épülnek, és közvetlenül az oldalon is szerkeszthetők, a médiatár és a menük szintén az adminból mennek.
A blogot tudástárként építettük fel: kategóriák, élő keresés, olvasási idő, tartalomjegyzék és cikkenkénti strukturált adat (BlogPosting), hogy a keresők is pontosan értsék, miről szól egy cikk. A megrendelő kérésére a cikkekben egy visszafogott felugró ablak ajánlja fel a kalkulátort, például annak, aki a díjmentes bankszámlákról olvas. Aki egy cikkből érkezik, egy kattintásra van attól, hogy a saját helyzetére kapjon választ.
Augusztusban a megrendelő azt kérte, hogy a tudástárat, a cikkeket, a banki ajánlatokat és a szcenáriókat ChatGPT-ből vagy Claude-ból is tudja kezelni, de úgy, hogy az éles oldalon ebből ne lehessen baj. Egy pénzügyi oldalon ez nem kényelmi kérdés: egy rosszul átírt díj vagy bónusz annak okoz kárt, aki ez alapján nyit számlát.
Ehhez saját MCP szervert építettünk az oldalhoz. MCP-n keresztül az AI asszisztens közvetlenül olvassa és szerkeszti a tartalmat, a belépés OAuth-tal, admin jogosultsághoz kötve történik. Az alapszabály: az AI mindent szerkeszthet, de semmit nem publikálhat. Minden módosítása javaslatként kerül egy jóváhagyási listába, és ember dönt róla. A jóváhagyó képernyő megmutatja:
Ha az éles tartalom a javaslat óta megváltozott, a rendszer figyelmeztet. A törlés kétlépcsős, minden tartalomnak megmarad az utolsó húsz verziója, ami vissza is állítható, és minden AI-írás naplózódik, a sikertelen és a jogosulatlan próbálkozás is. A leadek elérhetőségeit az AI csak kifejezett kérésre látja, a beállításokat, az e-mail sablonokat és a lead adatokat pedig egyáltalán nem írhatja. A saját weboldalunk tartalmát is ugyanígy, jóváhagyással kezeljük.
Minden mérés Google Tag Manageren keresztül megy, Consent Mode v2-vel: a mérési hozzájárulás alapból elutasított állapotból indul, és csak a látogató döntése után változik. A GA4, a Meta Pixel és a Microsoft Clarity is innen fut, a lead a generate_lead eseménnyel jelenik meg konverzióként, és egyik mérési esemény sem visz személyes adatot. A süti-döntéseket naplózzuk, az oldal alján pedig ott van a közvetítő MNB nyilvántartási száma, a nyilvántartás ellenőrző linkjével.
Laravel 12 az alap PHP 8.3-mal és MySQL-lel, a kalkulátor Vue 3 alkalmazás, az admin saját fejlesztés Blade és Vue alapon. Az oldalt több mint 280 automatikus teszt fedi le, köztük a fenti 25 szakmai eset. A levélküldés egyetlen úton megy, minden kiküldött levél archiválódik, az ütemezett feladatok (utókövetés, emlékeztetők) ötpercenként futnak. A tárhelyen nincs SSH-hozzáférés, ezért a karbantartó műveletek, például az adatbázis-migrációk, az admin felületről indíthatók egy rögzített listából, és ami adatot törölne, az szándékosan nincs a listában.
Ugyanezen az alapon építünk egyedi weboldalt és összetettebb üzleti rendszert is. A különbség a funkciólistában van, a technológia ugyanaz.
A munka 2026. június 8-án indult, és az első héten már működött az első kalkulátor, e-mailekkel és PDF-fel. Júniusban jött az admin, a mérés, a süti- és jogi oldalak, július közepén az új design és az éles indulás, a júliusi szakmai leírás szerinti ajánlatokkal és szabályokkal. Az élesítés utáni hetekben jött a tudástár, a hírlevélből kérhető visszahívás, az e-mailes utókövetés és a CRM-kapcsolat, augusztusban pedig az AI tartalomkezelés a jóváhagyási réteggel.
A jogosultság nem szempont a sok közül. Ha egy ajánlat feltétele nem teljesül, az ajánlatnak nincs helye a listában, akármennyi pontot érne egyébként.
A szakértő tudását érdemes esetekben leírni, olyan formában, hogy „ilyen jövedelemmel, ilyen szokásokkal ezt kell kapnia”. Ebből egyszerre lesz szabály és teszt, és ha valami nem úgy működik, ahogy kellene, egy konkrét esetre lehet rámutatni.
A kalkulátor pedig csak a munka fele. Hogy hány kitöltőből lesz beszélgetés, azon múlik, mi történik a kitöltés után: ki kap levelet, ki kap hívást, és mikor áll le az utókövetés.
Nézze meg a többi referenciánkat is, vagy ha kalkulátoron, ajánló rendszeren gondolkodik, vegye fel velünk a kapcsolatot. Az első konzultáció ingyenes.
Amit egy hasonló, feltételekből ajánlást adó oldal előtt érdemes tisztázni.
Ha az ügyfelei egy döntés előtt állnak, és a jó válasz feltételekből, díjakból és kivételekből jön ki, azt szabályokba lehet írni, a kitöltés végére pedig lead kerülhet. Az első egyeztetés ingyenes, és a végén tételes árajánlatot kap arról, melyik funkció mennyi.
Nézze meg az üzleti rendszer fejlesztés szolgáltatásunkat, vagy hívjon minket a +36 70 430 8133 számon.
Nézz meg más sikeres projektjeinket is
Készítsünk együtt egy hasonlóan sikeres projektet a Te vállalkozásodnak is!
