Partnerkezelés service cégnél: megbízó, alvállalkozó, egy helyen

Miért omlik össze a partnerlista Excelben

Egy tipikus 8–20 fős service cég 15–60 megbízót, 40–200 telephelyet és 3–12 alvállalkozót kezel. A „partnerlista” gyakran 2–4 fájl: ügyféllista a pénzügynél, telephely-tábla a diszpécsernél, alvállalkozó-kontakt a műszakvezető telefonjában, szerződéses PDF a megosztott mappában. Amikor a megbízó hív, a diszpécser 2–5 percet keres: melyik cím, milyen SLA, van-e keretszerződés, ki a műszaki kapcsolattartó, mehet-e alvállalkozó.

A szétesés nem „rendetlenség”, hanem skálahiba. 10 telephelynél az emlékezet még bírja; 50 fölött a hibák ismétlődnek: rossz címre kiszállás, lejárt szerződésre munkavégzés, alvállalkozónak kiosztott munka a megbízó tudta nélkül, vagy két alvállalkozó ugyanarra a calloutra. A számlázás is szenved: a lezárt munka nem kötődik partnerhez és service agreementhez, így a havi zárás Excel-összevetés, nem egy kattintás.

A megoldás nem „még egy CRM-mező”, hanem szerviz-specifikus partner-modell: a partner nem csak név és adószám, hanem telephelyek, kapcsolattartók, szerződések, SLA-sávok és — multi-tenant környezetben — adathatárok összessége. A jegy, a munkalap és a számlázandó tétel mind erre a gerincre épül.

• →15–60 megbízó + 40–200 telephely: Excel + e-mail master adat törékeny
• →Tipikus veszteség: 30–90 perc/nap keresés, 5–15% rossz cím / dupla kiszállás
• →Alvállalkozó-kontakt a telefonban = nem auditálható, nem skálázható
• →Cél: partner + telephely + service agreement + jogosultság egy forrásból

Megbízó, alvállalkozó, belső csapat — egy modell

Service oldalon három szereplő-típus keveredik, és a leggyakoribb hiba, ha mindhármat „ügyfélnek” hívod ugyanabban a listában. A megbízó (megrendelő) az, akinek a telephelyén dolgozol, akinek SLA-t vállalsz, és aki fizet — vagy a keretszerződés alapján jóváhagy. Az alvállalkozó a te kapacitás-kiterjesztésed: szakági munka (pl. hűtés, lift, gyengeáram), pót-callout, szezonális terhelés. A belső csapat (diszpécser, szervizes, admin) a saját szervezeted — ők nem partnerek, hanem user szerepkörök.

Egy helyen tartani azt jelenti: ugyanabban a rendszerben van partner-kártya a megbízónak és az alvállalkozónak, de eltérő típussal és jogokkal. A megbízóhoz telephelyek, service agreementek, jegyek és munkalapok kötődnek. Az alvállalkozóhoz kiosztott feladatok, elvégzett munkalapok, esetleg keretóra / díjszabás — de nem a megbízó teljes portfóliója. A belső user a szervezet tenantjében él, és szerepkör szerint lát (diszpécser mindent a saját ügyfélkörön, szervizes a rákiosztott munkát).

Gyakorlati számok: ha a partner-típust nem választod szét, a diszpécser listájában 80–150 „név” keveredik, és a keresés 3–4× lassabb, mint 2 szűrt listában (megbízók / alvállalkozók). Ha az alvállalkozót „megbízóként” veszed fel, a riport torzul: „ügyfélszám” nő, a valós bevételi partner aránya csökken, az SLA-riport pedig összeomlik.

• →Megbízó: telephely + SLA + jegy + számlázás forrása
• →Alvállalkozó: kiosztott munka + saját hatókör, nem teljes ügyfélportfólió
• →Belső csapat: user + szerepkör (diszpécser / szervizes / admin), nem partnerrekord
• →Típusmező kötelező: megbízó | alvállalkozó | egyéb (pl. hatóság, szállító)

Partner-csoportosítás: telephely, márka, szerződés

A service cégnél a „partner” ritkán egyetlen cím. Egy holding 4 márkanévvel és 12 telephelyel ír e-mailt; a számlázási partner egy Kft., a hibabejelentő a facility, a beléptetés a biztonsági cég. Ha minden telephely külön „ügyfél” a listában, a keretszerződés és az SLA szétesik. Ha minden egyetlen név alá van gyűrve telephely nélkül, a multi-site jegyek és riportok használhatatlanok.

A stabil modell három szint: 1) Partner (jogi / számlázási egység vagy szerződéses főfél). 2) Partner-csoport vagy holding-címke, ha több leánycég ugyanahhoz a kerethez tartozik. 3) Telephelyek a partner alatt — cím, kód, kapcsolattartó, opcionális SLA-felülírás. A jegy mindig partner + telephely pároshoz kötődik; a munkalap ugyanide. Így a „Park Irodaház B épület” nem új ügyfél, hanem a X Kft. 3. telephelye.

Csoportosítás haszna a diszpécsernél azonnal látszik: szűrés „csak holding A telephelyei”, összevont havi riport a megbízónak, és alvállalkozó-kiosztás telephely-szinten („csak a raktár-logisztikai zóna”). 20+ telephelyes megbízónál a csoport / holding nézet 40–60%-kal csökkenti a „melyik ügyfél ez?” félrekattintásokat a triage-ban — feltéve, hogy a master adat egységes (egy telephelykód, nem három alias).

• →Partner → telephely(ek) → kapcsolattartók (min. 1 műszaki, 1 számlázási)
• →Holding / csoport címke: több leány, egy keretriport
• →Telephelykód kötelező (ne 3 alias ugyanarra a címre)
• →Jegy és munkalap mindig partner + telephely mezővel — nem „csak tárgysor”

Service agreement: SLA, hatókör, lejárat a szoftverben

A service agreement (szolgáltatói / keretszerződés) a partnerkezelés gerince: mit vállalsz, hol, milyen válaszidővel, milyen áron vagy keretórában, meddig. Ha a szerződés PDF a megosztott mappában van, a diszpécser a jegy nyitásakor nem látja a 4 órás calloutot a kritikus hűtésre és a 24 órás ablakot az általános gépészetre. Eredmény: rossz prioritás, vitatott kötbér, „miért nem jöttetek ki?” konfliktus.

A szoftverben a service agreement minimum mezői: partner, hatókör (telephelyek és/vagy szolgáltatás-típusok), érvényesség (kezdet–lejárat), SLA-sávok (pl. P1 4 óra, P2 24 óra), opcionális keretóra / havi fix, kapcsolattartók, és státusz (aktív / lejáró / lejárt). A jegy prioritása és határideje ebből a sávból jön — nem a levélben lévő „sürgős” szóból önmagában. Ha a szerződés 30 nap múlva lejár, a diszpécser és az account manager listán látja; nem a kötbér-levélből derül ki.

Számok, amik számítanak: 25 aktív keretszerződésnél, ha nincs lejárat-figyelés, tipikusan 2–5 szerződés „csúszik el” évente (munkavégzés lejárt kereten, utólagos vita). Ha az SLA a jegyhez kötődik, a havi megbízói riport (átlagos válaszidő, P1 teljesülés %) 1–2 óra Excel helyett 10–15 perc export. A SafetyPro jellegű CMMS + ticketing láncban a partner és a szerződés a ticket→feladat→munkalap útvonal elején áll — nem a számlázás végén „utólag hozzárendelve”.

• →Service agreement = partner + telephely-hatókör + SLA-sáv + érvényesség
• →Jegy prioritás / határidő a szerződéses sávból, nem csak a levél hangneméből
• →Lejárat előtt 30–60 nap: emlékeztető account / diszpécser listán
• →Lejárt keretre ne lehessen „véletlen” callout számlázás nélkül — státusz guard

Multi-tenant határok: ki mit lát a partnerekből

Partnerkezelés enterprise service környezetben multi-tenant kérdés is. A te szervezeted tenantje tartalmazza az összes megbízót és alvállalkozót. A megbízó — ha meghívott portálon vagy megosztott telephely-hozzáférésen keresztül belép — csak a saját telephelyeit, jegyeit és munkalap-előzményét látja, nem a konkurens ügyfélét a szomszédos irodaházban. Az alvállalkozó csak a rákiosztott feladatokat és a szükséges telephely-kontextust — nem a teljes diszpécser-backlogot és nem más megbízók naplóit.

A határok három szinten érvényesülnek. Szervezet (tenant): a service cég adatai elválnak minden más cégétől. Partner / telephely: a meghívott fél can_access_site jellegű szabállyal csak a ráruházott helyszíneken dolgozik. Szerepkör: diszpécser vs. szervizes vs. megbízói viewer vs. alvállalkozói kivitelező — más írási jog. A leggyakoribb hiba a „gyors megoldás”: az alvállalkozót belső adminnak veszed fel, hogy „lássa a jegyeket”. Eredmény: látja az összes megbízót, más telephelyeket, esetleg árazást — ez nem kényelem, hanem adatszivárgás és szerződéses kockázat.

Audit szempontból is számít: ki hívta meg a partnert, ki módosította a service agreementet, ki osztott ki alvállalkozóra munkát. Időbélyeg + user + partner/telephely nélkül a „ki adta ki a kulcsot?” vita nem zárható. Negyedéves jogosultság-review 15–30 perc, ha a meghívások listázhatók; ha nem, napokig tart a Excel-összevetés a beléptetési listával.

• →Megbízó viewer: saját telephely + saját jegy/munkalap, más ügyfél = 0 sor
• →Alvállalkozó: kiosztott feladat hatókör, nem teljes backlog / nem idegen partner
• →Soha ne org-admin az alvállalkozó „hogy gyorsabb legyen”
• →Meghívás lejárata vagy projekt/szerződés zárás után visszavonás
• →Activity log: meghívás, szerződésmódosítás, kiosztás — auditálható

Bevezetési checklist service partner-modellhez

Ne big bangben cseréld a teljes CRM-et. 2–4 hét alatt stabilizálható a master adat egy élő ticket/CMMS rendszerben, ha sorrendet tartasz: előbb a top 10–20 bevételi megbízó, aztán a telephelyek, aztán a service agreementek, végül az alvállalkozók és a meghívások. A diszpécser a triage közben „tisztít”: minden új jegy kötelező partner + telephely mezővel — így a lista a valós forgalomból épül, nem egy egyszeri, elavult Excel-importból.

Az alábbi checklist a minimum. Ha 3+ sor piros, a partnerkezelés még nem gerinc, hanem mellékadat — és a SLA-riport, a számlázás és a multi-tenant meghívás is gyenge lesz.

• →Minden aktív megbízó partner-kártyán, típussal (megbízó), min. 1 kapcsolattartó
• →Telephelyek partner alá kötve, egyedi kód + cím, aliasok összevonva
• →Aktív service agreement: hatókör, SLA-sáv, lejárat dátummal
• →Alvállalkozók külön típus + kiosztási szabály (milyen munka / mely telephely)
• →Jegy kötelező mező: partner + telephely (+ prioritás a szerződéses sávból)
• →Meghívott felek: telephely-szintű jog, nem org-admin; lejárat beállítva
• →Lejáró szerződések lista (30/60 nap) heti 10 perces account review
• →Negyedéves jogosultság-review: meghívások, alvállalkozói userök, inaktív partnerek
• →Nincs megosztott jelszó / közös „alvállalkozó” fiók — személyenkénti user
• →Havi riport: top megbízók jegyvolumen, SLA %, alvállalkozóra kiosztott arány

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