Proč B2B technická podpora nesmí stát na e-mailech jednotlivců
U běžného zákaznického dotazu může e-mail fungovat naprosto bez problémů. Zákazník napíše, pracovník odpoví a tím je věc vyřešená. Jenže technická podpora v B2B prostředí bývá úplně jiný případ. Zákazník neřeší pouze jednoduchý dotaz. Může potřebovat nakonfigurovat konkrétní hardware, vyřešit problém s instalací, dohledat nastavení zařízení nebo oznámit výpadek systému. Takový požadavek může mít několik odpovědí, příloh, doplňujících informací a hlavně několik lidí, kteří se na jeho řešení postupně podílejí.
V takové chvíli začíná být problém, pokud celá historie zůstává v e-mailové schránce jednoho člověka. Technická podpora pak může fungovat dobře pouze do okamžiku, kdy je správný člověk dostupný. Jakmile má dovolenou, onemocní, změní pozici nebo jednoduše řeší jiný problém, začíná hledání informací nanovo.
Technická znalost firmy by neměla být uložená pouze v e-mailech jednotlivých techniků. Měla by zůstat u konkrétního zákaznického požadavku tak, aby se k ní mohl v případě potřeby dostat kdokoliv z týmu.
„Pošlete to kolegovi, on to řešil minule“
Tohle je jedna z vět, která v technické podpoře dokáže znamenat začátek zbytečně dlouhého hledání. Zákazník zavolá s problémem a pracovník podpory si vzpomene, že podobnou věc už někdy řešil kolega. Jenže kolega zrovna není u počítače. Nebo je na dovolené. Nebo si už přesně nepamatuje, jaké řešení tehdy použil.
Začíná hledání ve starých e-mailech. Prochází se sdílená schránka, hledají se klíčová slova, názvy zařízení nebo jména zákazníků. Někdy se správné vlákno najde během minuty. Jindy se objeví několik podobných případů a není jasné, který z nich je relevantní.
Samotný e-mail přitom není špatný nástroj. Problém je v tom, když se z něj stane jediné místo, kde existuje historie řešení technického problému.
Technický problém nekončí první odpovědí
U technického produktu málokdy funguje komunikace stylem „dotaz – odpověď – hotovo“. Zákazník může poslat fotografii zařízení, výrobní číslo, konfiguraci, chybovou hlášku nebo další informace. Technik následně požádá o změnu nastavení a zákazník odpoví, že problém stále trvá. Do řešení se může zapojit další kolega, který zná konkrétní hardware nebo software lépe.
Najednou máme komunikaci, která může trvat několik hodin nebo dní. A čím déle problém řešíme, tím důležitější je, aby všechny informace zůstaly pohromadě.
Pokud jsou jednotlivé odpovědi rozeseté mezi osobními schránkami, je velmi snadné ztratit souvislosti. Pokud jsou soustředěné v jednom tiketu, může se k nim nový řešitel vrátit a pokračovat tam, kde předchozí technik skončil.
Právě na tomto principu funguje EDA jako helpdesk. Zákaznické požadavky lze do systému dostávat automaticky z e-mailu nebo prostřednictvím formuláře a následná komunikace zůstává připojena ke konkrétnímu tiketu.
Co se stane, když technik odejde?
Tohle je možná nejméně příjemná otázka, kterou by si měla každá technická podpora položit. Co se stane s požadavky zákazníků, když člověk, který je běžně řeší, přestane být ve firmě?
Pokud jsou všechny informace uložené v systému tiketů, změna člověka nemusí znamenat ztrátu znalostí. Nový technik vidí historii požadavku, předchozí komunikaci a stav řešení. Může si projít, co zákazník poslal, co už bylo vyzkoušeno a na co se čeká.
Pokud ale většina komunikace probíhala pouze přes osobní e-mail a důležité informace byly navíc řečené po telefonu, firma může přijít nejen o člověka, ale zároveň o část historie, kterou během let vytvořil.
Odchod zaměstnance by neměl znamenat odchod historie zákazníka.
Co technická podpora získá, když požadavky řeší přes tikety?
Tiket není jen jiná forma e-mailu. Je to konkrétní záznam problému, který má svého řešitele, stav a historii.
1. Celá komunikace zůstává u jednoho požadavku
Zákaznické e-maily, odpovědi i přílohy mohou zůstat součástí jednoho tiketu. Když se k případu vrátí jiný technik, nemusí hledat jednotlivé části komunikace v několika schránkách.
2. Požadavek má svého řešitele
EDA umožňuje tikety přiřazovat konkrétním uživatelům nebo skupinám. Je tak jasné, kdo má daný problém řešit a kdo za něj odpovídá.
3. Je vidět stav řešení
Technický požadavek nemusí být pouze „vyřízený“ nebo „nevyřízený“. EDA umožňuje definovat vlastní stavy podle konkrétního procesu firmy. Může tak být například jasné, že se čeká na informace od zákazníka, řešení právě probíhá nebo je připravené k uzavření.
4. K problému se může vrátit celý tým
Pokud technik potřebuje pomoc kolegy, nemusí mu předávat celý případ znovu od začátku. Historie zůstává u tiketu a další člověk může pokračovat v řešení s dostupným kontextem.
Největší problém není množství e-mailů. Je to ztráta kontextu.
Ve velké technické podpoře může být e-mailů denně desítky nebo stovky. Samotný počet zpráv ale není hlavní problém. Důležité je, jestli z nich dokážete po několika týdnech nebo měsících znovu sestavit příběh konkrétního problému.
Zákazník například řeší konfiguraci zařízení. Technik mu pošle postup. Zákazník odpoví s fotografií zapojení. Technik zjistí další problém a předá případ kolegovi. Ten provede změnu konfigurace a požádá zákazníka o test. Zákazník se ozve o dva dny později.
V tu chvíli není důležité pouze to, co napsal v posledním e-mailu. Důležité je všechno, co tomu předcházelo.
Pokud je celá historie v jednom tiketu, stačí otevřít jeden záznam. Pokud je rozdělená mezi několik schránek, začíná detektivní práce.
Když zákazník odpovídá, systém už ví, kam odpověď patří
Jednou z praktických vlastností EDA je propojení zákaznického e-mailu s konkrétním tiketem. Zákazník přitom nemusí používat žádné nové rozhraní. Komunikuje běžně prostřednictvím svého e-mailu a jeho odpověď se automaticky přiřadí k již založenému tiketu.
Pro zákazníka se tedy způsob komunikace nemusí zásadně změnit. Změna probíhá hlavně na straně firmy. Místo toho, aby technik pracoval s jednotlivými zprávami jako s oddělenými e-maily, pracuje s celým požadavkem a jeho historií.
EDA podporuje také oboustranné zasílání příloh, takže fotografie, dokumentace nebo jiné soubory mohou zůstat součástí řešeného případu.
Technik nemusí být jediný člověk, který zná řešení
V technické podpoře je přirozené, že každý člověk má jiné zkušenosti. Jeden technik zná konkrétní typ zařízení, jiný se vyzná v síťové konfiguraci a další má zkušenosti s instalacemi. To není problém. Problém vzniká tehdy, když se znalost konkrétního zákazníka nebo produktu nikdy nepřenese do společného systému.
Pokud je řešení zaznamenané pouze v e-mailu jednoho technika, stává se jeho osobní znalostí. Pokud je uloženo u tiketu, může se stát součástí znalosti celého týmu.
To je důležitý rozdíl hlavně u produktů, které se konfigurují podle konkrétního zákazníka. Po několika měsících totiž nemusí být důležité jen to, jak se zařízení nastavuje obecně. Může být potřeba vědět, jak bylo nastavené právě u tohoto zákazníka a proč se určité nastavení použilo.
Historie řešení je užitečná i u problémů, které se opakují
Technická podpora často řeší problémy, které nejsou úplně nové. Stejný typ zařízení může mít podobnou chybu u několika zákazníků. Opakuje se určitý způsob konfigurace nebo se pravidelně objeví stejný problém po konkrétní aktualizaci.
Pokud jsou předchozí případy dohledatelné, nemusí technik pokaždé začínat od nuly. Může se podívat na předchozí řešení a použít ho jako podklad pro nový případ.
EDA umožňuje tikety filtrovat podle různých atributů, například projektu, řešitele, stavu, tagů nebo data vytvoření. Užitečná je právě možnost najít starší požadavky a pracovat s nimi jako s historií skutečných případů, které firma řešila.
Co když se požadavek přesune na jiného technika?
Předání požadavku je v technické podpoře běžná věc. Někdy je potřeba zapojit specialistu, jindy je původní technik vytížený nebo zákazník řeší problém, který patří do kompetence jiného člověka.
V e-mailu znamená předání často přeposlání celého vlákna. Jenže i v takovém případě může část kontextu zůstat mimo e-mail. Technik si může něco poznamenat do interního dokumentu, něco říct kolegovi po telefonu a něco si prostě pamatovat.
U tiketu může být samotný požadavek předán jinému řešiteli, aniž by se ztratil jeho obsah. Nový technik se dostane ke komunikaci, přílohám, stavu i dalším informacím, které byly v průběhu řešení zaznamenány.
Předání tak neznamená začít znovu. Znamená pokračovat v práci, kterou už někdo začal.
Technická podpora potřebuje vidět i to, co se právě neřeší
Další výhodou tiketového systému je přehled. U e-mailu vidíte především zprávy, které přišly. U tiketů můžete sledovat také stav požadavků, jejich řešitele a termíny.
EDA umožňuje například filtrovat otevřené úkoly po termínu nebo požadavky podle jejich dalších vlastností. Jednotlivé filtry je možné uložit a používat opakovaně. Vedoucí technické podpory tak nemusí procházet jednu společnou schránku a ručně odhadovat, co je ještě otevřené a co už bylo vyřešeno.
To je důležité zejména ve chvíli, kdy technická podpora neřeší deset požadavků měsíčně, ale desítky nebo stovky požadavků současně.
Historie pomáhá i vedení firmy
U technické podpory není důležitá pouze odpověď zákazníkovi. Firma potřebuje také vědět, kolik práce jednotlivé požadavky skutečně spotřebují.
EDA umožňuje u tiketů zaznamenávat čas strávený řešením. Z těchto údajů lze následně vytvářet statistiky a sledovat, kolik času zabírají jednotlivé úkoly nebo projekty. Pokud firma zároveň používá SYSDO, lze data o čase stráveném na tiketech propojit s evidencí pracovní doby a získat přehled o aktivitách zaměstnanců.
Najednou tak technická podpora není jen černá díra, do které přicházejí e-maily. Firma může získat přehled o tom, jaké požadavky řeší, kolik času zabírají a jak je vytížený tým, který se o ně stará.
Co se stane, když zákazník zavolá?
Telefonická komunikace samozřejmě nezmizí jen proto, že firma používá tiketovací systém. Zákazník může stále zavolat a vysvětlit technikovi problém po telefonu. Důležité ale je, co se stane potom.
Pokud telefonát zůstane pouze v hlavě technika, historie problému se znovu rozpadá. Pokud technik informace zaznamená k příslušnému tiketu, stávají se součástí případu a mohou s nimi pracovat i další členové týmu.
Právě v tom je důležitý rozdíl mezi „používáme e-mail“ a „máme systém pro technickou podporu“. Nejde o zákaz e-mailů. Jde o to, kam se informace z komunikace ukládají a jestli jsou později dohledatelné.
Technická podpora nemá být závislá na jednom člověku
Každá firma má své specialisty. Je normální, že některé problémy zná jeden člověk lépe než ostatní. Není ale dobré, aby byl jediným zdrojem informací o konkrétních zákaznících.
Jakmile se znalosti průběžně zapisují k jednotlivým požadavkům, firma postupně vytváří vlastní historii řešení. Ta zůstává k dispozici i ve chvíli, kdy se změní lidé v týmu.
Pro zákazníka je výsledkem především rychlejší pokračování v řešení. Nemusí pokaždé znovu vysvětlovat celý problém jen proto, že se jeho požadavku věnuje jiný technik.
Od e-mailu k systému, který si pamatuje
E-mail je skvělý komunikační nástroj. Není ale ideálním místem pro dlouhodobou správu technické podpory. Zvlášť pokud firma řeší konfigurace hardwaru, servisní požadavky, výpadky nebo jiné problémy, které mají historii a často vyžadují spolupráci více lidí.
EDA převádí tyto požadavky do tiketů, které lze přiřazovat konkrétním řešitelům, sledovat jejich stav, přidávat k nim komunikaci a přílohy a následně dohledávat jejich historii. Zákazník přitom může dál komunikovat běžným e-mailem.
Výsledkem není méně e-mailů. Výsledkem je méně informací ztracených v e-mailech.
A to je u technické podpory zásadní rozdíl. Protože když zákazník zavolá s problémem, nechcete hledat člověka, který „to určitě někdy řešil“. Chcete otevřít požadavek a vidět, co se stalo.
