Ticket → feladat → munkalap: a service cég teljes lánca

Miért szakad el a lánc: e-mail, Excel és papír között

A tipikus service vagy FM cégnél a hibabejelentés e-mailben jön. A diszpécser átírja Excelbe vagy WhatsAppba, a szervizes papíron vagy fejben viszi a kiszállást, a munkalap utólag készül — ha készül. A számla 2–4 héttel később megy ki, mert valaki még keresi az aláírást és az anyagleírást. A lánc 4–5 helyen szakad el: postafiók, táblázat, chat, papír, számlázó szoftver.

A pain nem „nincs szoftverünk”, hanem hogy nincs egyetlen, végigkövethető objektum a bejelentéstől a számláig. A ticket lezárul a postafiókban („válaszoltunk”), de a feladat nincs kiosztva. A feladat „kész” a naptárban, de nincs aláírt munkalap. A munkalap megvan, de nincs számlázandó státusz — a pénzügyi csapat nem tudja, mit lehet számlázni a hónap végén.

Service környezetben a megbízó nem akar új portált. Marad az e-mail. A megoldás nem a csatorna cseréje, hanem a lánc: a levél ticketté válik, a ticket feladattá a naptárban, a feladat munkalappá aláírással és PDF-fel, a munkalap számlázandó jelöléssel. Egy system of record — nem hat párhuzamos igazság.

Számok, amikkel a legtöbb 8–25 fős szervizcsapat találkozik: heti 40–120 bejövő hibajegy-e-mail; 15–30% másodlagos levél ugyanarról a hibáról; 10–20% lezárt jegy, ahol 48 órán belül még nincs aláírt munkalap. Ez utóbbi a rejtett bevételkiesés: a munka megtörtént, a számla nem indítható.

Állapotgép: ticket státuszok, amik a láncot védik

A ticket nem IT-helpdesk jegy. Service-ben a státusz azt jelzi: hol tart a bejelentés a kiszállás és a számla felé. Ha a státuszok lazák („kész” = „válaszoltunk e-mailben”), a lánc hamisan zárul. Az állapotgép feladata: ne engedd, hogy számlázásra lezárt vagy hibás állapotból új feladat induljon rossz irányba — és ne engedd a ticket lezárását aláírt munkalap nélkül, ha a szerződés ezt követeli.

Gyakorlati státuszsor (példa, a cég szabályaihoz igazítva): Új / beérkezett → AI feldolgozás alatt (javaslat kész) → Triage kész (telephely, eszköz, prioritás megerősítve) → Feladathoz kötve → Folyamatban (szervizes a helyszínen) → Munkalap kész (PDF + aláírás) → Számlázandó → Lezárva / archiválva. Opcionális mellékágak: Várakozik (alkatrész, megbízói ablak), Összefűzve (merge másik jegybe), Elutasítva (nem a mi hatáskörünk).

A státuszgátak (gates) a legfontosabbak. Ne konvertálj feladattá olyan ticketet, ami már számlázásra lezárt vagy merge-elve más jegybe került — különben dupla kiszállás és dupla számla-kísérlet lesz. Ne engedd a „Lezárva” státuszt, ha a szerződéses típusnál kötelező a digitális aláírás, és az még hiányzik. Ne engedd a „Számlázandó” jelölést üres anyagsorral és 0 órával, ha a számlázási sablon ezt tiltja.

Az AI a triage-ban segít: összefoglaló, javasolt megbízó, telephely, eszköz, prioritás — indoklással. Ember erősít meg. Az AI nem zár le ticketet, nem indít magától szervizest, és nem állít számlázandó státuszt. A szakmai kontroll a diszpécseré; a gép a másodperceket spórolja a levél kibogozásán.

• →Új: e-mail bejött, még nincs megerősített telephely/prioritás
• →Triage kész: AI javaslat elfogadva vagy kézzel javítva
• →Feladathoz kötve: van felelős és időablak a naptárban
• →Munkalap kész: PDF + aláírás + minimum mezők kitöltve
• →Számlázandó: pénzügyi/ops láthatja, mit lehet számlázni
• →Lezárva: csak ha a cég szabályai szerinti bizonyíték megvan

Feladattá alakítás és beosztás a naptárban

A ticket a bejelentés és a kommunikáció helye. A feladat a munkaszervezés egysége: ki megy, mikor, hová, milyen SLA mellett. A diszpécser a megerősített ticketből egy kattintással feladatot hoz létre — felelős(ök), határidő, opcionális ügyfél-értesítő a ticket e-mail szálába. Nem kell újra begépelni a telephelyet és a hibaleírást.

A naptár / beosztás nem „szép UI”, hanem kapacitás. Ha a feladat nincs a naptárban, a szervizes reggel WhatsApp-ot néz, a diszpécser telefonál, a második kiszállás ugyanarra a címre „elfelejtődik”. A jó láncban a feladat látszik a heti beosztáson, a kapcsolódó ticket státusza „Feladathoz kötve”, a szervizes a mobilján látja a címet, a prioritást és a korábbi megjegyzéseket.

Egy feladathoz több munkalap is tartozhat. Tipikus esetek: első kiszállás diagnózis, második kiszállás alkatrésszel; reggeli és délutáni műszak ugyanarra a hibára; két szakág (gyengeáram + gépészet) ugyanarra a ticketre. A lánc nem „1 ticket = 1 PDF” — hanem 1 ticket → 1+ feladat → 1+ munkalap, amíg a szerződéses munka és a bizonyíték kész nincs.

Meglévő feladat is köthető a tickethez: ha már van ütemezett PM vagy korábbi nyitott task ugyanott, ne nyiss felesleges párhuzamos sort. Kapcsolódó jegyek a telephelyen: a diszpécser látja, mi van még nyitva ugyanott — egy kiszállással több ügy zárható, ha a szerződés engedi.

• →Ticket megerősítve (telephely, prioritás, megbízó) → feladat létrehozás
• →Felelős + időablak a naptárban, ne csak „majd valaki”
• →Ügyfél-értesítő a szálban: „kimegyünk holnap 9–12 között”
• →Több munkalap / feladat megengedett ugyanarra a ticketre
• →Merge: ugyanarról a hibáról jövő levelek egy fő jegybe
• →Státuszgát: lezárt / számlázott jegyből ne indíts új felesleges feladatot

A munkalap mint számlázási és audit bizonyíték

A service cégnél a munkalap nem belső adminisztráció — hanem a számla és az ügyfél-igazolás alapja. Digitális munkalap: elvégzett munka leírása, felhasznált anyag, idő, fotó, ügyfél (vagy megbízotti) aláírás, PDF export. Időbélyeg és felelős minden lépésen. Ha ez megvan, a „kész” nem szóbeli állítás, hanem visszakereshető bizonyíték.

A klasszikus expert pain: a ticket „lezárva”, a szervizes elment, a számla nem megy ki, mert hiányzik az aláírt munkalap. Vagy a munkalap megvan papíron az autóban, de a pénzügyi csapat 10 nap múlva kapja meg. Késői számlázás = romló cash flow; hiányzó aláírás = vitás tétel a megbízónál; hiányzó fotó = gyenge pozíció garanciális vitában.

Számlázandó státusz: a lánc utolsó üzleti kapuja a lezárás előtt. A diszpécser vagy a ops vezető látja a listát: mi készült el aláírással, mi számlázható szerződés szerint, mi vár árajánlatra, mi belső (nem számlázandó) munka. A ticket nem „eltűnik a kész mappában” — a pénz is követhető a bejelentéshez kötve.

Audit és ügyfél-kérdés: „ki volt ott, mit csinált, mikor írta alá?” A válasz másodpercek, nem irattár-keresés. A munkalap a tickethez és a feladathoz kötve él — ugyanabban a rendszerben, ahol a napló és az eszközök is. A automatikus munkalapok és a munkalap-kezelés bevált gyakorlatai cikkünk a sablon- és lezárási részleteket bontja ki; itt a lánc a lényeg: a munkalap a ticket végállomása a számla felé.

Diszpécser vs szervizes: ki miért felel

A lánc akkor stabil, ha a szerepek nem keverednek. A diszpécser a beérkező csatorna és a triage gazdája: e-mail → ticket, AI megerősítés, merge, felelős kiosztás, ügyfél-válasz a szálból, státusz a számlázásig. A szervizes a feladat és a helyszíni munkalap gazdája: elfogadás, munka, fotó, aláírás, lezárás a telefonon. A ticketlista zaját a szervizesnek nem kell látnia — csak a rárendelt feladatokat.

Ha a szervizes „maga zárja a ticketet e-mailben”, a diszpécser elveszíti a képet. Ha a diszpécser „készre állítja” a jegyeket aláírás nélkül, a pénzügyi csapat késik. A szabály egyszerű: a ticket kommunikációs és triage-objektum; a feladat a beosztás; a munkalap a bizonyíték és a számlázás bemenete. Mindhárom összekötve, de más felelőssel.

Ops vezető KPI-k a láncra (heti 15 perc): átlagos idő e-mailtől triage-ig; átlagos idő feladattól első munkalap-lezárásig; „lezárt ticket aláírt munkalap nélkül” darabszám (cél: közel 0 a szerződéses kiszállásoknál); számlázandó backlog napokban; merge-arány (mennyi dupla levél lett egy jegy). Ezek nem gyári OEE-számok — service cash flow és ügyfélélmény mutatók.

• →Diszpécser: postafiók, AI triage, merge, kiosztás, ügyfél-szál, számlázandó lista
• →Szervizes: feladat, helyszín, munkavégzés, fotó, aláírás, munkalap lezárás
• →Pénzügy/ops: számlázandó státuszok feldolgozása, nem postafiók-vadászat
• →Megbízó: megszokott e-mail, státusz a válaszokban — nem kényszerportál

Anti-patternek checklist: mit ne csinálj a láncban

A legtöbb service cég nem „rossz folyamatot” tervez — hanem kényelmi rövidítésekkel bontja le a láncot. Az alábbi checklist a tipikus töréspontokat szedi össze. Ha 3-nál több igaz rátok, a számlázás és az audit valószínűleg már most szenved — csak nem méritek rá külön mutatót.

• →Ticket „kész”, de nincs aláírt munkalap — a számla 1–3 hetet csúszik
• →Feladat WhatsAppban / szóban, nincs naptárbejegyzés — a második műszak nem látja
• →Excel a ticketlista mellett — két igazság, senki nem tudja, melyik él
• →Számlázásra lezárt jegyből új feladat indul — dupla munka, zavaros számla
• →AI megerősítés nélkül automatikusan kiosztott kiszállás — rossz cím, rossz prioritás
• →Egy papír munkalap több ticketre — utólag nem derül ki, melyik bejelentéshez tartozik
• →Szervizes látja az összes bejövő e-mail-zajt — a terepi fókusz elvész
• →Aláírás „majd holnap az irodában” — a bizonyíték elvész az autóban
• →Nincs merge: 4 levél = 4 párhuzamos jegy ugyanarra a hibára
• →Számlázandó lista hó végén kézzel a postafiókból — nem státuszbó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.