2026-ban már senkit nem nyűgöz le önmagában az, hogy az ügyfélnek van valamilyen portálja. Inkább az számít, hogy a portál ténylegesen csökkenti-e az e-mailek, telefonhívások és ismétlődő kérdések számát — mint például „küldjék már el azt a jegyzőkönyvet a múlt hónapról”, „hol találom a BKL-t ehhez az anyaghoz” vagy „kinek van tulajdonképpen hozzáférése ehhez a telephelyhez”.
Pontosan itt mutatkozik a legnagyobb különbség a DDD cégeknél az összefüggő munkafolyamat és a széttöredezett gyakorlat között. Az egyik cégnél a beavatkozások eredményeit a rendszerben tárolják, a dokumentumok egy közös mappában vannak, a kommunikáció egy része e-mailben zajlik, és az ügyfél végül mégis kézzel kéri el az anyagokat. A másik cégnél az ügyfél bejelentkezés után megnyitja a jegyzőkönyveket, dokumentumokat és telephelyeit ugyanabban a kontextusban — és az irodának nem kell folyton ugyanazokat az anyagokat továbbítania.
Egyetlen bejelentkezés több céget is lefedhet, de a hozzáférés szűkíthető
A gyakorlatban nem ritka, hogy egyetlen személy egyszerre több társaságot vagy több objektumot kezel. Egy létesítményvezető több céget felügyel egy csoporton belül, egy irodavezető több fióktelepet kezel, vagy egy tulajdonos több telephely állapotát szeretné látni anélkül, hogy három különböző fiók között kellene váltogatnia.
Az ügyfélportál ezért nem csak az „egy fiók, egy cég” modellre épül. Egy felhasználó egyszerre több ügyfélhez is hozzárendelhető, és bejelentkezés után ugyanazon a fiókon belül válthat közöttük. Az irodának így nem kell duplikát hozzáféréseket létrehoznia csak azért, mert ugyanaz a személy több rekordot kezel.
Fontos, hogy ez nem korlátlan hozzáférés szabályok nélkül. Ha a felhasználónak nincs különleges korlátozása, látja az összes hozzárendelt cég telephelyeit. Ha azonban csak kiválasztott telephelyekre állítják be a hozzáférését, a portál csak azokat mutatja. Ez ott lényeges, ahol egyetlen személy több társaságot kezel, de nem kellene hozzáférnie minden szolgáltatási helyhez.
Ez a beállítás praktikusabb, mint a tipikus improvizált modell közös jelszavakkal, PDF-ek továbbításával kollégák között, vagy több külön fiókkal ugyanannak a személynek. A hozzáférés jobban tükrözi az ügyfél valóságát, miközben az Önök irodája számára is áttekinthető marad.
A jegyzőkönyveket az ügyfél nem a mellékletekben keresi, hanem cég és telephely szerint
Amikor az ügyfélnek szüksége van anyagokra egy audithoz, reklamációhoz vagy belső ellenőrzéshez, általában nem „valamilyen PDF-et keres egy e-mailből”. Egy konkrét beavatkozást keres egy konkrét telephelyen. Ha a jegyzőkönyvek mellékletek, közös mappák és régebbi üzenetek között vannak szétszórva, pontosan az a fajta kézi keresés keletkezik, amely feleslegesen terheli mindkét oldalt.
A portálban a jegyzőkönyvek azokhoz a cégekhez és telephelyekhez kapcsolódnak, amelyekhez a felhasználónak hozzáférése van. Az ügyfél tehát nem egy általános archívumot nyit meg, hanem a rekordok listáját a megfelelő kontextusban. Nagyobb ügyfelek esetében ez a különbség a „tudjuk, hogy valahol volt” és a helyes beavatkozási eredmény gyors megnyitása között.
Ezzel nem csak az ügyfél kényelme változik. Változik az iroda terhelése is. Amikor az ügyfél maga talál rá a beavatkozási előzményekre, megszűnik ugyanazoknak a mellékleteknek az ismételt továbbítása és a régebbi dokumentumok keresése a belső kommunikációban. A portál így nem marketing-kiegészítésként működik, hanem gyakorlati rétegként a valós üzemeltetési adatok fölött.
A dokumentumoknak világos szabályaik vannak, nem nyílt káosz
A dokumentumoknál a legnagyobb gond az, hogy a cégek gyakran összekeverik a különböző típusú anyagokat. Egy rész az anyagoknál van tárolva, másik az ügyfeleknél, további egy közös mappában, és az ügyfél végül nem tudja, mi érvényes, mi tartozik egy konkrét telephelyhez, és mit kellene egyáltalán kérnie.
Az ügyfélportál ezért nem jeleníti meg, „ami létezik”. Csak azokat a dokumentumokat mutatja, amelyeknek az ügyfél oldalon van értelmük. A telephelyi dokumentumok esetében ez azt jelenti, hogy az ügyfélnek csak azok jelennek meg, amelyeket kifejezetten hozzáférhetővé tettek a portál számára. Az anyagok esetében a portál az elmúlt 24 hónap jegyzőkönyveiben használt anyagok alapján gyűjti össze a kapcsolódó anyagokat. Ha egy anyag ebben az időszakban nem szerepelt beavatkozásban, a dokumentum nem jelenik meg az ügyfélnek csupán azért, mert valahol a rendszerben létezik.
Ez a szabály gyakorlati szempontból is fontos. Az ügyfél nem kap kezelhetetlen „dump”-ot az összes fájlból, hanem csak a cégéhez, telephelyeihez és a ténylegesen használt anyagokhoz kapcsolódó dokumentumokat. Az Önök irodájának viszont nem kell minden kérésnél azon gondolkodnia, melyik fájlt küldje még el és melyiket ne.
Az ügyfél a saját adatait és telephelyeit is ugyanabban a kontextusban látja
A portál nem csak jegyzőkönyvek olvasására hasznos. A napi működésben gyakran segít az is, hogy az ügyfél egy helyen látja a cég alapadatait, kapcsolattartókat, a telephelyek listáját és más kapcsolódó információkat. Amikor változik a kapcsolattartó, új telephely kerül be, vagy ellenőrizni kell, hová küldenek anyagokat, nem kell ezeket az információkat régi e-mailekben vagy különböző táblázatokban keresni.
A Saját adatok résznél fontos az is, hogy a terjedelem nem mindenki számára azonos. Egyes ügyfelek csak olvasási hozzáféréssel rendelkeznek, mások szerkeszthetik kapcsolattartói e-mail címeiket. Itt is igaz tehát, hogy a portál nem univerzálisan nyitott tér, hanem konfigurálható hozzáférés aszerint, amit az adott felhasználónak ténylegesen tennie kell.
Ez a belső rendben is segít. Ahelyett, hogy az ügyfél e-mailben küldi el a kapcsolattartó változását és az Önök irodájának kézzel kell átvinnie több helyre, az ilyen módosítások egy része közvetlenül ott kezelhető, ahol az ügyfél az adatokkal dolgozik.
Az iroda számára az a lényeg, hogy a hozzáférés-kezelés áttekinthető maradjon
Egy DDD cég szemszögéből az ügyfélportál nem csak akkor jó, ha az ügyfélnek kényelmes a használata. Észszerűen kezelhetőnek is kell lennie. Ez azt jelenti, hogy meg lehessen hívni egy ügyfelet, hozzá lehessen rendelni újabb céget, le lehessen választani a hozzáférését, vagy korlátozni lehessen kiválasztott telephelyekre — mindezt a rendszeren belül, kerülőutak nélkül.
Pontosan itt mutatkozik meg a különbség a tipikus széttöredezett megközelítéssel szemben. Amikor egy cég közös postafiókokon, kézi melléklettovábbításon és informális megállapodásokon keresztül működik arról, ki mit láthat, a rend néhány hónap után elvész. Később már senki nem tudja pontosan, kinek milyen dokumentum ment el, kinek vannak régi anyagai félretéve, és kinek kell még mindig kérnie őket.
A portál-modellben a hozzáférés-kezelés a normális működés része. Látják, melyik felhasználó melyik cégekhez van rendelve, van-e hozzáférése az összes telephelyhez vagy csak a kiválasztottakhoz, és ezt módosíthatják anélkül, hogy magát a jegyzőkönyvek vagy dokumentumok tartalmát megváltoztatnák.
Mit változtat ténylegesen az ügyfélportál
Az ügyfélportál nem azért érdekes, mert újabb képernyőt ad hozzá. Akkor válik fontossá, amikor csökkenti azoknak a rutinkéréseknek a számát, amelyeket ma sok DDD cégnél még mindig az iroda kezel kézzel: régi jegyzőkönyv elküldése, anyaghoz tartozó dokumentum megkeresése, annak magyarázata, melyik telephelyekhez van hozzáférése valakinek, vagy annak ellenőrzése, hogy egy kapcsolattartó-változást már valahol átvezettek-e.
Ha az ügyfél bejelentkezés után összefüggő kontextusban talál rá a jegyzőkönyvekre, dokumentumokra, cégekre és telephelyekre, a portál mindkét oldalon időt takarít meg. Ha csak újabb hely lenne, ahová néhány PDF van letéve szabályok nélkül, a haszna minimális lenne. Ebben rejlik a különbség egy valódi ügyfélportál és egy újabb fájltároló között.
Ha részletesebben szeretné megismerni a portált, folytassa az ügyfélportálnál, a dokumentumoknál, az ügyfélkezelésnél, az ügyfélportál dokumentációnál, a portálon belüli dokumentumoknál, az ügyfél meghívásánál a portálra, a saját adatoknál a portálban és a felhasználókezelésnél.
