Outlook helyett service desk: mikor nő ki a postafiókból a szerviz

Amikor még elég az Outlook

Érdemes őszintének lenni: a megosztott postafiók sok szervizcsapatnál nem „rossz szokás”, hanem működő eszköz. Egy diszpécser, 2–4 technikus, egy telephely, napi tucatnyi bejelentés — itt az Outlook gyors, olcsó és ismerős. A megbízó továbbra is e-mailben ír, a csapat mappákkal és színekkel tartja a rendet, és a „olvasatlan = nyitott” heurisztika nagyjából működik.

Tipikus, ha még elég a postafiók: kevés párhuzamos ügy, egy ember „birtokolja” a triage-t, a számlázás Excelben vagy ERP-ben külön megy, és nincs szigorú SLA-riport elvárás. Ilyenkor a service desk bevezetése nem kötelező — felesleges bonyolítás lenne.

A töréspont nem egy konkrét szoftver, hanem a skála. Amikor a csapat 5–8 fő fölé nő, több telephely jön be, vagy a megbízó havi SLA-t és munkalap-előzményt kér, a postafiók adminisztrációs teherré válik. Az e-mail maradhat belépési csatorna — a munkafolyamat viszont kinő belőle.

• →Működik: 1–8 fős csapat, 1 telephely, napi ~10–30 bejelentés, egy triage-felelős
• →Működik: mappák + szabályok + „olvasatlan = nyitott” heurisztika
• →Töréspont: 5–8+ ember, több telephely, SLA-riport, számlázás–munkalap összekötés
• →Cél nem az e-mail kiiktatása: a levél jegy lesz, a folyamat strukturált

5 jel, hogy kinőttétek a postafiókot

Ha az alábbi jelek közül kettő-három rendszeresen visszatér, a shared inbox már nem skálázódik — a „nálunk még megy Outlookban” érzés gyakran csak azt jelenti, hogy a káosz még tolerálható, nem azt, hogy kontrollált.

• →1. Státusz = mappa / olvasatlan: senki nem tudja 30 másodperc alatt, hány nyitott, késő és „vár ügyfélre” ügy van. A mappaáthelyezés nem auditálható státuszváltás — nincs időbélyeg, felelős és SLA-óra.
• →2. Dupla munka és elveszett szál: ugyanaz a hiba 2–3 levélben, CC-kkel, továbbítva WhatsAppon is. Két technikus kimegy, vagy senki — a szál „valakinél van a fejében”.
• →3. Telephely és eszköz rejtve: a tárgyban „sürgős lift”, a törzsben egy cím — de nincs kötelező telephely / eszköz mező. A hibatörténet nem kapcsolódik a géphez, a következő hívásnál újra nulláról indulsz.
• →4. SLA és prioritás fejben: a 4 órás callout és a „majd holnap” kérés ugyanabban a postafiókban ül. Nincs automatikus prioritás, eszkaláció, sem megbízói riport a válaszidőről.
• →5. Számlázás és munkalap elválik: a lezárt levél nem egyenlő számlázandó munkával. A diszpécser Excelbe másol, a pénzügy késik, a megbízó vitatja a tételt — mert nincs jegy → munkalap → számlázandó lánc.

Mappák → státuszok: mit mire cserélsz

A leggyakoribb hiba a bevezetéskor: a service desk mappáit 1:1 lemásoljátok a postafiókból. A mappa hierarchia az Outlook logikája; a jegy státusz a folyamat logikája. Először a munkafolyamatot rajzold le, aztán a mappákat státuszokra és mezőkre bontsd.

Gyakorlati mapping, amit szervizcsapatoknál bevált (finomítható a saját SLA-itokhoz):

• →Beérkezett / olvasatlan → Új jegy (triage vár, prioritás és telephely még nyitott)
• →Folyamatban / XY mappa → Hozzárendelve + felelős technikus (nem mappa, hanem személy)
• →Várunk alkatrészre / ügyfélre → Várakozás okkal (SLA-óra szünetelhet, de látható)
• →Kész / Archivált → Lezárva + opcionálisan Számlázandó (külön státusz vagy flag)
• →Sürgős piros kategória → Prioritás mező (P1–P4) + SLA szabály, nem színkód
• →Telephely mappák (Bp / Debrecen…) → Telephely mező + szűrő, nem párhuzamos fiókok
• →Tárgyban „#szerződés” jelölés → Megbízó / szerződés mező a jegyen, nem manuális címke

90 napos átállás: heti terv a postafiókból a service deskig

Ne „holnaptól csak jegy, e-mail tiltva” big banget csinálj. A megbízók továbbra is e-mailben írnak — a cél, hogy a levél jegy legyen, ne hogy az ügyfél új portált tanuljon. 90 nap alatt reális: e-mail szinkron, státuszok, diszpécser rutin, technikus munkalap, első SLA-riport.

1–4. hét — alap és mapping: döntsd el a státuszokat (max. 6–8), prioritásokat, telephelylistát. Kapcsold be az e-mail szinkront (pl. M365 megosztott fiók → jegy). Importáld a megbízókat és telephelyeket. Diszpécser napi 15 perc: minden bejövő levél jegy, mappaáthelyezés tilos a pilotban.

5–8. hét — pilot egy megbízónál / egy telephelyen: minden callout és hibabejelentés a pilot körben service deskben fut. AI triage (összefoglaló, telephely, prioritás javaslat) ember-megerősítéssel gyorsít — de a döntés a diszpécseré. Technikus: jegy → feladat → munkalap. Heti review: mi hiányzik a sablonból, mi felesleges mező.

9–12. hét — rollout és papír/mappa fázisout: 2–3. megbízó vagy telephely. Outlook mappák „csak archív”: új ügy nem kerül mappába. Első havi SLA-riport a megbízónak (válaszidő, lezárási idő, nyitott backlog). Számlázandó státusz a pénzügynek. 90. nap: go/no-go — ha a diszpécser még mappáz, ne bővíts, javítsd a sablont.

• →Hét 1–2: státusz + prioritás + telephely lista, e-mail szinkron teszt
• →Hét 3–4: diszpécser betanítás, 100% jegy a bejövőből (pilot fiók)
• →Hét 5–6: technikus jegy→munkalap, mobil / terep rutin
• →Hét 7–8: pilot review, SLA szabály finomhangolás, merge / dupla jegyek
• →Hét 9–10: 2. kör rollout, mappa fázisout új ügyekre
• →Hét 11–12: első megbízói riport, számlázandó lánc, projektzárás

Mit tarts meg az e-mailből — és mit ne

A service desk nem „helyettesíti” a megbízó e-mailjét. A megbízó továbbra is a megszokott címre ír; a rendszer a levelet jegyre emeli, a szál és a válasz a jegyből mehet vissza. Így nem veszíted el a kommunikációs csatornát, de nem a postafiók a munkavégzés helye.

Tartsd meg: a megbízó e-mail címét mint belépési pontot; a levél szálat a jegyhez csatolva (kontextus, mellékletek, fotók); a válaszírást a jegyből, hogy a történet egy helyen maradjon; a szabályokat (pl. bizonyos címekről automatikus prioritás javaslat).

Ne tartsd meg: a státuszkezelést mappákkal; a „kié a levél” döntést olvasatlan flaggel; a telephely- és eszközazonosítást csak a tárgysorból; a számlázási listát Excel-exportból, ha a jegy már tudja a „számlázandó” állapotot. A postafiók archívum legyen, ne operatív dashboard.

• →Megtart: ügyfél e-mail csatorna + szál a jegyhez kötve
• →Megtart: válasz a jegyből (egy történet, nem szétszórt CC)
• →Elenged: mappa = státusz, szín = prioritás, olvasatlan = nyitott
• →Elenged: párhuzamos WhatsApp / Excel listák a hivatalos triage mellett

Checklist és anti-patternek

Használd indulás előtt és a 90. napon. Ha a checklist nagy része „nem”, még ne expandáld a service desket minden megbízóra — előbb a pilotot stabilizáld.

• →Checklist: max. 6–8 státusz leírva, SLA-hoz kötve?
• →Checklist: telephely és megbízó kötelező mező a jegyeken?
• →Checklist: e-mail → jegy szinkron él, teszt levél 1 percen belül jegy?
• →Checklist: diszpécser napi triage <30 perc a pilot körben?
• →Checklist: technikus jegyből indít munkalapot (nem külön Excel)?
• →Checklist: lezárt jegy → számlázandó út dokumentálva?
• →Checklist: első havi nyitott / késő / átlagos válaszidő riport kész?
• →Anti-pattern: 20+ státusz „ahogy az Outlook mappák voltak”
• →Anti-pattern: e-mail tiltása 1. naptól az ügyfél felé
• →Anti-pattern: big bang minden telephelyre egyszerre
• →Anti-pattern: AI triage emberi megerősítés nélkül (hamis prioritás = elveszett bizalom)
• →Anti-pattern: párhuzamos mappa + jegy 3 hónapig „csak biztonságból” minden ügyön

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