Miért nem jó a Zendesk/Jira szerviz kiszállásra

Amire a Zendesk és a Jira kiváló — és amire nem

Érdemes elölről tisztázni: a Zendesk a klasszikus ügyfélszolgálati és IT-support stack egyik etalonja — bejövő csatornák, SLA-óra, ügynök-queue, tudásbázis, ügyfélportál. A Jira (és a Jira Service Management) a szoftverfejlesztés és az ITSM világában erős: backlog, sprint, változáskezelés, incidens–probléma–változás lánc. Ezeken a pályákon indokolt a választásuk.

A szerviz kiszállás más játék. A „jegy” nem egy távoli képernyő előtt ülő ügynök feladata, hanem egy cím, egy gép, egy időablak, egy aláírás és gyakran egy számlázandó tétel. A helpdesk a beszélgetést és a válaszidőt optimalizálja; a field service a helyszíni munkát, a bizonyítékot és a bevételt. Ha a kettőt összekevered, a szoftver „működik” — de a folyamat körülötte Excelben, WhatsAppon és papíron él tovább.

Tipikus indíték, amiért mégis Zendesk/Jira mellett dől a szerviz: „már van licence”, „az IT ismeri”, „a menedzsment is ezt használja”. Ezek valós költség- és politikai érvek — de nem helyettesítik a hiányzó domainmodellt. A kérdés nem az, hogy „rossz-e a Zendesk”, hanem: lefed-e 4 kötelező mezőt és láncot a kiszállásos munkához.

• →Erős IT/support: csatornák, SLA, queue, tudásbázis, ITSM incidens
• →Erős fejlesztés: backlog, sprint, change — nem helyszíni munkarendelés
• →Gyenge field service: telephely, eszköz, aláírt munkalap, számlázandó státusz
• →Döntés: licence megléte ≠ domain-illeszkedés a szervizre

Négy hiányzó pillér: telephely, eszköz, aláírt munkalap, számlázás

A field service minimumja négy dolog, amit az IT-helpdesk natívan nem modellez. 1) Telephely / helyszín: nem „ügyfél”, hanem cím, épület, zóna, bejutási kód, nyitvatartás. Egy megbízónak 5–50 telephelye lehet; a hiba mindig egy konkrét helyen van. Custom mezővel „rá lehet írni” a címet — de nincs hierarchia, térkép, multi-site szűrés, sem „ugyanott mi van még nyitva”.

2) Eszköz / berendezés: a jegy nem „valami elromlott”, hanem a 3. emeleti kazán, a 12-es lift, a raktári raklapmozgató. Kell eszközazonosító, előzmény, garancia, alkatrész-kapcsolat. Helpdeskben az „asset” gyakran laptop-leltár; a CMMS/service eszközmodell a gép életciklusa és a hibatörténet. Custom dropdown 200 géphez 6 hónap múlva kaotikus.

3) Aláírt munkalap: a kiszállás vége nem a jegy „Solved” státusza, hanem a helyszíni igazolás — elvégzett munka, anyag, idő, fotó, ügyfélaláírás, PDF. IT-ticketnél a lezárás = válasz / fix a távoli gépen. Szerviznél a lezárás = bizonyíték. Ha ez külön Word/PDF-ben él, a jegy és a számla elválik.

4) Számlázható lánc: jegy → feladat/kiszállás → munkalap → számlázandó. A helpdesk a support költséget méri (FCR, AHT); a service cég a bevételt. „Lezárt jegy” ≠ „számlázható tétel”. Pénzügy 2–4 hetet csúszik, ha a listát a postafiókból és a papír munkalapokból rakják össze.

• →Telephely: hierarchia, cím, hozzáférés — nem csak „requester”
• →Eszköz: gép-előzmény, QR/azonosító — nem IT-laptop leltár
• →Aláírt munkalap: PDF + aláírás + fotó a helyszínen
• →Számlázandó: státusz a lánc végén, ne Excel-export a hónap végén
• →Custom mező mind a 4-re = shadow process 6–12 hónapon belül

Helpdesk ticket vs. szerviz kiszállás: más állapotgép

Az IT-helpdesk tipikus útja: New → Open → Pending → Solved → Closed. A „Pending” = várunk ügyfélre vagy 3rd party-ra; a „Solved” = a probléma megoldódott a felhasználó gépén. A szerviz útja: Új bejelentés → Triage (telephely, eszköz, prioritás) → Feladathoz kötve / naptár → Helyszínen → Munkalap kész (aláírás) → Számlázandó → Lezárva. A „Solved” túl korai, ha még nincs aláírás; a „Closed” félrevezető, ha a számla nem indítható.

Szerepek is mások. Helpdesk: requester + agent (+ opcionális L2). Szerviz: megbízó / bejelentő, diszpécser, technikus (esetleg alvállalkozó), pénzügy. A technikusnak nem kell látnia a teljes ticket-zajt — csak a rárendelt kiszállásokat. A diszpécsernek kell a naptárkapacitás, a merge (dupla e-mail ugyanarra a hibára), és a „mi van még nyitva ugyanazon a telephelyen”.

Számok, amikkel 8–25 fős szervizcsapatoknál gyakran találkozunk, ha helpdesk-eszközön futtatják a fieldet: 20–40% jegy „megoldva” aláírt munkalap nélkül; 15–30% kiszállás, ahol a cím és az eszköz csak a megjegyzésmezőben van; heti 3–8 óra diszpécseridő custom mezők és Excel-párhuzam karbantartására. Ezek nem a Zendesk/Jira „hibái” — hanem a domainilleszkedés hiánya.

• →Helpdesk: válaszidő, FCR, queue — távoli / iroda-közeli munka
• →Szerviz: időablak, cím, gép, aláírás, számla — helyszíni munka
• →Státuszgát kell: ne „Solved” aláírás nélkül szerződéses kiszállásnál
• →Diszpécser ≠ agent: beosztás és telephely-kontextus, nem csak válasz

A rejtett költség: custom mezők, pluginek és shadow Excel

A leggyakoribb ellenérv: „beállítjuk custom mezőkkel”. Igen — rövid távon. Telephely szövegmező, eszköz szövegmező, „munkalap csatolva” checkbox, „számlázandó” tag. 3 hónap múlva: nincs kötelező kitöltés, a technikus üresen hagyja, a diszpécser utólag tölti, a riport hazudik. 6–12 hónap múlva: párhuzamos Excel a „valódi” listához, mert a jegyboard nem ad megbízható számlázandó nézetet.

Marketplace appok és Zaps/integrációk részben kitöltik a lyukakat — aláírás-app, forms, naptár-szinkron, ERP-csatlakozó. Minden integráció licence, hibapont és betanulási költség. A TCO gyakran 1,5–3× a „már van Zendeskünk” érzéshez képest, ha összeszámolod az appokat, a admin időt és a kettős adatrögzítést. A Jira-n hasonló minta: custom issue type „Field Work”, 15 custom field, Automation rule-ok — a technikus a terepen mégis papírt vagy második appot használ.

Ez nem azt jelenti, hogy soha ne integrálj. Azt jelenti: ha a magmodell (site, asset, work order, billable) nincs a termék magjában, az integrációs réteg lesz a valós rendszer — és azt te tartod karban. Döntés előtt számold: hány kötelező mező, hány app, hány manuális lépés a jegy beérkezésétől a számláig. Ha 5+ manuális ugrás van, a „helpdesk + custom” stratégia drágább, mint egy domainre épült service/CMMS stack.

• →Custom mező ≠ adatmodell (nincs hierarchia, előzmény, kötelező kapu)
• →App-marketplace: +licence, +hibapont, +betanítás technikusoknak
• →Shadow Excel: a „igazság” elköltözik a jegyek mellé 6–12 hónap alatt
• →TCO ellenőrzés: appok + admin órák + kettős rögzítés, ne csak seat-ár

Mikor maradhat a helpdesk — és mikor kell service/CMMS logika

Fair döntési keret: nem minden „szerviznek hangzó” munka igényel field stacket. Ha a csapat főleg távoli IT-támogatást, szoftver-incidenst vagy irodai first-line supportot csinál, a Zendesk/Jira a helyén van. Ha a munka 70%+ helyszíni kiszállás, multi-site, eszközhöz kötött, aláírásköteles és számlázandó — a helpdesk a rossz alap.

Maradhat helpdesk (vagy helpdesk a belépő csatorna), ha: 1 telephely / kevés helyszín; nincs eszköz-előzmény elvárás; a „munka” jórészt távoli vagy iroda; nincs ügyfélaláírás a szerződésben; a számlázás fix havi díj, nem munkalap-alapú. Ilyenkor a ticket elegendő system of record.

Kell service/CMMS jellegű lánc, ha: több telephely vagy multi-megbízó; gép/berendezés a hiba alanya; technikus naptárbeosztással megy ki; digitális vagy papír munkalap + aláírás kötelező; a bevétel a lezárt munkalapokból jön; audit/hatóság/megbízó visszakeresi a helyszíni bizonyítékot. Ilyenkor a helpdesk maximum e-mail/ticket belépő lehet — a munka a munkarendelésen fut.

• →Helpdesk OK: távoli IT, 1 helyszín, fix díj, nincs aláírt work order
• →Service/CMMS kell: multi-site, eszköz, kiszállás, aláírás, számlázandó tétel
• →Hibrid: e-mail/ticket belépő + lánc a munkalapig — ne fordítva
• →Döntés 1 kérdés: a „kész” = válasz, vagy = aláírt helyszíni bizonyíték?

Döntési checklist a tool-váltás előtt

Mielőtt „maradunk Zendeskben custom mezőkkel” vagy „mindenáron új rendszer” döntesz, futtasd le a listát a diszpécserrel és egy technikussal. Ha a checklist jobb felén 4+ „nem” van, a helpdesk-alapú field folyamat valószínűleg már most shadow processben él — csak nem nevezitek annak.

• →Van kötelező telephely mező hierarchiával / listával — nem szabad szöveg?
• →Az eszköz/gép a jegyhez kötve van, előzménnyel visszakereshető?
• →A technikus a telefonon lezár munkalapot fotóval és aláírással?
• →A „Solved/Closed” blokkolható hiányzó aláírásnál (szerződéses típus)?
• →Van számlázandó lista státuszból — nem hó végi Excel-gyűjtés?
• →A naptár/beosztás a jegyhez kötött, nem külön WhatsApp-csoport?
• →Dupla e-mail ugyanarra a hibára merge-elhető egy fő jegybe?
• →A technikus csak a saját kiszállásait látja, nem a teljes support-zajt?
• →Anti-pattern: 15+ custom field „majd a riport megoldja”
• →Anti-pattern: aláírás-app + jegy + Excel + ERP = 4 igazság
• →Anti-pattern: „az IT már Zendesk/Jira, a szerviz is oda megy” domain 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.