Jak připravit zadání pro e-shop nebo B2B portál

Cíl a obchodní model

Než se řeší funkce a design, je potřeba ujasnit, kdo bude přes web nakupovat a za jakých podmínek. Veřejný B2C nebo D2C e-shop, přihlášený B2B portál pro firemní odběratele a jejich kombinace vyžadují odlišné nastavení cen, oprávnění i objednávkového procesu.

• ›Popište, zda jde o veřejný e-shop, přihlášený B2B portál, nebo o kombinaci obou (veřejná část a přihlášená firemní sekce).
• ›Uveďte, zda se u firemních odběratelů počítá s registrací na základě schválení, nebo s otevřenou registrací.
• ›Zmiňte hlavní obchodní cíl řešení – rozšíření prodejních kanálů, přenesení opakovaných objednávek z e-mailu a telefonu do systému, nebo obojí.
• ›Ujasněte, zda se řešení má integrovat s existující kamennou prodejnou nebo obchodním týmem, a jak se mají role doplňovat.

Katalog, SKU, varianty a datová kvalita

Kvalita a struktura katalogových dat rozhoduje o tom, jak rychle a spolehlivě půjde katalog naplnit a udržovat. Zadání by mělo popsat rozsah sortimentu a stav dat, ne jen počet produktů.

• ›Uveďte přibližný počet produktů, kategorií a variant (barva, velikost, balení, provedení).
• ›Popište, odkud pocházejí produktová data (interní systém, dodavatelský ceník, ruční zadávání) a v jakém jsou stavu.
• ›Zmiňte, zda existuje jednotné číslování SKU a zda se shoduje napříč e-shopem, skladem a účetnictvím.
• ›Ujasněte, zda se katalog liší podle typu zákazníka (např. část sortimentu jen pro firemní odběratele).
• ›Popište požadavky na obrázky, technické parametry, dokumenty ke stažení a jejich zdroj.

Cenotvorba, slevy a DPH

Cenotvorba je jedním z hlavních rozdílů mezi e-shopem a B2B portálem. Zatímco veřejný e-shop obvykle pracuje s jednou cenou pro všechny, B2B portál často potřebuje individuální ceníky podle odběratele nebo skupiny odběratelů.

• ›Uveďte, zda existují veřejné ceny pro všechny, nebo se pracuje s individuálními ceníky podle zákazníka či skupiny.
• ›Popište slevové hladiny a to, podle čeho se přiřazují (obrat, smlouva, obchodník, ruční nastavení).
• ›Zmiňte, zda se uplatňují množstevní ceny (cena podle objednaného množství nebo balení).
• ›Ujasněte práci s DPH – zobrazení cen s DPH nebo bez, různé sazby podle sortimentu, ceny pro zahraniční odběratele.
• ›Uveďte, zda se má pracovat s více měnami a jak se kurz aktualizuje.

Uživatelské role, oprávnění a schvalování objednávek

U B2B portálu často nenakupuje jedna osoba, ale více lidí v rámci jedné firmy s různými pravomocemi. Zadání by mělo popsat, jaké role existují a kdo objednávky schvaluje.

• ›Popište uživatelské role (např. objednávající, schvalovatel, administrátor firemního účtu) a jejich oprávnění.
• ›Uveďte, zda objednávka nad určitou hodnotu vyžaduje schválení nadřízenou osobou nebo více osobami.
• ›Zmiňte, zda si firemní účet spravuje sám svoje uživatele, nebo je spravuje dodavatel či obchodní tým.
• ›Popište, zda mají různí uživatelé v rámci jedné firmy vidět stejné, nebo odlišné ceny a sortiment.

Košík, objednávkový proces a opakované objednávky

Objednávkový proces u B2B odběratelů často potřebuje jiné nástroje než běžný e-shopový košík, protože firmy typicky objednávají opakovaně stejné nebo podobné položky ve větším množství.

• ›Popište kroky standardního objednávkového procesu a to, co je v každém kroku povinné.
• ›Uveďte, zda má portál umožňovat rychlé objednání podle čísla produktu nebo hromadné vložení položek ze seznamu.
• ›Zmiňte, zda se má nabízet opakování dřívější objednávky nebo uložené oblíbené sestavy položek.
• ›Popište, zda existují rozpracované košíky sdílené mezi více uživateli jedné firmy.
• ›Uveďte, zda se pracuje s minimální hodnotou objednávky nebo balicími jednotkami.

Platby a fakturace

Platební možnosti u B2B odběratelů obvykle zahrnují i platbu na fakturu se splatností, což vyžaduje jinou logiku než platba kartou u veřejného e-shopu.

• ›Uveďte požadované platební metody (karta, převod předem, platba na fakturu, jiné).
• ›Popište, zda se u platby na fakturu pracuje s kreditním limitem odběratele a co se stane po jeho vyčerpání.
• ›Zmiňte, zda se faktury generují automaticky v portálu, nebo je vystavuje účetní systém a portál je jen zobrazuje.
• ›Ujasněte, zda mají firemní odběratelé přístup k historii faktur a přehledu splatností v rámci svého účtu.

Doprava, výdejní místa, reklamace a vratky

Doprava a poprodejní procesy patří k částem, které se snadno podcení v zadání, přestože ovlivňují spokojenost zákazníka stejně jako samotný nákup.

• ›Uveďte požadované způsoby dopravy a to, zda se liší podle typu zákazníka nebo objemu objednávky.
• ›Popište, zda se mají nabízet výdejní místa nebo osobní odběr a odkud pocházejí jejich data.
• ›Zmiňte, jak má fungovat reklamační proces – zda přes portál, e-mail, nebo obojí.
• ›Ujasněte, zda B2B odběratelé řeší vratky a reklamace jinak než koncoví zákazníci (např. přes svého obchodního zástupce).

Integrace na okolní systémy

E-shop nebo B2B portál málokdy funguje samostatně – obvykle je napojený na řadu dalších systémů, které spravují data o produktech, objednávkách, zákaznících a skladu.

• ›Uveďte, zda se má propojit s ERP systémem, a jaká data se mají synchronizovat (produkty, ceny, sklad, objednávky).
• ›Popište napojení na CRM, pokud se sdílejí data o zákaznících nebo obchodních příležitostech.
• ›Zmiňte propojení se skladovým systémem a to, jak často se má aktualizovat dostupnost zboží.
• ›Uveďte, zda účetní doklady vznikají v účetním systému, nebo v e-shopu, a jak se předávají.
• ›Popište napojení na dopravce (generování štítků, sledování zásilek) a na e-mailingovou platformu (transakční a marketingové e-maily).

Migrace dat a URL adres

Pokud vzniká náhrada za existující e-shop nebo portál, zadání by mělo popsat, co se má z původního řešení převzít, aby se neztratila historická data ani pozice ve vyhledávání.

• ›Uveďte, zda se mají migrovat produktová data, zákaznické účty, historie objednávek nebo jen jejich část.
• ›Popište, zda existuje aktuální export dat z původního systému a v jakém je formátu.
• ›Zmiňte, zda se mají zachovat stávající URL adresy produktů a kategorií, nebo se počítá s přesměrováním na nové adresy.
• ›Ujasněte, kdo migraci dat věcně kontroluje a kdo potvrzuje, že proběhla úplně a správně.

Obsah, jazyky a trhy

Rozsah obsahu a počet jazykových mutací ovlivňuje strukturu i způsob správy katalogu, proto by to zadání mělo řešit spolu s cílovými trhy.

• ›Uveďte, pro které trhy a v jakých jazycích má e-shop nebo portál fungovat.
• ›Popište, zda se produktové texty a popisky liší podle trhu, nebo se překládají z jedné výchozí verze.
• ›Zmiňte, jaký doprovodný obsah má web mít mimo katalog (návody, často kladené dotazy, obchodní podmínky pro jednotlivé trhy).
• ›Ujasněte, kdo bude obsah a jeho jazykové mutace dlouhodobě spravovat po spuštění.

Měření, analytika a souhlasy

Měření chování zákazníků a objednávek je u e-shopu i B2B portálu klíčové pro další rozhodování, ale musí respektovat pravidla pro souhlasy, zejména pokud jde o přihlášené firemní uživatele.

• ›Uveďte, jaké metriky a konverze se mají sledovat (dokončené objednávky, opuštěné košíky, opakované nákupy).
• ›Popište, zda existuje přístup k datům z předchozího řešení pro srovnání.
• ›Zmiňte požadavky na souhlas s používáním cookies a sledováním, včetně specifik pro přihlášené firemní účty.
• ›Ujasněte, kdo bude po spuštění vyhodnocovat naměřená data a k jakým rozhodnutím mají sloužit.

Přístupnost a výkon

Přístupnost a výkon ovlivňují, zda katalog s velkým množstvím produktů zůstane použitelný pro všechny zákazníky, včetně těch, kteří používají asistivní technologie nebo pomalejší připojení.

• ›Uveďte, zda existují požadavky na přístupnost (např. z důvodu veřejného sektoru nebo interní politiky firmy).
• ›Popište očekávané chování katalogu při velkém počtu produktů, filtrů a souběžných uživatelů.
• ›Zmiňte, zda se má počítat s výrazně odlišným výkonem pro mobilní zařízení, například u terénních obchodních zástupců.

Provoz, podpora, role na straně klienta a akceptační kritéria

Zadání by mělo popsat i to, co se stane po spuštění – kdo řešení provozuje, kdo řeší podporu uživatelů a podle čeho se pozná, že je řešení hotové a připravené k předání.

• ›Uveďte, kdo bude po spuštění zajišťovat běžný provoz, aktualizace a řešení chyb.
• ›Popište, kdo na straně klienta odpovídá za správu katalogu, cen a uživatelských účtů.
• ›Zmiňte, jak se má řešit podpora koncových a firemních zákazníků (kdo ji poskytuje a jakým kanálem).
• ›Ujasněte akceptační kritéria – podle čeho se pozná, že je objednávkový proces, platby a integrace funkční a připravené ke spuštění.

Nejčastější chyby v zadání

• ✕Zadání neuvádí, zda jde o veřejný e-shop, přihlášený B2B portál, nebo obojí, takže se špatně odhaduje rozsah rolí a cenotvorby.
• ✕Chybí popis stavu produktových dat, takže se podcení čas potřebný na přípravu a čištění katalogu.
• ✕Není jasné, zda existují individuální ceníky a slevové hladiny, takže se cenotvorba řeší až za chodu.
• ✕Zadání neřeší schvalování objednávek u firemních odběratelů, přestože je to pro B2B provoz zásadní.
• ✕Chybí informace o integraci na ERP nebo sklad, takže se dostupnost zboží a ceny neshodují s realitou.
• ✕Migrace dat a URL adres z původního řešení není v zadání zmíněná vůbec.
• ✕Zadání neurčuje, kdo bude po spuštění spravovat katalog, ceny a uživatelské účty.
• ✕Akceptační kritéria nejsou popsaná, takže není jasné, podle čeho se pozná, že je řešení hotové.

Co může zadání zbytečně prodražit

• ✕Nekonzistentní nebo nekompletní produktová data, která je nutné dodatečně čistit a doplňovat.
• ✕Individuální ceníky a slevové hladiny zadané pozdě, po návrhu základní cenotvorby.
• ✕Vícekolové schvalování objednávek popsané až v průběhu vývoje, ne v zadání.
• ✕Integrace na ERP, sklad nebo účetnictví objevené až po zahájení prací na katalogu a objednávkách.
• ✕Migrace historických objednávek a účtů zadaná dodatečně, bez předchozí analýzy zdrojových dat.
• ✕Vícejazyčný a vícetrhový obsah přidaný do rozsahu až po dokončení struktury katalogu.
• ✕Opakované změny v uživatelských rolích a oprávněních poté, co je proces objednávání už navržený.

Checklist zadání

• ✓Je jasné, zda jde o veřejný e-shop, přihlášený B2B portál, nebo o kombinaci obou?
• ✓Je popsaný rozsah katalogu, struktura SKU a stav zdrojových dat?
• ✓Je uvedeno, zda existují veřejné ceny, individuální ceníky a slevové hladiny?
• ✓Je ošetřená práce s DPH a případně s více měnami?
• ✓Jsou popsané uživatelské role, oprávnění a schvalování objednávek?
• ✓Je popsaný objednávkový proces včetně opakovaných a rychlých objednávek?
• ✓Jsou uvedené požadované platební metody včetně platby na fakturu a kreditních limitů?
• ✓Je popsaná doprava, výdejní místa, reklamace a vratky?
• ✓Jsou vyjmenované potřebné integrace na ERP, CRM, sklad, účetnictví, dopravce a e-mailing?
• ✓Je popsaná migrace dat a URL adres z původního řešení?
• ✓Je jasné, pro které trhy a jazyky má řešení fungovat?
• ✓Jsou uvedené požadavky na měření, analytiku a souhlasy?
• ✓Jsou zmíněné požadavky na přístupnost a výkon při větším počtu produktů a uživatelů?
• ✓Je určeno, kdo bude řešení po spuštění provozovat a spravovat?
• ✓Jsou popsaná akceptační kritéria pro předání řešení?

Časté otázky

Jak poznám, jestli potřebuju e-shop, nebo B2B portál?

Rozhoduje o tom, kdo bude nakupovat a za jakých podmínek. Pokud prodáváte jednotlivým zákazníkům za veřejné ceny, jde o e-shop. Pokud nakupují přihlášené firmy s individuálními ceníky a schvalováním objednávek, jde o B2B portál. Řada projektů obojí kombinuje v jednom řešení.

Musíme mít hotová všechna produktová data předem?

Data nemusí být dokonalá, ale zadání by mělo popsat jejich aktuální stav a zdroj, aby šlo reálně odhadnout, kolik práce bude jejich příprava a čištění vyžadovat.

Je nutné mít individuální ceníky hned od začátku?

Ne, ale pokud se s nimi počítá i jen do budoucna, je lepší to uvést v zadání. Přidávat cenotvorbu podle odběratele až po návrhu základní logiky bývá výrazně náročnější než ji zohlednit od začátku.

Jak řešit platbu na fakturu u firemních odběratelů?

Zadání by mělo popsat, zda se má pracovat s kreditním limitem, jak se odběratel k platbě na fakturu dostane a co se stane, když limit vyčerpá. Tyto detaily ovlivňují návrh objednávkového procesu i integraci na účetní systém.

Co se stane, pokud v zadání chybí popis integrací?

Integrace na ERP, sklad nebo účetnictví patří k částem, které se nejhůř dodávají dodatečně, protože ovlivňují datový model celého řešení. Bez jejich popisu v zadání hrozí, že dostupnost zboží nebo ceny nebudou odpovídat realitě.

Musíme řešit migraci dat, i když jde o úplně nové řešení?

Pokud nahrazujete existující e-shop nebo portál, migrace produktových dat, účtů a případně URL adres patří do zadání vždy – jinak hrozí ztráta historických objednávek nebo propad ve vyhledávání kvůli změně adres.

Jak podrobně máme v zadání popisovat akceptační kritéria?

Stačí popsat, podle čeho poznáte, že objednávkový proces, platby a integrace fungují tak, jak mají – tedy co je potřeba otestovat a kdo výsledek potvrzuje před spuštěním.