A szervizjegyek figyelése fenyegető csúszás szempontjából olyan feladat, amelyet az AI alapvetően teljes mértékben át tud venni. Itt nem egy szürke zónáról van szó emberi felügyelettel kiegészítve: maga a jelzés olyan feladat, amely már ma is automatizálható meglévő technológiával (rpa), feltéve hogy néhány alapfeltétel rendben van.
Három tengely a meghatározó itt: strukturáltság, mennyiség és mérlegelési tér. Mindhárom ugyanabba az irányba mutat.
Strukturáltság (5/5). A feladat egy dátum és egy szabály összehasonlításából áll: mennyi ideje nyitott már egy jegy, és mikor jár le a megállapodott elintézési határidő? Ez nem értelmezés, ez számolás. A jegykezelő rendszer rögzíti a nyitás időpontját, az SLA-határidő előre meg van határozva, és mindössze két szám összehasonlítására van szükség. Amint ezek az SLA-határidők egyértelműen meg vannak határozva, nincs kétség afelől, mit jelent a "fenyegető".
Mennyiség (5/5). Egy ügyfélszolgálati csapat általában napi tízes-százas nagyságrendben dolgoz fel jegyeket, mindegyiknek saját, lejáró órájával. Egy csapatvezető, aki ezt kézzel követi nyomon, folyamatosan végig kell nézze a listát és összeadja az adatokat. Ez pontosan az a fajta ismétlődő, nagy mennyiségű munka, amitől a szoftver nem fárad el, és amelynél nem néz el jegyeket.
Mérlegelési tér (4/5). Maga a jelzés alig igényel mérlegelést: a határidő a határidő. Van egy kis mozgástér, mert egyes szervezeteknél árnyalatok vannak (például: az ügyfélnél töltött várakozási idő beleszámít-e az SLA-órába vagy sem), de amint ezek a szabályok rögzítve vannak, magában a jelzésben már nincs tér az értelmezésre.
A többi tengely itt gyakorlatilag irreleváns a fő kérdés szempontjából. Ügyfélkapcsolat és fizikai cselekvések nem játszanak szerepet ennél a feladatnál: háttérfolyamatról van szó, nem ügyféllel folytatott beszélgetésről. Kreativitás nincs szóban: nincs új megoldást kitalálni, csak egy határidőt kell figyelni. A hibaköltségek és a megfelelőség átlagosan (3) pontszámot kapnak, nem azért mert maga a jelzés kockázatos, hanem mert egy elmulasztott vagy hibás jelzés kihatással lehet az ügyfél-elégedettségre vagy a szerződéses megállapodásokra. Ez nem szól az automatizálás ellen, de igenis szól a helyes előzetes beállítás mellett.
Az ehhez alkalmas technológia viszonylag szerény: robotic process automation (rpa). Nincs szükség nyelvi modellre vagy komplex AI-ra egy dátum és egy szabály összehasonlításához. Egy script, amely rendszeresen kiolvassa a jegykezelő rendszert, kiszámítja az SLA-határidőig hátralévő időt, és egy előre beállított küszöbnél jelzést küld a csapatvezetőnek, elvégzi a munkát. Ez történhet e-mailben, dashboard-widgeten keresztül vagy magában a jegykezelő rendszerben megjelenő értesítés formájában.
Az alapfeltételek egyszerűek, de lényegesek: az SLA-határidőket világosan és egyértelműen kell rögzíteni, és a jelzést technikailag ezekre a határidőkre kell beállítani. Ha ezek közül bármelyik hiányzik, az automatizálás nem fog jól működni — nem azért, mert a feladat alkalmatlan, hanem mert az alap nem stimmel.
Ez az eredmény a jelzésre vonatkozik. Nem vonatkozik automatikusan arra, hogy mi történik a jelzés után. Egy olyan szervezetnél, ahol egy fenyegető csúszás eszkalációja azonnal egy fix, kiszámítható lépést indít el (például: a jegy automatikus továbbítása egy szakértőhöz), az a következő lépés is nagyrészt automatizálható. Egy olyan szervezetnél, ahol az eszkaláció az ügyfélkapcsolattól, a szerződéstípustól vagy a politikai érzékenységtől függ, ez a következő lépés emberi munka marad — itt az AI feletti emberi felügyelet, konkrétan releváns kiindulópont.
Az "SLA-határidő" fogalma is szervezetenként eltérő. Egy vállalatnál, ahol egyetlen egyszerű, egységes elintézési határidő van, egyszerűbb az automatizálási feladat, mint egy olyan vállalatnál, ahol tucatnyi szerződésváltozat, prioritási szint és kivételszabály létezik. Minél összetettebb ez a szabályrendszer, annál több előkészítő munkára van szükség, mielőtt a jelzés megbízhatóan automatikusan futhatna. Pontosan ezért van szükség egy feladatonkénti, nem pedig funkciónkénti felmérésre: ugyanaz a beosztás, a "csapatvezető ügyfélszolgálat", az egyik vállalatnál egy nagyrészt automatizálható jelzési feladatot takarhat, egy másiknál pedig egy olyan feladatot, amely még jelentős részben kézi munkát igényel.
Ez az oldal egy feladatot ír le, nem személyzeti döntést. Hogy a felszabaduló kapacitást egy csapaton belül hogyan osztják el újra, olyan döntés, amely a szervezet saját hatáskörébe tartozik, és amelyre saját jogi követelmények vonatkoznak, különösen ha az funkciókra vagy létszámra kihat. Az ezzel kapcsolatos gondosság, beleértve a munkavállalói képviselet tájékoztatását, külön folyamat — lásd például az üzemi tanács tájékoztatása az AI-ról és gondosság a funkciók megszüntetésénél. Ez az oldal ehhez nem ad alátámasztást, csak tényeket közöl magáról a feladatról.
A fenyegető SLA-csúszás jelzése nem áll önmagában. Hasonló monitoring- és jelzési feladatok fordulnak elő pénzügyi folyamatoknál is, mint például az időszakos előfizetési számlázás vagy a digitális számlák e-számlázáson keresztüli cseréje. Ott is érvényes: minél strukturáltabbak a szabályok és minél nagyobb a mennyiség, annál alkalmasabb a feladat automatizálásra.
Szeretné tudni, hogy ez az Ön saját csapata esetében hogyan alakul, beleértve a pontos SLA-struktúrát és a jegymennyiséget, amellyel dolgozik? Az ftetoai ingyenes gyorsfelmérése tizenkét kérdésből áll, fiók nélkül elvégezhető, és jelzi, hogy az Ön profiljában szereplő órák mekkora része vehető át már ma AI által. A teljes munkafelmérés, amely egészen a feladatszintig lemegy az Ön saját folyamataiban, még fejlesztés alatt áll — ezt az ígéretet itt szándékosan nem nagyítjuk fel a valóságosnál.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.