Elakadt ticketek és lejárt feladatok: diszpécser riasztási rendszer

Definíciók: mi az elakadt ticket és a lejárt feladat

A két fogalmat a diszpécser gyakorlatban gyakran egy kalap alá veszi („késő dolgok”), pedig más a gyökér és más a beavatkozás. Az elakadt ticket a bejelentés oldala: a jegy nyitva van, de a folyamat megállt. Nincs triage, nincs felelős, vagy van felelős, de X órája sem státusz, sem komment, sem feladat nem született. Tipikus okok: e-mail jött be, de a diszpécser nem erősítette meg; „várunk alkatrészre” státusz, de senki nem követte; merge nélkül három párhuzamos jegy ugyanarra a hibára, mindegyik „folyamatban”.

A lejárt feladat a beosztás oldala: van felelős, van due date, a munka a naptárban volt — de a határidő elment, és a feladat nincs lezárva (nincs munkalap, nincs „kész” státusz). Tipikus okok: túlterhelt nap, ügyfél nem engedi be, alkatrész késik, vagy a technikus lezárta fejben, de a rendszerben nem. A lejárt feladat gyakran SLA-sértés a megbízó felé; az elakadt ticket gyakran „még nem is indult el a munka”, ami ügyfél-élményben még rosszabb.

Számokban: egy 12 fős szervizcsapatnál heti 80–150 nyitott ticketből tipikusan 8–15% elakad 24–48 óra után (kb. 10–20 jegy), ha nincs riasztás. Ugyanott a heti feladatok 5–12%-a lejár (due +1 napon túl), ha a naptár csak „szép” és nem figyelmeztet. A kettő együtt a diszpécser reggeli stresszének 70–80%-a — nem az új bejövők, hanem a reggelre felhalmozódott csendes késések.

A SafetyPro-ban a header riasztás pont ezt a kettőt emeli ki: elakadt ticket számláló + lejárt feladat számláló. Nem kell listát görgetni, Excel-szűrőt építeni vagy „ki emlékszik rá” kört indítani. A szám magától jön a szabályokból; a kattintás a szűrt nézetre visz.

• →Elakadt ticket: nyitott jegy, X órája nincs státusz / hozzárendelés / komment / feladat
• →Lejárt feladat: due date elmúlt, a task nincs lezárva
• →Elakadt = bejelentés megállt; lejárt = beosztott munka csúszik
• →Más a beavatkozás: triage / kiosztás vs. átütemezés / eszkaláció / lezárás
• →Cél: mindkettő látszódjon a fejlécben, ne csak a „mai listában”

Küszöbök: mikor legyen riasztás

A riasztás értéke a küszöbön múlik. Ha minden 2 órás csend riaszt, a diszpécser 1 hét alatt kikapcsolja a hangot. Ha csak 5 nap után jön a jelzés, a megbízó már panaszt írt. A küszöböt prioritás és szerződés szerint érdemes bontani — nem egy globális „minden ticket 48 óra”.

Gyakorlati kiindulás service / FM környezetre (finomítsd a saját SLA-idhoz). Elakadt ticket: P1 (kritikus leállás / biztonság) 2–4 óra inaktivitás után riasztás; P2 (sürgős, de nem életveszély) 8–12 óra; P3 (normál hiba) 24 óra; P4 (kis javítás / kérés) 48–72 óra. „Inaktivitás” = nincs státuszváltás, nincs új komment, nincs létrehozott vagy frissített feladat. A „várakozás ügyfélre / alkatrészre” státusznál az óra szünetelhet — de a várakozás oka és a következő emlékeztető dátuma kötelező, különben a jegy örökre elakad csendben.

Lejárt feladat: a due date napján reggel (vagy due −4 óra P1-nél) sárga figyelmeztetés; due +1 munkanap piros riasztás a headerben; due +3 nap vezetői eszkaláció. Preventív / ismétlődő SLA feladatoknál (havi bejárás) a due +1 nap már diszpécser-szint, due +3 nap vezető — mert a szerződéses határidő keményebb, mint egy „majd holnap befejezem” belső task.

Mérj heti 5 percben: hány riasztás jött, hány volt „hamis pozitív” (a munka ment, csak nem frissült a jegy), hány volt valós. Ha a riasztások >40%-a zaj, emeld a küszöböt vagy szűkítsd a státuszokat. Ha a panaszok jönnek riasztás nélkül, csökkentsd 20–30%-kal az időablakot a P2–P3 sávon. A header nem dekoráció — a küszöb a hangolás.

• →P1 elakadás: 2–4 óra inaktivitás → header riasztás
• →P2: 8–12 óra; P3: 24 óra; P4: 48–72 óra
• →Lejárt task: due nap sárga; due +1 nap piros header; due +3 nap vezető
• →Várakozás státusz: SLA-óra szünetelhet, de ok + következő emlékeztető kötelező
• →Heti hangolás: ha >40% zaj a riasztásban, emeld a küszöböt

Reggeli 10 perc rutin a diszpécsernek

A riasztási rendszer csak akkor hoz ROI-t, ha a diszpécser reggel ugyanazzal a rituáléval nyit. Nem 45 perces „listabúvárkodás”, hanem 10 perces döntési kör: mi piros, mi sárga, mi mehet a napi beosztásba. A header számlálói a belépőpontok — nem a heti Excel.

Perc 0–2: nyisd a headert. Elakadt ticketek száma + lejárt feladatok száma. Ha mindkettő 0, a nap indítható a friss bejövőkkel. Ha van piros, ne a legújabb e-maillel kezdj — a csendes késések előbb eszkalálódnak ügyfélnél, mint a friss bejelentés.

Perc 2–6: elakadt ticket lista (egy kattintás a számlálóból). Minden tételre 20–30 másodperc döntés: (A) triage most — telephely, prioritás, felelős; (B) feladat létrehozás / átütemezés; (C) merge másik jegybe; (D) várakozás okkal + emlékeztető dátum; (E) eszkaláció vezetőnek, ha P1/P2 és 24+ órája áll. Ne hagyd „majd délután” — a délután tele lesz új bejövőkkel.

Perc 6–9: lejárt feladatok. Minden task: technikus elérhető? Ügyfél ablak? Alkatrész? Döntés: ma átütemez + új due, vagy azonnali kiszállás, vagy vezetői eszkaláció. A „kész volt, de nem zártam le” eseteket a technikus 1 perc alatt zárja mobilról — ha 3 napig nyitva marad, az admin adósság, nem munka.

Perc 9–10: írj 3–5 soros napi képet magadnak vagy a csapatcsatornába: X elakadt tisztázva, Y lejárt átütemezve, Z eszkalálva. 10 perc múlva a headernek csökkennie kell, vagy a maradék tételeknek felelőse és következő lépése van. Ha 10 perc után ugyanott tartasz, a küszöbök vagy a szerepek hibásak — nem a rutin.

• →0–2 perc: header számlálók — elakadt + lejárt
• →2–6 perc: elakadt ticket döntés (triage / task / merge / vár / eszkalál)
• →6–9 perc: lejárt task (átütemez / ma viszi / eszkalál / lezár admin adósság)
• →9–10 perc: 3–5 soros napi kép a csapatnak
• →Cél: 10 perc után minden pirosnak van felelőse és következő lépése

Eszkalációs mátrix: ki kap riasztást, mikor

A header riasztás a diszpécsernek szól először. Ha csak ott marad, és a diszpécser szabadságon van, a rendszer néma. Az eszkalációs mátrix idő × prioritás × szerep: ki kap push/e-mail értesítést, ha a tétel tovább áll.

Elakadt ticket mátrix (példa): P1 — 2 óra diszpécser header + push; 4 óra csapatvezető; 8 óra ops vezető. P2 — 12 óra diszpécser; 24 óra csapatvezető. P3 — 24 óra diszpécser header (nincs push-áradat); 48 óra csapatvezető. P4 — csak heti riport, ne napi riasztás. A felelős technikus kapjon értesítést, ha rá van rendelve a jegy és elakad — de ne kapjon 40 mások jegyéről szóló push-t.

Lejárt feladat mátrix: due nap — felelős technikus emlékeztető. Due +1 munkanap — diszpécser header piros + technikus ismétlés. Due +2 — csapatvezető. Due +3 / kritikus SLA — ops vezető + opcionálisan megbízói SLA flag a riportban. Ismétlődő szerződéses feladatoknál (havi bejárás, negyedéves audit) a lánc rövidebb: due +1 már diszpécser, due +3 vezető.

A mátrix három szabálya: (1) ne riaszd ugyanazt a személyt 3 csatornán egyszerre ugyanarról (header + e-mail + SMS = zaj); (2) a riasztás mindig linkkel a konkrét jegyre/feladatra menjen, ne „van 12 késő” szöveggel; (3) az eszkaláció ne oldja meg a munkát helyetted — csak emberi döntést kényszerít, ha a diszpécser szintje nem elég. Heti KPI: átlagos idő riasztástól első státuszváltásig (cél elakadt P1–P2-nél <2 óra munkaidőben).

• →P1 elakadás: 2 óra diszpécser → 4 óra vezető → 8 óra ops
• →P2: 12 óra diszpécser → 24 óra vezető
• →Lejárt task: due nap technikus → +1 nap diszpécser → +2–3 nap vezető
• →Egy riasztás = egy link a tételre, ne csak összesített szöveg
• →KPI: riasztás → első státuszváltás ideje (P1–P2 cél: <2 óra)

Anti-patternek: ami elrontja a riasztást

A legtöbb „van riasztásunk, de senki nem nézi” történet nem technikai hiba — hanem folyamat-anti-pattern. Ha ezek közül 3+ igaz rátok, a header badge csak piros dekoráció lesz a képernyő sarkában.

• →Minden ticket ugyanazzal a 4 órás küszöbbel — P4 zaj elnyomja a P1-et
• →Nincs „várakozás okkal” státusz: minden csend elakadásnak számít, hamis riasztás
• →Riasztás e-mailben, de a jegy más rendszerben — kattintás nélkül keresel 3 percet
• →Technikus 20 push/nap → 1 hét múlva mindent elnémít
• →Header számláló van, de a kattintás nem szűrt listára visz
• →„Kész” a WhatsAppon, a ticket/task nyitva marad — örök elakadás/lejárás
• →Diszpécser helyett mindenki kap mindent — felelősség diffúzió
• →Küszöb soha nincs hangolva: 6 hónapja ugyanaz, a volume megduplázódott
• →Lejárt taskot törlitek a listából audit nélkül — a késés eltűnik, a panasz marad
• →Reggeli rutin helyett „majd ha van idő” — a piros szám estére nő

Checklist: riasztási rendszer bevezetése és heti audit

Használd bevezetéskor (1–2 hét) és utána heti 10 perces auditként. Ha a checklist nagy része zöld, a header riasztás tényleg csökkenti a rejtett backlogot — nem csak új UI elem.

• →Checklist: elakadt ticket definíció leírva (mely státuszok, mi számít aktivitásnak)?
• →Checklist: lejárt feladat = due < ma ÉS nincs lezárva — egyértelmű a csapatnak?
• →Checklist: küszöbök prioritásonként (P1–P4) dokumentálva és beállítva?
• →Checklist: header számláló elakadt + lejárt, kattintás szűrt listára?
• →Checklist: eszkalációs mátrix szerepekkel (diszpécser / vezető / ops)?
• →Checklist: várakozás státusz okkal + emlékeztető dátum kötelező?
• →Checklist: diszpécser reggeli 10 perc rutin be van vezetve (nem opcionális)?
• →Checklist: heti zajarány mérés (hamis pozitív <40%)?
• →Checklist: KPI riasztás→első státuszváltás követve?
• →Checklist: szabadság esetén helyettes kapja a header/eszkaláció szerepet?
• →Anti-check: ne legyen 15+ riasztástípus — 2 fő (elakadt, lejárt) + prioritás elég
• →Anti-check: ne töröld a lejártat audit trail nélkül

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