--- title: "Notifikace v podnikové aplikaci: e-mail, SMS a push" description: "Notifikace, kterou nikdo nečte, je horší než žádná — naučí lidi ignorovat i ty důležité. Jak navrhnout upozornění, která si udrží důvěru." canonical: "https://interfase.sk/cz/novinky/notifikace-v-podnikove-aplikaci-email-sms-a-push" lang: "cz" last_updated: "2026-10-19" --- # Notifikace v podnikové aplikaci: e-mail, SMS a push > Notifikace, kterou nikdo nečte, je horší než žádná — naučí lidi ignorovat i ty důležité. Jak navrhnout upozornění, která si udrží důvěru. Publikováno: 2026-10-19 - První otázka není jakým kanálem, ale jestli má notifikace vůbec vzniknout — většina zbytečných upozornění je informace, která mohla počkat v aplikaci. - Kanál vyplývá z naléhavosti: push na to, co je třeba teď, e-mail na to, co je třeba dnes, SMS jen na to, co se nesmí ztratit. - Pokud se notifikace posílají příliš často, lidé si je vypnou nebo přestanou číst — a vypnou i ty důležité. - Doručitelnost e-mailu je technická disciplína; bez nastavených záznamů domény skončí zprávy ve spamu bez varování. Aplikace posílá upozornění na všechno: nová objednávka, změna stavu, komentář, přiřazení úkolu, blížící se termín. Po měsíci si je polovina týmu vypne a druhá polovina je přestane otevírat. Tím se neztratila jen ta záplava — ztratily se i ty tři notifikace měsíčně, na kterých opravdu záleželo. ## Nejdřív se ptejte, jestli má vůbec vzniknout Před volbou kanálu přichází otázka, která se přeskakuje: **musí se to uživatel dozvědět aktivně, nebo mu stačí, když to uvidí, až se podívá?** Většina upozornění v podnikových aplikacích patří do druhé kategorie. Změna stavu objednávky je informace, ne událost. Patří do přehledu v aplikaci, ne do telefonu. Dobré pravidlo: notifikace je namístě, když od uživatele **něco vyžaduje** nebo když by ho nevědomost **stála peníze či čas**. Všechno ostatní je zdvořilostní vyrušení. ## Kanál podle naléhavosti - **Push** — je třeba to řešit teď. Výpadek, kritická chyba, úkol s termínem dnes. - **E-mail** — je třeba to vědět dnes, ale ne v této minutě. Souhrny, schválení, doklady. - **SMS** — jen to, co se nesmí ztratit a je časově kritické. Je nejrušivější a nejdražší, proto se hodí na jednorázové kódy a opravdu vážné události. - **V aplikaci** — všechno ostatní. Častá chyba je posílat tutéž věc všemi kanály najednou „pro jistotu". Uživatel dostane třikrát totéž a naučí se, že aplikace křičí. ## Souhrn místo jednotlivostí Pokud se událost opakuje často, nemá se posílat pokaždé. Místo patnácti e-mailů o nových objednávkách je lepší jeden ranní souhrn. Osvědčené je nechat uživatele vybrat frekvenci — okamžitě, denně, týdně — a předvolbou nastavit **denně**. Kdo potřebuje okamžitě, přepne si to; kdo ne, nemusí nic řešit. ## Nastavení musí být po typech Jeden přepínač „posílat notifikace" je málo. Uživatel chce vědět o přiděleném úkolu a nechce o každém komentáři. Pokud si může vypnout jen všechno, vypne všechno. Členění po typech události a kanálu je víc práce při návrhu, ale je to rozdíl mezi funkcí, kterou lidé používají, a funkcí, kterou obcházejí. ## Doručitelnost e-mailu je samostatné téma Toto překvapí skoro každý projekt. Aplikace e-mail odešle, v logu je „odesláno" — a zpráva je ve spamu. Bez nastavených ověřovacích záznamů domény (SPF, DKIM, DMARC) se e-maily z nové aplikace často nedoručí vůbec. Další věci, které pomáhají: posílat z domény, která se používá i na běžnou poštu, mít funkční zpáteční adresu, a **sledovat odmítnutí** místo toho, aby se tiše zahodila. U notifikací o přihlášení a bezpečnosti platí navíc to, co popisujeme v článku o [přihlašování a správě uživatelů](/blog/prihlasovanie-a-sprava-pouzivatelov-sso-dvojfaktor-a-role) — jsou to zprávy, které musí dorazit. ## Co do notifikace napsat Tři věci: **co se stalo**, **koho se to týká** a **co s tím**. Předmět „Nová objednávka" neříká nic; „Objednávka 2841 čeká na schválení do zítřka" říká všechno potřebné ještě před otevřením. A odkaz nemá vést na úvodní stránku, ale přímo na to místo. Pokud se mezitím situace změnila, uživatel to má vidět — ne se dostat na prázdnou obrazovku. ## Mobilní specifika Push notifikace se ztrácejí, když je aplikace offline nebo má zařízení úsporný režim. Proto je vždy potřeba **přehled v aplikaci**, který je zdrojem pravdy — push je jen upozornění, ne doručení. Souvisí to s tím, co píšeme o [offline režimu v mobilní aplikaci](/blog/offline-rezim-v-mobilnej-aplikacii-synchronizacia-a-konflikty). ## Co měřit - **Podíl otevřených notifikací** podle typu — typ pod deseti procenty je kandidát na zrušení. - **Podíl uživatelů, kteří si je vypnuli** — nejsilnější signál, že jich je příliš. - **Doručitelnost e-mailů** — kolik se nedoručilo a proč. ## Kde začít U existující aplikace se vyplatí udělat inventuru: vypsat všechny notifikace, které systém posílá, a u každé se zeptat, co od uživatele vyžaduje. Ty, u kterých odpověď neexistuje, přesuňte do aplikace. Obvykle je to víc než polovina. Pokud stavíte novou aplikaci a chcete to mít promyšlené od začátku, [ozvěte se](/kontakt). Řešíme to v rámci [vývoje na míru](/riesenia/vyvoj) — příklady v [referencích](/referencie). --- Webová verze: https://interfase.sk/cz/novinky/notifikace-v-podnikove-aplikaci-email-sms-a-push llms.txt: https://interfase.sk/llms.txt