Több kapcsolattartó telephelyenként: ki engedi be a szervizest

Egy név a CRM-ben — három ember a kapunál

Reggel 7:55, külső szervizes a raktárkapunál. A munkalapon egyetlen név: „Kiss Péter”. Kiss Péter szabadságon van. A porta a listán nem találja; a műszakvezető más épületben; a biztonsági cég más szerződéssel dolgozik, mint a facility. A diszpécser a saját telefonkönyvében és a tavalyi Excelben keres — 18 perc múlva megvan a beléptető, de az SLA órája már ketyeg, a technikus órabérje pedig áll.

A „fő kapcsolattartó” mező legacy a single-site világból. Irodaház, logisztikai központ, gyártótelep, kórház, multi-tenant park: ugyanazon a címen 3–8 ember érintett a kiszállásban. Ki engedi be a gépjárművet? Ki kíséri a gépteremig? Ki veszi át a munkát és írja alá a munkalapot? Ki kap értesítést a leállásról? Ha mindhárom kérdésre ugyanaz a név a válasz a rendszerben, a valóság és az adat eltér — és a valóság nyer, a folyamat veszít.

A költség nem elméleti. 12 fős szervizcsapat, napi 18–25 kiszállás, telephelyenként átlag 8 perc beléptetési súrlódás = napi 2,5–3,5 elveszett technikusóra. Havi ~50–70 óra, ami nem javítás, nem preventív, nem számlázható utazás — csak „ki engedi be?”. Ehhez jön a második hívás a diszpécsernek, a rossz e-mail a megrendelőnek, és a lezárás utáni „miért nem szóltatok a műszaknak?” reklamáció.

A master adat szintje a telephely (site), nem a partner számlázási címe. Egy megbízónak 15 telephelye lehet; mindegyiknek saját porta, saját műszakrend, saját biztonsági protokoll. A partner szintű egyetlen „kapcsolat” mező ezért strukturálisan kevés — telephelyenként 1:N kapcsolattartó kell.

Szerepkör-mátrix: kit rögzíts a telephelyre

Ne „összes ismerős e-mailje” listát vezess, hanem szerepkör szerinti, rövid, naprakész kontaktokat. A cél: a diszpécser és a szervizes 10 másodperc alatt tudja, kit hívjon beléptetésre, kit a műszaki egyeztetésre, és kit tájékoztasson a lezáráskor. Az alábbi mátrix a facility / multi-site service gyakorlatból jön — finomítsd a saját portfóliódra, de ne spórolj a szerepek elkülönítésén.

• →Beléptetés / porta / recepció: név, mobil, műszak (pl. 6–14 / 14–22), kapu vagy épület; első hívás a szervizes érkezésekor — 80–90% esetben ez oldja meg a belépést.
• →Műszaki / facility / üzemeltető: gépterem, tető, gépészeti zónák; tudja, hol a hiba, van-e LOTO, mikor lehet leállni; nem mindig ő engedi be a kapun.
• →Műszakvezető / termelés: gyártósor, hideg lánc, raktári forgalom; dönt a beavatkozás időablakáról; ticket Cc, ha a munka termelést érint.
• →Biztonság / őrzés: külső vagy belső security; belépőkártya, vendéglista, kamerazóna; külön szerződés, külön telefonszám — ne a facility mobilszámára bízva.
• →Megrendelő / contract owner: SLA, panasz, keretszerződés; ritkán van a kapunál, de a lezárás, eszkaláció és havi riport neki szól — ticket válasz Cc.
• →Aláíró / átvevő a helyszínen: munkalap aláírás, fotó, „kész” visszaigazolás; lehet a műszakvezető vagy a gondnok — külön mező, ha nem azonos a beléptetővel.
• →Helyettes / backup: szabadság és betegség; legalább 1 másodlagos beléptető és 1 másodlagos műszaki; frissítés negyedévente vagy fluktuációkor.
• →Csatorna-szabály: mobil a beléptetéshez, e-mail a ticket szálhoz; WhatsApp ne legyen az egyetlen „hivatalos” adat a CRM-en kívül.

1:N site_contacts — web és mobil, egy forrás

A technikai modell egyszerű: egy telephelyhez (site) több kapcsolattartó (contact) tartozik — 1:N. Minden sor: név, szerep/címke, telefon, e-mail, opcionális megjegyzés (pl. „csak hétköznap 8–16”, „kapu B, csengő 3”). A lista a telephely master adat része, nem a diszpécser privát telefonkönyve és nem a technikus WhatsApp-csoportja.

Webes felületen a facility vagy a service admin a telephely kártyáján adja hozzá, szerkeszti és inaktiválja a kontaktokat. Nincs „majd Excelben frissítjük”: ha valaki kilép, a sor kikerül vagy „inaktív” lesz, és a következő kiszállásnál már nem hívja senki a régi számot. Importáláskor a partner–telephely–kontakt lánc egyszer felépíthető; utána a napi változás 30–60 másodperc szerkesztés.

Mobil appban a szervizes a feladaton vagy a telephelyen látja ugyanazt a listát offline-barát módon: ki a beléptető, ki a műszaki, milyen sorrendben érdemes hívni. Nem kell a diszpécsernek diktálnia a számot a parkolóból, és nem kell a tavalyi SMS-ből visszakopizni. Ha a porta nem veszi, a backup egy koppintás — nem 4 perces visszahívás a központba.

A SafetyPro-ban a site_contacts pont ezt a 1:N modellt adja: telephelyenként több kapcsolattartó a webes létesítmény- és partnerkezelésben, és ugyanez a lista a mobil szervizes nézetben a helyszíni belépéshez. A ticketing és a CMMS ugyanarra a telephely-masterre épül — a kontakt nem „másik modul adatja”, hanem a kiszállás része.

Adatminőségi szabályok, amik 2 hét alatt megtérülnek: kötelező szerep-címke (ne csak név); legalább egy beléptető és egy e-mailes értesítendő kontakt telephelyenként; negyedéves review a top 20 forgalmas telephelyre; tilos a „06-30…” magánszám megjegyzés nélkül a céges lista helyett. 40 telephely × átlag 4 kontakt = 160 sor — kezelhető, ha a rendszer a forrás, nem a fejek.

Ticket válasz és Cc: ki kapja meg az ügyet

A második klasszikus hiba: a jegy a service@ fiókból megy ki, de a Cc lista a diszpécser emlékezetéből. Hol a műszakvezető, hol a megrendelő, hol senki — hol mindenki, spammelve. A ticket szálnak a telephely kontaktjaiból kell épülnie: válaszadáskor a rendszer felajánlja (vagy sablon szerint kitölti) a releváns e-mail címeket a site_contacts listából.

Gyakorlati szabály. Beléptetés és időpont-egyeztetés: nem feltétlenül e-mail — telefon a porta / beléptető sorra. Műszaki státusz, várható érkezés, lezárás, „holnap reggel 7:00-kor jövünk”: e-mail a jegy szálában, Cc a műszaki + megrendelő szerepű kontaktokra. Így a helyettes diszpécser is ugyanazt a címlistát látja, és a szabadságolás nem viszi el a tudást a személyes Sent mappába.

A Cc nem egyenlő a teljes partner-mailinglistával. 6 cím minden „fogadtuk” válaszra = zaj, és a fontos leállás-üzenet is elvész. Szűkíts: 1–3 Cc szerep szerint, ticket típus vagy prioritás alapján (pl. P1 leállás → műszak + megrendelő; preventív → csak facility). A site_contacts szerepcímkéi pont ehhez kellenek — nem dekoráció.

Audit és reklamáció: ha a megrendelő azt mondja, „senki nem szólt a leállásról”, a jegy szál + a telephelyről felvett Cc időbélyeggel bizonyít. Ha a levél privát fiókból ment, a bizonyíték a diszpécser gépén van — vagy sehol. A kontaktlista és a ticket reply összekötése ezért nem „szép UX”, hanem felelősségi lánc.

Bevezetés 14 nap alatt — checklist számokkal

Ne big bangben „minden partner, minden történelmi kontakt”. 14 napos, forgalom-alapú feltöltés stabilabb, mint a tökéletes, de soha el nem készülő Excel-import.

• →1–2. nap: szerepkör-címkék rögzítése (beléptetés, műszaki, műszak, biztonság, megrendelő, aláíró, backup) — max. 6–8 címke.
• →3–5. nap: top 15–25 telephely (ami a kiszállások 70–80%-át adja): telephelyenként min. 2 kontakt (beléptető + e-mailes).
• →6–8. nap: mobil próba — 5 éles kiszállás, szervizes csak a app listából hív; diszpécser méri a beléptetési időt (cél: medián < 5 perc a kaputól).
• →9–11. nap: ticket válasz sablon + Cc a site_contacts-ből; 10 próba-reply, helyettes diszpécser is végigcsinálja.
• →12–14. nap: maradék telephelyek minimum 1 beléptető + 1 értesítendő; inaktív / kilépett nevek takarítása; negyedéves review naptárbejegyzés.
• →KPI a 30. napra: elveszett beléptetés miatti visszahívás diszpécsernek (cél: −50%), átlagos kapu→munkakezdés idő, ticket reply Cc arány a releváns szerepekre (cél: >80% a P1–P2 ügyeknél).

Összefüggés a ticketinggel, a facility-vel és a CMMS-sel

A kapcsolattartó lista önmagában nem „CRM-dísz”. Akkor él, ha a ticket a helyes telephelyre van kötve, a feladat a szervizes telefonján van, és a munkalap ugyanahhoz a helyszínhez zárul. A multi-site service és a létesítményüzemeltetés közös nyelve a telephely-master: eszközök, jegyek, kontaktok, SLA — egy ID.

Ha a ticketing külön sziget, a CMMS pedig más néven hívja ugyanazt az épületet, a kontaktlista is szétesik. Érdemes egy platformon tartani a láncot: bejelentés → telephely + kontaktok → feladat → helyszíni belépés a mobil listából → aláírt munkalap → Cc-s lezáró válasz. A SafetyPro ticketing, létesítményüzemeltetés és CMMS moduljai ugyanerre a telephely-adatmodellre épülnek; a site_contacts a beléptetés és a kommunikáció rétege rajta.

Zárásként a döntési kérdés egyszerű: a „ki engedi be a szervizest?” válasz ma a diszpécser fejében, egy Excelben vagy a telephely 1:N kontaktlistájában van? Ha az első kettő, minden szabadság, fluktuáció és esti ügyelet újraírja a folyamatot. Ha a harmadik — webben szerkeszthető, mobilról hívható, ticketből Cc-zhető —, a kapu nem a szűk keresztmetszet, hanem egy 30 másodperces lépés a javítás előtt.

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