Vlastní aplikace pro e-shop: vyplatí se, nebo stačí mobilní web?

01Nejdřív najděte důvod, proč se zákazník vrátí

Aplikace zabere místo na telefonu a vyžaduje další rozhodnutí. Zákazník ji musí najít, nainstalovat, případně se přihlásit a pochopit, čím mu pomůže. To všechno je náklad, i když za stažení nic neplatí. Nabídka „náš e-shop teď i v aplikaci“ tento náklad sama nevyváží.

Silnější důvod zní konkrétně: zopakujete týdenní objednávku, naskenujete prázdné balení nebo při vyzvednutí ukážete připravený kód. Hodnota vzniká z kratšího úkonu, menšího počtu chyb nebo lepšího přehledu. Někdy ji stejně dobře poskytne mobilní web. To je užitečný výsledek analýzy, nikoli prohra projektu.

Rozhodujte podle opakované situace, ne podle velikosti katalogu. Deset často objednávaných položek může vytvořit lepší důvod k instalaci než deset tisíc produktů nakupovaných jednou za několik let. Také drahé zboží může mít vhodný servisní scénář: přehled zařízení, náhradní díly a objednání údržby. Pak ovšem stavíte zákaznickou službu, ne druhou výlohu.

02Z objednávek zjistěte, pro koho aplikaci stavíte

Začněte zákazníky, kteří už se vracejí. Zjistěte, jak dlouho trvá druhý nákup, jaké skupiny nakupují pravidelně a které úkony opakují. Rozdělte spotřebitele a firemní zákazníky, sezónní nákupy a běžné doplňování. Jediný průměr za celý obchod může schovat skupinu, pro kterou aplikace dává smysl, i velkou skupinu, která ji nepotřebuje.

Sledujte zároveň příspěvek objednávky po variabilních nákladech. Zákazník, který nakupuje často jen s vysokou slevou a zboží vrací, nemusí financovat nový prodejní kanál. Do podkladů patří také dotazy podpory: zapomenutá hesla, dostupnost předchozí faktury, opakované hledání kompatibilního dílu. Každý ukazuje konkrétní problém, který lze ověřit v prototypu.

Vyberte malou, jasně popsanou cílovou skupinu. Například vedoucí kaváren, kteří každý týden doplňují stejné zásoby a objednávají mezi obsluhou hostů. Potom pozorujte jejich současný postup. Jestli nejvíc času zabere schválení nákupu nadřízeným, hezčí katalog nepomůže. Řešení musí zrychlit celý proces, nejen první obrazovku.

03Mobilní web, PWA a aplikace řeší různé překážky

Mobilní web zákazník otevře z vyhledávače, reklamy nebo odkazu. PWA je webová aplikace, kterou lze na podporovaných zařízeních přidat na plochu a doplnit vybranými funkcemi. Aplikace distribuovaná přes App Store nebo Google Play má vlastní vydávání a kontrolu verzí. Samotný název žádné varianty neurčuje kvalitu nákupního procesu.

Apple umožňuje web přidat na plochu iPhonu jako webovou aplikaci. Web Push pro aplikace na ploše podporuje od iOS 16.4; oprávnění se žádá po přímém úkonu uživatele. Notifikace tedy nejsou výhradou aplikací z obchodu. Návod Apple a dokumentace WebKit popisují podmínky.

Podrobnější technické hranice shrnuje náš průvodce PWA a nativní aplikace. Pro e-shop je podstatné převést je do konkrétního nákupu: zda člověk obnoví přerušený košík, otevře správnou objednávku z upozornění a pozná, že údaje už nejsou aktuální. Bez těchto detailů může dobře vypadající prototyp vytvořit falešný pocit připravenosti.

Před rozhodnutím nechte předvést kritický scénář na telefonech zákazníků. Nestačí seznam funkcí „PWA umí“. Záleží na kombinaci systému, prohlížeče, oprávnění a způsobu používání. Pokud potřebujete specializované zařízení nebo složitější práci na pozadí, ověření prototypem má větší cenu než obecná tabulka technologií.

04Opakované objednávky a B2B jsou silnější argument než další katalog

Obchod se spotřebním materiálem může nabídnout uložené seznamy podle provozovny. Vedoucí otevře seznam, upraví množství a vidí cenu i dostupnost. U B2B přibývají zákaznické ceníky, objednání na fakturu, schvalování, oprávnění a rozpočty. Přínos aplikace pak může spočívat i v tom, že obchodní oddělení nemusí objednávky přepisovat z e-mailů.

Právě tady ale vzniká podstatná část složitosti. Cena musí odpovídat smlouvě zákazníka, sklad skutečné dostupnosti a oprávnění konkrétní roli. Uživatel nesmí objednat za jinou pobočku jen změnou identifikátoru v požadavku. Pokud e-shop tyto věci nemá vyřešené v rozhraní, mobilní vývoj je nezachrání.

Pro první verzi vyberte jednu dokončitelnou cestu. Třeba opakování objednávky s kontrolou náhrad za nedostupné zboží. Padesát obrazovek nemusí být lepší než pět, které člověku každý týden odstraní obtížný krok. Volbu nativního či sdíleného vývoje řešte až poté, například podle našeho srovnání nativního a multiplatformního vývoje.

05Věrnostní program potřebuje důvod i mimo slevu

Body, kupony a digitální karta se do aplikace vejdou snadno. Hůř se dokazuje, že přinesou výnos navíc. Jestli si aplikaci stáhnou lidé, kteří by nakoupili tak jako tak, sleva může pouze snížit marži. Část rozpočtu pak nefinancuje růst, ale odměňuje přesun stejné objednávky z webu do jiného rozhraní.

Zkuste výhodu, která řeší skutečný problém: dostupné doklady, rychlé opakování, servisní přehled nebo informaci o připravené objednávce. Marketingové zprávy navrhujte podle užitečnosti a četnosti. Upozornění na vyzvednutí má jiný účel než každodenní připomínka slevy. Zákazník by měl rozumět tomu, co si zapíná, a umět preference změnit.

Počet instalací není vhodný hlavní cíl. Sledujte, kolik oslovených zákazníků dokončí první užitečný úkon a vrátí se při další nákupní příležitosti. Denní aktivita nemusí být důležitá pro obchod, kde se zásoby doplňují jednou měsíčně. O práci s návraty píšeme podrobněji v článku push notifikace a retence.

06Nejprve opravte nákup na telefonu

Pokud zákazník na mobilním webu nenajde dopravu, ztratí košík nebo nedokončí platbu, začněte tam. Nová aplikace neodstraní nekvalitní produktová data ani nespolehlivý sklad. Navíc většina nových zákazníků potřebuje funkční web ještě předtím, než bude uvažovat o instalaci.

Projděte nákup jako člověk, který vás nezná: vyhledání položky, volba varianty, dostupnost, konečná cena, doprava a potvrzení objednávky. Vyzkoušejte slabší telefon i přerušení cesty. Zda může nakoupit bez účtu, zjistí zákazník často až v košíku. Tato překážka bývá levnější na odstranění než vytvoření dalšího kanálu.

Zlepšení webu je také kontrolní varianta investice. Za stejný rozpočet můžete zkrátit objednávku všem návštěvníkům, nebo financovat pohodlnější cestu pro menší skupinu. Porovnávejte očekávaný přínos obou možností. Mobile first pomůže u návrhu, rozhodnutí o aplikaci musí navíc obstát v ekonomice.

07Aplikace musí sdílet obchod, ne vytvářet druhý

Před zadáním sepište, odkud přicházejí produkty, ceny, dostupnost, objednávky a zákaznické účty. Aplikace by měla využívat společná obchodní pravidla. Dvě oddělené implementace slev dříve nebo později ukážou jiný výsledek. Pak se zákazník ptá, proč na telefonu zaplatil víc než na počítači.

Rozhraní musí zvládnout i chyby: požadavek se odešle dvakrát, platební brána odpoví pozdě nebo se mezitím změní sklad. Opakování požadavku nesmí vytvořit druhou objednávku. Při obnovení připojení musí být jasné, zda už nákup proběhl. Testujte tyto situace stejně vážně jako barevnost tlačítka.

Offline režim neznamená, že lze bez připojení slíbit aktuální cenu nebo rezervovat poslední kus. MDN popisuje ukládání vybraných podkladů pomocí service workeru. Pro obchod z toho plyne nutnost rozlišit uložený seznam od potvrzené objednávky. Před dokončením se musí ověřit stav na serveru.

08Počítejte celý provoz včetně vydávání a podpory

Do rozpočtu patří návrh, napojení, testování na zařízeních, příprava obchodu s aplikacemi i první nasazení. Následují aktualizace systému, knihoven a platebních součástí, opravy, sledování chyb, zákaznická podpora a práce s obsahem. Změna API e-shopu může vyžadovat kompatibilitu se starší aplikací, kterou lidé dosud neaktualizovali.

Apple v pravidlech minimální funkčnosti vyžaduje hodnotu nad rámec přebaleného webu. Schválení nelze zaručit pouhým vložením e-shopu do obalu. Distribuční účty, podpisové prostředky a proces vydávání musí být předem vyřešené a pod kontrolou firmy.

U fyzického zboží Apple požaduje jiné platební metody než In-App Purchase a Google Play Billing se na tyto platby používat nesmí. Digitální obsah má odlišná pravidla. Rozpočet e-shopové aplikace proto nelze automaticky navýšit o univerzální „provizi obchodům“. Ověřte pravidla Apple a Google Play podle konkrétní nabídky.

09Návratnost počítejte z přírůstku, ne ze všech objednávek

Aplikace vydělává až tím, co přidá oproti situaci bez ní. Model níže není ceník vývoje ani předpověď výsledků. Firma si pro rozhodnutí stanovila měsíční náklad 50 000 Kč včetně rozpočítané počáteční investice a provozu. Z jedné dodatečné dokončené objednávky po variabilních nákladech získá 250 Kč.

Při dvou tisících aktivních zákazníků potřebujete navíc v průměru jednu objednávku na deset zákazníků za měsíc. Pokud aplikací projde tisíc objednávek, ale devět set padesát z nich by přišlo přes web, skutečný přírůstek je jen padesát. Příspěvek činí 12 500 Kč a model náklady nepokryje.

Zvlášť připočítejte prokazatelnou úsporu práce a odečtěte slevy poskytnuté jen kvůli instalaci. Ušetřený čas má jiný význam, pokud skutečně sníží náklady, a jiný, pokud zaměstnancům jen uvolní kapacitu. Stejnou logiku vysvětluje návratnost investice do softwaru.

10Ověřte zájem dřív, než objednáte celý vývoj

Nejprve ukažte zákazníkům konkrétní úkon v prototypu. Nechte je zopakovat objednávku, opravit množství a zkontrolovat cenu. Otázka „chtěli byste aplikaci?“ obvykle přinese zdvořilé odpovědi. Pozorování skutečného úkonu ukáže, kde se lidé ztrácejí a zda je nová cesta vůbec lepší.

Potom vyberte omezený pilot s jasnou podmínkou úspěchu. Měřte pozvání, aktivaci, dokončení úkonu a návrat v odpovídajícím období. Pokud je to proveditelné, porovnejte podobné zákazníky s přístupem k pilotu a bez něj. Samotné srovnání uživatelů aplikace s ostatními bývá zkreslené: aplikaci si častěji stáhnou lidé, kteří mají značku rádi už předem.

Předem napište i podmínku zastavení. Třeba že opakované objednání nepřináší dostatečný přínos proti vylepšenému webu nebo integrace vyžaduje nejprve opravu základního systému. Pilot není povinná zastávka před velkým vývojem. Je to způsob, jak se rozhodnout, zda v něm pokračovat.

11Co má obsahovat zadání pro dodavatele

Zadání začněte zákazníkem a úkonem, který chcete zlepšit. Přidejte současný postup, očekávaný přínos, zdroje dat, podporovaná zařízení a způsob měření. Seznam obrazovek je až další vrstva. Dodavatel musí vědět, co rozhodne o převzetí: například že opakovaná objednávka respektuje ceník, oprávnění a aktuální dostupnost.

Ve smlouvě a provozním plánu řešte odpovědnost za aktualizace, reakci na chyby, přístupy, dokumentaci a předání jinému týmu. Určete, kdo obslouží neúspěšnou platbu nebo dotaz na účet. Aplikace nekončí stažením z obchodu. Je to další část služby, kterou zákazník bude přičítat vaší značce.

Pokud zatím nemáte pravidelný scénář, spolehlivé rozhraní a způsob, jak ověřit přírůstek, zlepšujte mobilní web. Pokud všechny tři podmínky máte, dejte první verzi úzký a měřitelný úkol. Dobrá aplikace může být obchodní výhodou. Rozhodnutí pro ni ale musí přežít i chvíli, kdy z prezentace odstraníte logo App Storu.

12Časté otázky

13Zdroje

• Apple: webová aplikace na ploše iPhonu
• WebKit: Web Push pro iOS a iPadOS
• MDN: offline režim a operace na pozadí
• Apple: pravidla App Storu, platby a minimální funkčnost
• Google Play: pravidla plateb

Dokumentace ověřena 23. října 2026. Rozhodovací doporučení a model návratnosti jsou redakční analýza. Dostupnost funkcí závisí na zvolených zařízeních a implementaci.