Biztosan tudjátok, hogy a munkám során egy support központot (is) vezetek. Ez egy nem túl nagy support központ, összesen négyen látjuk el a feladatot és kb. 500-600 felhasználót szolgálunk ki. Megnéztem egy statisztikát is, a tavalyi évben (2014-ben) közel 400 bejövő hívást kezeltünk havonta, nem számítva a saját mobilhívásokat és bejövő e-maileket. Persze nem úgy kell elképzelni, hogy mind a négyen egyfolytában a telefon mellett ülünk és várjuk a hívást, de aki irodában van, azok közül bárki felveheti a telefont. Van egy dedikált ún. elsődleges supportot ellátó kolléga (1st line support), aztán van két tanácsadó kolléga és én (2nd line support) és ha nem tudjuk megoldani, akkor egy igénykezelő rendszeren keresztül (ticketing system) delegáljuk a problémát, feladatot a fejlesztés részére, akik így az ún. 3rd line supportot látják el.
Ahogy egy korábbi cikkben is utaltam rá, az ügyfélszolgálaton mindig zajlik az élet. Most be szeretnék mutatni néhány tipikus hibabejelentési hiba típust, amit általában ügyfelek követnek el. Na nem azért, hogy kioktassak bárkit, de egy hibabejelentésnél az SLA-kban általán 1-2 óra szerepel, ha viszont a hibabejelentés nem pontos, hiányos, akkor nem valósulhat meg az SLA-ban vállalt határidő. Ilyenkor ráadásul nem is a szolgáltató hibája miatt nem valósul meg az SLA-ban foglalt határidő, hanem a bejelentő miatt. A következő néhány pontban tehát tipikus bejelentési hibákat szeretnék bemutatni. Az üzleti levelezéssel kapcsolatban már egyszer írtam, érdemes előtte végigolvasni.
1. Továbbküldés
Cégeken belül gyakran előfordul, hogy a munkatársak nem adhatnak le semmilyen hibát, változtatási kérést vagy új igényt közvetlenül a szolgáltató felé, helyette házon belül van egy koordinátor, akinek feladata lenne, hogy megszűrje a házon belüli hibákat, igényeket (kvázi egy kulcsfelhasználó), és csak azokat küldje meg a szolgáltatónak, amelyeket ő nem tudott kezelni. Hát ebben sajnos nem mindenki sikeres. Sajnos több esetben is előfordul, hogy ez a koordinátor egyszerűen továbbküldi a saját kollégája levelét anélkül, hogy megértené a problémát, vagy megpróbálná megérteni a problémát. Esetleg el sem olvassa. Vagy adott esetben nem is a szolgáltatóra tartozik az ügy. Például fordult már elő, hogy az iroda klímájával kapcsolatos problémát küldtek tovább nekünk, mi pedig természetesen nem a klímával, hanem a vállalatirányítási rendszerrel foglalkozunk.
2. Csak hibaüzenet
A másik tipikus probléma amikor csak átküldenek egy hibaüzenetet a felhasználók és mellé csak annyit, hogy ez a hiba jelentkezik. De körítést már nem tesznek mellé, hogy a hiba akkor jelentkezik, amikor az adott modulban ezt és ezt csinálom. Pedig ezen információk nélkül a képernyőn megjelenő hibaüzenet nem ad elég támpontot, hogy segíthessünk, a segítségnyújtásnál viszont az idő a legfontosabb.
3. Hibaüzenet rosszul kiegészítve
Vannak olyan felhasználók, akik már profibbak és tudják, hogy egy hibaüzenet lejelentésénél a hibaüzenet mellé célszerű valamilyen kiegészítő információt is adni, de sokszor mégis hibáznak a felhasználók. A kapott hibaüzenetekről készült képernyőfotókat nézegetve vettem észre, hogy sokszor mérnöki pontossággal helyezik a felhasználók a hibaüzenetet egy olyan pontra a képernyőn, amivel hasznos információt takarnak el (például az alatta lévő képen látható számlaszámot, vagy munkalapszámot), de ezt az információt külön már nem írják le. Így előfordul, hogy kapunk egy hibaüzenetet, még azt is tudjuk, hogy számlázási gond van, de sajnos a hibaüzenet pont a számlaszámot takarja el (és a felhasználó nem mozgatja el és nem is írja le a levélben).
4. Válasz mindenkinek
Na ez még mindig a vesszőparipám, elég borzasztó, hogy olyan felhasználóknak is, akik napi szinten több tucat levelet írnak és a munkájuk szervers része az elektronikus levelezés, fel kell hívni a figyelmüket, hogy válasz esetén a "válasz mindenkinek" opciót használják. Hibabejelentésnél ugyan nincs ilyen opció, hiszen a felhasználó ír egy levelet a címzettnek. Viszont a címzett saját hatáskörben akár több munkatársat is rátehet a levelezésre és ezeket a személyeket az ún. CC mezőbe (másolat) teszi. A felhasználó viszont gyakran ilyenkor már nem "válasz mindenkinek" opcióban levelez tovább, megfosztva a többi felhasználót az értékes információktól, akik viszont enélkül nem tudnak segíteni.
5. Inkább írásban, mint telefonban
Én azt gondolom, hogyha egyértelműen hibabejelentésről beszélünk, akkor sokkal hatásosabb az írásbeli bejelentés (e-mail), hiszen ilyenkor csatolmányt, képernyő képeket és kiegészítő szöveget is a szolgáltató tudtára tudunk adni, ráadásul időbélyeggel ellátva (pontosan visszakövethező, hogy mikor adtuk le a hibát). Telefonon inkább konzultációt érdemes kérni, hogyha elakadt a felhasználó egy bizonyos dologban és tudja, hogy egy kis segítséggel tovább tudna lendülni a problémán, de nem hibával áll szemben, hanem inkább felhasználói hiányosság van a dologban.
És minden hibaleadás előtt egy tanács, amit én magam is meg szoktam fogadni: Próbálja meg újraindítani!
Támogatónk: |
A bejegyzés trackback címe:
Kommentek:
A hozzászólások a vonatkozó jogszabályok értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a Felhasználási feltételekben és az adatvédelmi tájékoztatóban.
annmbp 2015.02.03. 10:18:48
Jómagam 2000 körüli ügyfelet kezelek, hibajegyek száma havi 15-20.
Giller Tamás 2015.02.03. 10:52:51
Én nem azt írtam, hogy 400 hibajegy van :), hanem ennyi bejövő hívás (nagy különbség). És igen 400 bejövő hívás van egy ekkora hálózatnál. Ez egy vállalatirányítási rendszer, amire havi szinten kb. 500-1000 fejlesztési óra (új igény, változtatás) kerül ki. Rengeteg újítás, fejlesztés. És az ügyfelek nem szeretnek használati útmutató olvasni, sokat kérdeznek. Vagy mert érdeklődnek, vagy mert egyszerűen elakadtak.
annmbp 2015.02.03. 11:22:09
wrstjnethn 2015.02.03. 14:14:51
"Kérem válaszát a 'Válasz Mindenkinek...' opció használatával küldje el Részünkre!"
Vagy részletesebb, jövőre nézve nevelő-magyarázó komment:
"Mivel a probléma megoldásán mostantól több kollégánk is dolgozik, kérem válaszát a 'Válasz Mindenkinek...' opció használatával küldje el Részünkre!"
Marketing válasz:
"Mivel a jelzett probléma mielőbbi megoldásán mostantól több szakemberünk is dolgozik, a gyors és hatékony problémamegoldás érdekében és a minőségbiztosítási rendszerünkben vállalt feldolgozási határidő betartásához kérem válaszát a 'Válasz Mindenkinek...' opció használatával küldje el Részünkre!"
Giller Tamás 2015.02.03. 14:27:56
kneissl 2015.02.03. 14:44:39
...biztos, hogy mindenki (minden potenciális olvasó) tudja azt, mit jelent az "SLA" ?
;-)
Giller Tamás 2015.02.03. 15:31:22
De ha a blog keresőjébe beírod, hogy SLA, akkor több cikket is kapsz eredményül, például ezt: erp-blog.blog.hu/2013/10/15/szerzodes_menedzsment_contract_management és ebben le van írva pontosan mi is az.
De röviden annyi a lényeg, hogyha leszerződsz egy informatikai szolgáltatásra valakivel, akkor szinteket állapítanak meg, például hibajavítás 1 órán belül, vagy 2 órán belül, vagy távolról elháríthatatlan hiba esetén 2 órán belül helyszíni kiszállás, stb. Nyilván minél jobb szolgáltatást kérünk, annál drágább a szerződés és így többe kerül a díj.
Remélem azért máskor is benézel hozzám :)!
pythonozok · http://visszabeszelo.blog.hu 2015.02.03. 17:21:54
(Anno üzemeltettem, az elején mi voltunk a helpdesk is)
Giller Tamás 2015.02.03. 20:50:49
Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:40:20
- Hehehe... szóval windows. Vagy Java. Én számítógépen dolgozom. Volt h egyszer rácsodálkoztunk egy tervezett áramszünetnél, hogy bazz, másfél éve hívtunk utoljára IPL-t.
Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:45:44
Komolyan az egyik első kérdés amit oktattak, hogy melyik gép előtt ül és az be van-e kapcsolva? :-))
Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:47:48
Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:58:28
De jó neked. Nekem csak mint renccer garázdának küldi a szupport másolatban a cuccost és kapok vagy százat naponta. Igaz eg része jogosulcság ügy, amihez közöm nincs.
mt-03 2015.02.04. 08:43:37
amiben minden benne van, az is hogy miket nyomkodott es oda hogy jutott el, rengeteg debug informacioval megspekelve. minel kevesebb plusz bekerincselendo info legyen az ugyfeltol (amikre raadasul soxor rosszul emlexik) mert ez van hogy inkabb megteveszt mint segit.
a hibauzenetink minidg ket halmazbol allnak, egyik a kultur ami megmondja emberi nyelven a usernek hogy mi a gixer, ha lehet beirom hogy mivel tudja megoldani (nem a helpre meg a user manualra mutogatok), e mellett van egy hatterinfo ami szamunkra info. mikor o a hibat elkuldi akkor ezt csak ugy tudja megtenni hogy az egesz infohalmazt elkuldi, nincs kimasolok egy darabot es csak azta, ez le van tiltva. altalaban a kepernyo menteseket is letiltom. az nem hibajegy hogy atkuld egy kepernyot. sot igazabol a kepernyomentest en keszitem el a hibauzenet feldobasa elotti pillantrl igy nincs letakart mezo sem. ezt osszedobom neki egy bejelento mailba es neki csak ra kell nyomnia a kuld gombra, esetleg irhat hozza meg rizsat.
hat ja a hatekony hibakaezeles mar onmagaban egy muveszet :)