Hogyan NE jelentsünk be hibát!

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.

tumblr_m7do1deqes1qa8nfxo1_1280.jpg

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!

 

 

 

 

logo_white_red_1.png

Támogatónk:
prodHost zrt.
Az okos vállalatirányítási rendszer 
Kis és gyártó vállalatoknak
www.prodHost.com

 

A bejegyzés trackback címe:

https://erp-blog.blog.hu/api/trackback/id/tr507079645

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

5-600 felhasználóból 400 havonta? Valami nagy baj lehet ennél a cégnél.
Jómagam 2000 körüli ügyfelet kezelek, hibajegyek száma havi 15-20.

Giller Tamás 2015.02.03. 10:52:51

Üdv!

É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

@Giller Tamás: áh, ok, így rendben van, ha folyamatosak a fejlesztések

wrstjnethn 2015.02.03. 14:14:51

4. pont: Ha ennyire gyakori, hogy az ügyfelek nem a válasz mindenkinek opciót választják, akkor ha választ várnak az ügyféltől, érdemes lenne a levél végére odabiggyeszteni, hogy:

"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

@wrstjnethn: ezek valóban jó megoldások! A probléma az, hogy már eleve fel kell hívni rá az emberek figyelmét, olyanokét is, akik számítógépes munkát végeznek :).

kneissl 2015.02.03. 14:44:39

Ha feltételezzük, hogy nem magadnak írod a blogot, hanem számítasz pár olvasóra, akkor ...pl ...
...biztos, hogy mindenki (minden potenciális olvasó) tudja azt, mit jelent az "SLA" ?
;-)

Giller Tamás 2015.02.03. 15:31:22

@kneissl: Üdv! Kicsit meglepődtem, hogy mi ez a hirtelen érdeklődés a blogon, aztán egy olvasó mutatta, hogy a blog kikerült az Index2 címoldalra. Így nyilván több olyan olvasó is rákattintott, akik eddig nem jártak itt :), aminek nagyon örülök!!! A blogot - remélem - nem csak magamnak írom, de az SLA - Service Level Agreement (Szolgáltatási szintekről szóló megállapodás), már annyi cikkben és írásban megjelent, hogy ebbe nem írtam már le hogy micsoda, mert valóban a törzsolvasók tudják (nem tudtam, hogy Index2 címlap lesz :)).

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

@Giller Tamás: a cím nálam kiverte a biztosítékot. Azt hittem, valamelyik "telko" szolgáltató helpdeskesének nyavalygását kell majd olvasni. Már épp készültem pár cifra válasszal, de így, hogy majdnem kolléga... :)
(Anno üzemeltettem, az elején mi voltunk a helpdesk is)

Giller Tamás 2015.02.03. 20:50:49

@pythonozok: Örülök, hogy megváltozott a véleményed :). De a hozzászólásoknak mindig örülök, én nem vagyok letéteményese a biztos tudásnak. Én csak tapasztalok sok mindent és azt leírom :). A lényeg az lenne, hogy ne csak én írjam le :) hanem ti is!

Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:40:20

"És minden hibaleadás előtt egy tanács, amit én magam is meg szoktam fogadni: Próbálja meg újraindítani!"
- 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

Én még a 90-es évek elején voltam tanfolyamon, hogy kell kezelni a felhasználókat, a nyikorgó "ljuzereket".
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

Aztán tényleg volt ilyen. Én rendszergarázda voltam, nem szupportos, de én hülye felvettem egy telefont. Egy nagyhatalmú csávó üvöltött velem, hogy szar minden és nem megy. Kiderült - több rendszer is volt biztonsági okok miatt, teljesen elkülönült hálózatban - hogy a másik rendszernél próbálkozott. :-)

Kurt úrfi [teuto-nordikus parasztlegény] 2015.02.04. 06:58:28

@annmbp: "hibajegyek száma havi 15-20. "
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

mivel tobbek kozt en magam irom a rendszerunket, ezert a hibajegyek beerekezesenel arra tudok tamaszkodni amit magamnak a hibajelentesben elhelyezek (szerencsere ugyfellel kozvetlenul nem nagyon beszelek, nem is szeretek;). ez sztem nagyon fontos dolga a programozonak hogy olyan hibat legyen kepes kikopni a rendszer amibol o hozzaadott info nelkul meg tudja oldani az ufsz a hibat. pl itt emlitett dolgok kozul nem a felhasznalotol varom hogy a szamlaszamot vagy barmifele azonositot megmondjon. ezeket beteszem a hibauzenetbe. de ezen kivul ezer mas hasznos infot is, sot olyan hibastacket hasznalunk
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 :)

Macher Judit

macher_judit.jpg

Magamról

Macher Judit vagyok, a Macher Gépészeti és Elektronikai Zrt. második generációjának tagja. A szüleim által 30 éve indított, bérmunkával foglalkozó Bt-ből mára egy közel 100 főt foglalkoztató integrátori szerepkört is ellátó Zrt. lettünk. Az innovatív megoldásokra való nyitottság mindig is jelen volt cégünk életében, így lettünk Magyarország öt Mintagyárának egyike. Ennek kapcsán számos céggel osztottuk meg a tapasztalatunkat a digitalizációval kapcsolatban, mely során mi is rengeteget tanultunk. Ezzel a bloggal az offline térből az online térbe tesszük át a párbeszédet a legújabb technológiákról (elsősorban az ERP-k területén), és az egymástól való tanulás lehetőségét. Időről időre olyan szakértőket kérek fel tapasztalataik megosztására, akiktől hiszem, hogy sokat tanulhatok, tanulhatunk.

Facebook

Elérhetőség

Ha kapcsolatba szeretnél velem lépni, mert véleményed van, meg akarsz osztani velem valamit, segítségre van szükséged, akkor ne habozz, írj nekem!

macherjudit@gmail.com 

Friss topikok

Kiemelt partnerek

 
logo_white_red_1.png

 prodHost Zrt.
Az okos vállalatirányítási rendszer

 

macher.jpg

MACHER Gépészeti és Elektronikai Zrt.

 

Partnerek

 

 cmo_logo.png

 

  

corvinus-logo-400x280.jpg

 kulcs.png

 hrp_logo_new-1024x552.png

 

 sclogo.png

 

 graphit_logo_1.jpg

www.erpblog.hu

Macher Judit vagyok, a Macher Gépészeti és Elektronikai Zrt. második generációjának tagja. A szüleim által 30 éve indított, bérmunkával foglalkozó Bt-ből mára egy közel 100 főt foglalkoztató integrátori szerepkört is ellátó Zrt. lettünk. Az innovatív megoldásokra való nyitottság mindig is jelen volt cégünk életében, így lettünk Magyarország öt Mintagyárának egyike. Ennek kapcsán számos céggel osztottuk meg a tapasztalatunkat a digitalizációval kapcsolatban, mely során mi is rengeteget tanultunk. Ezzel a bloggal az offline térből az online térbe tesszük át a párbeszédet a legújabb technológiákról (elsősorban az ERP-k területén), és az egymástól való tanulás lehetőségét. Időről időre olyan szakértőket kérek fel tapasztalataik megosztására, akiktől hiszem, hogy sokat tanulhatok, tanulhatunk.

Search Clear

süti beállítások módosítása