Megfelelőség
Tevékenységnapló service cégnél: ki mit módosított a jegyben
Ha a jegy „kész”, de senki nem tudja, ki törölte a feladatot vagy ki írta át a prioritást, az audit és a megbízói vita elveszett. Tevékenységnapló: ki, mit, mikor — telephelyenként szűrve.
A service cégnél a tevékenységnapló nem IT-admin napló: azt mutatja, ki mit módosított a jegyben, ki törölte a feladatot, ki emelte a prioritást, és ki zárta le a munkalapot — időbélyeggel, visszavonhatatlanul. Megbízói vitánál, belső auditon vagy hatósági kérdésnél a kérdés nem az, hogy „emlékszik-e valaki”, hanem hogy a rendszer 10 másodperc alatt visszaadja: ki, mit, mikor, melyik telephelyen. A napló multi-tenant szűréssel védi a kivitelező partnereket is: mindenki csak a saját hatókörét látja.
Miért nem elég a „kész” státusz: a service cég felelősségi lyukai
A jegy státusza megmutatja, hol tart az ügy. Nem mutatja meg, hogyan jutott oda. Service környezetben ez a különbség drága: a megbízó vitatja a kiszállást, a diszpécser azt mondja „valaki törölte a feladatot”, a szervizes azt, hogy „soha nem is kaptam meg”. Excel- és Outlook-világban ezek a történetek fejből és chatből rekonstruálódnak — vagy sehogy.
Tipikus lyukak 8–30 fős szervizcsapatnál: a prioritás P2-ről P1-re ugrik, de nincs indoklás; a telephely mezőt valaki átírja a triage után; egy feladat eltűnik a naptárból, és a ticket „kész” marad; a megbízói megjegyzés felülíródik; a számlázandó flag le- és felkapcsolódik a hónap végén. Napi 40–120 bejövő jegy mellett ezek nem ritka balesetek — hanem a skála melléktermékei, ha nincs tevékenységnapló.
A napló feladata nem a mikromenedzsment. A cél: vitás esetben tény, nem emlék; auditon bizonyíték, nem dosszié-vadászat; több partner mellett tiszta határ — ki mit láthat a közös telephelyen. A ticket → feladat → munkalap lánc csak akkor auditálható, ha a lánc minden törése is rögzül.
- →Státusz = hol tart az ügy; tevékenységnapló = hogyan és ki által változott
- →8–30 fős csapat, heti több tucat prioritás- és felelős-váltás: napló nélkül vakság
- →Megbízói vita 15–40 perc „ki csinálta?” helyett 30–60 másodperc szűrés
- →Törölt feladat = rejtett kockázat: a jegy „él”, a kiszállás nincs
Mit rögzítsen a tevékenységnapló a jegy életciklusán
A jó activity log nem mindent dump-ol zajként, hanem a döntési és felelősségi eseményeket. Service jegyeken a minimumkészlet: létrehozás (forrás: e-mail, telefon, portál, manuális), mezőváltozások (telephely, eszköz, prioritás, megbízó, SLA típus), felelős és hozzárendelés, státuszváltások, megjegyzések és belső note-ok, csatolmány hozzáadás/eltávolítás, merge / összefűzés, munkalap-kötés és számlázandó jelölés.
Kritikus külön tétel: a feladatok életciklusa a jegyhez kötve. Feladat létrehozása, áthelyezése, felelős-csere, lezárás — és a törlés. Ha a törlés nem naplózódik a jegy idővonalán, a diszpécser „üres” naptárral marad, a megbízó pedig „miért nem jöttetek?” üzenetet küld. A napló sora legyen emberi nyelven is olvasható: „Kiss Anna törölte a 2026-07-12 09:00–12:00 feladatot (ok: ügyfél elhalasztotta)” — ne csak egy technikai DELETE kód.
Időbélyeg, aktor (felhasználó vagy rendszer/AI), régi → új érték, és ha van, indoklás / megjegyzés. Az AI triage javaslat is esemény: „AI javasolta: telephely X, prioritás P2 — megerősítette: diszpécser Y”. Így később látszik, hol volt gépi javaslat, és hol emberi döntés — anélkül, hogy az AI „magától” felelősséget vállalna.
- →Létrehozás: forrás, idő, létrehozó (ember / e-mail szinkron / import)
- →Mezőváltozás: prioritás, telephely, eszköz, megbízó, SLA — régi → új
- →Státusz: Új → Triage → Feladathoz kötve → Munkalap kész → Számlázandó → Lezárva
- →Feladat: létrehozás, áthelyezés, felelős-csere, lezárás, törlés (ok kötelező)
- →Kommunikáció: ügyfél-válasz a szálban, belső note, csatolmány
- →Merge / split: melyik jegyekből / melyikbe, ki indította
- →AI esemény: javaslat + ember megerősítés / elutasítás — nem automatikus lezárás
Feladat törlése a jegy idővonalán: a leggyakoribb „láthatatlan” hiba
Service-ben a feladat a kiszállás és a kapacitás egysége. Ha valaki törli — ügyfél elhalasztotta, rossz cím, dupla kiosztás — a jegy státusza gyakran változatlan marad. A naptárból eltűnik a sor; a megbízó továbbra is „folyamatban” ügyet lát; a következő műszak nem tudja, miért nincs beosztás. Ezt a rést csak a jegyhez kötött törlés-napló zárja be.
Gyakorlati szabály: a feladat törlése soha ne legyen csendes. Kötelező mezők: ki törölte, mikor, melyik időablak és felelős volt, mi az indok (előre definiált lista + szabad szöveg), és mi a jegy következő státusza (pl. Várakozik ügyfélre, Újra triage). Ha a törlés „visszaállítandó” (téves kattintás), a napló akkor is maradjon — a soft-delete / restore is esemény, nem magyarázat nélküli újranyitás.
Számok a valós életből: 15 fős szerviznél heti 8–25 feladat-törlés vagy jelentős áthelyezés nem ritka (időjárás, alkatrész, megbízói ablak). Ha ezek 30%-a nincs indokolva a jegyben, a hónap végi SLA-riport és a számlázási vita „lyukas” lesz. A napló nem büntetés: a diszpécser 20 másodperc alatt indokol, és később 20 perc vita marad el.
- →Törlés = naplózott esemény a jegy idővonalán, nem naptár-mellékhatás
- →Kötelező: aktor, időbélyeg, eredeti ablak/felelős, indok, következő jegy-státusz
- →Téves törlés → restore esemény; a lánc ne „felejtsen”
- →Heti 8–25 törlés/áthelyezés: indok nélkül az SLA-riport nem megbízható
- →Megbízói kérdés: „miért nem jöttetek?” → egy szűrés a jegy történetén
Kivitelező és multi-tenant: telephely-szűrés a naplóban
A service és FM világban ritkán egyetlen cég dolgozik a telephelyen. Megbízó, fővállalkozó, alvállalkozó, külső szerviz — több szervezet, közös jegyek vagy megosztott munkaterület. A tevékenységnapló itt két követelményt szolgál egyszerre: auditálhatóság a megrendelő felé, és adatsziget a partnerek között.
A multi-tenant telephely-szűrés lényege: a megrendelő a saját telephelyén látja a releváns eseményeket (ki módosította a jegyet, ki törölte a feladatot, melyik partner zárta a munkalapot). A meghívott kivitelező / szerviz csak a saját (és a ráruházott) hatókörében lát naplót — nem a megrendelő más projektjeit, nem idegen brigádok belső note-jait, nem más telephelyek jegy-történetét. Így a napló nem válik adatszivárgássá, de a közös munka auditálható marad.
Gyakorlati szűrők a diszpécser és az ops vezető számára: telephely, megbízó, jegy, felhasználó / partner szervezet, eseménytípus (státusz, törlés, prioritás, merge), időszak. Export (PDF/CSV) csak a jogosult hatókörben — auditra 1 kattintás, de soha ne „az egész tenant teljes history” egy alvállalkozónak. A megrendelő–kivitelező közös terv és jogosultságok cikkünk a szerepköröket bontja ki; itt a napló a megfelelőségi vágány.
- →Megrendelő: telephely-szintű teljes audit trail a meghívott felek eseményeivel
- →Kivitelező / külső szerviz: csak saját hatókör + rákiosztott jegyek/feladatok
- →Szűrők: telephely, partner, jegy, aktor, eseménytípus, dátumtartomány
- →Export jogosultsághoz kötve — ne legyen tenant-szintű adatlehúzás partnernek
- →Belső note vs. ügyfél-látható megjegyzés: a napló is tartsa a láthatósági határt
Audit, vita, KPI: hogyan használd a naplót a mindennapokban
Három tipikus forgatókönyv. 1) Megbízói vita: „miért 3 napig nem jött senki?” — jegy idővonal: triage idő, feladat létrehozás, törlés indokkal, új ablak, munkalap lezárás. 2) Belső / hatósági audit: mintavétel 10 véletlen jegyen — minden státuszváltás és felelős látszik, nincs „valaki Excelben átírta”. 3) Ops minőség: heti 15 perc — hány prioritás-váltás indok nélkül, hány feladat-törlés ismétlődik ugyanazon a telephelyen, hol nő a merge-arány (dupla e-mailek).
Mutatók, amik a naplóból jönnek (nem kell 20 dashboard): átlagos idő e-mailtől triage-ig; „törölt feladat / nyitott jegy” arány; prioritás-váltások száma P3→P1 hetente; lezárt jegy aláírt munkalap nélkül; napló-export válaszidő audit kérésre (cél: <5 perc). Ha a törlés-arány egy telephelyen 2× a többinél, az nem „rossz diszpécser” — gyakran rossz SLA-ablak vagy megbízói kommunikációs hiba.
Anti-pattern: a napló csak IT-nak van, a diszpécser nem látja a jegy idővonalát. Ha a történet nem a jegy mellett él, senki nem fogja megnyitni vita közben. A tevékenységnapló UI-ja a ticket detail része legyen — nem külön „admin only” menü, amit csak a rendszergazda ismer.
- →Vita: jegy idővonal megosztása a megbízóval (szűrt, ügyfél-biztonságos nézet)
- →Audit: 10 jegy mintavétel + export 12 hónapra telephelyenként
- →Heti ops: törlés-arány, indok nélküli prioritás-váltás, merge-arány
- →Cél: audit export <5 perc; „ki csinálta?” <60 másodperc
- →UI: idővonal a jegy mellett — ne elrejtett admin modul
Bevezetési checklist: 10 lépés a csendes káoszból a naplózott működésig
Nem kell big bang. 2–4 hét alatt bevezethető a minimum: kötelező naplózás a jegy és a feladat kritikus eseményeire, telephely-szűrés a partnereknél, diszpécser rutin a jegy idővonalán. Az alábbi checklist a bevezetés sorrendjét adja — ha 3-nál több pont „nincs”, a megbízói viták és az audit továbbra is fejből mennek.
- →1. Definiáld a naplózandó eseményeket (státusz, mező, feladat törlés/létrehozás, merge, számlázandó)
- →2. Kötelező indok a feladat-törléshez és a P1/P2 prioritás-emeléshez
- →3. Régi → új érték minden mezőváltozásnál (ne csak „módosítva”)
- →4. Aktor mindig személy vagy egyértelmű rendszer-azonosító (e-mail sync, AI + megerősítő)
- →5. Idővonal a jegy detail oldalon — diszpécser és ops is látja
- →6. Multi-tenant telephely-szűrés: partner csak saját hatókört exportálhat
- →7. Soft-delete + restore esemény (ne hard delete nyom nélkül)
- →8. 2 hetes pilot 1 megbízónál / 1 telephelyen: 100% jegy a naplózott folyamatban
- →9. Heti 15 perc ops review a törlés- és prioritás-mutatókra
- →10. Első audit-export próba: 10 jegy + 30 nap history <5 perc alatt
Ö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.
Gyakori kérdések
Mi a tevékenységnapló service cégnél?+
A jegyhez és a feladatokhoz kötött, időbélyeges eseménylista: ki mit módosított, ki törölte a feladatot, ki változtatta a prioritást vagy a státuszt. Nem általános szervernapló, hanem a szervizfolyamat audit trail-je — vitához, SLA-hoz és hatósági / megbízói ellenőrzéshez.
Miért kell naplózni a feladat törlését a jegyben?+
Mert a törlés gyakran nem zárja le a jegyet: a naptárból eltűnik a kiszállás, a megbízó pedig továbbra is folyamatban lévő ügyet vár. A jegy idővonalán látszania kell, ki, mikor és milyen indokkal törölte a feladatot, és mi a következő státusz — különben a „miért nem jöttetek?” kérdés fejből dől el.
Mit láthat a kivitelező / alvállalkozó a tevékenységnaplóból?+
Csak a saját hatókörét: a rákiosztott jegyeket, feladatokat és a saját (vagy ráruházott) műveleteit az adott telephelyen. A megrendelő más projektjeinek, más partnereinek és a belső, nem megosztott note-jainak naplója nem jelenik meg. A telephely-szűrés multi-tenant szabály, nem „udvariasság”.
Elég a jegy státuszváltozás-előzménye naplónak?+
Nem. A státusz csak a végállapotot mutatja. A prioritás-átírás, telephelycsere, felelős-csere, merge, feladat-törlés és a számlázandó flag kapcsolása ugyanolyan döntések — ezek nélkül a vita és az audit lyukas. A státusz-előzmény a minimum, nem a teljes activity log.
Hogyan segít a napló a megbízói vitában?+
Egy szűrt jegy-idővonal másodpercek alatt megmutatja: mikor jött a bejelentés, mikor volt triage, mikor jött létre / törlődött a feladat, milyen indokkal, mikor készült a munkalap. Nem kell Outlook-szálat és WhatsAppot rekonstruálni. Az ügyfél-biztonságos nézet a belső note-okat kihagyhatja.
Milyen mutatókat érdemes a naplóból nézni hetente?+
Törölt feladat / nyitott jegy arány; indok nélküli vagy gyakori P3→P1 emelések; merge-arány (dupla bejelentések); e-mail→triage idő; lezárt jegy aláírt munkalap nélkül. 4–5 mutató elég — ha a törlés egy telephelyen kiugrik, ott a folyamatot kell javítani, nem csak a diszpécsert figyelmeztetni.
Az AI triage is bekerül a tevékenységnaplóba?+
Igen, javaslatként: mit ajánlott (telephely, prioritás, összefoglaló), és ki erősítette meg vagy utasította el. Az AI nem zár le jegyet és nem töröl feladatot magától. A napló így elválasztja a gépi javaslatot az emberi felelősségtől — ez auditon és belső vizsgálatnál is tiszta.
Mennyi idő bevezetni a kötelező tevékenységnaplót?+
A minimum (kritikus események, törlés-indok, jegy idővonal, telephely-szűrés) 2–4 hét pilotban reális egy megbízónál. A kulturális rész — hogy a diszpécser indokolja a törlést — 1–2 sprint után szokássá válik, ha az UI a jegy mellett van, és a vita tényleg a naplóból dől el.