Open Monday: Nejčastější chyby v objednávkovém procesu

Zvuk! Prosím prosím, kupte si pořádný mikrofon.

Pěkný souhrn. Ze svého osobního pohledu vidím jako zdaleka největší chybu neperzistenci košíku, jak to nazýváte. Když chci objednat, prokoušu se lecčím. Ale když si musím po hodině znovu všechno dávat do košíku, tak nadávám jak dlaždič.

Dobrá přednáška, pěkně vypracováno. S téměř všemi body souhlasím, přesto mi to nedá a musím se na pár věcí zeptat , i vzhledem k tomu, že zrovna testujeme novou verzi eshopu.

1. neperzistence košíku – dost dobře nechápu, jak by jste navrhoval řešení takového stavu. Pokud si uživatel v průběhu objednávkového procesu zavře prohlížeč a následně jej otevře, má si prohlížeč pamatovat obsah košíku po dobu 24 hodin?? Nejsem tedy žádný kovaný vývojář nebo programátor, ale netuším, jak by jste to chtěl řešit technologicky – to jako navrhujete ukládat obsah košíku průběžně do cookies nebo přímo do DB?? SessionID máme nastavenou na 30 mins, docela by mě zajímaly argumenty pro natažení sessID na 24 hod, nicméně při zavření prohlížeče stejně o sessionID přijdete.
2. Chyba č. 14 – výběr způsobu platby následuje až po vyplnění osobních údajů – vám připadá přirozenější napřed vybírat dopravu a platbu a až následně vyplňovat údaje o zákazníkovi ? Cena dopravy je totiž většinou určena 3 proměnnými – celkovou částkou v košíku, vybraným způsobem dopravy a platby a v neposlední řadě právě místem doručení (pokud provozujete nadnárodní eshop s možností doručení do zahraničí). A jak vyřešit, když se cena za dopravu odvíjí právě z údajů o zákazníkovi, například cena za dopravu do Švýcarska a Německa je velmi rozdílná, proto napřed potřebuji znát stát, kam máme zboží dodat a podle toho v následném kroku určuji cenu za dopravu. Samozřejmě chápu, že zákazník chce vidět konečnou cenu včetně poštovného a balného už v košíku, ještě lépe přímo už v detailu produktu. V našem řešení to zkoušíme tak, že zákazník se celkovou cenu za dopravu dozví už v košíku i detailu produktu a to podle tzv. defaultní platby a dopravy a celkové částky v košíku.

4Adam: Vy si něco objednáváte déle než 1 hodinu, objednávkou myslím samotný objednávkový proces?? To mě nikdy nenapadlo, že objednávka může trvat tak dlouho. navíc takové chování je spíše problémem z bodu 3 – tj. rozptylování pozornosti – objednávka má být jasná, a pokud možno rychlá :) nemluvím o výběru / nákupním procesu, mluvím pouze o samotné objednávce.

Libore, dělám to velmi často. Zboží většinou dlouho vybírám a do košíku si dávám, co mě nejvíc zaujme. Před přechodem k objednávce to někdy několikrát změním.

Samozřejmě když přesně vím, co chci, tak objednávám hned a rychle. To ale většinou nebývá. Když jsem si kupoval komponenty na nový počítač, vybíral jsem si je víc jak týden. A celou dobu jsem chtěl mít svůj výběr uložený v košíku.

Co se týče perzistence košíku, pak jako uživatel chci zachovávat obsah košíku, dokud mám otevřené okno prohlížeče + zálohu pro odložení nákupu na pozdější dobu (u některého zboží se rozhoduji třeba i několik dní, než objednávku odešlu). Některé e-shopy mají možnost zaslat kód k obnovení košíku na e-mail, což je ale jednorázové obnovení a při příštím pokusu obnovení ze stejného kódu se již košík neobnoví – pokud s tím uživatel není seznámen, nebo pokud mu spadne prohlížeč, je to dost nepraktický postup. Nejjistější je ukládání do DB, pro přihlášené uživatele řešitelné jednodušeji, pro nepřihlášené složitější kvůli sessions a době trvání perzistence dat.

Pořadí kroků v objednávkovém procesu se mi zdá ještě složitější. Dělal jsem analýzu obj. procesů na různých e-shopech a většinou se začíná dodací adresou. Pokud na mě jako 1. bafne najednou způsob dopravy a platby, znejistím a nutí mě to přemýšlet. Souhrn objednávky jako krok objednávky je také ošemetná záležitost. Nedávno jsem právě musel stornovat objednávku, když jsem čekal v kroku Souhrn poslední stránku objednávky, kde vše uvidím a teprve pak odešlu objednávku, ale najednou už objednávka byla odeslána. Nepomůže ani odlišení tlačítek Pokračovat v objednávce a Odeslat objednávku (málokdo to čte, spíše automaticky kliká na další krok). Opět je běžnější na e-shopech souhrnná stránka, která se teprve pak potvrzuje v objednávku. Když je to někde jinak, může to vést ke zmatení – před odesláním závazné objednávky chci vidět kompletní souhrn, který si zkontroluji a pak teprve potvrdím správnost odesláním. Pokud si uživatel nevšimne, že ještě objednávku nepotvrdil, pak bude možná chyba jinde než v krocích objednávky.

S políčkem pro slevový kupón bych to neviděl tak vážně. Opět jsou tato políčka na spousty e-shopech, buď kupon mám, nebo nemám, pomalu již tato políčka lidé nemusí vnímat. Pro lidi bez kuponu sice může znamenat přemýšlení, jak získat slevu, přes koho nakoupit apod., což povede k odložení objednávky. Pokud ale někdo má slevový kupón, určitě ocení uplatnění slevy hned v košíku, aby viděl celkovou cenu před vstupem do objednávky. Započtení slevy z posledního kroku by muselo být hodně dobře řešeno a já jako uživatel s kuponem bych celou dobu přemýšlel, jestli mi tu slevu skutečně započtou, kolik bude výsledná cena objednávky, jestli zůstane doprava zdarma, jestli neudělám chybu při opisování kódu, jak zjistím, že mi tu slevu skutečně započetli, … zkrátka předem příliš otázek, obav a nejasností, které když budu vysvětlovat uživateli na stránce objednávky, stejně uživatele bez kuponu mohu odradit stejně jako políčkem pro uplatnění slevy. Pro uživatele se slevovým kuponem by objednávka mohla znamenat tolik úsilí a možná i stresu, že bych ty slevové kupony snad raději zrušil a soustředil se na stálé zákazníky procentuální slevou nákupu. Obecně, slevové kupóny pro zlákání nových zákazníků stejně asi nebudou mít takovou úspěšnost jako u stálých zákazníků.