Odpověď hned: Hlášení chyb ve firemní aplikaci je přesně ten typ procesu, který se vyplatí zautomatizovat celý: uživatel klikne na plovoucí ikonu přímo v aplikaci, označí problém na screenshotu a odešle. Systém sám přibalí technický kontext včetně chyb z konzole prohlížeče, jazykový model hlášení shrne a navrhne prioritu a upozornění doletí na Telegram dřív, než by uživatel dopsal e-mail. Takový systém jsme postavili pro vlastní provoz, běží centrálně pro víc projektů najednou a nasazení do další aplikace znamená vložit jeden řádek kódu. Tahle case study popisuje, jak funguje uvnitř a co si z ní vzít pro automatizaci procesů ve vaší firmě.

O automatizaci firemních procesů jsme na blogu psali dvakrát obecně — co se reálně vyplatí automatizovat a sedm procesů, které šetří hodiny. Obecné rady ale mají slabinu: nejde na nich ukázat, jak hotová automatizace vypadá zblízka — kde začíná, kde končí a co v ní zůstává na člověku. Proto tentokrát konkrétní projekt z našeho provozu: systém hlášení chyb, který jsme si postavili sami pro sebe, protože nás klasické „nefunguje to, mrkněte na to” přestalo bavit.

Výchozí stav: „nefunguje to” e-mailem

Provozujeme několik webových aplikací — vlastních i takových, které jsme postavili a spravujeme pro zákazníky. A u každé z nich se dřív nebo později objeví stejný proces: uživatel narazí na chybu a potřebuje ji někomu říct.

Bez systému vypadá ten proces pokaždé stejně:

Uživatel napíše e-mail nebo zavolá: „Nejde mi uložit záznam.”
Technik se doptává: Ve kterém prohlížeči? Na jaké stránce? Co přesně jste klikli? Pošlete screenshot?
Uživatel mezitím dělá něco jiného, odpověď přijde za den a půlku detailů už neví.
Technik zkouší chybu zopakovat naslepo — často neúspěšně, protože klíčová okolnost v popisu chybí.

Každé kolo téhle smyčky znamená čekání na obou stranách. A hlavně: hlášení nemá žádnou strukturu ani frontu. Jedno přijde e-mailem, druhé po telefonu, třetí ústně na schůzce — a čtvrté se ztratí úplně, protože ho uživatel „nechtěl otravovat”.

Podle checklistu z našeho článku o automatizaci je to učebnicový kandidát: proces se opakuje, má jasný vstup i výstup (chyba → strukturované hlášení ve frontě) a dnes ho brzdí ruční přepisování a doptávání.

Zadání: hlášení vzniká tam, kde chyba — a padá do jedné fronty

Cíl jsme si dali takhle:

Uživatel nahlásí chybu přímo v aplikaci, kde na ni narazil — bez e-mailu, bez přepínání oken, bez pořizování screenshotů bokem.
Hlášení má vždy stejnou strukturu: screenshot s označeným místem, popis a technický kontext.
Všechny aplikace hlásí do jedné centrální fronty — ne pět schránek, pět formulářů a pět zvyklostí.
Prioritu a shrnutí navrhne AI triáž, aby byla fronta roztříděná dřív, než ji člověk poprvé otevře.
O novém hlášení se tým dozví okamžitě na Telegram.

Jak to vidí uživatel: brouk vpravo dole

V rohu aplikace plave malá ikona brouka. Po kliknutí se otevře tříkrokový průvodce:

Označit místo. Widget vyfotí aktuální obrazovku a uživatel tužkou nebo výřezem označí, kde je problém. Žádné „stiskněte PrintScreen a vložte to do mailu” — kreslí se přímo v aplikaci.
Popsat. Krátký popis, co se stalo a co uživatel čekal. Kdo nechce psát, může popis nadiktovat hlasem.
Zkontrolovat a odeslat. Uživatel vidí, co se odesílá, a potvrdí.

Celé to trvá méně času, než by zabralo otevřít e-mailového klienta. A co je podstatné: k hlášení se automaticky přibalí chyby z konzole prohlížeče — tedy přesně ta technická informace, kterou by běžný uživatel nikdy neposlal, protože neví, že existuje.

Widget běží v takzvaném shadow DOM, takže je úplně nezávislý na technologii stránky. Nerozbije vzhled aplikace a je jedno, jestli je web postavený v Reactu, ve starším redakčním systému, nebo jde o statickou stránku.

Co se děje po odeslání: sanitizace, triáž, Telegram

Tady začíná ta zajímavější část. Všechno následující proběhne bez jediného lidského zásahu:

1. Sanitizace. Ještě před zápisem do databáze projde text hlášení filtrem, který redaguje hesla, tokeny, e-maily, telefonní čísla i rodná čísla. Když uživatel omylem vloží do popisu heslo, do fronty už nedorazí. Identita ohlašovatele — jméno a e-mail — se naopak zachovává, aby bylo komu odpovědět.

2. AI triáž. Jazykový model si hlášení přečte a doplní návrh priority a stručné shrnutí. Fronta je tak roztříděná dřív, než ji člověk poprvé otevře: pád ukládání vyskočí nahoru, kosmetická připomínka k barvě tlačítka počká. Triáž běží přes OpenAI-kompatibilní rozhraní, takže model lze provozovat i lokálně na vlastním hardwaru — hlášení z interních aplikací pak nemusí opustit firmu.

3. Upozornění na Telegram. Zpráva o novém hlášení přijde do chatu okamžitě po odeslání. Každý projekt přitom může mít vlastní kanál, takže upozornění z klientovy aplikace vidí ti, kdo ji mají na starosti.

4. Fronta v adminu. Řešitel vidí všechna hlášení na jednom místě a filtruje podle projektu, stavu, typu nebo priority. U každého hlášení má anotovaný screenshot, popis, konzolové chyby i kontext — doptávání odpadá, protože všechno podstatné dorazilo napoprvé. Po opravě označí hlášení jako vyřešené.

Všimněte si dělby práce, kterou opakujeme v každém textu o AI: stroj třídí a připravuje, člověk rozhoduje a opravuje. Triáž prioritu jen navrhuje — sama nikoho nebudí a nic neopravuje. To je záměr. Hlášení chyby je proces s jasným vstupem a výstupem, ideální pro automat; samotná diagnóza a oprava už ne.

Citlivá data: co systém záměrně nezapisuje

U interních nástrojů se na bezpečnost často myslí až po nasazení. Tady byla součástí zadání od začátku:

Redakce citlivých údajů před zápisem. Hesla, tokeny, e-maily, telefony a rodná čísla se z textu hlášení odstraní dřív, než se cokoli uloží.
Screenshoty mimo veřejný web. Snímky obrazovky se ukládají mimo veřejně dostupné soubory a zobrazit je jde jen přes zabezpečený admin. Screenshot z interní aplikace tak nikdy neleží na veřejné adrese.
Kontrola původu. Server přijme hlášení jen z domén, které jsou u projektu registrované. Cizí web nemůže frontu plnit balastem.
Admin za tokenem. Fronta hlášení je přístupná jen s tajným tokenem, bez něj server přístup odmítne.

Nasazení do dalšího systému: jeden řádek kódu

Systém je od začátku stavěný jako centrální služba pro víc projektů. Nasazení do další aplikace vypadá takhle:

Do stránky se vloží jeden <script> odkazující na centrální službu.
V registru služby dostane projekt klíč, seznam povolených domén a případně vlastní Telegram kanál.
Hotovo — brouk se objeví v rohu a hlášení začnou padat do společné fronty.

Do klientova systému se nezasahuje: žádná změna jeho kódu, žádná instalace na jeho serveru, žádná závislost na tom, jak je web postavený. Celá služba přitom běží jako jeden kontejner na našem serveru — žádná složitá infrastruktura, kterou by musel někdo další udržovat.

Za zmínku stojí i to, jak systém vznikl. Zhruba 80 % kódu jsme převzali z modulu hlášení chyb, který jsme původně postavili do jedné konkrétní aplikace pro správu provizí, a zobecnili ho pro víc projektů; dalším nasazením byla naše aplikace pro evidenci revizí. To je typický průběh dobré automatizace — nevzniká na zelené louce jako velký projekt, ale zobecněním něčeho, co se už jednou v ostrém provozu osvědčilo.

Co to reálně šetří

Nebudeme tvrdit, že jsme ušetřili přesně tolik a tolik hodin — takhle jsme to neměřili. Úspora je ale vidět přímo na struktuře procesu:

Odpadla smyčka doptávání. Dřív se screenshot, verze prohlížeče a postup skládaly z několika kol e-mailů; teď dorazí všechno napoprvé, včetně konzolových chyb, které by uživatel sám nikdy neposlal.
Hlášení se neztrácí. Všechno je v jedné frontě se stavem. Nic nevisí v e-mailové schránce, v poznámkách z telefonátu ani v něčí hlavě.
Priorita je známá hned. Fronta je předtříděná strojem, takže kritické věci nezapadnou mezi drobnosti.
Klesla bariéra hlásit. Když je nahlášení otázkou tří kliknutí přímo v aplikaci, přestává platit „nebudu kvůli tomu psát e-mail” — a chyby se k řešiteli dostanou dřív.

Co si z toho vzít, když chcete automatizovat vlastní proces

Tenhle projekt sedí přesně do rámce, který popisujeme v obecných článcích:

Jasný vstup a výstup. Chyba v aplikaci → strukturované hlášení ve frontě. Žádné rozhodování s odpovědností — ideální práce pro automat.
Člověk zůstává ve smyčce. AI třídí a shrnuje; diagnózu, opravu a komunikaci s uživatelem dělá technik.
Citlivá data pod kontrolou. Sanitizace před uložením, screenshoty mimo veřejný web, možnost lokálně běžícího modelu.
Malý start, pak zobecnění. Nejdřív modul v jedné aplikaci; teprve když se osvědčil, vznikla z něj centrální služba pro všechny projekty.

Stejný vzor se dá přenést na příjem objednávek, reklamace, interní požadavky na IT nebo schvalování podkladů — všude tam, kde dnes lítají e-maily bez struktury a někdo je ručně přepisuje dál.

Pokud vás při čtení napadlo „tohle bychom potřebovali taky” — ať už jde o hlášení chyb, nebo o úplně jiný proces, který u vás běží přes e-maily a doptávání — přesně takové automatizace stavíme firmám na míru v rámci služby IT pro firmy. Začínáme krátkou konzultací nad vaším konkrétním procesem, ne prezentací o umělé inteligenci; ozvat se nám můžete přes kontakt. A jestli chcete, aby podobné příležitosti uměl najít váš tým sám, od toho je školení AI pro firmy.

Často se ptáte

Ne. Vkládá se jedním skriptem a díky shadow DOM běží nezávisle na technologii stránky — v moderní jednostránkové aplikaci, ve starším redakčním systému i na statickém webu. Do kódu aplikace se nezasahuje.

Co když uživatel do hlášení napíše heslo nebo osobní údaje?

Text hlášení prochází před uložením sanitizací, která hesla, tokeny, e-maily, telefonní čísla a rodná čísla redaguje. Jméno a e-mail ohlašovatele se zachovávají, aby bylo komu odpovědět na vyřešené hlášení.

Nahradí AI triáž programátora?

Ne — a ani to není cíl. Triáž hlášení shrne a navrhne prioritu, takže člověk otevírá roztříděnou frontu místo hromady nestrukturovaných e-mailů. Diagnózu a opravu dělá vždy technik.

Musí data z hlášení téct do zahraničního cloudu?

Nemusí. Služba běží na vlastním serveru, screenshoty se ukládají mimo veřejně dostupné soubory a AI triáž jde provozovat přes lokálně běžící model. Hlášení z interní aplikace pak neopustí firemní infrastrukturu.

Kolik taková automatizace stojí?

Záleží na rozsahu a na tom, co už ve firmě máte — proto konkrétní nabídku dáváme až po krátké konzultaci nad vaším procesem. Obecný rámec nákladů na firemní AI popisujeme v článku kolik stojí AI pro firmu.

Case study: hlášení chyb, které si samo dělá triáž