Szabadságkérelem szervizcsapatnál: beosztás és SLA ütközés

Miért a szabadság a legdrágább „láthatatlan” kapacitásveszteség

Egy 12 fős szervizcsapatnál ha egyszerre 2–3 ember van távol (szabadság + betegség + képzés), a tényleges beosztható kapacitás 25–35%-kal csökken. Az SLA viszont nem csökken: a 4 órás P1 és a 24 órás P2 határidő ugyanaz marad. Ha a diszpécser csak a „ki van ma a listán” fejből dolgozik, a hiány akkor derül ki, amikor a ticket már késik — nem amikor a kérelmet még el lehetett volna utasítani, átütemezni vagy helyettesítőt kijelölni.

A rejtett költség három helyen üt. Először a beosztásban: aznap délelőtt scramble, túlóra, rossz match (aki épp bent van, nem aki illik a hibához). Másodszor az SLA-n: a megbízó a szerződéses válaszidőt méri, nem a te nyári keretedet. Harmadszor a csapatban: aki „mindig bent van”, megterhelődik, a következő körben ő is kiesik — a lyuk önmagát erősíti.

A tipikus magyar szerviz-rutin: kérelem Messengerben / e-mailben, „oké” a vezető válaszában, Excel-tábla a HR-nek, naptár a diszpécser laptopján, ticket a CMMS-ben. Négy hely, egy igazság sehol. Egy elutasított vagy félreértett nap (a technikus azt hitte, oké, a diszpécser nem látta) könnyen 2–4 elvesztett kiszállást és egy ügyfél-eszkalációt jelent — 3–6 óra vezetői idő egyetlen ütközésből.

• →12 fős csapat, 2–3 távol: 25–35% kapacitáscsökkenés ugyanazokkal az SLA-kkal
• →Szabadság chatben ≠ beosztás a naptárban ≠ ticket felelős a rendszerben
• →Ütközés felismerése a kérelemkor olcsó; a lejárt P1-nél drága
• →Cél: egy igazságforrás a kérelemtől a naptárblokkon át a beosztásig

Beosztás × SLA: hol ütközik a kérelem a valósággal

Az ütközés nem elvont HR-szabály — konkrét munkákkal ütközik. Három réteg: (1) már kiosztott ticketek / feladatok a kért időszakra; (2) ismétlődő preventív körök, amiknek a due date-je a távollétre esik; (3) szerepkör-hiány: ha a csapat egyetlen F-gázos / lift-jogosult / éjszakás ügyeletes kér szabadságot, a „helyettes van” önmagában nem elég — kompetencia-helyettes kell.

Számolj egyszerűen. 5 nap szabadság × átlag 4 ticket/nap egy specialistánál = 20 ügy, amit át kell adni vagy átütemezni. Ha ebből 3 P1-es, és nincs előre kijelölt backup, a diszpécser a szabadság első reggelén 45–90 percet tölt scramble-lel. Ha ugyanezt a kérelem jóváhagyása előtt csinálja (helyettes + ticket-átadás + naptár), a scramble 10–15 percre csökken, és az SLA nem „szerencse” kérdése.

A szabály, ami a gyakorlatban működik: ne legyen „láthatatlan jóváhagyás”. A kérelem státusza (beküldve / jóváhagyva / elutasítva) ugyanabban a rendszerben él, ahol a naptár és a ticket. A diszpécser a heti naptár-review-ban (15 perc, jövő 14 nap) látja a szabadságblokkokat a ticketek mellett — nem külön Excel-lapot kell összeolvasnia. Ha a naptár szűrhető szabadságra, 5 másodperc alatt kiderül, hogy jövő héten a keleti régióban két ember is távol van.

• →Ellenőrizd a kért napokon: nyitott ticket, preventív due date, ügyelet
• →Specialista-szabadság = kompetencia-helyettes, ne csak „van valaki bent”
• →5 nap × ~4 ügy/nap = ~20 átadandó tétel — előre, ne az első reggelen
• →Heti 15 perc naptár-review: jövő 14 nap, szabadság + SLA együtt

Mobil szabadságkérelem: a terepről, nem a háttérirodából

A szervizes nem az asztalánál ül, amikor a nyári hetet kéri. Ha a kérelem csak webes HR-portálon megy, amihez VPN és asztali böngésző kell, a valóság visszaesik a chatbe: „Jövő hétfőtől elmennék 5 napra, oké?” A mobil kérelem pont ezért nem „nice to have” — hanem az egyetlen út, hogy a folyamat a terepi rutin része legyen, ne kerülőút.

A jó mobil flow egyszerű: dátumtól–dátumig, opcionális megjegyzés (pl. „családi ok”, „előre egyeztetett helyettes: Kovács”), beküldés, státusz követése. Nincs PDF-űrlap, nincs e-mail-csatolmány, amit a vezető a telefonján nem tud rendesen bírálni. A kérelem azonnal bekerül a közös listába; a vezető / diszpécser értesítést kap, és a naptárban (legalább pendingként) látszik a szándék, mielőtt a jóváhagyás megszületik.

Gyakorlati elvárás a csapat felé: a kérelem minimum 10–14 nappal a kezdés előtt, kivéve igazolt sürgős eset. A rendszer nem helyettesíti a szabályzatot, de láthatóvá teszi a késői kérelmeket: ha valaki pénteken kér hétfői kezdést, a diszpécser a naptárban azonnal látja a ticket-ütközést, és indokoltan elutasíthat vagy átütemezést kérhet — nem „rosszindulatból”, hanem mert 8 nyitott ügy van a nevére.

• →Kérelem mobilon: dátum, megjegyzés, beküldés, státusz — 1 perc
• →Pending kérelem is látszódjon a naptárban (ne csak a jóváhagyott)
• →Belső szabály: 10–14 nap előre, kivéve sürgős / igazolt eset
• →Chat-kérelem = nincs nyoma a beosztásban → tiltsd a „hivatalos” csatornának

E-mail értesítés és a jóváhagyási lánc

A kérelem önmagában nem elég, ha a bíráló nem tud róla. Az e-mail értesítés a legkisebb súrlódású csatorna: a vezető / diszpécser a meglévő postafiókjában kapja a „új szabadságkérelem” üzenetet, linkkel a döntéshez. Ugyanígy értesül a kérelmező a jóváhagyásról vagy elutasításról — nem kell a chatben visszakérdezni „láttad?”.

A döntési rend legyen egyértelmű: ki bírál (csapatvezető, diszpécser, mindkettő), mi a SLA a bírálatra (pl. 2 munkanap), és mi történik, ha a kérelem ütközik. Jó gyakorlat: a bíráló a döntés előtt 30 másodpercben megnézi a naptár-szűrt nézetet (szabadságok + a kérelmező ticketjei a kért időszakra). Ha van ütközés, a válasz ne „nem”, hanem „átütemezés helyettessel / más héten / részben” legyen — 1 mondatos indokkal a rendszerben.

Az értesítés nem spamszórás. Értesüljön: a kérelmező, a közvetlen bíráló, és ha a csapat több műszakos / több régiós, a diszpécser, aki a naptárat viszi. Ne értesüljön az egész cég minden 1 napos kérelmről. A cél a döntés sebessége (cél: 80%+ kérelem 48 órán belül lezárva), nem a zaj.

• →Új kérelem → e-mail a bírálónak; döntés → e-mail a kérelmezőnek
• →Bírálati SLA: pl. 2 munkanap; mérés: % lezárva 48 órán belül
• →Döntés előtt: naptár + ticket-ütközés 30 mp-es ellenőrzése
• →Elutasítás / módosítás mindig indokkal — később auditálható

Naptár-szűrés szabadságra és a védett jóváhagyás

A naptár akkor használható beosztásra, ha a szabadság nem „másik modulban” van elrejtve. A diszpécsernek tudnia kell szűrni: csak szabadságok, csak egy régió / csapat, csak a következő 14 nap. Egy 20 fős listánál a szűretlen naptár zsúfolt; a „szabadság” szűrő 5 másodperc alatt megmutatja a lyukakat — mielőtt a hétfői P1-eket kiosztanád.

Második szabály: a jóváhagyott szabadság ne legyen szabadon törölhető bárki által. Ha a technikus (vagy akár a műszakvezető) egy gombnyomással törölhet egy már jóváhagyott hetet, a beosztás és a helyettesítés érvényét veszti — „visszajöttem, mégsem megyek” káosz. A helyes modell: jóváhagyott tétel törlése / visszavonása csak admin (vagy kijelölt HR / vezetői) jogosultsággal; a kérelmező módosítást kérhet, de a törlés nem „önkiszolgáló undo”.

Ez nem bürokrácia — audit és kapacitásvédelem. A naptárban látszó blokk a diszpécser tervezési alapja: ha az eltűnik nyom nélkül, a ticketek felelőse „visszaáll” egy olyan napra, amikor az ember valójában mégis távol van, vagy fordítva: a helyettes feleslegesen marad beosztva. Admin-törlés + napló (ki, mikor, miért) = a beosztás megbízható marad.

• →Naptár szűrő: szabadság / csapat / időszak — lyukak 5 mp alatt
• →Pending + approved blokkok külön színnel a ticketek mellett
• →Jóváhagyott szabadság törlése: csak admin — nem önkiszolgáló
• →Változás = napló: ki vonta vissza, mikor, indok (helyettes újraosztás)

Bevezetési checklist: 2 hét alatt működő folyamat

Ne a „mindenki használja a HR-modult” jelszóval kezdd. Először a szabály, utána a csatorna, utána a mérés. Két hét alatt egy 10–15 fős szervizcsapatnál stabilizálható a folyamat, ha a diszpécser és egy vezető végigviszi a listát.

• →Írd le 1 oldalon: ki bírál, hány nap előre a kérelem, mi a helyettes-szabály specialistánál
• →Kapcsold be a mobil kérelmet; tiltsd a chatet hivatalos csatornaként (1 körös team-üzenet)
• →E-mail értesítés: bíráló + kérelmező; teszteld 1 próbakérelemmel
• →Naptár: szabadság-szűrő a diszpécser kezdőképernyőjén / heti review checklistjén
• →Jogosultság: approved leave delete = admin only; ellenőrizd technikus fiókkal
• →Baseline 2 hét: hány kérelem jött chaten, hány SLA-csúszás volt távollét miatt
• →Célmutatók: 90%+ kérelem rendszeren keresztül; 80%+ bírálat 48 órán belül; 0 „láthatatlan” szabadság a naptárban
• →Heti 15 perc: jövő 14 nap naptár — szabadság × ticket × ügyelet ütközés

Összegzés és következő lépés

A cikkben összefoglalt gyakorlati lépések akkor működnek tartósan, ha egy központi rendszerben futnak a munkalapok, az eszköznyilvántartás, a preventív ütemezés és — ahol kell — a tűzvédelmi ellenőrzések is. A szétszórt Excel-fájlok és papír naplók hosszú távon nem adják az auditálhatóságot és a valós idejű átláthatóságot.

A SafetyPro CMMS ezeket egy platformon egyesíti: QR/NFC azonosítás, mobil app offline módban, riportok és emlékeztetők. A Basic csomag 24 900 Ft/hó-tól indul; 14 napos ingyenes próba egyeztethető személyesen, a bemutató után.

Ha a témában leírt folyamatokat szeretnéd élesben látni a saját telephelyed példáján, kérj bemutatót — az értékesítési csapat általában 1 munkanapon belül válaszol.