Centralizace komunikace

Konkrétní firma - možná trošku netypická, ale podstata je všude stejná. Fungují jako zprostředkovatel nebo možná integrátor mezi tisíci zákazníků (po celém světě) a stovkami subdodavatelů. Denně dostávají a odesílají vyšší stovky až tisíce zpráv elektronické pošty. Desítky lidí v obchodní administrativě.

Už dřív přišli na to, že pro komunikaci se zákazníky není možné používat osobní schránky jednotlivých spolupracovníků. Vytvořili tedy několik sdílených schránek podle toho, jaká skupiny (útvar) se měla kterému typu zpráv věnovat. Což není právě účelný princip. Život si nezjednodušili, ale zkomplikovali. Aby se s tím vyrovnali, vymýšleli komplikovaná pravidla a organizaci práce (týmů). Potom přišel COVID a bylo nutno počty pracovníků výrazně redukovat. Tím se vše ještě zhoršilo.

Museli si přiznat, že externí partneři nebudou vždy ukáznění. 

Více schránek je peklo. Téměř každý pracovník administrativy je téměř všechny prochází a složitě si značkuje, které zprávě se již věnoval. Občas to zapomene zaznamenat. Ne všichni jsou schopni vyřizhovat všechny typy zpráv (požadavků). Takže jednu a tutéž zprávu, kterou nevyřídí Tonda, si otevře Zuzana, zjistít, že ji taky neumí vyřídit, tak ji opět nechá být. Absolutní zmar a zkáza.

Pokusili se vytvořit nezávislou aplikaci, do které se měly přebírat zprávy ze všech schránek a tam uspořádávat tak, aby se dostaly ke správným lidem. Po dvou letech spolupráce s poměrně renomovanou vývojářskou firmou (jen na specifikaci řešení) to vzdali.

Protože vyrážet klín klínem není řešení.

Korektní (jediný rozumný) způsob zpracování příchozí a odchozí firemní komunikace (nejen elektronické pošty) je respektovat realitu. 

Zprávy doručovat do jediné schránky

Nemůžete si dovolit aby:

• Spolupracovníci byli s externími subjekty v kontaktu prostřednictvím osobních adres.
• Aby měli "své" zákazníky či dodavatele. Při interakci se kýmkoli musí každý člověk u každé události evidovat informace a naplánovat pokračující činnosti tak, aby v komunikaci mohl kdykoli pokračovat jiný spolupracovník.
• Aby data (a přílohy) zůstávala ve zprávách elektronické pošty nebo v hlavách lidí, takže kdykoli je potřeba v dané záležitosti něco řešit, musí se hledat a znovu číst příslušná zpráva.
• Aby nebylo ověřitelné, jak/kdy/kým byla přijatá zpráva odbavena.

Pracovník má mít jenom jeden seznam zpráv/úkolů, kterým se má věnovat. Optimálně seřazený podle naléhavosti (typicky význam zákazníka/události nebo explicitní klasifikace). Lze vést nekonečnou diskusi o tom, jestli je lepší jediná sdílená schránka na firmu nebo je lepší mít jich více (dle izolovaných týmů... dřív nebo později také zjistíte, že z logiky věci ty týmy nebudou nikdy dostatečně oddělené a že "všechno souvisí se vším"). Je ale zbytečná - je potřeba to vyzkoušet a přizpůsobit reálným podmínkám. Přesněji - pokud neexistují nezvratné důvody pro více schránek, správný počet je jedna.

Např. pokud je firma tak malá, že na veškerou administrativu jsou dva či tři pracovníci, je rozhodně účelné, když mají všichni jedno prostředí právě proto, aby si mohli pomáhat. V jedné střední firmě mají takové špičky v přijímání objednávek (tak nastavené dodací lhůty), že je potřeba, aby všichni administrativní pracovníci každý den na čas odložili svoji práci a zpracovávali objednávky - tam je to ale řešeno tak, že se dočasně přihlásí do obchodního systému. Navíc všichni umí všechno, není potřeba práci přidělovat.

V různých situacích a čase může vyhovovat pokaždé něco jiného. Rozhodně však nelze zapomínat na ochranu informací a řízení přístupu a výkonu.

Přijaté zprávy klasifikovat

Jednoduše. Ihned při jejich doručení (automatizovaně na serveru).

• Pokud je to zpráva v existujícím vlákně (odpověď na dříve odeslaný vlastní mail nebo je jinak identifikovatelná záležitost, které se zpráva týká - např. číslem zakázky, specifickým klíčovým slovem v kombinaci se zákazníkem apod.), propojí se s danou záležitostí. U té je také definováno (šablonou předchozího zpracování a stavem záležitosti), kdo by se takovéto zprávě měl věnovat, odvodí se její naléhavost atd.
• Když nelze identifikovat záležitost, dohledá se podle adresy odesílatele existující zákazník. U něj jsou definovány analogické údaje potřebné pro klasifikaci zprávy. Nabízí se přiřazení k některé ze stávajících záležitostí nebo vytvoření nové. Když adresu odesílatele nelze najít, je automaticky vytvořen nový kontakt (který musí zpracovávající pracovník doplnit, popř. přiřadit existujícímu zákazníkovi, pokud má odesílatel jinou doménu).
• Případně klasifikaci může ovlivnit adresa příjemce - např. pokud někdo píše na adresu <reklamace@firma.xy>, lze určit, o co se asi jedná a lze nastavit, komu má být přidělena. Podle identifikovaného partnera lze někdy dohledat obchodní případ a pokusit se reklamaci (či cokoli jiného) přidělit člověku, který zakázku vyřizoval.

Záležitost je univerzální "spojka" mezi komunikačními vlákny a obchodními případy ať už v prodeji či nákupu nebo projekty, investicemi, personálními záležitostmi, sjednáváním úvěru nebo daňové kontroly. Nebo několika takovýchto věcných případů, které spolu spouvisí (typicky zakázka, která vyžaduje subdodávky nebo nákup materiálu). Logika věci říká, že neexistuje komunikace, která není přiřazena některé záležitosti. Ty lze následně sledovat a vyhodnocovat.

• Zpráva je tedy automatizovaně identifikována. Je určeno, kdo (který tým) se jí má věnovat. O kterého se jedná externího partnera. O jakou záležitost.
• Prostřednictvím porovnání klíčových údajů se šablonami je předběžně navržen její typ. Např.
  • Nová poptávka.
  • Objednávka.
  • Reklamace.
  • Požadavek.
  • Výzva k <xxx>.
  • Faktura dodavatele.
  • Nabídka dodavatele.
  • ...
• Pokud je známa záležitost a typ, je součástí také předchozí a pravděpodobný nový stav záležitosti (množina možných), který může pomoci při podpoře odpovědi.

Přidělovat konkrétním pracovníkům dle kvalifikace

Jelikož se jednotlivé záležitosti mohou výrazně lišit v požadavcích na kvalifikaci lidí (např. zákazník vyžaduje produkt ~ výrobek či služba ~ pro jehož specifikaci a zajištění je nutná specifická odbornost, kterou nemohou a nemají mít všichni pracovníci zákaznického servisu), pro každou zprávu se (automatizovaně nebo ručně) určí požadavek na způsobilost. Ten slouží jako parametr pro výběr skupiny či jednotlivce ke zpracování.

• Zpráva určená skupině se zobrazuje všem členům týmu do okamžiku, než si ji některý z členů týmu převezme ke zpracování (pokud se zprávy zobrazují v režimu "všechny čekající" - v některých režimech zpracování může být užitečné, aby člověk viděl, kolik položek ještě čeká. Jiný přístup říká, že člověk má dostat bezprostřední úkol a o dalším se má dozvědět, až splní ten aktuální.
• Při přiřazování zpráv s nejnižšími požadavky na způsobilost pracovníka se musí preferovat ti, kteří mají nejnižší kvalifikaci, aby byly chráněny vzácnější zdroje.
• Bylo by možné nechat lidi, aby si zprávy "vybírali", ale pokud přistoupíme na to, že se jim nemají zobrazovat ty, pro které nemají potřebnou kvalifikaci, tak je to zbytečné.

Mají vyřizovat jednu zprávu za druhou.

Pokud lidé konkrétní zprávu nemohou zpracovat (ať už vzhledem k nesprávně stanovenému požadavku na kvalifikaci nebo z osobních příčin), musí by uvést důvod a zpráva se předá koordinátorovi, který stav zprávy / nároky na zpracování potvrdí a určí nejvhodnějšího zpracovatele. Pokud je někomu přidělena zpráva na základě nesprávného stanovení požadavků, dotyčný by ji měl překlasifikovat (popř. předat koordinátorovi) a vrátit k novému přiřazení. Klasifikace případů a zákazníků je v takovéto situaci poněkud náročnější, ale vyplatí se.

Přílohy ukládat a nahrazovat odkazy

Ve zmiňované firmě byly přílohy masívní. Naprostá většina z obrovského objemu dat, který se musel synchronizovat na mnoho počítačů současně. Navíc se obsah sdílených schránek neustále modifikoval - nejen nově příchozími zprávami, ale zásahy mnoha uživatelů současně. Není divu, že to bylo příšerně pomalé.

Příchozí přílohy tam, kam patří. Např.

• Přijatá faktura či nabídka dodavatele by se asi měla zkusit vytěžit a automatizovaně zaúčtovat, pokud to jde. Nebo alespoň získaná data zaznamenat do provozních evidencí tak, aby se příslušná data (např. potvrzení dodávky) dostala tam, kde jsou potřeba.
• Podepsané smlouvy a podobné tam, kde mají být.
• Poptávka z webu nebo poptávkového portálu automatizovaně zpracovat.
• Data, která posílá zákazník ke zpracování zakázky (např. podklady pro grafiku), uložit do úložiště asociovaného s danou zakázkou a přejmenovat v souladu s konvencemi.

Nahradit přílohu ve zprávě odkazem na uložený soubor. Ve schránce nebudou žádné přílohy. Výrazně se jí uleví.

Pokud odesíláte data, mělo by to být prostřednictvím odkazu, přes který se příjemce dostane k souboru na cloudovém úložišti. Když to musí být příloha, tak je rozumné ji po odeslání nahradit odkazem na původní zdrojový soubor (pokud se tato data budou upravovat, musí existovalt pouze jediná verze... jak často se stává, že se upraví dokument otevřený z přílohy a k jakým zmatkům to vede). Po odeslání zprávy je nezbytné dotyčný soubor ochránit proti neřízeným úpravám (což lze mnohem snáze zajistit v souborovém úložišti než v příloze - je ideální, když je to na tom sdíleném úložišti).

Data patří do databáze

Zpracování zprávy člověkem znamená:

• Potvrdit či korigovat její přiřazení (partner, záležitost, typ, stav).
• Do záležitosti (a jejím prostřednictvím do odpovídajícího provozního systému, pokud je to potřeba a možné) převést (či potvrdit, pokud se podařilo vytěžit) ze zprávy údaje - termín, množství, cenu apod. Když se zákazník pouze na něco ptá, otázku najít a pomocí šablony poslat odkaz na odpověď. Pokud je to něco dosud nezodpovězeného, zajistit odpověď, uložit ji do katalogu a totéž.
• Udělat to, co odesílatel očekává - tedy např. k poptávce vytvořit nabídku (pokud možno automatizovaně/průvodcem) a tu odeslat jako přílohu či odkaz odpovědí na původní zprávou, vytvořenou pomocí šablony. Nebo v případě objednávky (automaticky) zjistit stav obchodního úvěru zákazníka a informovat jej (pomocí zprávy generované s využitím odpovídající šablony) o tom, že nejdříve musí zaplatit dosud nezaplacené faktury po splatnosti a které to jsou (dle nastavení či volby lze danou objednávku jako latentní obchodní případ vytvořit a čekat, až se stav pohledávek změní, nebo dotyčného informovat o tom, že danou objednávku nelze přijmout).
  Místo, kde jsou obrovské příležitosti pro skutečnou automatizaci. 
• Tím zprávu "uzavřít" a odstranit ze složky přijaté pošty.

Minimálně ze seznamu zpráv k vyřízení. Pokud jsou objemy opravdu obrovské či spíše pokud sdílenou složku využívá hodně spolupracovníků, je lepší se vyvarovat jakýchkoli změn, které by vedly k neustálé synchronizaci. Takže se zprávy dají přesunout až mimo pracovní dobu, nejlépe do jiné sdílené schránky.

Nebo se sdílená schránka vůbec do lokálního klienta nepřipojuje a pracuje se s ní vzdáleně (webový klient, popř. nadstavba, která umožní zpracování bez zobrazení / synchronizace schránky). Což má své výhody, ale i nevýhody (nižší komfort než u desktopového klienta, i když dnes je to sporné).

Odvozovat úkoly

Zpracování zprávy může být náročnější nebo má reakce více fází. Bezprostřední reakcí je potvrzení přijetí a informace o dalším postupu. Teprve následně se např. položí upřesňující zpáteční dotaz, popř. získávají podklady či součinnost odjinud. 

• Je zřejmé, že stav zprávy není totožný se stavem případu. Případ (může to být samostatná záležitost nebo její součást) existuje nezávisle na iniciační zprávě. Byť je propojen s ní či spíše všemi souvisejícími zprávami a úkoly.
• V takovém případě je možné zprávu považovat za vyřízenou (relevantní informace byly převzaty do případu/záležitosti) a lze ji odstranit ze seznamu zpráv ke zpracování (ze složky Doručená pošta). Samozřejmě je možno se k ní kdykoli jednoduše vrátit.
• Výjimečně může dojít k tomu, že nelze práci, kterou je v reakci na zprávu potřeba udělat, převést na úkol / záležitost (např. některý kritický údaj chybí). Většinou by se to mělo dát řešit obratem, ale může se to protáhnout. Tehdy zpráva zůstává "rozpracovaná". Již není v seznamu ke zpracování pro ostatní členy příslušného týmu, ale zobrazuje se jako první tomu, kdo její zpracování nedokončil.

Sofistikovaný filtr dle uživatelů, skupin a způsobilostí je jedním z důvodů, proč je lepší použít nadstavbu a nepracovat přímo v prostředí poštovního klienta. Pro  rutinní zpracování typizovaných zpráv je to správná volba i z hlediska ergonomie.  

Představte si to tak, že se pro (první) zprávu na seznamu spustí průvodce. Ten si

• Nechá potvrdit typ zprávy.
• Načte šablonu pro zpracování daného typu interakce/zprávy. Ta obsahuje uživatelsky definovatelný seznam atributů včetně vzájemných závislosti + případné schéma výskytu potřebných údajů ve zprávě (těch může být více podle partnera, pokud pro něj došlo k upřesnění typického vzoru). 
• Pokusí se (pokud v šabloně existuje příslušné schéma) vytáhnout ze zprávy data (rozumí se použitím regulárních výrazů a obdobných mechanismů).
• Podle šablony si vyžádá potvrzení/zadání údajů.
• Podle hodnot významných položek se nabízejí následné kroky průvodce a potom akce (workflow)...
• ...až je to hotové, zobrazí následnou zprávu se všemi dohledanými údaji.

Říkáte, že to nejde / nevyplatí se❓ A co to zkusit?
Jistě, je potřeba mít kompatibilní provozní systém - např. nabídky či správu zakázek... Pokud zatím žádný nemáte (nebo potřebujete vyměnit), tak jej takto můžete získat (protože data pro správu zákazníků, zakázek, dodávek a dodavatelů tak jako tak musí systém umět zpracovávat a udržovat konzistentní v životních cyklech podporovaných záležitostí). Pokud ten váš má API, není problém.

Odpovídat pomocí šablon

Pokud je znám typ zprávy a stav záležitosti, je snadné odpovědi automatizovat. Nejen odpovědi. I nově vytvářené zprávy mají být generovány - tím se zajistí, že mají všechny součásti a náležitosti & hlavně data, na základě kterých byly vytvořeny, jsou k dispozici ve strukturované podobě.

• Pokusem o odpověď se spustí průvodce. Nebo uživatelé mají k dispozici nadstavbu, která přímo funguje jako průvodce danou záležitostí. Uživatel vybírá z předdefinovaných možností, popř. zadává vyžadované hodnoty.
• Data, pomocí kterých byla zpráva vytvořena, jsou uložena v příslušném systému/databázi (minimálně v záznamech dané záležitosti).
• Každá odchozí zpráva je identifikována právě pomocí ID záležitosti, takže pokud externí subjekt následně na zprávu odpoví standardním způsobem, je triviální ji při příjmu identifikovat.
• Zprávě je nastavena správná zpáteční/odesílací adresa.
  To je výhoda - při přímém použití "odpovědět" je potřeba odesílací adresu  (pokud je jiná, než primární adresa sdílené schránky) nastavit ručně, což je poměrně komplikované, plus by bylo potřeba ověřit správnost (zda odesílací adresa odpovídá schématu), takže průvodce odpovědí je významným zjednodušením.

Mechanismus pro odesílání zcela přirozeně zajistí i iniciální odchozí komunikaci, např. skupinovou. Stačí určit nebo vytvořit šablonu, vybrat kontakty, nastavit parametry (vyzkoušet) a spustit. Což má spoustu výhod (mj. možnost trasování zpráv).

Výkon

Příchozí zprávy musí být přiděleny uživatelům. Chceme vědět, kdo kterou zpracoval. Jak dlouho mu to trvalo. Co všechno zaznamenal a udělal.

• Všechny dosud nevyřízené zprávy jsou klasifikovány. Pomocí klasifikace je určena i naléhavost (priorita), typicky podle bonity zákazníka, případně stavu (či nezávislého atributu "naléhavost") záležitosti.
• Tak se zobrazují v pořadí dle jejich naléhavosti odpovídající skupině kompetentních pracovníků (viz požadavek). Nemají přemýšlet nad tím, jeslti se jim chce zpracovávat právě tuto zprávu - mají ji vyřídit a potom se věnovat té další. Nebo ji eskalovat (označit tak, aby někdo způsobilý odstranil překážku, která jim ve zpracování brání).
• Pro skutečně efektivní práci více uživatelů nad jednou (jedinou) složkou doručené pošty je výhodné mít nadstavbu, která každému uživateli zobrazí "jeho" úkoly. Protože pokud je některá zpráva explicitně přiřazena konkrétnímu člověku (což může být užitečné), nemá se zobrazovat ostatním členům týmu. Totéž platí, pokud někdo začně zprávu zpracovávat. Navíc může být užitečné rozdělit nezpracované zprávy podle toho, kterým týmům patří, jelikož toto rozdělení znamená různé kvalifikační požadavky a je účelné, aby se lidé se specifickou kvalifikací prioritně zabývali odpovídajícími případy, teprve potom pomáhali se zpracováním ostatních agend.

V oné firmě z úvodu intenzívně obhajovali, že lidé musí mít možnost si vybírat, kterou zprávu budou zpracovávat. Nakonec pochopili, že neřešitelné komplikace, které si tím způsobují, jsou důsledkem toho, že ne všichni členové týmů, kterým byly zprávy přidělovány, jsou způsobilí je zpracovat. Následně přistoupili i na to, že potřebná způsobilost nemá vznikat "samovolně", ale prostřednictvím striktní metodiky a důsledného zapracování (a následné kontroly).

Výkon / produktivita se zvedl na více než trojnásobek.

Inbox Empty 

Možná si to na základě aktuálních praktik neumíte představit. Snažíme se všechny přijaté zprávy "zlikvidovat". A to nikoli tak, že je "roztřídíme" do složek, ve kterých se potom málokdo vyzná (ve sdíleném prostředí to vůbec není efektivní).

• Zpracované zprávy přesunout ze složky "Doručená pošta" někam, kde nebudou překážet (výhodná je při větších objemech třeba i jiná sdílená schránka).
• Zprávy obsahují veškerá zmíněná metadata. Je tedy snadné se v nich vyznat i bez jakékoli nadstavby - lze je třídit a seskupovat podle libovolného údaje. Podstatné je, že by to nemělo být potřeba.
• Každá zpráva je přiřazená k záležitosti, je tedy snadné se k nim dostat právě jejím prostřednictvím. Není k tomu však důvod.

Zpracovat a zapomenout.

Archivovat 

Ke zpracovaným zprávám se nevracet.

• Průběžně upřesňovat strukturu extrahovaných dat dle typů zpráv a stavů záležitostí tak, aby bylo čím dál méně často potřeba se k nim vracet.
• Jakmile se záležitost dostane do stavu, který znamená ukončení aktivního životního cyklu, je možné ji a všechny její zprávy přesunout do archívní schránky, kterou lze (podle potřeb hospodaření s kapacitou úložišť) následně exportovat a uložit např. na médium nebo do archivního souborového úložiště či obojí.

Pokud máte zájem o informace nebo spolupráci, prosíme ozvěte se. Umíme komunikaci nastavit i u vás tak, aby se minimalizovalo riziko zmatků, komplikací, průšvihů. Správné používání elektronické pošty je pravděpodobně nezbytnou podmínkou smysluplné digitalizace a automatizace.