Każdy użytkownik chciałby aby gdy pojawią się problemy z działaniem usługi, aplikacji, rozwiązania IT, mógł liczyć na kompetentną i szybką pomoc. Czy takiemu oczekiwaniu trudno sprostać? Okazuje się, że nie jest to trywialne zadanie i nie każdy zespół wsparcia, serwisu, utrzymania poradzi sobie z nim w satysfakcjonujący sposób. Na czym polega ta trudność? Co jest takiego szczególnego i będącego wyzwaniem w świadczeniu serwisu, czym nie każdy serwis będzie mógł się pochwalić?

Błędy, awarie, incydenty, problemy

Nie ma i w najbliższym czasie nie będzie systemu IT, który działa bezbłędnie. Każde, nawet najlepiej przetestowane rozwiązanie IT, po wdrożeniu na produkcję, będzie wymagało wsparcia dla użytkowników. Wręcz tendencja jest odwrotna. Użytkownikom udostępniane są usługi IT, które z definicji nie są dokończone aby to użytkownik „w boju” sprawdził rozwiązanie i zgłosił błędy i niepoprawne działanie. Co raz więcej mamy systemów w wersji beta, które są oddawane do użytkowników aby je testowali, tzw testowanie przez używanie. Z tego powodu, informacją zwrotną od użytkowników są zgłaszane incydenty i problemy. Użytkownik nawet rozumie, że coś może się zepsuć, nie działać lub funkcjonować niepoprawnie. Jednocześnie jednak oczekuje, że zgłoszone problemy zostaną rozwiązane, tak aby mógł korzystać z danego systemu, aplikacji, rozwiązanie i wykonywać swoje codzienne obowiązki. Aby to się działo w sposób uporządkowany, dobrze jest mieć ustalone SLA dla obsługi zgłoszeń, nie wspominając o ustalonych praktykach i narzędziach, które pomogą obu stronom: użytkownikowi i IT.

SLA

Dla uruchomionych na produkcji rozwiązań informatycznych, powinniśmy mieć zdefiniowane w katalogu usług, usługi oraz poziom ich świadczenia czyli SLA. W zakresie SLA powinno być ustalone, w jaki sposób użytkownik zgłasza pojawiające się niesprawności oraz jak szybko zespół wsparcia naprawi te niesprawności. Dwa parametry SLA są tutaj kluczowe: czas reakcji i czas naprawy. Dla obu powinniśmy mieć zdefiniowane wartości dopuszczalne, czyli po jakim czasie zgłoszenie zostanie potwierdzone oraz po jakim naprawione. Oczywiście użytkownik chciałby aby te czasy były jak najkrótsze a IT aby były jak najdłuższe. Musimy znaleźć kompromis pomiędzy tymi dwoma podejściami. Skracanie tych czasów aby uzyskać przewagę konkurencyjną a później ich nie dotrzymywanie, nie będzie z korzyścią dla nikogo. Czy jednak dobrze zdefiniowane wartości SLA dla obsługi serwisowej są wystarczającym warunkiem aby uzyskać satysfakcję użytkownika? Okazuje się, że nie koniecznie. Dostawca może spełniać wymagania SLA zawarte w umowie a użytkownik nie będzie zadowolony, ze świadczonych usług serwisu.

Przyczyny

Jakie mogą być przyczyny takiego stanu rzeczy? 

• Po pierwsze, sam fakt że błędów jest bardzo dużo może powodować irytację użytkownika i rozwiązywanie ich zgodnie z SLA nic tu nie zmieni.
• Po drugie, wartości dopuszczalne czasu reakcji i naprawy mogą być za duże, co oznacza, że użytkownik za długo czeka na rozwiązanie zgłoszonego problemu.
• Po trzecie, niska jakość świadczonych przez zespół wsparcia usług serwisowych. Nie mam tu na myśli SLA, tylko sprawy związane z komunikacją, uprzejmością, zrozumieniem, pomiędzy użytkownikiem i serwisem.

Zapewne przyczyn można podać więcej. Ja wskazuję te według mnie najważniejsze. Co więc zrobić aby użytkownik lepiej postrzegał IT i osoby, które wspierają go w rozwiązywaniu błędów?

Rozwiązania

Na pewno pomoże większa koncentracja przy tworzeniu rozwiązania IT. Należy już u źródła spowodować, że będzie popełniane mniej błędów, które później wpływają na pracę użytkownika. Można spróbować zweryfikować parametry SLA i dostosować je do oczekiwań użytkownika oraz możliwości IT. Jednak te działania mogą nie przynieść zamierzonego wyniku. Co więc jeszcze możemy poprawić? Obsługa serwisowa wymaga kontaktu pomiędzy użytkownikiem a pracownikiem zespołu wsparcia. Kontakt ten może być telefoniczny, przez komunikator, chat, mail, narzędzie klasy ITSM. Niezależnie jaka to będzie forma kontaktu, po obu stronach są ludzie i powinni umieć się „dogadać”. Nie musi to być wcale takie proste. Osoby w zespole wsparcia to techniczni guru, którzy znają się bardzo dobrze na rozwiązaniu IT ale już z komunikacją mogą mieć problemy.

Przyjacielski serwis

Potraktujmy użytkownika jak naszego przyjaciela. Na co można liczyć w przypadku przyjaciela?

• Na pewno na empatię. Osoby z zespołu serwisu muszą podejść ze zrozumieniem i szczególną uwagą do problemów zgłaszanych przez użytkownika, którego nie można traktować jako zło konieczne i naszego wroga. Wręcz przeciwnie to biznes, którego użytkownik jest przedstawicielem, płaci nam za świadczone usługi wsparcia. Wejście w buty użytkownika, na pewno zmniejszy dystans pomiędzy użytkownikiem a IT.
• Niezależnie co się dzieje, pracownik zespołu serwisowego musi być uprzejmy dla użytkownika. Wiadome jest, że użytkownik może być zdenerwowany występującym błędem, ponieważ uniemożliwia mu on wykonanie określonej czynności. Nie można pod żądnym pozorem być nie miłym dla użytkownika, nawet jeżeli on jest niemiły w stosunku do serwisu. Należy uspokajać sytuację a nie ją jeszcze nakręcać. Trzy proste słowa proszę, przepraszam, dziękuję mogą zdziałać cuda, a nie wymagają żadnego szkolenia i dużego nakładu sił.
• Słuchać, słuchać, słuchać. Umiejętność aktywnego słuchania, pomoże w zrozumieniu potrzeb użytkownika i przyczyni się do budowania relacji pomiędzy użytkownikiem a IT.
• Otwartość i elastyczność na wyrażane potrzeby. Nie zamykajmy się w sztywnych ramach SLA i obowiązujących umów, tylko wykażmy się inicjatywą i zaangażowaniem.

Czy serwis może być przyjacielski. Może. Czy łatwo jest to osiągnąć. Niestety trudno ale nie znaczy, że jest to niemożliwe. Wymaga to dużego zaangażowania kierownictwa w ustalenie strategii i konsekwentne jej realizowanie. Jeżeli nawet nie mamy ludzi z takimi umiejętnościami to można się ich nauczyć. Potrzebne są szkolenia, warsztaty a może nawet specjalny program, który na kilka miesięcy, a może nawet lat rozpisze działania, które są wymagane aby użytkownik zaczął postrzegać wsparcie serwisowe jako swojego przyjaciela a nie geeka i nerda z IT, z którym kontakt to najzwyklejsza męczarnia i katorgi. Takiego podejścia i przyjacielskiej relacji życzyłbym sobie w każdej organizacji, która świadczy wsparcie w obsłudze serwisowej.