2026-ban mar senkit nem nyugoz le onmagaban az, hogy az ugyfélnek van valamilyen portalja. Inkabb az szamit, hogy a portal ténylegesen csokkenti-e az e-mailek, telefonhivasok és ismetlodo kérdések szamat — mint peldaul „kuldjék mar el azt a jegyzokonyvet a mult honaprol”, „hol talalom a BKL-t ehhez az anyaghoz” vagy „kinek van tulajdonképpen hozzaférése ehhez a telephelyhez”.
Pontosan itt mutatkozik a legnagyobb kulonbség a DDD cégeknel az osszefuggo munkafolyamat és a széttoredezett gyakorlat kozott. Az egyik cégnél a beavatkozasok eredményeit a rendszerben tarolják, a dokumentumok egy kozos mappaban vannak, a kommunikacio egy része e-mailben zajlik, és az ugyfél végul mégis kézzel kéri el az anyagokat. A masik cégnél az ugyfél bejelentkezés utan megnyitja a jegyzokonyveket, dokumentumokat és telephelyeit ugyanabban a kontextusban — és az irodanak nem kell folyton ugyanazokat az anyagokat tovabbitania.
Egyetlen bejelentkezés tobb céget is lefedhet, de a hozzaférés szukitheto
A gyakorlatban nem ritka, hogy egyetlen személy egyszerre tobb tarsasagot vagy tobb objektumot kezel. Egy létesitményvezeto tobb céget felug egy csoporton belul, egy irodavezeto tobb fioktelepet kezel, vagy egy tulajdonos tobb telephely allapotat szeretné latni anélkul, hogy harom kulonbozo fiok kozott kellene valtogatnia.
Az ugyfélportal ezért nem csak az „egy fiok, egy cég” modellre épul. Egy felhasznalo egyszerre tobb ugyfélhez is hozzarendelheto, és bejelentkezés utan ugyanazon a fiokon belul valthat kozottuk. Az irodanak igy nem kell duplikat hozzaféréseket létrehoznia csak azért, mert ugyanaz a személy tobb rekordot kezel.
Fontos, hogy ez nem korlatlan hozzaférés szabalyok nélkul. Ha a felhasznalonak nincs kulonleges korlatozasa, latja az osszes hozzarendelt cég telephelyeit. Ha azonban csak kivalasztott telephelyekre allitjak be a hozzaférését, a portal csak azokat mutatja. Ez ott lényeges, ahol egyetlen személy tobb tarsasagot kezel, de nem kellene hozzaférnie minden szolgaltatasi helyhez.
Ez a beallitas praktikusabb, mint a tipikus improvizalt modell kozos jelszavakkal, PDF-ek tovabbitasaval kollegak kozott, vagy tobb kulon fiokkal ugyanannak a személynek. A hozzaférés jobban tukrozi az ugyfél valosagat, miközben az Onok irodaja szamara is attekintheto marad.
A jegyzokonyveket az ugyfél nem a mellékletekben keresi, hanem cég és telephely szerint
Amikor az ugyfélnek szuksége van anyagokra egy audithoz, reklamaciohoz vagy belso ellenorzéshez, altalaban nem „valamilyen PDF-et keres egy e-mailbol”. Egy konkrét beavatkozast keres egy konkrét telephelyen. Ha a jegyzokonyvek mellékletek, kozos mappak és régebbi uzenetek kozott vannak szétszorva, pontosan az a fajta kézi keresés keletkezik, amely feleslegesen terheli mindkét oldalt.
A portalban a jegyzokonyvek azokhoz a cégekhez és telephelyekhez kapcsolodnak, amelyekhez a felhasznalonak hozzaférése van. Az ugyfél tehat nem egy altalanos archivumot nyit meg, hanem a rekordok listaját a megfelelo kontextusban. Nagyobb ugyfelek esetében ez a kulonbség a „tudjuk, hogy valahol volt” és a helyes beavatkozasi eredmény gyors megnyitasa kozott.
Ezzel nem csak az ugyfél kényelme valtozik. Valtozik az iroda terhelése is. Amikor az ugyfél maga talal ra a beavatkozasi elozmenyekre, megszunik ugyanazoknak a mellékleteknek az ismetelt tovabbitasa és a régebbi dokumentumok keresése a belso kommunikacioban. A portal igy nem marketing-kiegészitésként mukodik, hanem gyakorlati rétegként a valos uzemeltetési adatok folott.
A dokumentumoknak vilagos szabalyaik vannak, nem nyilt kaosz
A dokumentumoknal a legnagyobb gond az, hogy a cégek gyakran osszekeverik a kulonbozo tipusu anyagokat. Egy rész az anyagoknal van tarolva, masik az ugyfeleknel, tovabbi egy kozos mappaban, és az ugyfél végul nem tudja, mi érvényes, mi tartozik egy konkrét telephelyhez, és mit kellene egyaltalan kérnie.
Az ugyfélportal ezért nem jelenitimeg, „ami létezik”. Csak azokat a dokumentumokat mutatja, amelyeknek az ugyfél oldalon van értelmuk. A telephelyi dokumentumok esetében ez azt jelenti, hogy az ugyfélnek csak azok jelennnek meg, amelyeket kifejezetten hozzaférhetové tettek a portal szamara. Az anyagok esetében a portal az elmult 24 honap jegyzokonyveiben hasznalt anyagok alapjan gyujti ossze a kapcsolodo anyagokat. Ha egy anyag ebben az idoszakban nem szerepelt beavatkozasban, a dokumentum nem jelenik meg az ugyfélnek csupan azért, mert valahol a rendszerben létezik.
Ez a szabaly gyakorlati szempontbol is fontos. Az ugyfél nem kap kezelhetetlen „dump”-ot az osszes fajlbol, hanem csak a cégéhez, telephelyeihez és a ténylegesen hasznalt anyagokhoz kapcsolodo dokumentumokat. Az Onok irodajanak viszont nem kell minden kérésnél azon gondolkodnia, melyik fajlt kuldje még el és melyiket ne.
Az ugyfél a sajat adatait és telephelyeit is ugyanabban a kontextusban latja
A portal nem csak jegyzokonyvek olvasasara hasznos. A napi mukodésben gyakran segit az is, hogy az ugyfél egy helyen latja a cég alapadatait, kapcsolattartokat, a telephelyek listaját és mas kapcsolodo informaciokat. Amikor valtozik a kapcsolattarto, uj telephely kerul be, vagy ellenorizni kell, hova kuldenek anyagokat, nem kell ezeket az informaciokat régi e-mailekben vagy kulonbozo tablazatokban keresni.
A Sajat adatok résznél fontos az is, hogy a terjedelem nem mindenki szamara azonos. Egyes ugyfelek csak olvasasi hozzaféréssel rendelkeznek, masok szerkeszthetik kapcsolattartoi e-mail cimeiket. Itt is igaz tehat, hogy a portal nem univerzalisan nyitott ter, hanem konfiguralhato hozzaférés aszerint, amit az adott felhasznalonak ténylegesen tennie kell.
Ez a belso rendben is segit. Ahelyett, hogy az ugyfél e-mailben kuldi el a kapcsolattarto valtozasat és az Onok irodajanak kézzel kell atvinnié tobb helyre, az ilyen modositasok egy része kozvetlenul ott kezelheto, ahol az ugyfél az adatokkal dolgozik.
Az iroda szamara az a lényeg, hogy a hozzaférés-kezeles attekintheto maradjon
Egy DDD cég szemszogébol az ugyfélportal nem csak akkor jo, ha az ugyfélnek kenyelmes a hasznalatata. Észszeruen kezelhetonek is kell lennie. Ez azt jelenti, hogy meg lehessen hivni egy ügyfelet, hozza lehessen rendelni ujabb céget, le lehessen valasztani a hozzaférését, vagy korlatozni lehessen kivalasztott telephelyekre — mindezt a rendszeren belul, kerulouttak nélkul.
Pontosan itt mutatkozik meg a kulonbség a tipikus széttoredezett megkozelitéssel szemben. Amikor egy cég kozos postafiokokon, kézi melléklettovabbitason és informalis megallapodasokon keresztul mukodik arrol, ki mit lathat, a rend nehany honap utan elvész. Késobb mar senki nem tudja pontosan, kinek milyen dokumentum ment el, kinek vannak régi anyagai félretéve, és kinek kell meg mindig kérnie oket.
A portal-modellben a hozzaférés-kezeles a normalis mukodés része. Latjak, melyik felhasznalo melyik cégekhez van rendelve, van-e hozzaférése az osszes telephelyhez vagy csak a kivalasztottakhoz, és ezt modosithatjak anélkul, hogy magat a jegyzokonyvek vagy dokumentumok tartalmat megvaltoztotnak.
Mit valtoztat ténylegesen az ugyfélportal
Az ugyfélportal nem azért érdekes, mert ujabb képernyot ad hozza. Akkor valik fontossa, amikor csokkenti azoknak a rutinkéréseknek a szamat, amelyeket ma sok DDD cégnél még mindig az iroda kezel kézzel: régi jegyzokonyv elkuldése, anyaghoz tartozo dokumentum megkeresése, annak magyarazata, melyik telephelyekhez van hozzaférése valakinek, vagy annak ellenorzése, hogy egy kapcsolattarto-valtozast mar valahol atvezettek-e.
Ha az ugyfél bejelentkezés utan osszefuggo kontextusban talal ra a jegyzokonyvekre, dokumentumokra, cégekre és telephelyekre, a portal mindkét oldalon idot takarit meg. Ha csak ujabb hely lenne, ahova nehany PDF van letéve szabalyok nélkul, a haszna minimalis lenne. Ebben rejlik a kulonbség egy valodi ugyfélportal és egy ujabb fajltarolo kozott.
Ha részletesebben szeretné megismerni a portalt, folytassa az ugyfélportalnal, a dokumentumoknal, az ugyfélkezelesnél, az ugyfélportal dokumentacionnal, a portalon beluli dokumentumoknal, az ugyfél meghivasanal a portalra, a sajat adatoknal a portalban és a felhasznalokezelesnél.
