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 stovkami tisíc zákazníků (po celém světě) a tisíci 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ý koncept. Ž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í, ž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. Pokud se vám to nezdá, ptejte se.

Proč jediná sdílená schránka

Nemůžete si dovolit aby:

• Spolupracovníci byli s externími subjekty v kontaktu prostřednictvím osobních adres.
• Jednotliví lidé 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.
• Přijatá a odesílaná 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. Nesmí se stávat, že odbavena není.
• Posílat odpovědi v kopii na všechny potenciálně dotčené spolupracovníky.

Pracovník má mít jediný 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"). Dohadování je ale zbytečné - je potřeba to vyzkoušet a přizpůsobit reálným podmínkám (typicky nutná kvalifikace pro řešení požadavků partnera). Přesněji - pokud neexistují nezvratné důvody pro více schránek (typicky ochrana informací, ale i to se dá řešit - možná efektivněji, rozhodně flexibilněji - nad jednou schránkou), 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 a dle úrovně dovedností lidí mohou vyhovovat odlišné metody/organizace. Usilujeme o to, aby se zpráva dostala co nejjednouššeji k člověku, který má v dané situaci nejvyšší pravděpodobnost dostatečného zpracování. Nelze přitom zapomínat na ochranu informací a řízení přístupu a výkonu. Pokud si s externími subjekty vyměňujete více desítek zpráv (či stovky) týdně, rozhodně se v dobré organizaci jejich zpracování skrývají desítky procent výkonu (produktivity).

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 zkusit dohledat obchodní případ a pokusit se reklamaci (či cokoli jiného) přidělit člověku, který zakázku vyřizoval (pokud je práce v dané firmě tak zorganizována - někde může být na reklamace vyčleněný člověk - ale ten samozřejmě potřebuje veškeré informace o průběhu obchodního případu). Ani v tomto případě není nutná samostatná schránka (vždy se může stát, že žádný z pracovníků vyřizujících reklamace není dostupný).

Záležitost je univerzální "spojka" mezi komunikačními vlákny a obchodními či obdobný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 a práci projekce & technologů). 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ě (nebo ručně) identifikována (opatřena metadaty).
  • 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ů obsažených ve zprávě 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.

Klasifikace a opatření zprávy metadaty zásadním způsobem podporuje (je podmínkou) automatizace. Lze využít i vytěžování obsahu zpráv, ale ve většině případů stačí hodně jednoduchá analýza klíčových slov. Nesprávně identifikovanou zprávu překlasifikuje ten, kdo se k ní dostane první.

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í. Dává to smysl, když - byť by to bylo pouze ve špičkách - příchozí poštu má zpracovávat (nikoli "přijímat" - jsou firmy, kde se nedokázali odpoutat od praktik z dob papírových a veškerá pošta je s využitím prapodivných technik doručována "na sekretariát") víc než jeden člověk.

• 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. Rozhodně si nemají vybírat.

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.

Když to promyslíte, zjistíte, že čím méně lidí přijaté zprávy zpracovává, tím lépe. Jejich povinností je převést doručený obsah na řádné či mimořádné aktivity. Případné odpovědi mohou být výrazně automatizované. Přitom se obsah dá zpřístupnit, komu je potřeba. Chce to nový způsob myšlení.

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 práci, kterou je v reakci na zprávu potřeba udělat, nelze 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 (např. externí partner si vyžádá lhůtu na doplnění). Tehdy zpráva zůstává "rozpracovaná" (odloží se... ale podle podmínek a typu by to nemělo být na více hodin - pro "aktuálně nezpracovatelné zprávy" je nejčastěji lepší využívat specifický druh záležitosti - dost často je vhodné, aby se problematickému případu věnoval někdo jiný, než výchozí pracovník). Již ovšem není v seznamu ke zpracování pro ostatní členy příslušného týmu, ale zobrazuje se pouze tomu přiřazenému.
  Samozřejmě je v takovém případě vybavena časovým limitem pro doplnění (povinná položka, kterou musí přiřazený pracovník při odložení vyplnit). Při jeho exspiraci je přiřazený uživatel upozorněn, pokud nereaguje, zpráva se eskaluje.

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 × specializace (kvalifikace)

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 je užitečné rozdělit nezpracované zprávy podle toho, kterému týmu patří dle kvalifikačních požadavků (pokud lze určit typ zprávy).
  • Lidé se specifickou kvalifikací se prioritně zabývají odpovídajícími případy
  • Teprve potom pomáhají se zpracováním ostatních typů zpráv.
  • Nadstavba může představovat průvodce, který vytváří záznamy/transakce potřebného typu - např. vytvoří objednávku na subdodavatele, úkol pro vyřízení reklamace atd.

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). Plus analýza kapacitních potřeb.

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. Také kolem tohoto pojmu existuje řada mýtů a blábolů. Podstatou je, že se snažíme všechny přijaté zprávy  (nejen email) "zlikvidovat". A to nikoli tak, že je "roztřídíme" do složek, ve kterých se stěžíkdo vyzná (ve sdíleném prostředí to vůbec nedává smysl). Musí zmizet.

• Organizace zpracování se řídí charakterem a rozsahem komunikace (ve zmíněné firmě se zpracováním zpráv nepřetržitě zabývá 16 hodin denně několik lidí). Pokud jsou přijímaných zpráv jednotky denně, stačí jen určitý čas a třeba jen jeden člověk (viz výše a jinde úvahy o tom, jak by zpracování mělo vypadat). Pokud je pro skutečné zpracování potřebná (byť ve špičkách) větší kapacita nebo je efektivní, aby se zpracováním zabývali přímo někteří specialisté (technolog, konstruktér, účetní, ...) jsou pravidla poněkud složitější a téměř jistě je účelná výše zmíněná nadstavba. Cílem je vyprázdnit složku s přijatou poštou.
• Zpracovávané zprávy (ty, které nejsou vyřízené/uzavřené) přesunout ze složky "Doručená pošta" někam, kde nebudou překážet (při větších objemech může být výhodná třeba i jiná sdílená schránka či v případě citlivých informací i více).
• Zprávy obsahují dříve 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.
• Jakmile jsou veškeré informace předávané zprávou "použity" (tedy vznikla odpovídající událost - v podnikové rovině příslušná instance - úkol, zakázka, ... v osobní schránce to odpovídá např. přesunutí informací ze zprávy do úkolu, termínu, nově založeného dokumentu apod.), zpráva již není potřebná a má být buď odstraněna zcela (to je motivační pro opravdu robustní nastavení celého systému) nebo přesunuta do archivu. 

Zpracovat a zapomenout (viz podrobněji).

Archivovat 

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

• Průběžně upřesňovat/rozšiř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 vlákno (aktivity iniciované zprávou) dostane do stavu, který znamená ukončení aktivního životního cyklu dané instance, je možné všechny jeho zprávy  a pomocné záznamy přesunout do archívní schránky.
• Tam je dobré sledovat (evidovat & analyzovat) případné přístupy (kdy kdo potřeboval co) - podle toho upravovat pravidla.
• Tak jako tak se stará pošta jednou musí "vyhodit". Obsah lze (podle potřeb hospodaření s kapacitou úložišť) exportovat a uložit např. na médium nebo do archivního souborového úložiště či obojí. Je to spíš rituál než užitečný krok.

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.