Průvodce vývojem B2B portálu bez slepých uliček

B2B portál často vzniká ve chvíli, kdy obchodní tým přestává zvládat objednávky v e-mailech, zákazníci volají kvůli dostupnosti a data žijí v několika tabulkách. V tu chvíli nemá smysl začínat výběrem technologie ani kreslením úvodní stránky. Nejdřív je potřeba říct, co se má přestat dělat ručně a kdo za jednotlivé kroky odpovídá.

Portál může zákazníkovi sloužit k objednávkám, obchodníkovi jako denní nástroj a provozu jako zdroj dat. Bez priorit se tyhle potřeby snadno smíchají a projekt nabobtná. Technicky něco běží, ale vedle toho dál žije Excel a výjimky se řeší po telefonu.

Co má B2B portál vyřešit dřív, než se začne stavět

B2B portál se od běžného e-shopu s přihlášením liší prakticky ve všem podstatném. Ceny bývají individuální, objednávky mohou čekat na schválení, u jednoho zákazníka je víc uživatelů a pravidla se liší podle smlouvy, země nebo typu partnera. Distributor často potřebuje hlavně rychlé opakování objednávek. Výrobce konfiguraci, technické dokumenty a dostupnost. Ve službách jde spíš o požadavky, smlouvy a faktury.

Nejdřív chceme znát konkrétní tok práce. Kdo založí zákazníka? Kde vzniká ceník? Co se stane po odeslání objednávky? Kdo ji může změnit, zastavit nebo schválit? A co má zákazník vidět, když se dodávka zpozdí? Odpovědi rovnou ovlivní datový model, oprávnění i to, které integrace budou nutné.

Dobré zadání nemusí mít stovky stran. Musí ale oddělit standardní proces od výjimky. Výjimky bolí hlavně tehdy, když je objevíte až po spuštění. Někdy je levnější upravit interní postup, než do systému zabalit složité pravidlo, které použijí dva lidé několikrát za rok.

Začněte procesy a daty

Nejčastější chyba je popsat portál jako seznam obrazovek: katalog, košík, profil, administrace. Obrazovky přijdou až potom. Nejdřív musí být jasné, odkud berete pravdu o produktech, cenách, skladu, zákaznících a objednávkách. Jestli ERP drží skladovou dostupnost, portál ji nemá vést bokem. Jestli obchodník spravuje podmínky v CRM, musí být jasné, jak a kdy se propíšou.

Integrace často určují rozsah víc než samotné UI, takže je nemá smysl odkládat na konec. Starší ERP může dávat jen omezené rozhraní, data můžou být neúplná nebo se aktualizují jednou denně. To nemusí projekt zabít. Musíte ale přiznat dopad: když se sklad obnovuje v noci, zákazníkovi nemůžete slibovat stav z poslední minuty.

U každé integrace si vyjasněte:

• která data se přenášejí a který systém je vlastní,
• jak často se změny synchronizují,
• co se stane při výpadku nebo chybě přenosu,
• kdo chybu uvidí a kdo ji dokáže vyřešit.

Integrace, která funguje jen za ideálních podmínek, v provozu nestačí. Potřebuje záznamy o chybách, možnost dohledat konkrétní objednávku a jasnou odpovědnost u systémů i u lidí. Podrobněji o tom píšeme u API integrace systémů.

Role nejsou jen zákazník a administrátor

Jeden odběratel může mít nákupčího, člověka ke schválení, účetní s přístupem k fakturám a provozního pracovníka, který jen hlásí reklamaci. U vás obchodník často vidí jen svoje portfolio, zatímco finance řeší limity a splatnost.

Oprávnění proto stavíme podle rozhodnutí, ne podle názvů pozic. Má uživatel vidět ceny? Objednává za celou firmu, nebo jen za vybrané provozovny? Smí schválit objednávku nad limit? Může stáhnout faktury? Každá odpověď sahá do bezpečnosti i do toho, jestli se v portálu vůbec dá pracovat.

Příliš hrubá oprávnění vedou ke sdíleným účtům. Příliš jemný systém rolí zase zahltí administraci. U menší sítě partnerů stačí pár jasných rolí. U větší struktury často dává smysl řešit přístup po organizacích, pobočkách nebo skupinách zákazníků.

Rozsah první verze: stavět celé, ale ne všechno

První produkční verze nemusí pojmout všechny nápady z workshopů. Musí ale dotáhnout jeden hodnotný pracovní tok. Zákazník najde svoje produkty, vidí správné ceny, odešle objednávku, firma ji zpracuje a zákazník pak vidí stav. K tomu musí fungovat účet, správa přístupů a provozní administrativa.

Pokročilé reporty, složité konfigurátory, individuální dashboardy nebo automatizace vzácných výjimek můžou počkat, pokud neblokují hlavní proces. Už v návrhu dat a architektury ale ověřte, že jejich doplnění později nebude znamenat přepsat základ. Co stavět dřív, rozebírá i článek o funkcích B2B platformy.

Prioritu určuje frekvence a dopad. Funkce, která ušetří dvě minuty u každé z tisíců objednávek, má často větší cenu než efektní přehled, na který se vedení podívá jednou za měsíc. Totéž platí u zákonné povinnosti nebo rizika chybného nacenění — to má přednost před kosmetikou.

Kdy nestačí upravit existující e-shop nebo ERP

Někdy dává smysl rozšířit to, co už máte. Standardní produkty, jednoduché cenové hladiny a málo specifických procesů — úprava existujícího řešení bývá rychlejší. Jindy se B2B pravidla začnou vrstvit: individuální smlouvy, víc entit zákazníka, schvalování, servisní požadavky, návaznost na výrobu nebo specifická cenotvorba.

Pak může být levnější postavit samostatnou aplikaci napojenou na ERP a další systémy, než dál ohýbat nástroj navržený pro jiný způsob práce. Rozhodují náklady na změny v dalších letech, provozní riziko a to, jestli dokážete reagovat na obchodní požadavky bez zásahu do kritického jádra firmy. Kdy se tahle sázka vyplatí, je v článku kdy se B2B portál na míru vyplatí.

Technologie má sloužit provozu, ne prezentaci

Technologický návrh hlavně rozhoduje o tom, jak půjde portál provozovat po spuštění. Potřebujete mít pod kontrolou přístupy, zálohy, monitoring chyb, aktualizace závislostí a nasazování nových verzí. U systému s objednávkami, cenami nebo osobními údaji je to stejně důležité jako obrazovka košíku.

Portály stavíme jako produkční aplikace, ne jako jednorázovou zakázku k předání. API, databáze a administrace musí jít rozvíjet bez neustálých zásahů do nejcitlivějších částí. Zároveň nemá smysl budovat složitou infrastrukturu pro proces, který firma teprve ověřuje na několika zákaznících.

Bezpečnost musí být konkrétní: přihlášení a obnova hesla, vícefaktorové ověření tam, kde to riziko dává, audit citlivých změn, oddělená oprávnění a bezpečné napojení na okolní systémy. Stejně důležité je vědět, kdo spravuje uživatele, jak řešíte odchod zaměstnance u zákazníka a kdo sahá na provozní data.

Spuštění je teprve začátek ověřování

Před ostrým nasazením je lepší začít s vybranou skupinou zákazníků, než otevřít portál všem najednou. Nesledujte jen chyby. Dívejte se, kde lidé váhají, které údaje jim chybí a které kroky pořád obcházejí e-mailem. Opakuje-li se stejný dotaz, obvykle to není „hloupý uživatel“ — systém nebo proces něco neříká dost jasně.

Připravte i interní provoz. Obchodníci musí vědět, kdy zákazníka poslat do portálu a kdy objednávku převzít jinak. Podpora potřebuje vidět, co zákazník viděl a provedl. Bez toho nový kanál jen přidá další vrstvu práce.

Nejužitečnější portál vznikne tak, že vyberete jeden obchodně důležitý tok, dotáhnete ho do reálného provozu a pak ho podle používání zpřesňujete — ne tak, že do první verze nacpete všechny požadavky.