--- title: "SaaS árazási szintek tervezése 2026 ban · 3 tier vs usage based magyar piacon" description: "3 tier vs usage based árazás, expansion revenue mechanikák, magyar PSD2 háttér. Konkrét magyar SaaS példák és tipikus hibák." date: 2026-04-26 updated: 2026-04-26 author: "Mező Dezső" tags: "SaaS, Pricing, Stripe, PSD2, Expansion Revenue, Tiering" slug: saas-arazasi-szintek-tervezese-2026 canonical: https://dfieldsolutions.hu/blog/saas-arazasi-szintek-tervezese-2026 --- # SaaS árazási szintek tervezése 2026 ban · 3 tier vs usage based magyar piacon A magyar B2B SaaS piacon a 3 tier alaplogika nem mindig optimális. Mikor érdemes usage based be váltani, és mit hagyj el. A magyar SaaS startupok 80 százaléka 3 tier (Basic / Pro / Enterprise) árazási sablonnal indul. Ennek oka, hogy a Stripe Pricing Tables, a Lemon Squeezy és a többi turnkey eszköz erre van optimalizálva, és a Y Combinator pitch deck sablonok is ezt használják. A magyar piacon viszont 2026 ban ez sokszor szuboptimális. Ez a poszt arról, mikor érdemes másképp árazni. > **NOTE:** Az árazás nem CSAK pénz dolog · az ügyfélprofilt is kódolja. Egy 9 990 / 19 990 / 49 990 Ft os 3 tier ből kiindulva a céltárgyalópartner 80 százalékban a középső tier re lő. Ha a középső tier nem kompetitív, akkor egész árazási struktúra nem kompetitív. ## 1. Mikor működik a 3 tier · és mikor nem A 3 tier akkor működik, ha (a) a használati terhelés viszonylag stabil ügyfélkategóriánként, és (b) a feature lista t bele tudod tesztelni a Pro / Enterprise sávba. Egy projektmenedzsment SaaS (Jira, Asana, Trello klón) jó kandidátus. Egy AI alapú szolgáltatás (LLM tokenek, képgeneráció, dokumentum feldolgozás) viszont rossz, mert a használati költség 100x szórása van az ügyfél körön belül, és a fix díj logikailag nem fedi a unit economics t. - Jól működik 3 tier · CRM, projekt menedzsment, marketing automatizálás, dokumentum kezelés, számlázás, HR. - Rosszul működik 3 tier · AI generáció, infra (storage, compute), API gateway, e mail küldés, képoptimalizálás. - Vegyes · ahol a fix díj fedi a base feature t, és a használati díj a drága műveleteket fedi le (pl. AI tokens, képtárolás GB). ## 2. Usage based · a 'pure' modellek és a kombinált A usage based pure forma (kizárólag a használat alapján fizet) minden ügyfél nyilatkozat ellenére nehéz a magyar piacon. Egy ügyvezető nem szeret 'nyitott' számlájú szolgáltatást vásárolni, mert a havi kiadás kiszámíthatatlan. Az ún 'cap' (felső limit) jó ellenintézkedés. A Vercel és a Supabase ezt csinálja: 'fizetsz a használat után, de soha nem fizetsz többet, mint X · ott automatikusan blokkol a service'. A kombinált modell (alapdíj + overage) a magyar piacon is jól működik. Példa az SMS provider iparág: a havi 5 000 Ft fix + 7 Ft / SMS modell tipikus, és nem zavar senkit. Az AI SaaS ben mi 9 990 Ft fix + 0.5 Ft / 1000 token modellt használtunk az egyik magyar ügyfélnél, és a churn 4 hónap után 6 százalékkal alacsonyabb volt, mint a pure 3 tier es konkurensé. ## 3. Expansion revenue · ahol a SaaS nyer A SaaS növekedés legjobb forrása nem az új ügyfél, hanem az expansion revenue · meglévő ügyfél emelkedő havidíja. Ezt csak akkor tudod elérni, ha az árazás olyan dimenziókkal kapcsolódik, amelyek az ügyfél növekedésével skálázódnak. Példák: 'team seat ek száma', 'havonta feldolgozott tranzakciók', 'aktív projekt szám', 'tárolt dokumentum'. - Rossz expansion dimenzió · 'admin user szám' (mert egy cégben az admin szám konstans). - Jó expansion dimenzió · 'rendelés / hónap', 'kontakt szám a CRM ben', 'csapat tag', 'API call', 'AI token'. - A 'feature gating' (azaz egy feature csak Enterprise ben van) nem expansion · az tier upgrade. A kettő különbözik. - Az expansion revenue korai jele: ha az ügyfelek 30 százaléka egy féléven belül átlép a következő tier be vagy emelkedik a usage alapú számlájuk, akkor jó az árazás. Ha 5 százalék, akkor rossz. ## 4. Magyar PSD2 háttér · recurring billing reality A PSD2 (és a magyar implementációja) szigorúbb SCA (Strong Customer Authentication) követelményeket szab meg, mint korábban. A recurring SaaS billing speciális esete az 'MIT' (Merchant Initiated Transaction): a kártyatulajdonos egyszer engedélyezi (3DS sel), és utána a merchant kezdeményezi a havi terhelést. Ez 2026 ban fokozottan ellenőrzött a magyar bankoknál. - A Stripe automatikusan 'off session' tranzakcióként kezeli, és a kártyatulajdonos PaymentMethod ját menti · ez 95 százalékban átmegy. - A SimplePay és a Barion is támogatják a recurring t, de a flow lassabb, és a sikertelen recurring tranzakciók aránya magasabb. - Magyar specifikum: a magyar bankok közül az Erste és a Raiffeisen szigorúbb a recurring SCA exemption ellen, az OTP és a K&H lazább · ez user retention különbséget okozhat. - A 'dunning' (sikertelen tranzakció utáni email + retry sorozat) kötelező · ne kapcsold le. A Stripe Smart Retries 6-8 százalékkal csökkenti a churnt. ## 5. Magyar piaci példák · konkrét számok Néhány magyar SaaS, amelyik nyilvánosan publikálta az árazását 2026 ban (vagy ahol mi voltunk az implementáló partner): - Számlázz.hu · 3 tier, leginkább a feature lefedettséggel differenciál. Free / havi 2 990 Ft / havi 6 990 Ft. Sikeres példa, mert a számlázás use case ben a feature stable. - Egy magyar AI marketing SaaS, ahol mi adtunk pricing tanácsadást · 9 990 Ft alap + 0.5 Ft / 1000 token. ARR növekedés 2x volt 6 hónap alatt, miután a pure 3 tier ből átálltunk. - Egy magyar B2B logisztikai SaaS · havi 19 900 Ft + 200 Ft / lefoglalt szállítás. Az alapdíj fedi az infra t, a per szállítás díj a piaci elismertséget. - Hibás példa, amit láttunk auditban · havi 3 990 / 9 990 / 24 990 Ft 3 tier, de az ár különbség 2 negyedéve nem indokolt feature ben. Az ügyfelek 92 százaléka az olcsóbb tier en volt, expansion revenue szinte nulla. ## 6. A pricing oldal mint kommunikáció A pricing oldal egy meggyőzési felület, nem egy táblázat. A magyar B2B konverzió (pricing oldal · regisztráció) az általunk látott projekteknél átlagosan 8 12 százalék. A három legfontosabb növelő tényező: (1) konkrét ár (nem 'kérjen ajánlatot' · az alulrelegálódik, kivéve enterprise nél), (2) konkrét limit (50 user nem 'unlimited team', mert az 'unlimited' marketing buzz), (3) magyar nyelvű FAQ az árazás melletti '3 leggyakoribb kérdés' formában. ## 7. Tipikus hibák, amiket a magyar SaaS k elkövetnek - Free tier korlát nélkül · az infra költség miatt értéket éget, és a free user nem konvertál szignifikánsan jobban. - Annual plan 12 hónapos kötés és 0 százalék kedvezmény · ha kötsz, kedvezzj. Az ipari standard 17-20 százalék éves kedvezmény. - Az áreltérés OFW (online flexible willingness to pay) ellenőrzése nélkül · soha ne ár emelj 30 százalékot egy lépésben anélkül, hogy a meglévő ügyfeleknek nem grandfathered árat tartasz fent. - ÁFA kezelés rossz · a magyar B2B fizető 'fordított adózás' alá esik, ha EU n belüli, viszont a B2C nem. A pricing page megmondja, hogy 'nettó' vagy 'bruttó' árat lát, és a checkouton korrigálja. - A trial végén 'silent' lejárat · küldj 7, 3, 1 napos emlékeztetőt magyar nyelven, máskülönben a vissza nem térés 78 százalék fölé megy. > **TIP:** Egy egyszerű elemzés, amit minden 6 hónapban érdemes elkészíteni: az ARPU (átlagos havi árbevétel ügyfélenként) eloszlása. Ha 80 százalék ugyanazon az áron van, akkor a tier struktúra nem dolgozik · vagy rossz dimenziók szerint árazsz, vagy a tier ek nem kellően differenciáltak. Az ARPU eloszlás Bell shape lesz, ha jól csinálod. Záró: a magyar SaaS piac 2026 ban már nem 'turn key Stripe Pricing Tables' világ. A pricing tervezése független diszciplína, és a kód oldali ár implementáció (Stripe Subscriptions, Metered billing) ennek a következménye, nem a kiindulópontja. A SaaS, ami pricing oldalról kompetitív, jellemzően ARR növekedésében 1.5-2x szignifikánsan a vetélytársaihoz képest. --- Source: https://dfieldsolutions.hu/blog/saas-arazasi-szintek-tervezese-2026 Author: Mező Dezső · Alapító, DField Solutions Site: https://dfieldsolutions.hu