A weboldal kész, de mi van utána? A support szerződés jelentősége
Sajnos a mai napig tapasztaljuk, hogy egy-egy fejlesztési projekt végén szinte mindenki – megrendelő és kivitelező is – csak a kész termékre koncentrál, az üzemeltetés és a gondozás azonban háttérbe szorul. Ez olyan, mintha csak akkor kezdenénk el foglalkozni az egészségünkkel, amikor már baj van, vagy csak akkor kötnénk lakásbiztosítást, amikor már lángokban áll a ház. Pedig a digitális jelenlétünk is folyamatos figyelmet és karbantartást igényel, ha hosszú távon sikeresek szeretnénk lenni.
Miért éri meg proaktívan gondolkodni?
- Megelőzés = Megtakarítás: Az iparági statisztikák szerint minden egyes forint, amit előzetes karbantartásra költünk, akár négyszeresen is megtérülhet a későbbi problémák elkerülésével. Gondoljunk csak a váratlan leállások, elmaradt leadek vagy értékesítési veszteségek valós költségeire.
- Biztonság mindenek előtt: A súlyos biztonsági incidensek 60%-a az elmaradt frissítésekből ered. Ha nincs folyamatos támogatás, akkor jelentős kockázatot vállalunk a saját rendszerünk és ügyfeleink adatai tekintetében.
- Hatékonyság és nyugalom: Egy jól kialakított támogatási szerződéssel, mivel a fejlesztőcsapat ismeri a rendszert, így nem kell minden alkalommal a nulláról kezdeni, ami nagyon sok időt és nem mellesleg pénzt takarít meg. Az előre kalkulálható, fix havi költségek pedig kiszámíthatóságot és tervezhetőséget biztosítanak.
Nagyon elcsépelten hangzik, de az elmúlt 15 év alatt biztosan megtapasztaltuk, hogy az igazi érték a hosszú távú partnerségben rejlik, ezért nem csupán projektekben, hanem termék életciklusokban gondolkodunk. Szerencsére azt látjuk, hogy a vállalkozások egyre tudatosabbak ezen a területen is. Ebben a blogposztban igyekeztünk összefoglalni, milyen tényezőket érdemes átgondolni, amikor fejlesztői vagy ügynökségi támogatási szerződés megkötéséről döntesz.
Konstrukciók és csomagok
Első körben fontos végiggondolni, hogy mi történik abban az esetben, ha nincs együttműködési szerződésünk a weboldal kivitelezővel. Ez egy nagyon szürke, nehezen definiálható zóna, ahol senkinek nincs a másik felé pontosan megfogalmazott elvárása és a feladatköre sem. Természetesen az átadás után a fejlesztő garanciát vállal a termékre, de mi van ha ezen felül újabb igények keletkeznek, esetleg újabb ötleteink támadnak? Ilyenkor jellemzően eseti óradíj ellenében dolgozik az ügynökség, gyakran magasabb díjszabással, mint szerződéses ügyfeleknek. A munka megkezdése előtt az ügynökség egyedi ajánlatot vagy időbecslést készít minden feladatra, amit az ügyfélnek jóvá kell hagynia. Jellemzően a fejlesztő cég az ad-hoc megkeresések esetén külön díjat számít fel a feladat felmérésére is, és csak az ajánlat elfogadása után kezdik a munkát . Eseti támogatásnál nincs garantált SLA: a válaszidő a lehetőségekhez mérten történik, ez kritikus hibáknál komoly problémát és feszültséget okozhat. Összességében az ad-hoc modell rugalmasságot ad az ügyfélnek, de kiszámíthatatlan és kevésbé prioritásos a fejlesztő számára.
Havidíjas óracsomag (retainer): Ez az egyik legelterjedtebb konstrukció, ahol az ügyfél havonta fix díjat fizet egy meghatározott mennyiségű fejlesztői/support óra keretéért. Az ongoing support contract vagy retainer lényege, hogy az ügynökség garantál egy bizonyos kapacitást az ügyfélnek, amelyet a rendszer karbantartására, hibajavításra, kisebb fejlesztésekre fordítanak. A konkrét megvalósítás ügynökségenként változhat: van, aki csomagok formájában kínálja (pl. Lite csomag havi 5 órával, Pro csomag 10 órával stb.), míg mások teljesen egyedi keretszerződést kötnek az ügyfél igényeire szabva. A havi órakeretes modellekben tipikusan szerepelnek feltételek: például minimum 6 hónap elköteleződés szükséges, utána lehet felülvizsgálni az óraszámot; a havidíjban foglalt óraszám túllépése esetén a többletet magasabb óradíjjal kiszámlázzák, a fel nem használt órák pedig a hónap végén lejárnak (nem vihetők át következő hónapra). Ez utóbbi kikötés biztosítja, hogy az ügynökség ütemezni tudja az erőforrásait, és az ügyfél is arra ösztönözve legyen, hogy folyamatosan használja a szolgáltatást. A havidíjas retainer modell előnye az ügyfélnek a kiszámíthatóság és a preferált bánásmód: általában kedvezőbb óradíjat kap és gyorsabb reakciót tervezhető SLA-val, mint szerződéssel nem rendelkező társai. A fejlesztő cég pedig biztos, folyamatos bevételhez jut, ami lehetővé teszi, hogy fenntartson egy dedikált csapatot az ügyfél számára.
Vannak ügynökségek, amelyek lehetővé teszik, hogy a fel nem használt támogatási órák ne vesszenek el, hanem átvihetők legyenek a következő hónapra. A hrenkonál mi is ezt a szemléletet követjük. A havi support szerződésben kínált gördülő órák azt jelentik, hogy a partnereink akkor használhatják fel a rendelkezésre álló keretüket, amikor valóban szükségük van rá. Ha egy adott hónapban kevesebb fejlesztés vagy támogatás történik, a megmaradt órák automatikusan átvihetők a következő időszakra.
Ez a rendszer nemcsak rugalmasabb és költséghatékonyabb, de kiszámítható támogatást is biztosít. Partnereink így mindig pontosan annyi figyelmet, fejlesztést és technikai támogatást kapnak, amennyire épp szükségük van – veszteség nélkül, tervezhetően, prioritással és biztonságban.
Többszintű SLA-alapú csomagok: Különösen nagyobb ügynökségek vagy üzemeltető cégek kínálnak többféle támogatási szintet előre definiált szolgáltatási szintekkel (Service Level Agreement – SLA), amelyek növekvő havidíjért cserébe egyre magasabb szintű szolgáltatást nyújtanak. Például egy Bronz csomag tartalmazhat alap 8x5 órás ügyfélszolgálatot, mondjuk 1 munkanapos reakcióidővel e-mailben, míg az Ezüst csomag 12x5 vagy 24x7 elérhetőséget, gyorsabb (4 órás) reakcióidőt és telefonos támogatást is, a Gold pedig 24x7 ügyeletet, akár 1 órán belüli reakcióidőt, dedikált csapatot. A lényege, hogy az ügyfél választhat a szükségleteinek és költségkeretének megfelelően, milyen szintű készenlétet és szolgáltatást akar.
Példa erre a weboldal-karbantartási piacon elterjedt website care plan rendszerek: sok webfejlesztő ügynökség kínál alap csomagot havi 40 000 - 100 000 HUF körül, amelyben a legalapvetőbb karbantartási feladatok vannak benne, például biztonsági monitorozás, teljesítmény-ellenőrzés, biztonsági mentések, plugin- és rendszerfrissítések. A magasabb szintű csomagok ennél több órát, gyorsabb válaszidőt vagy extra szolgáltatásokat (pl. tartalomfeltöltés, fejlesztési órák, grafikai tervezés, tanácsadás) tartalmaznak. Az SLA-alapú támogatásnál részletesen rögzítik a vállalt mutatókat: pl. üzemidőt (uptime), rendelkezésre állási időablakokat, reakcióidőt a különböző súlyosságú hibákra, hibaelhárítási célidőket. Ez a konstrukció a felek számára egyértelmű elvárásokat és felelősségi köröket határoz meg. Az ilyen struktúrák inkább közép- és nagyvállalati ügyfeleknél jellemzők, ahol elvárás a formális szolgáltatási szint és akár kötbér vagy jóváírás jár, ha az ügynökség nem teljesíti a vállalt szintet.
Hostinggal egybekötött üzemeltetési szerződés: Néhány ügynökség a support szolgáltatást a tárhely-üzemeltetéssel kombinálva nyújtja (nekünk is vannak ilyen csomagjaink). Ilyenkor az ügyfél egyben kapja meg a weboldal hostingját és a ráépülő technikai karbantartást. A tárhellyel együtt kért csomagban benne van a szerver díja, annak frissítése/monitorozása, napi biztonsági mentés, a bővítmények frissítése, hibajavítás. Az ilyen integrált konstrukciók előnye, hogy az ügyfél egy kézben tudhat mindent (a domain fenntartást, hostingot és a supportot is), az ügynökség pedig teljes rálátással tudja biztosítani a rendszer működését. Gondoljunk csak bele, hogy mennyire kényelmes, hogy a weboldallal kapcsolatos összes feladat egy cég kezében van.
A fenti modellek gyakran kombinálódnak is a gyakorlatban. Egy ügynökség kínálhat havi retainer csomagot SLA garanciákkal, míg az eseti ügyfeleknek csak best-effort alapon dolgozik. Az alábbi táblázat egy ügynökség példáján keresztül összefoglalja a szerződés nélküli (ad-hoc) és a retainer szerződéses ügyfelek közti tipikus különbségeket a support szolgáltatás minőségében:
| Szempont | Ad-hoc ügyfél (szerződés nélkül) | Retainer ügyfél (havi szerződéssel) |
|---|---|---|
| Reakcióidő | Kritikus hibára ~2–4 órán belüli reagálás, nem sürgős kérésre ~1 munkanapos válaszidő |
Minden bejelentésre ~1 órán belüli reagálás |
| Ütemezés |
A munka a következő szabad fejlesztői kapacitás alapján ütemeződik (általában csak a soron következő sprintben indul el) |
Prioritásos ütemezés: a retainer ügyfél kéréseit előre sorolják a fejlesztési queue-ban, szükség esetén más feladatok átütemezéséve |
| Hozzárendelt erőforrás | Nincs dedikált kapcsolattartó; a kérést annak beérkezésekor adják ki egy éppen ráérő fejlesztőnek | Dedikált account manager foglalkozik az ügyféllel, munkaidőben “ügyeletben” van a kérésekre . Az ügyfélnek hozzáférése van a senior fejlesztőkhöz is |
| Adminisztráció | Minden új feladat előtt külön időbecslést és árajánlatot kell készíteni, amit az ügyfélnek jóvá kell hagynia – ez akár külön díjjal járhat és időveszteséggel járhat | Nincs szükség minden kérésnél új ajánlatra; a havidíjas keretszerződés alapján automatikusan elindulnak a feladatok, az elszámolás a havi riport része. |
| Prioritás | Korlátozott priorizálás: üzletileg kritikus eseteknél igyekeznek gyorsan reagálni, de a nem szerződéses ügyfél kérései összességében alacsonyabb prioritást élveznek a szerződéssel rendelkező ügyfelekhez képest | Kiemelt prioritás: a retainer ügyfél problémáit előbbre sorolják minden más bejövő feladatnál, garantálva a gyors beavatkozást szükség esetén |
Látható, hogy a havidíjas szerződés jelentős előnyöket nyújt az ügyfélnek a szolgáltatás szintjében (gyorsabb válasz, dedikált felelős, priorizált ügyintézés), ami fontos érv a support szerződés kötésére. Ugyanakkor az ügynökség számára is előnyös, mert a betervezett kapacitás révén hatékonyabban szervezheti a munkát és stabil bevételhez jut.
A nem közvetlen fejlesztéssel töltött idő (briefelés, kutatás, tesztelés) elszámolása
A legtöbb esetben a “láthatatlan” erőforrások elszámolása triggereli a konfliktusok kirobbanását. A support tevékenység során nem csak konkrét kódolási feladatok merülnek fel, hanem számos kapcsolódó tevékenység is: pl. ügyféllel való egyeztetés (briefelés) a problémáról vagy igényről, megoldási kutatómunka és technikai tervezés egy-egy hiba vagy új funkció kapcsán, illetve alapos tesztelés a javítások után. Ezek az indirekt feladatok sok esetben ugyanúgy időigényesek, mint maga a fejlesztés – felmerül tehát, hogyan számolják el ezeket az ügynökségek. Bevett iparági gyakorlat, hogy minden, az ügyfél érdekében végzett időráfordítást az ügynökség beleszámít a support keretbe és kiszámláz az ügyfélnek. A fejlesztői közösségben egyetértés van abban, hogy az olyan tevékenységek, mint a tervezés, dokumentáció, kutatás és tesztelés a munka részei, tehát elszámolható tétel. (Természetesen ezzel a gyakorlattal megrendelők nem mindig értenek egyet! 🙂)
Nyilván ez nem jelenti azt, hogy az ügyfél minden egyes 5 perces e-mail-váltásért vagy telefonhívásért automatikusan külön számlát kap. A gyakorlatban az ügynökségek összevonva, időráfordítási alapon számolják el ezeket a feladatokat. Például ha egy fejlesztő 20 percet töltött azzal, hogy a hibajelzést reprodukálja és átgondolja a megoldást (kutatás), majd 1 órát a kód módosításával (fejlesztés) és újabb 40 percet a teszteléssel, akkor összesen 2 munkaórát könyvelnek el az adott ügyfél feladatra.
Átlátható kommunikációval elejét lehet venni az esetleges vitáknak: érdemes előre tisztázni, hogy a támogatási keret milyen típusú szakmai munkákat, vagy kommunikációs elemeket tartalmaz a konkrét fejlesztésen felül.
Ide sorolható az ügyféllel folytatott konzultáció, a levelezések megválaszolása, a belső megbeszélések az adott ügyben, az utánajárás egy új megoldásnak, vagy épp a deployment és tesztelés folyamata – ezek nélkül ugyanis nem garantálható a minőségi szolgáltatás. A mi ügynökségünk is nyomon követi és kategorizálja is ezeket a ráfordításokat belsőleg, hogy látni lehessen, a support idő hány százaléka megy el fejlesztésre és mennyi kommunikációra vagy tesztelésre vagy garanciális javításokra. Ez nem különül el tételesen az ügyfél felé számlázásban, viszont belső elemzés szempontjából fontos adat. Például ha azt látjuk, hogy egy adott partnerünk havidíjának jelentős részét rendszeresen a kérdések tisztázása viszi el, az felvetheti a szerződés módosítását, újragondolását. Az ilyen jellegű mérések tehát az ügynökség érdekeit szolgálják, de az ügyfélnek is előnyös, mivel a transzparens riportokban viszontláthatja, hogy a befizetett díja milyen tevékenységekre oszlott szét. A bizalom alapja, hogy a supportot nyújtó cég részletesen dokumentálni tudja, mivel töltötte az idejét az ügyfélnek szánt keret terhére. Az ügynökségnek kötelessége is átláthatóan elszámolni a retainer keret felhasználásával és ez magában foglalja a „rejtett” munkát is. Ha egy webfejlesztő ügynökség ezen a téren nem transzparens, az hosszú távon alááshatja a partnerek bizalmát. Bevált gyakorlat az, hogy a fejlesztők minden ráfordított órát rögzítenek, és kérésre vagy rendszeres riport formájában ezt az ügyfél rendelkezésére bocsátják.
Összességében tehát a nem fejlesztői jellegű feladatok idejét a support keret részeként kell kezelni, mert a problémamegoldás nem varázsütésre történik, hanem gondos elemző és tesztelő munka előzi meg a kódolást. 🙂
Belső folyamatok és eszközök az idő mérésére és riportolására
A hatékony support szolgáltatás mögött jól felépített belső folyamatok és eszközök állnak, amelyek biztosítják, hogy az ügynökség pontosan nyomon kövesse a ráfordított időt, betartsa a vállalt SLA-kat, és rendszeresen jelentést adjon az ügyfélnek. Néhány kulcselem ezek közül: időkövetés és timesheet-ek: Szinte minden ügynökségnél standard gyakorlat az idő nyilvántartása – még akkor is, ha az ügyfél felé éppen nem óradíjas elszámolás történik. A belső timesheet rendszerek segítségével a csapat tagjai rögzítik, mennyi időt töltöttek el egy adott ügyfél egy adott feladatán. Ez jellemzően taskokra bontott mérés (például egy Jira tickethez naplózza a fejlesztő a ráfordított órákat). Számos erre szolgáló szoftver létezik a piacon, melyeket kifejezetten ügynökségek igényeire szabtak.
A hrenko-ban például a JetBrains által fejlesztett YouTrack szoftvert használjuk, ami egy könnyen kezelhető időkövető project management eszköz és persze egy kicsit felturbóztuk az igényeinknek megfelelően. Hasonló célt szolgál a Timely vagy a Toggl, amelyek automatikus időmérést és projekt-alapú bontást is kínálnak. Az időkövetés nem pusztán adminisztratív teher – a jól mért adatok alapvető betekintést adnak a cégnek a projektek jövedelmezőségéről és a folyamatok hatékonyságáról. Olyan ügynökségek is trackelik a munkaórákat, amelyek fixdíjas vagy havidíjas alapon dolgoznak, hiszen csak így látják, hol csúszhatnak túl a tervezett ráfordításon, vagy mely ügyfeleknél dolgoznak esetleg többet a szerződött keretnél . Összességében elmondható: egy naprakész fejlesztő cégnél a billable (díjköteles) órák miatt elengedhetetlen a time tracking, de még más díjazási modellek mellett is hasznos nyomon követni, mennyi idő megy el a különböző feladatokra, hogy optimalizálni lehessen az árképzést és a működést .
Az SLA-kal dolgozó cégeknél a helpdesk rendszer monitorozza a reakcióidőket is: be van állítva, hogy jelezzen, ha egy ticket túlhaladta a vállalt reakcióidőt vagy megoldási időt. Az ilyen rendszerek nemcsak a belső szervezettséget javítják, hanem a riportolást is: könnyen lekérdezhető, hogy adott időszakban hány hibajegyet oldottak meg, mennyi idő alatt, volt-e SLA-sértés stb.
A lényeg, hogy minden bejelentés nyomon követhető legyen egy egyedi azonosítóval, státusszal, felelőssel és határidővel. Az ügynökségek belső folyamatai általában meghatározzák, hogyan kezeljik a bejövő support kéréseket: pl. triage-olás (prioritás és kategória adása), majd hozzárendelés egy megfelelő szakemberhez, státuszkövetés (nyitott, folyamatban, megoldva, lezárva), és végül az ügyfél értesítése a megoldásról.
Riportolás és ügyféljelentések: A mérés mit sem ér megfelelő riportolás nélkül. A bevált gyakorlat az, hogy az ügynökség havonta írásos jelentést ad az ügyfélnek a support keret felhasználásáról és az elvégzett feladatokról. Ennek kettős haszna van: egyrészt az ügyfél kézzelfogható bizonyítékot kap arról, hogy mit kap a pénzéért, másrészt edukálja is a folyamatokról. A riport általában tartalmazza az adott hónapban elvégzett feladatok listáját , az ezekre fordított időt/keretet, és az ezekhez tartozó megjegyzéseket is.
Összefoglalva, a kulcs az, hogy az ügynökség méri a support munkát (időben és minőségben egyaránt), és ezt átlátható módon kommunikálja az ügyfél felé. A megfelelő eszközök (időmérő appok, ticketing rendszerek, riport automatizmusok) és folyamatok (SLA nyomon követés, rendszeres beszámolás) nélkül ma már nem lehet hatékony és elszámoltatható support szolgáltatást nyújtani.
Összességében elmondható, hogy egy webfejlesztési projekt sikere nem ér véget a weboldal átadásával. Fontos, hogy tudatosan készüljünk fel arra is, ami a fejlesztés után következik: a weboldal üzemeltetésére, karbantartására és folyamatos fejlesztésére. Ahogyan bejegyzésünkben is kiemeltük, az előzetes tervezés és proaktív gondolkodás jelentős megtakarítást eredményezhet, csökkentheti a biztonsági kockázatokat, és biztosíthatja, hogy a digitális jelenlét hosszú távon is stabilan működjön.
Ezért azt javasoljuk, hogy bármilyen fejlesztésbe úgy vágj bele, hogy már előzetesen tisztában vagy az üzemeltetés és a support pontos részleteivel és azok költségeivel.
Reméljük, hasznosnak találtad a cikket! Ha bármilyen további kérdésed lenne a weboldalak fejlesztésével vagy üzemeltetésével kapcsolatban, keress minket bátran, szívesen segítünk!
