Kde ve firmě vzniká CX a proč to není jen práce podpory

CX, zkratka anglického customer experience, označuje celkovou zkušenost zákazníka s tím, co firma slíbí, dodá, zkomplikuje nebo napraví.

CX vzniká dřív než požadavek na podporu

Zákaznická zkušenost začíná ve chvíli, kdy člověk hledá informace. Pokračuje při vyplňování formuláře, čekání na nabídku, podpisu smlouvy, převzetí služby i placení faktury. Podpora je jen jedním místem na této cestě a často řeší až následek dřívější chyby.

Zákazník se už 3. ptá na termín, protože obchod slíbil datum, realizační tým o něm neví a v systému chybí úkol. Podpora odpoví rychle a zdvořile. V danou chvíli pomůže, ale příčinu neodstraní. Stejný dotaz proto brzy položí někdo další.

CX tedy nepatří pouze oddělení podpory. Obchod ovlivňuje srozumitelnost a splnitelnost slibu. Provoz odpovídá za dodání, finance za správnost dokladů a vývoj za použitelnost formuláře. Vedení rozhoduje, zda firma opakovanou chybu odstraní u zdroje, nebo na její řešení přijme dalšího člověka. Nový pracovník však příčinu chyby sám neodstraní.

Pomoci může CRM systém, tedy společné místo pro kontakty, dohody a navazující kroky. Samotné pořízení systému ale nic nespraví. Musí být jasné, kdo zapisuje slíbený termín, kdo za něj přebírá odpovědnost a jaký postup následuje, když ho nelze dodržet.

Na čem CX poznám v praxi

Nejdřív nehledám skóre spokojenosti, ale zbytečnou práci zákazníka. Musí znovu poslat adresu, dohledat číslo smlouvy, připomenout slíbený telefonát nebo vysvětlit stejnou věc 2krát?

Dalším signálem je rozdíl mezi interním stavem a skutečným výsledkem. Požadavek může být v helpdesku, tedy systému pro evidenci dotazů, označený jako vyřešený. Zákazník přitom stále nemá opravenou fakturu. Interně je případ uzavřený, ale problém trvá.

Pro první rozbor nepotřebuji rozsáhlý průzkum ani nový software. Postupuji takto:

1. Vyberu 1 konkrétní cestu, například dobu od přijetí nabídky po vystavení první faktury.
2. Projdu posledních 20 dokončených případů. Pracuji se skutečnými e-maily, úkoly a doklady, nikoliv s modelovým procesem z prezentace.
3. U každého případu zapíšu jednotlivé kroky, odpovědnou osobu, dobu čekání a údaje, které musel dodat zákazník.
4. Označím opakované dotazy, ruční přepisování, předávání mezi týmy a nesplněné termíny.
5. Vyberu 1 závadu, určím vlastníka změny a po 4 týdnech znovu porovnám stejné typy případů.

Měřím hlavně to, co lze změnou procesu ovlivnit. Vhodná je celková doba vyřízení, počet předání mezi lidmi, počet žádostí o doplnění údajů, počet oprav nebo opakovaný kontakt do 7 dnů. Pro jeden proces zpravidla stačí 2 ukazatele. Větší množství grafů může ztížit rozpoznání konkrétního problému i vyhodnocení změny.

Dotazník spokojenosti může doplnit souvislosti, ale nenahradí provozní data. Zákazník může dát podpoře hodnocení 5 z 5, protože pracovník ochotně opravil chybný doklad. Takové hodnocení vypovídá o práci podpory, nikoliv o celé zkušenosti, jejíž součástí byla i chyba ve faktuře.

Kdy má řízení CX smysl a kdy ne

CX začínám řídit systematicky ve chvíli, kdy se stejná překážka opakuje ve více případech nebo kvůli ní musí zasahovat alespoň 2 části firmy. Typickým signálem jsou dotazy na stav zakázky, opakované opravy údajů, rozdílné informace od obchodu a podpory nebo rostoucí počet výjimek řešených ručně.

Samostatný CX projekt naopak nemusí dávat smysl tam, kde za měsíc vzniknou 3 požadavky a každý má jasného vlastníka. V takové situaci bych místo nové role zavedl 30minutový týdenní rozbor posledních 5 případů. Zbytečná je také podrobná mapa zákaznické cesty, pokud je příčina známá. Nefunkční formulář potřebuje opravit. Jeho zakreslení do mapy problém neodstraní.

Bez možnosti měnit procesy nemá cenu sbírat další zpětnou vazbu. Pokud se připomínky pouze třídí a posílají mezi odděleními, vzniká další interní fronta bez odpovědnosti za nápravu.

S čím se CX nejčastěji plete

Zákaznická podpora řeší konkrétní požadavky. CX zahrnuje také situace, kdy zákazník podporu vůbec nekontaktuje. Může nedokončit objednávku, nerozumět nabídce nebo odejít po další chybné faktuře. Takové případy se do evidence podpory vůbec nedostanou.

UX, tedy uživatelská zkušenost s webem nebo aplikací, je také jen jednou částí CX. Formulář může být snadný na ovládání, ale pokud po jeho odeslání nikdo 4 dny nereaguje, dobré UX nezachrání celou zákaznickou zkušenost. Podobně spokojenost zachycuje názor v určité chvíli, nikoliv celý postup, který k němu vedl.

CX není ani automatizace. API, tedy rozhraní pro předávání dat mezi aplikacemi, může odstranit ruční přepisování. Nejdřív však musí být jasné, která aplikace obsahuje správný údaj a co se má stát při chybě. Proto si před integrací pokládám 5 otázek k propojení systémů. Automatizace chybně nastaveného procesu pouze urychlí předávání nesprávných údajů.

V jednom rozboru nevznikal opakovaný dotaz na termín faktury kvůli práci podpory. Obchod nezapsal fakturační kontakt, realizace neoznačila předání a účetní systém čekal na údaj bez určeného vlastníka. Řešením nebylo školení podpory, ale 2 povinná pole, jedno předání a jasný postup pro výjimku. Po těchto změnách už zákazník nemusel zjišťovat, které oddělení má dodat chybějící údaj a kdo odpovídá za vystavení faktury.