Weboldal-fejlesztési igények priorizálása marketing szempontból

Scheo · 2026-10-18 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy kkv-nál a weboldal-fejlesztés szinte mindig szűk keresztmetszet. Van egy belsős vagy külsős fejlesztő, havonta néhány nap kapacitással, és közben a marketing új landing oldalt kér, az értékesítés egy új mezőt az ajánlatkérő űrlapra, a vezetés pedig azt, hogy „legyen gyorsabb az oldal”. Ha a kérések e-mailben, telefonon és folyosói beszélgetésben érkeznek, a sorrendet az dönti el, ki szól a leghangosabban. Ez a cikk egy egyszerű, táblázatban is vezethető módszert mutat arra, hogyan rangsorold ezeket a kéréseket úgy, hogy a korlátos fejlesztői idő a lehető legtöbb üzleti hatást hozza.

A szövegben külön jelölöm, mi hivatalosan igazolt (dokumentált forrásból, például a Google vagy a W3C anyagaiból), mi saját tapasztalat (kkv-s weboldal-projektekben visszatérő mintázat), és mi szakmai feltételezés (logikus, de általánosan nem mért állítás).

Miért nem jó sorrend az, hogy ki kérte előbb?

Röviden: a beérkezés sorrendje semmit nem mond a kérés üzleti értékéről, a ráfordításról és a kockázatról. Egy közös, pontozott lista viszont láthatóvá teszi, melyik munka hoz többet kevesebb fejlesztői időből.

Saját tapasztalat, hogy a sorrend nélküli kéréskezelésnek két tipikus tünete van. A fejlesztő folyamatosan kontextust vált, mert a félkész feladatot félreteszi egy „sürgős” kérés miatt. A nagy, nehezen elkezdhető munkák (például a mobilos sebesség javítása) pedig hónapokig csúsznak, mert mindig akad egy gyorsabb apróság.

Milyen típusú weboldal-kérések jönnek be egy kkv-nál?

Röviden: nagyjából öt kategória van, a hibajavítás, a sebesség és technikai állapot, az űrlap-módosítás, az új oldal és az új funkció. Ezek hatása és kockázata eltérő, ezért érdemes már a beérkezéskor besorolni őket.

• Hibajavítás. Nem működő gomb, törött link, szétcsúszó mobilnézet, meg nem érkező űrlap-értesítő. Gyakran kicsi a ráfordítás, a hatás viszont nagy lehet, ha a hiba a konverziós úton van.
• Sebesség és technikai állapot. Képoptimalizálás, gyorsítótár, bővítmények ritkítása, a Core Web Vitals mutatók javítása. A hatása lassabban és közvetetten jelentkezik.
• Űrlap-módosítás. Mező hozzáadása vagy elvétele, kötelező mezők, köszönőoldal, mérés. Közvetlenül érinti a leadeket, ezért a kockázata is nagyobb, mint amilyennek látszik.
• Új oldal. Szolgáltatásoldal, kampány landing, GYIK, tudásbázis-cikk. A ráfordítása jellemzően közepes, a hatása a keresési szándéktól és a várható forgalomtól függ.
• Új funkció. Időpontfoglaló, kalkulátor, ügyfélportál, webshop-bővítés. Itt van a legnagyobb ráfordítás és a legtöbb rejtett függőség.

Hogyan pontozd a kéréseket hatás, ráfordítás és kockázat alapján?

Röviden: minden kérést három szempontból értékelj 1-től 5-ig, vagyis mekkora a várható üzleti hatása, mennyi fejlesztői időt visz el, és mekkora az esélye, hogy elront valamit. A prioritási pontszám a hatás duplája osztva a ráfordítás és a kockázat összegével.

Hatás (1-5)

A hatásnál azt kérdezd, közelebb visz-e a kérés egy mérhető üzleti célhoz, például több ajánlatkéréshez, több híváshoz, több rendeléshez vagy kevesebb ismétlődő ügyfélkérdéshez.

• 5, ha a fő konverziós utat érinti (például nem érkeznek meg az ajánlatkérések).
• 4, ha egy sok látogatót kapó oldal konverzióját javíthatja jó eséllyel.
• 3, ha egy fontos, de kisebb forgalmú oldalt vagy folyamatot érint.
• 2, ha kényelmi vagy belső javulást hoz.
• 1, ha főleg ízlésbeli kérdés (szín, betűméret, ikon).

A Google Analytics 4-ben megnézheted, hány munkamenet érinti az adott oldalt, a Search Console teljesítményjelentésében pedig azt, hogy az oldal milyen keresésekre jelenik meg.

Ráfordítás (1-5)

A ráfordítást a fejlesztő becsülje, ne a kérő. Elég egy durva skála, és tartalmazza a tesztelést és az élesítést is.

• 1, ha egy óránál kevesebb munka.
• 2, ha nagyjából fél nap.
• 3, ha egy-két nap.
• 4, ha egy hét körül van.
• 5, ha ennél több, vagy a becslés nagyon bizonytalan.

Kockázat (1-5)

A kockázat azt méri, mennyire valószínű, hogy a módosítás mást is elront, és mennyire nehéz visszacsinálni. Magas a kockázat, ha a változtatás az űrlapot, a fizetést, a mérőkódokat, az URL-szerkezetet vagy egy központi bővítményt érint. Alacsony, ha egyetlen statikus oldal szövegét módosítod.

Szakmai feltételezés, hogy a kkv-k a kockázatot rendszeresen alulbecsülik, mert a hiba nem a fejlesztés napján derül ki, hanem napokkal később, egy elmaradt lead formájában.

Hogyan számold ki a prioritást?

A képlet szándékosan egyszerű, hogy táblázatban bárki vezethesse. A hatást duplán számolod, mert a lista célja az üzleti eredmény. Ez a termékmenedzsmentből ismert RICE-modell egyszerűsített rokona.

Prioritás = (Hatás × 2) / (Ráfordítás + Kockázat)

Google Táblázatban ez a képlet az E2 cellába kerül, ha a B oszlop a hatás, a C a ráfordítás és a D a kockázat.

=ROUND((B2*2)/(C2+D2);2)

Egy szemléltető példa hat tipikus kérésre (a pontok illusztrációk, nem mért adatok).

• Nem érkezik meg az ajánlatkérő űrlap értesítője. Hatás 5, ráfordítás 1, kockázat 2, prioritás 3,33.
• Új szolgáltatásoldal egy ténylegesen keresett szolgáltatásra. Hatás 4, ráfordítás 3, kockázat 1, prioritás 2,00.
• Mobilos képek tömörítése a nyitóoldalon. Hatás 3, ráfordítás 2, kockázat 1, prioritás 2,00.
• Új „költségkeret” mező az ajánlatkérő űrlapra. Hatás 3, ráfordítás 1, kockázat 3, prioritás 1,50.
• A fejléc színének módosítása. Hatás 1, ráfordítás 1, kockázat 1, prioritás 1,00.
• Online időpontfoglaló teljes integrációja. Hatás 4, ráfordítás 5, kockázat 4, prioritás 0,89.

A példából látszik, hogy a fejlécszín hiába egyórás munka, nem kerül előre. Az időpontfoglaló alacsony pontszáma sem azt jelenti, hogy soha nem készül el. Azt jelzi, hogy érdemes kisebb, kevésbé kockázatos lépésekre bontani, például előbb egy külső foglalónaptár linkje kerül ki, és csak a tényleges használat után jön a teljes integráció.

Hogyan kerüljön egy közös listába a marketing, az értékesítés és a vezetés kérése?

Röviden: legyen egyetlen bejárat (egy táblázat vagy jegykezelő), mindenki ugyanazzal a sablonnal kérjen, a pontozást pedig egy rövid, rendszeres egyeztetésen véglegesítsétek, ahol döntetlennél a vezetés dönt.

1. Egy bejárat. Minden kérés ugyanoda kerül, egy megosztott táblázatba, egy jegykezelőbe vagy egy projekttábla „Beérkezett” oszlopába. Ami szóban vagy e-mailben jön, azt a kérő maga rögzíti, különben nem kerül sorra.
2. Egységes sablon. A kérés csak akkor kap pontot, ha a sablon kötelező mezői ki vannak töltve.
3. Előpontozás. A kérő megadja a hatás-tippjét indoklással, a fejlesztő a ráfordítást és a kockázatot.
4. Rendszeres egyeztetés. Kéthetente egy rövid alkalom, ahol a marketing, az értékesítés, a fejlesztő és a vezetés egy-egy képviselője átnézi az új tételeket. Itt korrigáljátok a hatás-pontokat, mert a saját kérését mindenki hajlamos felülértékelni.
5. Fix kapacitás-szelet. Saját tapasztalat, hogy jól működik, ha a fejlesztői idő egy részét előre lefoglaljátok karbantartásra és hibajavításra. Így a technikai adósság nem halmozódik a látványos kérések mögött.
6. Látható állapot. Minden tételnek legyen állapota (beérkezett, pontozva, folyamatban, élesítve, mérve), hogy a kérőnek ne a fejlesztőt kelljen kérdezgetnie.

Szakmai feltételezés, hogy a legtöbb priorizálási vita abból adódik, hogy a marketing, az értékesítés és a vezetés szempontjai nem egy helyen és nem egy skálán találkoznak.

Hogyan néz ki egy jó fejlesztési kérés?

Röviden: egy jó kérés leírja a problémát, az érintett oldalt, a várt üzleti eredményt, a mérés módját és az elfogadás feltételét. Megoldást javasolhat, de nem írja elő a fejlesztőnek.

Ezt a sablont másold a táblázatba vagy a jegykezelőbe.

1. Cím igével. Például „Az ajánlatkérő űrlap értesítője érkezzen meg a beérkező mappába”.
2. Kérő és típus. Ki kéri (marketing, értékesítés, vezetés), és melyik kategóriába tartozik.
3. Érintett URL-ek. Pontos címek, nem „a szolgáltatásos oldal”.
4. Mi a probléma most? Tény, képernyőkép, a hiba előidézésének lépései, eszköz és böngésző.
5. Kit érint, mekkora forgalmat? GA4- vagy Search Console-adat, ha van.
6. Várt üzleti eredmény. Melyik mutatónak kellene változnia, és milyen irányba.
7. Mérés. Melyik esemény, kulcsesemény vagy jelentés mutatja meg a változást.
8. Elfogadási feltétel. Mikor mondjuk ki, hogy kész.
9. Időbeli kényszer és oka. Például kampányindulás vagy jogszabályi kötelezettség, ha van ilyen.
10. Függőségek. Szöveg, kép, hozzáférés, harmadik fél jóváhagyása.
11. Hatás-tipp (1-5) indoklással. Egy mondat, miért annyi.

Egy kitöltött példa, szemléltetésként. Cím: „A fejlécben lévő telefonszám mobilon indítson hívást”. Típus hibajavítás, minden oldal fejlécét érinti. A probléma az, hogy mobilon a szám sima szövegként jelenik meg, ezért a látogatónak ki kell másolnia. A várt eredmény több hívás mobilról. A mérés a tel: linkre beállított kattintási esemény a GA4-ben. Az elfogadási feltétel az, hogy iOS-en és Androidon is hívást indít, és az esemény megjelenik a valós idejű jelentésben. Javasolt megoldás egy <a href="tel:+36XXXXXXXXX"> link, a beillesztést a fejlesztő dönti el.

Mi kerüljön előre a pontszámtól függetlenül?

Röviden: a biztonsági hibák, a jogszabályi kötelezettségek, a leállást okozó hibák és a törött mérés. Ezeket ne pontozd a többivel együtt, kezeld őket külön, azonnali sávként.

• Biztonság. Ismert sérülékenységű, elavult bővítmény, gyanús adminfelhasználó, lejárt SSL-tanúsítvány.
• Jogi megfelelés. Adatkezelési tájékoztató, süti-hozzájárulás, az űrlapnál az adatkezelési hozzájárulás. Hivatalosan igazolt, hogy a GDPR a személyes adatot gyűjtő űrlapokra is vonatkozik, és hogy az Európai Akadálymentesítési Irányelv (European Accessibility Act) 2025 júniusától bizonyos digitális szolgáltatásokra, köztük az e-kereskedelemre is kiterjed, a mikrovállalkozásokra vonatkozó kivételekkel. A pontos megfelelést jogásszal tisztázd.
• Leállás. Elérhetetlen oldal, nem működő kosár.
• Mérés. Ha a konverziókövetés nem működik, minden további hatás-becslés vakon történik.

Hogyan kezeld a sebességet, ha mindenki mást akar előbb?

Röviden: a sebességet konkrét, mérhető feladatokra bontva pontozd, ne egyetlen „legyen gyorsabb” kérésként. Így a gyors, kis kockázatú lépések előre kerülhetnek, a nagyobb átalakítás pedig külön döntést kap.

Hivatalosan igazolt, hogy a Google a Core Web Vitals mutatókat (LCP, INP, CLS) az oldalélmény részeként veszi figyelembe, és a web.dev szerint jónak számít a legfeljebb 2,5 másodperces LCP, a legfeljebb 200 ezredmásodperces INP és a legfeljebb 0,1-es CLS. A Google Search Central ugyanakkor azt is leírja, hogy a jó oldalélmény önmagában nem pótolja a releváns, hasznos tartalmat. A sebesség ezért a keresési helyezés felől ritkán 5-ös hatású, a felhasználói élmény és a konverzió felől viszont jó eséllyel többet számít.

Saját tapasztalat, hogy kkv-s WordPress-oldalakon a leggyakoribb gyors lépések a túlméretezett képek tömörítése, a nem használt bővítmények kikapcsolása és a gyorsítótár beállítása. Ezek jellemzően 1-es vagy 2-es ráfordításúak. Egy sablon- vagy oldalépítő-csere viszont 5-ös ráfordítású és 4-es vagy 5-ös kockázatú, ezért azt vezetői döntésként, külön projektként kezeld.

Milyen hibák torzítják a rangsort?

Röviden: leggyakrabban a felfújt hatás-pontok, a kérő által becsült ráfordítás és az elmaradó utólagos mérés.

• Mindenki 5-öst ad a saját kérésére. Az 5-ös hatás csak konkrét adattal adható, és az egyeztetésen a csapat közösen véglegesíti.
• A ráfordítást a kérő becsüli. A fejlesztő becslése nélkül a pontszám nem mond semmit.
• Nincs utólagos mérés. Ha az élesítés után senki nem nézi meg, változott-e a mutató, a következő hatás-becslés sem lesz pontosabb. Ezért kell a „mérve” állapot.
• A nagy kérés egyben kap pontot. Bontsd szét, mert a részek külön-külön gyakran jobb pontszámot kapnak.
• Kapkodás egy kampány előtt. Szakmai feltételezés, hogy sok kockázatos élesítés közvetlenül egy kampányindulás előtt történik. Ha a kampány dátuma ismert, a hozzá tartozó fejlesztést jóval korábban vedd fel a listára.

Mit ellenőrizz, mielőtt elindítod a közös listát?

Röviden: ha az alábbi pontok rendben vannak, a lista első változata működőképes.

• Van egyetlen, mindenki által ismert bejárat a kérésekhez.
• A sablon kötelező mezői minden tételnél ki vannak töltve.
• A hatás-, ráfordítás- és kockázatskála le van írva, példákkal.
• A fejlesztő minden tételhez megadta a ráfordítást és a kockázatot.
• A biztonsági, jogi és leállást okozó hibák külön, azonnali sávban vannak.
• Működik a konverziómérés (űrlap, hívás, vásárlás).
• Minden élesített tételnél van mérési megjegyzés.
• Élesítés előtt készül mentés, a nagyobb módosítás pedig tesztkörnyezetben készül el.

Mi hivatalos, mi tapasztalat és mi feltételezés ebben a módszerben?

Röviden: a Core Web Vitals küszöbértékei, a GDPR és az akadálymentesítési követelmények dokumentált forrásokra épülnek, a pontozási képlet és a folyamat gyakorlati tapasztalaton alapul, a kockázat alulbecsléséről szóló megfigyelések pedig szakmai feltételezések.

A módszer nem garantál jobb keresési helyezést vagy több leadet. Arra jó, hogy a korlátos fejlesztői idő átláthatóan, indokolhatóan és utólag ellenőrizhetően oszoljon el, és a kérések mögötti feltételezések idővel mérésekre cserélődjenek.

Források és további olvasnivalók

• Google Search Central: Understanding page experience in Google Search results
• web.dev: Web Vitals
• Google Analytics súgó: Események és kulcsesemények a GA4-ben
• Google Search Console súgó: Teljesítményjelentés
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2
• (EU) 2019/882 irányelv a termékek és szolgáltatások akadálymentesítési követelményeiről (European Accessibility Act)
• (EU) 2016/679 rendelet, általános adatvédelmi rendelet (GDPR)
• Intercom: RICE prioritization framework