Jak na generování a prodej poukazů na e-shopu? Automatizujte to!

Pokud chcete z pozice majitele e-shopu nabídnout svým zákazníkům kvalitní zážitek z nákupu, je třeba zajistit, aby fungovaly ty nejdůležitější funkce: správná prezentace informací o produktech, kvalitní objednávkový proces s rozmanitou nabídkou dopravních a platebních metod a zajištění rychlého doručení objednaného zboží.

V okamžiku, kdy si u těchto bodů uděláte jednu velkou zelenou fajfku, můžete se pustit do ladění dodatečných funkcí, které zákazníkovi používání e-shopu zpříjemní. Můžete přidat parametrický filtr na kategorii, věrnostní program, umožnit zákazníkům přístup k historii objednávek nebo zadání reklamace v uživatelském profilu, …. Nebo zákazníkům můžete nabídnout lákavé marketingové funkce jako akční ceny, zvýhodněné sety a slevové kupóny. Ty mohou umocnit jeho rozhodnutí nakoupit právě u vás.

Někde mezi dodatečné „technické“ funkce a žádané funkce (hlavně teď o Vánocích) můžeme zařadit tzv. dárkové poukazy. Jeden produkt, který dokáže kupujícímu vyřešit problém hned v několika situacích. Pojďme si uvést ty nejčastější z nich:

• nejsem si jistý, co by se obdarovanému hodilo a nechci kupovat dárek, který nakonec nevyužije
• vím, že nejlepší cestou je věnovat dotyčnému peníze, ale nechci jít cestou bankovek v obálce
• nejvíc dárkové poukazy oceníme my, kteří odkládáme nákup dárku na poslední chvíli a jediným „otevřeným obchodem“ je internet a vlastní tiskárna ;-)

Všechny tyto situace dokáže vyřešit dárkový poukaz ve vybrané finanční hodnotě. Ideálně, pokud je proces objednávky co nejjednodušší a umožňuje zaplatit real-time online kartou. Pak už jen zbývá stáhnout si z e-mailu PDF, poslat ho na tiskárnu, vložit do obálky a hurá na oslavu.

Zní to jednoduše? Ano, z pohledu zákazníka by to tak mělo přesně vypadat! Pojďme se ale podívat, co vše se skrývá na straně e-shopu z pohledu vývoje a na co je potřeba myslet. A abychom jen nepolemizovali, ukážu vám, jak jsme se s touto implementací poprali na českém e-shopu ElectroWorld.cz a jeho slovenském dvojčeti Nay.sk.

E-shopy ElectroWorld.cz a Nay.sk

Než začnu rozebírat jednotlivé fáze implementace, pojďme si krátce udělat představu, pro koho jsme tuto funkcionalitu chystali a s jakými specifiky jsme do vývoje šli.

E-shopy ElectroWorld.cz a Nay.sk nejsou jen čistě elektronickými obchody, ale tvoří pouhou část celého prodejního ekosystému. Druhou, neméně významnou částí, jsou kamenné prodejny. A z pohledu těchto brandů to je 39 prodejen v ČR a 39 prodejen v SK. Stejně jako funguje nákup produktu napříč oběma světy, tak bylo základním požadavkem, aby šel dárkový poukaz:

• zakoupit jak na e-shopu, tak i na kterékoliv prodejně
• uplatnit jak na e-shopu, tak na kterékoliv prodejně

Už jen u těchto dvou základních požadavků je cítit, že nepůjde jen o to vymyslet správnou implementaci na e-shopu, ale také promyslet, jak umožnit načítání a uplatňování poukazů na pokladních systémech na prodejnách, sdílet informace o zakoupených dárkových poukazech na jednom místě a zabezpečit, aby nedošlo například k dvojímu čerpání.

Protože zákazníkům těchto e-shopů tyto funkce dlouho scházely a fungovaly jen v základním režimu na prodejnách, chtěli jsme naši implementaci posunout ještě dál a ve finále poskytnout co nejvíce funkcí. Vše se ale muselo stihnout před vypuknutím předvánoční sezóny.

Dárkový poukaz versus slevový poukaz na konkrétní hodnotu

Samotný úvod do dárkových poukazů bych ještě doplnil krátkým vysvětlením rozdílu mezi dárkovým poukazem a slevovým poukazem na konkrétní hodnotu. Na první pohled (uživatelsky) jde téměř o stejnou věc. Z pohledu účetnictví a hlavně implementace, jsou to ale velmi rozdílné pojmy. Posuďte sami:

Slevový poukaz na konkrétní hodnotu

• Slevový poukaz na konkrétní hodnotu zákazník většinou obdrží zdarma jako součást slevové kampaně. Například jako kompenzaci za drobnou vadu na prodávaném zařízení nebo za poskytnutou informaci – např. přihlášení do newsletteru, vyplněním ankety, atd. Slevový poukaz si tedy zákazník nekupuje.
• Slevový poukaz by měl reálně ponižovat cenu zboží v objednávce. A např. při výpočtu finančních služeb (prodloužená záruka, pojištění proti poškození, …), které se počítají z ceny produktu, by měl výpočet vycházet z ponížené ceny produktu. Vše ale záleží na tom, jak si to daný e-shop stanoví ve svých obchodních podmínkách.
• Z účetního hlediska tak ponižují slevové poukazy i vypočtenou hodnotu produktu bez DPH a hodnotu DPH (pozor nezaměnit si se sazbou DPH).

Dárkový poukaz

• Dárkový poukaz v dané hodnotě si zákazník naopak kupuje. A to s nulovou sazbou DPH.
• Zákazník si tak vlastně kupuje ceninu.
• Uplatněním dárkového poukazu v objednávce nedochází k ponížení ceny kupovaného zboží, ale jen k umoření části ceny objednávky nebo dokonce pokrytí celé ceny objednávky.
• Například do výpočtu hodnoty ceny prodloužené záruky počítané z ceny výrobku tak jde standardní cena výrobku.
• Představte si to tak, že místo platby dobírkou nebo online kartou zaplatíte objednávku kódem dárkového poukazu.

Nákup dárkového poukazu

Skočme ale z teorie rovnou do praxe a pojďme si ukázat, jak umožnit zákazníkovi nákup dárkového poukazu. Prvním důležitým, ale jednoduchým bodem je, po konzultaci s marketingem navrhnout, jaké hodnoty dárkových poukazů budeme zákazníkům nabízet. My jsme šli do pilotního provozu tento rok s hodnotami 500, 1000, 2000 a 5000 Kč a na slovenském e-shopu s hodnotami 20, 50, 100 a 200 €. A pro pilotní projekt jsme začali jen s prodejem elektronických poukazů na e-shopu a papírových poukazů na prodejně.

Zkuste odhadnout jaká nejčastější hodnota dárkového poukazu je kupovaná? Už máte svůj tip? Realita je taková, že nejčastější hodnotou na ElectroWorld.cz webu je to 500 Kč kupón a hned za ním 2000 Kč. Na Nay.sk je ta nejnižší hodnota asi pro slovenské zákazníky moc nízká a vede hodnota 50 € kupónu.

Jakmile se shodnete na částkách dárkových poukazů, přichází na řadu otázka, jak dárkové poukazy umožníme nakoupit. Prvním nápadem bude umožnit zákazníkovi nakoupit elektronickou podobu dárkového poukazu skrze klasickou objednávku. Tu přeci již máme pro standardní zboží (v případě našich e-shopů většinou fyzických produktů), tak proč ji nevyužít. V zápětí si ale uvědomíte, že namixovat v jedné objednávce nákup dárkových poukazů a fyzického zboží není úplně ideální – ať už z pohledu rozdílné logistiky, tak z pohledu rychlosti vyřízení objednávky. Poukazy většinou zákazník potřebuje obdržet rychle.

3 možnosti, jak tuto situaci vyřešit:

1. možnost: nechat zákazníka nakoupit vše dohromady

• výhody:
  • zákazník objedná dárkové poukazy skrze objednávku, na kterou je zvyklý
  • zákazník může objednat dárkové poukazy různých hodnot v rámci jedné objednávky
  • v objednávce si zákazník může zakoupit i fyzické produkty
• nevýhody/komplikace
  • je potřeba v objednávce omezit nabídku platebních metod (dobírka, splátky, …), aby finální nabídka zákazníka neodradila od dokončení objednávky
  • na pozadí bude potřeba vyřešit komplikace související s obtížnou logistikou v podobě dělené expedice, nebo rozdělením objednávek na pozadí
  • velká pravděpodobnost dalších skrytých problémů
• závěr:
  • z našeho pohledu velmi obtížná implementace, do které jsme nechtěli jít

2. druhá možnost: a na mnoha e-shopech používaná, je informovat zákazníka, že v objednávce lze zakoupit jen jeden typ zboží. Buď dárkový poukaz, nebo fyzické zboží. Pokud má v košíku produkty namixované, tak si musí některé z nich z košíku odstranit a vložit si je do košíku později. Myslím, že je to přijatelná varianta, skrze kterou necháte zákazníka využít všechny funkce objednávky za drobné nepohodlí v podobě odstranění produktů jiného typu.

• výhody:
  • zákazník objedná dárkové poukazy skrze objednávku, na kterou je zvyklý
  • zákazník může objednat dárkové poukazy různých hodnot v rámci jedné objednávky
• nevýhody / komplikace
  • zákazník musí odstranit z košíku jeden typ zboží a vy jako obchodník budete doufat, že si ho do košíku pak znovu dá a dokončí druhý proces objednávky
  • stále bude potřeba omezit nabídku platebních metod (dobírka, splátky,.. )
  • je potřeba omezit nabídku doručovacích metod jen na jednu – doručení emailem
  • z pohledu UX byste např. neměli chtít po zákazníkovi vyplňovat (doručovací) adresu (pokud ji nechce vyplnit např. kvůli vystavené faktuře)
• závěr
  • z našeho pohledu přijatelná varianta

3. možnost: oddělený objednávkový proces. Cesta, kterou jsme se vydali my. Oddělený objednávkový proces mimo standardní košík jsme zjednodušili na nejnutnější kroky tak, aby nákup dárkového poukazu byl co nejrychlejší a požadovali jsme po zákazníkovi jen ty nejnutnější údaje. My jsme tento průchod provedli skrze modální okno, které jsme měli již vyzkoušené z procesu rezervací.

• výhody:
  • nákupní proces oddělený od klasické objednávky. Není tak potřeba odstraňovat fyzické produkty z košíku
  • proces lze oproti standardní objednávce ořezat jen na nejnutnější funkce a vyvarovat se tak různým kolizním situacím – např. neumožnit uplatnit slevový poukaz při nákupu dárkového poukazu atd.
  • cílená nabídka jen relevantních plateb a vyhnutí se prezentace doručovacích metod (samotnou systémovou dopravu si ukládáme až na pozadí čistě technicky my)
• nevýhody/komplikace
  • obtížnější nákup dárkových poukazů různých hodnot v rámci jednoho nákupu. Ale i to je řešitelné, pokud data ukáží, že je to častý reálný use-case
  • z určitého pohledu je potřeba implementovat některé funkce – např. načtení dat zákazníka, výpis platebních metod na dalším místě. Při dobrém naprogramování jednotlivých komponent to pro nás ale nebyl velký problém
• závěr:
  • díky tomu, že jsme uměli pracovat s nákupem skrze modální okno (tj. z funkce rezervace) a viděli jsme zde spoustu dalších výhod, šli jsme touto cestou a za 6 měsíců od nasazení jsme se nesetkali s žádnou výtkou od zákazníků

Zákazník poukaz nakoupil a zaplatil. Co dál?

Pokud zákazník za dárkový poukaz zaplatil a zobrazila se mu děkovací stránka, může se zdát, že je vyhráno. Opak je ale pravdou. Jsme zhruba v půlce. Co dalšího nás z pohledu implementace čeká?

Úložiště dárkových poukazů:

Je potřeba vymyslet, kde dárkové poukazy ukládat. V případě čistě elektronického obchodu se nabízí právě databáze samotného e-shopu. Pokud ale chcete zajistit, že půjde dárkový poukaz načíst a uplatnit i na pokladnách, musí se vyřešit místo, které nabídne přístup k dárkovým poukazům oběma „světům“. V případě uložení v databázi e-shopu je potřeba pro pokladny vystavit např. REST API endpoint a nebo, jako v našem případě, vybral management e-shopů Electro World a Nay systém od firmy NG retail s názvem Air&Me, který měl předchystanou komunikaci s pokladním systémem provozovaným na pokladnách prodejen.

Naším úkolem bylo zprovoznit REST API komunikaci s tímto systémem, kterému jsme, z pohledu nákupu, dali vědět, že zákazník úspěšně objednávku dokončil. Od systému očekáváme zaslání kódů pro zakoupené dárkové poukazy.

Zaslání dárkového poukazu e-mailem

Po obdržení čísla dárkového poukazu/poukazů, je třeba zákazníkovi poukaz nějakým způsobem předat. U nás jsme to vyřešili tak, že obdržené číslo dárkového poukazu a další doplňující informace (např. informace o datu platnosti) vezmeme a vygenerujeme PDF soubor, který pošleme zákazníkovi na jeho e-mailovou schránku. Příloha je nachystaná na formát A4 pro snadné vytištění na tiskárně. Celý proces od zobrazení děkovací stránky až po obdržení e-mailu je tak v řádech jednotek sekund.

Mysleli jsme zde však i na prodejny, a tak jsme na dárkový poukaz kromě uživatelsky čitelného čísla kódu umístili i strojově čitelný kód pro čtečky. V prvním kole jsme tam měli jen moderní QR kód, ale brzy se zjistilo, že na některých pobočkách jsou ještě čtečky, které podporují jen standardní čárové kódy. Nakonec se nám povedlo nenásilně vložit na poukaz oba dva.

A co když si zákazník obdržený e-mail smaže nebo ztratí?

Abychom při této situaci předešli tomu, že bude zákazník psát na info e-mail nebo volat na infolinku a vytíží tak operátory, přichystali jsme v uživatelské sekci přehled všech historicky zakoupených poukazů i s možností dodatečného stažení samotného PDFka.

Uplatnění dárkového poukazu na e-shopu

Skvělé, jsme ve stavu, kdy si u nás zákazník koupil dárkový poukaz. Nyní nastává fáze, kdy má obdarovaný k dispozici dárkový poukaz a chce s ním uhradit část objednávky. Jak jsem už zmiňoval výše, při naší implementaci byl hlavní důraz na to, aby šel poukaz uplatnit jak na prodejně, tak na e-shopu.

Implementaci na prodejnách jsme přenechali spolupracující firmě se zaměřením na pokladní systém na prodejnách a my jsme se zaměřili na implementaci na e-shopu. Cílů pro začátek bylo několik:

• oproti situaci, kdy zákazník uplatňuje poukaz na prodejně a v případě nejasností má na místě zaučeného prodavače, který mu poradí, při uplatnění na e-shopu musí být vše co nejvíce intuitivní aby celý proces proběhl co nejhladší cestou
• dále jsme si dali za cíl posunout naši implementaci tak, abychom u nás odbourali omezení, která jsme zjistili z analýzy konkurence, případně které jsme znali z vlastních zkušeností. Mezi ty patří například:
  • uplatnění jen jednoho dárkového poukazu na objednávku
  • hodnota objednávky musí být stejná nebo vyšší než je hodnota uplatněného poukazu
  • hodnotu dárkového poukazu nelze čerpat postupně
  • dárkovým poukazem nelze zaplatit cena za vybranou dopravní metodu
  • atd.
• zvládnout vše správně po účetní stránce

Podařilo se nám cíle splnit? A kolik use-casů jsme museli vyřešit?

Místem, kde u nás může zákazník uplatnit dárkový poukaz jsou nakonec dvě stránky:

• první krok objednávky Košík
• druhý krok objednávky Výběr dopravy a platby

A jaké možné use-case jsme pro zákazníky řešili a připravili:

• zákazník může zadat 1 až N dárkových poukazů různých nebo stejných hodnot (případně může využít už použitý dárkový poukaz, na kterém mu zbyla nevyčerpaná hodnota)
• pokud je hodnota poukazu vyšší než hodnota objednávky, tak mu zbytková hodnota zůstane na dárkovém poukazu pro další využití. Hodnotu zůstatku zákazníkovi přímo zobrazujeme
• uplatněné dárkové poukazy má možnost z košíku odstranit a nakombinovat si je např. v jiném pořadí nebo složení
• při změně počtu kusů vloženého produktu do košíku se dynamicky přepočítává hodnota uplatněného dárkového poukazu a případně zbytkové hodnoty bez toho, aniž by dárkový poukaz z objednávky zmizel a musel se uplatnit znovu
• to stejné se děje, pokud si do košíku přidá další produkt a nebo z košíku produkt odebere. A to jak ručně, tak v rámci automatiky na pozadí, kdy se např. produkt stane v průběhu objednávky nedostupný.
• v rámci stránky košíku se dá dárkovým poukazem zaplatit jak samotný fyzický produkt, tak např. cena vybrané příplatkové finanční služby
• pokud je v objednávce zároveň uplatněný slevový poukaz a dárkový poukaz, tak je nastavené správné pořadí výpočtu. Nejprve se poníží cena objednávky/produktů o uplatněný slevový poukaz a teprve poníženou cenu hradíme dárkovým poukazem
• obdobně máme nastavené správné workflow při uplatnění věrnostních bodů
• na stránce Doprava a platba se po výběru dopravní metody vyhodnotí, zda je doprava placená a pokud ano, tak v případě již uplatněného dárkového poukazu se opět přepočte hodnota využití hodnoty dárkového poukazu. Pokud je ještě prostor, využije se hodnota z již načteného, pokud ne, tak má zákazník dvě možnosti:
  • může zadat další dárkový poukaz (bez potřeby se vracet na stránku Košíku)
  • a nebo může zbytkovou hodnotu objednávky zaplatit některou z nabídnutých plateb
• pokud dárkový poukaz pokryje vše, je na e-shopu ošetřeno, že se nezobrazí žádná klasická platební metoda, ale jen informace o tom, že je vše zaplaceno
• stejně jako možnost zaplatit dárkovým poukazem finanční služby u produktu (např. prodloužená záruky), je možné na stránce Doprava a platba zaplatit poukazem cenu za logistické služby (např. výnos do patra, instalace spotřebiče, atd.)
• každá změna opět vyvolá přepočet uplatněné hodnoty dárkových poukazů
• a další desítka use-case, které řeší další okrajové situace a různé kombinace výše zmíněných

Na konci objednávky, než dojde k finálnímu uložení, dochází k ověření, zda je hodnota uplatněných dárkových poukazů stále k dispozici a zda již nebyl poukaz pararelně využit na prodejně nebo při jiné objednávce. Pokud vše sedí, objednávka jde do finále a zákazník se může těšit na doručení své objednávky.

Technické výzvy na pozadí

Externí uložiště

Jak bylo zmíněno výše, jako uložiště dárkových poukazů byla zvolena externí služba. To znamenalo připravit se kromě implementace komunikace skrze REST API i na situace, kdy bude mít např. tato služba výpadek nebo bude po nějakou dobu nedostupná.

Ve finále máme tedy při nákupu dárkového poukazu všechny procesy na pozadí asynchronně zpracovávané skrze RabitMQ fronty a pokud systém neodpovídá, tak se ho opakovaně po předem určené délce intervalu doptáváme znovu, dokud od něj neobdržíme informace. Pro samotného zákazníka to není žádné omezení – ten má zaplaceno a jen čeká na obdržení dárkového poukazu.

Při uplatnění dárkového poukazu bylo naopak potřeba zajistit real-time komunikaci na úrovni uplatnění a zjištění aktuální dostupnosti hodnoty poukazu/poukazů a ve finále ověření, zda jsou uplatněné hodnoty k dispozici. Pokud systém neodpovídá, nedovolíme zákazníkovi poukaz uplatnit a informujeme ho o nedostupnosti systému. Zde si žádnou asynchronost dovolit nesmíme.

Je vidět, že externí uložiště má své výhody i nevýhody, ale je potřeba se připravit na všechny situace, aby se data o objednávce někde neztratila nebo abyste zákazníkovi nedovolili uhradit objednávku hodnotou, která už není k dispozici.

Doporučení: pokud i vy budete vybírat externí systém, dejte prioritu tomu, aby měl systém k dispozici obecné (REST) API, aby se na něj mohl připojit jakýkoliv externí systém a nebyl tam nějaký lock jen na vybrané systémy.

Jak zaslat e-mailem více dárkových poukazů nakoupených v jedné objednávce

V rámci zaslání poukazů v PDF e-mailem jsme řešili, jak se vypořádat s tím, pokud někdo nakoupí více kusů dárkového poukazů v jedné objednávce. Možnosti, které jsme zvažovali:

• v jednom emailu poslat jedno X-stránkové PDFko
• v jednom emailu poslat X samostatných PDFek
• poslat tolik emailů, kolik je zakoupených dárkových poukazů

Po pečlivé analýze, konzultace s kolegy a po zohlednění zkušeností z implementace firemních e-mailových schránek (které mívají většinou omezení na maximální počet příloh nebo velikost příloh) jsme sáhli po poslední variantě.  Příjemce (např. v podobě HR, sekretářky, orgranizátora akce, …) má tak možnost (pře)poslat každý email zvlášť a mít tak přehled, který už zpracovala a který ne.

Generování poukazů do PDF až na vyžádání

Předpokladem je, že zakoupených dárkových poukazů bude přibývat a bylo cílem zajistit, aby vygenerenované poukazy v PDF souborech nezabíraly prostor na serverovém disku. Proto máme implementaci udělanou tak, že PDF soubor generujeme vždy až na vyžádání a tím nám stačí mít uložená jen čísla dárkových poukazů. Jako sekundární výhodu bereme to, že můžeme v průběhu času měnit grafiku a nejsme tak svázání grafikou, která byla platná v moment zakoupení a nebo grafikou, na které bychom objevili nějakou technickou chybu (např. zjištění, že nové čtečky na prodejně nebudou podporovat čárové kódy, …)

Potkal nás při realizaci nějaký  „fuckup“?

I když se snažíme při každé implementaci zanalyzovat veškeré use-cases a myslet na vše, občas se stane, že vás při vývoji nějaký ten „fuckup“ potká. Bývá to častým tématem různých podcastů, kde na tento bod každý posluchač čeká, protože se chce poučit a nebo kolegiálně zasmát, že se to neděje jen jemu.

U nás to dlouho vypadalo, že se nic nestane. Při vývoji šlo vše podle plánu, první dny ostrého spuštění také bez problému, objednávky se zakládaly a nikdo nehlásil problém. Až cca po pár dnech od spuštění jsme ráno v monitoringu zaznamenali větší trafic na pozadí a větší záznam chyb právě z modulu dárkových poukazů. Po podrobné analýze jsme zjistili, že si nějaký „šikovný“ uživatel internetu napsal skript, skrze který zkoušel uhádnout čísla dárkových poukazů a automatizovaně zkoušel jejich uplatnění.

Naštěstí jsme to zjistili docela včas a nedošlo k větším komplikacím. Na naší straně ve spolupráci s externím systémem jsme ale zavedli dvě ošetření:

• na straně externího systému došlo ke změně generování čísel dárkových poukazů na náhodný výběr
• na naší straně jsme implementovali pro daný formulář reCaptcha ověření a i když to uživatelsky nevypadá úplně nejlépe, svůj účel to plní

Jaké je hodnocení po cca půl roce provozu?

Za sebe bych to shrnul do několika bodů:

• splnili jsme implementaci všech use-cases, které jsme si pro pilotní provoz tento rok stanovili a dokázali jsme společnými silami s klientem opět nachystat implementaci „na míru“ tak, jak jsme si přáli a nebyly jsme (snad kromě účetních věcí) svázáni žádnými limity
• jak na Electro Worldu, tak na Nay jsme stihli implementaci daleko před vánoční sezónou a zákaznici tak mohli tuto službu využívat už nějaký ten pátek. My jsme si zatím ověřili, že vše funguje a do vánoční sezóny jsme šli bez obav
• po ostrém nasazení nás, až na jednu technickou perličku, nepotkalo žádné překvapení a jak nákup, tak uplatnění funguje bez větších komplikací
• radost máme i z toho, že se potrdil předpoklad, že zákazníci využívají v objednávce více dárkových poukazů naráz (byl i příklad, kdy jich tam měl zákazník např. 4)
• potvrzuje se, že hlavní sezónou nákupů je období před Vánoci, ale desítky nákupů jsme měli i v srpnu a září. Tedy ještě před tím, než se spustila větší marketingová propagace na jejich umožněný nákup.

V oblasti dárkových poukazů jsme určitě nevyužili vše, co lze zákazníkům nabídnout a už nyní máme To-Do list plný nápadů, jaké další funkce doprogramovat. Jen je potřeba si opět stanovit priority napříč všemi nápady, abychom se posouvali ve všech oblastech.

Víte, že …

Modul dárkových poukazů není na námi vyvíjených e-shopech jen na zmiňovaném Electro Worldu a Nay, ale i na dalších. Pro představu zmíním e-shop Global-Wines, Hudy, Megapixel, Designville, ….

Důležité je zmínit, že každý projekt má svá specifika, specifické zadání a potřeby u klienta. A tak se vždy snažíme při návrhu a vývoji individuálně vyjít vstříc a udělat každou implementaci specifickou a přesně na míru danému klientovi.

S jakými „namírovkami“ se tedy můžete setkat na našich dalších projektech:

• uložiště a správa dárkových poukazů přímo v databázi e-shopu a administraci skrze naše CMS Publicator bez potřeby implementace a platby provozu externí služby
• nákup více dárkových poukazů různých hodnot v jedné objednávce
• nákup jak elektronických, tak papírových dárkových poukazů
• u vygenerovaných dárkových poukazů jiné grafické pozadí v generovaném PDFku pro každou hodnotu dárkového poukazu
• možnost vytvořit si v CMS šablonu nějakého dárkového poukazu a následně dodávat kódy mimo objednávkový proces s platbou např. na fakturu – primárně pro B2B zákazníky