SLA szervizszerződés digitalizálása: esedékesség, ticket, bizonyíték

Mit jelent valójában az SLA a szervizszerződésben

Az SLA (Service Level Agreement) a szerviz- vagy facility szerződésben nem „szép melléklet”, hanem mérhető kötelezettség. Tipikusan három réteget fed: (1) reaktív válasz — hiba bejelentésétől mennyi időn belül kell visszajelezni (response time); (2) megoldási határidő — mennyi időn belül kell helyreállítani vagy ideiglenes megoldást adni (resolution time); (3) ciklusos kötelezettség — havi bejárás, negyedéves felülvizsgálat, éves nagyjavítás, ami nem hibából, hanem naptárból jön.

Számokban egy közepes irodaház- vagy multi-site service szerződésnél: P1 kritikus hiba response 1–2 óra, resolution 4–8 óra; P2 response 4–8 óra, resolution 24–48 óra; P3 1–3 munkanap. Emellett 12 havi bejárás, 4 negyedéves checklist és 1 éves audit-csomag. Éves szinten ez könnyen 200–600 ticket/munkalap esemény — ha csak a „nagy” tételeket számolod. Excelben és e-mailben ez a volumen nem követhető tiszta response/resolution mutatóval.

A megfelelőségi kockázat kettős. A megrendelő (üzemeltető, tulajdonos, létesítménygazda) nem tudja bizonyítani a bérlőnek vagy a hatóságnak, hogy a szolgáltató teljesített. A szolgáltató (kivitelező, FM, szervizcég) nem tudja megvédeni magát a büntető tétel vagy a tender-veszteség ellen, mert a bizonyíték szétszóródott. Az SLA digitalizálása mindkét oldalon ugyanazt adja: egy láncot esedékességtől a lezárt munkalapig.

• →Response time: bejelentés → első érdemi válasz / kiszállás indítás
• →Resolution time: bejelentés → helyreállítás vagy elfogadott ideiglenes megoldás
• →Ciklusos SLA: havi / negyedéves / éves ismétlődő kötelezettség due date-tel
• →Prioritás (P1–P3) határozza meg az órákat — nem a „majd megnézzük”
• →Bizonyíték: munkalap + időbélyeg + fotó / aláírás, nem szóbeli „kész”

A papír–Excel–e-mail háromszög bukási pontjai

A legtöbb élő SLA-szerződés így néz ki a gyakorlatban: a szerződés PDF a megosztott mappában; a havi esedékességek Excel naptárban vagy Google Sheetben; a hibabejelentés e-mailben vagy telefonon; a kiszállás WhatsApp-csoportban; a lezárás papír munkalapon az autóban. Auditnál 3–5 nap megy el a „összeszedésre” — és mégis hiányzik 8–15% tétel fotója vagy aláírása.

Öt tipikus bukás: (1) az esedékesség nincs a munkavégző előtt — a technikus nem látja a due date-et a mobil listában; (2) a response/resolution nem indul automatikusan a bejelentés időbélyegétől, hanem utólag „visszaírják” a táblázatba; (3) a ciklusos kötelezettség nem generál ticketet — valaki „emlékszik” a havi bejárásra; (4) a lezárás nem kötődik a szerződéses tételhez — nem derül ki, melyik SLA-sor teljesült; (5) a havi megfelelőségi riport utólagos színezés, nem valós idejű KPI.

Egy 15 telephelyes, 3 prioritásos SLA portfóliónál havi ~80–120 reaktív ticket és ~20–40 ismétlődő kötelezettség reális. Ha a response mérés 30%-ban hiányos (nincs tiszta „első válasz” időbélyeg), a havi SLA-riport vitatható — és a megrendelő–szolgáltató meeting 40 perce nem a javításról, hanem a táblázat hitelességéről szól. A digitalizálás célja: ne a riport legyen a vita tárgya, hanem a nyitott P1-ek.

• →Szerződés PDF ≠ működő SLA — a határidőnek ticketben kell élnie
• →Utólagos Excel-színezés nem response/resolution mérés
• →Ciklusos kötelezettség ticket nélkül = rejtett lemaradás
• →Papír munkalap az autóban = audit-lyuk 24–72 órán át
• →Nincs kapcsolat: szerződéses tétel ↔ ticket ↔ lezárt munkalap

Esedékesség: response, resolution és ciklusos due date

Az esedékesség az SLA szíve. Három óraütés kell tisztán: (1) bejelentés időbélyege — a ticket létrehozásakor, ne „majd beírom”; (2) response esedékesség — bejelentés + SLA response ablak (pl. P1 = +2 óra); (3) resolution esedékesség — bejelentés + SLA resolution ablak (pl. P1 = +8 óra). A diszpécser és a technikus a ticketen látja mindhármat; a lejárt ablak piros, a közelgő sárga.

A ciklusos kötelezettségeknél az esedékesség due date: a havi bejárás 2026-08-15, a negyedéves felülvizsgálat 2026-09-30. Itt nincs „response a hibára” — van ismétlődő szabály, ami a due előtt létrehozza a ticketet, checklisttel és felelőssel. A két világ (reaktív SLA órák vs. naptár-SLA napok) ne keveredjen egy Excel-oszlopba: más a KPI, más az eszkaláció, de mindkettő ticket + munkalap láncon zárul.

Gyakorlati beállítás: prioritásonként response/resolution percben vagy órában a szerződésből; munkaidő-naptár (7×24 vs. 5×8) a számoláshoz — különben a hétvégi P2 hamisan „sérül”; ismétlődő szabályok a havi/negyedéves tételekre due date-tel a tárgyban. A SafetyPro ticketing és ismétlődő feladatai pont ezt fedik: a határidő a munkán van, nem a PDF 14. oldalán.

• →Bejelentés időbélyeg = a response/resolution óra nullpontja
• →P1–P3 ablakok szerződésből, nem „érzésből”
• →Munkaidő-naptár: 7×24 vs. munkanap-SLA külön számolás
• →Ciklusos due date az ismétlődő ticket tárgyában is látszik
• →Közelgő / lejárt esedékesség vizuális kiemelés a listában és a naptárban

Ticket mint az SLA végrehajtási egysége

A digitalizált SLA-ban a ticket a végrehajtási egység: minden szerződéses kötelezettség — reaktív hiba vagy ciklusos bejárás — ticketként él. Mezők, amik nélkül az SLA-riport üres: megbízó / telephely, prioritás, SLA típus (reaktív vs. ismétlődő), response due, resolution due (vagy ciklusos due date), felelős, kapcsolódó eszköz vagy helyszín, státusz. A kommunikáció (e-mail szál, megjegyzés) a ticketen marad — nem párhuzamos postafiókban.

Ismétlődő ticketek a ciklusos SLA-ra: havi bejárás, negyedéves checklist, éves felülvizsgálat. Egy szabály = ciklus + sablon + felelős + due logika; a rendszer generálja a futásokat. Így a „elfelejtett havi kötelezettség” nem diszpécser-szabadság kérdése. A reaktív oldalon a bejövő e-mail vagy telefon ticketet nyit prioritással — a response óra azonnal ketyeg.

Státuszok, amik védik az SLA-t: Új → Válaszolva / úton (response teljesítve) → Folyamatban → Várakozik (alkatrész, megrendelői ablak — az óra szabály szerint szünetelhet) → Munkalap kész → Lezárva. A „kész e-mailben” nem response; a „kimentünk” nem resolution. A response akkor teljesül, ha a rendszer rögzíti az első érdemi lépést (visszajelzés vagy kiszállás indítás); a resolution akkor, ha a helyreállítás elfogadott és a munkalap lezárható.

• →Minden SLA-tétel = ticket (reaktív vagy ismétlődő)
• →Prioritás + response/resolution due a jegy fejlécében
• →Ismétlődő szabály a havi/negyedéves szerződéses sorokra
• →Várakozik státusz: megrendelői késleltetés ne büntesse hamisan a szolgáltatót
• →Egy telephely = egy hely a riportban, ne 4 Excel-fájl

Munkalap mint szerződéses és audit bizonyíték

Az SLA viták 80%-ában nem az a kérdés, „elment-e valaki”, hanem „bizonyítható-e, hogy a szerződéses szint teljesült”. A munkalap a válasz: elvégzett munka, időbélyeg, felelős, fotó, checklist OK/NOK, ügyfél vagy helyszíni aláírás, PDF. A ticket mondja meg, mi volt az esedékesség; a munkalap mondja meg, mi történt. Ha a kettő nincs összekötve, a megfelelőségi lánc elszakad.

Minimum lezárási csomag szerződéses kiszállásnál: (1) kapcsolódó ticket ID és telephely; (2) megérkezés és távozás / munkavégzés időbélyege; (3) rövid műszaki leírás; (4) legalább 1–3 fotó, ha a checklist vagy a hiba jellege indokolja; (5) aláírás vagy megrendelői visszaigazolás, ha a szerződés kéri; (6) felhasznált anyag, ha számlázás is van. Enélkül a „resolution teljesült” állítás auditnál gyenge.

A riport oldala: havi SLA megfelelőség = időben response-olt ticketek % + időben resolution-özött ticketek % + időben lezárt ismétlődő kötelezettségek %. Cél service/FM környezetben gyakran ≥95% response, ≥90–95% resolution (P1 szigorúbb), ≥98% ciklusos due. A SafetyPro munkalap és riport modulja ezt egy forrásból adja — nem hó végi PDF-vadászatot a megosztott mappából.

• →Ticket = kötelezettség és határidő; munkalap = helyszíni bizonyíték
• →Időbélyeg + felelős + fotó/checklist a lezárás minimuma
• →Aláírás / visszaigazolás, ha a szerződés vagy a számla kéri
• →Havi KPI: response %, resolution %, ciklusos due %
• →Audit kérdésre másodperces válasz: ki, mikor, mit, milyen jeggyel

Bevezetés 30 napban: mit digitalizálj először

Ne a teljes 40 oldalas szerződést akard nap 1-jén leképezni. 30 napos, megfelelőség-központú sorrend: 1. hét — a 3 leggyakoribb prioritás (P1–P3) response/resolution ablakai + munkaidő-naptár; minden új bejelentés ticket, tiszta időbélyeggel. 2. hét — a top 5–10 ciklusos kötelezettség ismétlődő szabállyá (havi bejárás, negyedéves checklist); due date a tárgyban. 3. hét — munkalap-sablon a lezárási minimummal; tilos a „kész” aláírás/fotó nélkül a szerződéses típusoknál. 4. hét — első havi SLA-riport a rendszerből; a lemaradások oka (kapacitás / megrendelő / alkatrész / egyéb).

Szerepek: a megrendelői oldalon a létesítménygazda a KPI-t és az auditcsomagot kéri; a szolgáltatói oldalon a diszpécser a ticket és az esedékesség gazdája, a szervizes a munkalap gazdája. Heti 20 perc közös review: lejárt P1/P2, közelgő ciklusos due-k, aláírás nélküli lezárások darabszáma (cél: 0 a kötelező típusoknál).

Ha 30 nap után a response % még mindig „nem tudjuk megmérni”, a gond nem a szoftver — hanem hogy a bejelentés nem a ticket időbélyegénél indul. Ha a ciklusos tételek 10%-a csúszik, nézd a naptár terhelését és a felelős backupot, ne azonnal a szerződést. A digitalizált SLA akkor érett, ha a havi meeting 15 perce a kivételekről szól, nem arról, hogy „melyik Excel az igaz”.

• →1. hét: P1–P3 response/resolution + minden hiba = ticket
• →2. hét: top ciklusos kötelezettségek ismétlődő ticketként
• →3. hét: munkalap-sablon + lezárási kapu (bizonyíték kötelező)
• →4. hét: első rendszeres SLA-riport + lemaradás-okok
• →Heti 20 perc: lejárt ablakok, közelgő due, hiányzó aláírások
• →Cél 90 napra: ≥95% response, mérhető resolution, ≥98% ciklusos due

Ö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.