Offline szerviz app: pinceszint, gyár, liftakna — hálózat nélkül

Hol szakad el a hálózat: pinceszint, gyár, liftakna

A szervizes nem a fogadóirodában tölti a napot. Pincében, mélygarázsban, gépészeti aknában, acélcsarnokban, liftaknában, alállomáson, hűtőházban — a mobilnet és a Wi-Fi ott a leggyakrabban eltűnik. Ha az app „csak online” munkalapot enged, a gyakorlat visszatér a papírra, a WhatsApp-fotóra és az utólagos gépelésre. A hálózat hiánya nem kivétel: a tipikus kiszállás 30–70%-a gyenge vagy nulla térerőn történik.

A service cégnél ez nem elméleti IT-kérdés. A megbízó a helyszínen várja az aláírást. A diszpécser nem tudja, zárult-e a jegy. A második műszak nem látja, mit csinált az előző. Ha a lezárás „majd az autóban, ha lesz jel”, a munkalap 1–3 órával — vagy napokkal — késik, a számlázandó státusz pedig a hó végén még mindig üres.

Számok, amikkel a legtöbb 6–20 fős szervizcsapat találkozik: heti 25–80 helyszíni lezárás; 40–60% olyan helyszín, ahol a beltéri térerő gyenge vagy nincs; 15–25% olyan lezárás, ami offline készült, de később „elveszett” a papír/chat útvesztőben; 10–20 perc extra adminisztráció lezárásonként, ha a terep nem offline-képes. Ez heti 4–25 óra felesleges irodaidő — és audit-lyuk a hiányzó időbélyegeknél.

A mobil naplózás a terepen cikkünk a napló és a fotó offline oldalát bontja ki. Itt a fókusz a service objektumokon van: ticket státusz, work order / munkalap, offline queue és az, hogy az elutasított szerverválasz ne indítson végtelen újrapróbálást.

Ticket és munkalap offline — nem csak naplóbejegyzés

A napló azt rögzíti: „mi történt az eszközön”. A service ticket és a munkalap ennél több: ki kérte, milyen prioritással, ki ment ki, mit vállaltunk, mit írt alá a megbízó, mi számlázható. Offline módban is ezeknek az objektumoknak kell élniük — nem egy szabadszöveges jegyzetnek a telefonon.

Offline-képes szerviz appban a szervizes a kiszállás előtt (vagy térerőnél) letölti a rárendelt feladatokat: ticket összefoglaló, cím, eszköz, SLA, korábbi megjegyzések, checklist sablon. A helyszínen hálózat nélkül: státusz váltás (folyamatban → munkalap kitöltés), fotó, mérési mező, alkatrész, idő, digitális aláírás, PDF előkészítés. A lezárás lokálisan „kész, vár szinkronra” állapotba kerül — nem vész el, és nem vár netet a gombnyomáshoz.

A különbség a „csak offline napló” és az „offline service app” között: a napló belső történet; a ticket–munkalap lánc ügyfél felé és a számlázás felé is él. Ha csak a napló megy offline, a diszpécser ticketlistája továbbra is „folyamatban” marad, a megbízó e-mail szálába nem kerül lezárás, a számlázandó lista üres. Az offline képességnek tehát a munkalap-lezárásra és a ticket státusz frissítésére is ki kell terjednie — a ticket → feladat → munkalap lánc részeként.

Gyakorlati minimum mezők offline is: elvégzett munka, idő, fotó (legalább 1 a szerződéses típusoknál), aláírás ha kötelező, ticket/feladat azonosító. Ami netet igényel (élő alkatrészkészlet-lekérdezés, új ticket létrehozás a megbízótól), az maradhat online-only — de a lezárás soha ne függjön a térerőtől.

• →Előre letöltött feladatok: ticket, cím, eszköz, checklist a készüléken
• →Helyszíni lezárás térerő nélkül: fotó, idő, aláírás, státusz
• →Ticket státusz is frissül a szinkron után — nem csak a napló
• →Számlázandó út offline lezárt munkalapból is indulhat
• →Napló + munkalap együtt: belső történet és ügyfélbizonyíték

Offline queue: mi kerül sorba, mi nem

Az offline queue a készüléken várakozó, még fel nem töltött műveletek sora: „zárd le a munkalapot”, „csatold a fotót”, „frissítsd a ticket státuszt”. Amint van hálózat, az app sorrendben elküldi őket a szervernek. A szervizesnek nem kell „szinkron” gombot keresnie — a queue a háttérben dolgozik, a UI pedig mutatja: hány tétel vár, mi sikerült, mi bukott el.

A queue nem ömlesztett feketeláda. Minden tétel: művelet típusa, cél objektum (ticket id, munkalap id), payload, létrehozás ideje, próbálkozások száma, utolsó hiba. A sorrend számít: előbb a munkalap tartalom és a mellékletek, aztán a lezárás és a ticket státusz — különben a szerver „üres lezárást” kap. A fotók nagyok: a queue darabolhat és folytathat, de a lezárás ne legyen „kész” a szerveren, amíg a kötelező melléklet nem ment fel.

Idempotencia: ugyanaz a lezárás ne jöjjön létre kétszer, ha a hálózat félúton szakad. A kliens stabil művelet-azonosítót küld; a szerver ugyanarra az id-re ugyanazt a választ adja, nem második munkalapot. Konfliktus (pl. a diszpécser közben merge-elte a ticketet): a queue tétel nem „eltűnik” — sikertelen / elutasított státuszba kerül, a szervizes és a diszpécser látja, miért nem ment át.

Számok a jó queue-hoz: tipikus tétel 1–30 másodperc alatt felmegy térerőnél; 95%+ sikeres első próbálkozás stabil 4G-n; a „várakozó” badge a telefonon 0-ra esik, mire a szervizes a kocsiba ül a telephely kijáratánál. Ha a queue 2 órán túl is 5+ tételnél ragad, az ops jel: rossz hálózat a környéken, vagy szerverhiba — nem a szervizes „lustasága”.

• →Művelet = típus + objektum id + payload + próbálkozás számláló
• →Sorrend: melléklet → tartalom → lezárás / ticket státusz
• →Idempotens lezárás: hálózati törés ne hozzon dupla munkalapot
• →UI: várakozó / sikeres / elutasított — ne fekete doboz
• →Nagy fotók: folytatható feltöltés, kötelező melléklet a lezárás előtt

Elutasított kérés: ne kerüljön újra a sorba

A legtöbb „rossz offline” app hibája: minden sikertelen HTTP-t újrapróbál — örökké. A 500-as szerverhiba és a timeout újrapróbálható. A 400-as validációs hiba, a 409-es konfliktus, a 403-as jogosultság, a „ticket már lezárva / merge-elve” üzleti elutasítás nem az. Ha ezeket a queue újra és újra elküldi, a szerver zajt kap, az akkumulátor fogy, a szervizes pedig hamis „szinkronizál…” állapotot lát, miközben a tétel soha nem fog átmenni.

Szabály: elutasított (rejected) kérés ne kerüljön automatikusan vissza a retry queue-ba. Állapot: sikertelen / elutasított, indoklással (pl. „a ticketet a diszpécser közben lezárta”, „hiányzó kötelező mező: aláírás”, „nincs jogod ehhez a telephelyhez”). A szervizes dönt: javít és kézzel újraküld, vagy a diszpécser oldja a konfliktust. Az automatikus retry csak a tranzens hibákra marad: hálózat, 502/503, timeout — háttér-backoff-fal (pl. 30 s → 2 perc → 10 perc), nem percenkénti spammeléssel.

Ez védi a láncot is. Ha a szerver elutasítja a lezárást, mert a ticket merge-elve van egy másik jegybe, a második „kész” ne íródjon felül csendben. Ha a validáció elutasítja a számlázandó jelölést üres anyagsorral, a queue ne próbálja 50-szer ugyanazt. Az elutasítás látható esemény — audit és ops szempontból is értékesebb, mint a csendes, végtelen újrapróbálás.

Diszpécser oldalon: a „terepen elutasított szinkron” lista heti 5–15 perc. Tipikus okok: párhuzamos merge, lejárt session a nagyon hosszú offline nap után (token frissítés térerőnél), kötelező mező hiánya a sablonban. A lista nem büntetés a szervizesnek — a folyamat és a sablon hibáit mutatja.

• →Retry: timeout, 502/503, hálózati hiba — backoff-fal
• →No retry: 400 validáció, 403 jog, 409 konfliktus, üzleti elutasítás
• →Elutasított tétel: indok + manuális újraküldés vagy diszpécser
• →Ne spammeld a szervert ugyanazzal a hibás payload-dal
• →Ops lista: elutasított szinkronok heti átnézése

Szinkron után: diszpécser, megbízó, számla

Amint a queue lefut, a ticket státusza a szerveren is frissül: munkalap kész, opcionálisan számlázandó. A diszpécser a listán látja a lezárást — nem kell telefonálnia „kész vagy?”. A megbízó e-mail szálába (ha a folyamat engedi) mehet automatikus vagy félautomata válasz: elvégezve, PDF csatolva. A pénzügyi/ops sor a számlázandó backlogban nő — nem a papírköteg az autóban.

Konfliktuskezelés a szinkron után: ha két szervizes ugyanarra a ticketre dolgozott offline (ritka, de előfordul párhuzamos szakágnál), a rendszer ne írja felül csendben a másikat. Két munkalap ugyanarra a ticketre megengedett a lánc szabályai szerint; a ticket lezárása a diszpécser vagy a szerződéses szabály döntése. Az offline app feladata: mindkét lezárás megérkezzen, ne az, hogy az egyik elveszzen a „last write wins” miatt.

SLA és KPI offline mellett is mérhető: első válasz, helyszínre érkezés, lezárás ideje — a készülék időbélyegeivel, nem a szinkron percével. Fontos: a „munka vége” időbélyeg a helyszíni lezárás, nem a net visszatérése. Különben a pinceszinti munka mindig „lassabbnak” tűnik, mint a jó térerőjű irodaház.

A digitális munkalap aláírás helyszínen és a service ticket lánc cikkei a PDF és a státuszgátak részleteit adják. Az offline app ezeket a szabályokat a térerő hiányában is betartja — a szinkron csak a szállítószalag, nem a döntés helye.

Bevezetési checklist: offline szerviz app a csapatnál

Ne „majd offline is lesz” feature-flaggel indulj. A szervizes akkor hisz az appnak, ha a legrosszabb helyszínen is lezárhat. Az alábbi checklist a tipikus bevezetési lyukakat zárja. Ha 3-nál több hiányzik, a papír és a chat 30 napon belül visszatér.

• →Feladatok előtöltése a nap / túra elején térerőnél (ne csak élő listára támaszkodj)
• →Munkalap lezárás 100% offline: fotó, aláírás, kötelező mezők a készüléken
• →Offline queue UI: várakozó tételek száma és állapot látszik a szervizesnek
• →Elutasított kérés nem automatikus retry — indok + kézi / diszpécser út
• →Idempotens lezárás: hálózati törés ne hozzon dupla PDF-et / dupla státuszt
• →Időbélyeg = helyszíni lezárás, nem a szinkron időpontja (SLA igazság)
• →Ticket státusz frissül a munkalap után — a diszpécser listája él
• →Nagy fotó: folytatható feltöltés, ne fulladjon el a queue egy 12 MB képen
• →Session / token: hosszú offline nap után térerőnél csendes megújítás
• →Pilot: 2 hét, 3–5 szervizes, szándékosan „rossz térerő” helyszínekkel
• →Ops mutató: elutasított szinkron / hét, átlagos queue-ürülési idő térerőnél
• →Papír menekülőút tilos a pilotban — ha hiányzik mező, sablont javítunk, nem nyomtatunk

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