Průvodce návrhem B2B zákaznického portálu v 8 rozhodnutích

Obchodník v pondělí ráno opět odpovídá na stejné otázky: dorazila objednávka, je zboží skladem, kdy bude odesláno, je faktura ke stažení. Mezitím zákazník posílá novou objednávku e-mailem a kolega ručně přenáší data do ERP. Tento průvodce návrhem B2B zákaznického portálu nezačíná tím, jaké rozhraní je vhodné vyvinout, ale tím, který obchodní proces je třeba dát do pořádku.

Skutečná hodnota dobře navrženého zákaznického portálu nespočívá v přihlašovací obrazovce nebo působivém katalogu produktů. Měří se tím, že je méně opakovaných dotazů, kratší zpracování objednávek, přesnější data a zákazníci pracují se stejnými informacemi jako interní tým. K tomu je však nejprve nutné pochopit fungování.

1. Neptejte se na portál, ale na úkol zákazníka

Většina projektů B2B portálů začíná příliš obecnými požadavky: „zákazníci by měli mít možnost objednávat online“. To samo o sobě nestačí jako základ pro rozhodnutí. Jiný systém potřebuje velkoobchod s náhradními díly, kde zákazník objednává podle katalogového čísla, a jiný výrobce, kde každá objednávka zahrnuje smluvní ceny, specifikace, schválení a harmonogramy dodávek.

Je vhodné začít sledováním cesty zákazníka. Na co se nejčastěji ptá? Jaký dokument hledá? Kdo schvaluje objednávku u zákazníka? Kdy se zjistí, že produkt není dostupný? Kdy musí zasáhnout obchodník, logistika nebo finance?

Cílem není převést všechny stávající e-maily a telefonáty na digitální formuláře. Mnoho otázek přichází proto, že zákazník nedostává včas srozumitelné informace. Jiné kroky zůstaly v procesu pouze z historických důvodů. Pokud objednávka vyžaduje tři interní schválení, ale dvě kontrolují stejná data, portál to nevyřeší. Nejprve je třeba zjednodušit proces.

2. Zmapujte, odkud pochází pravda

Zákaznický portál způsobuje problémy s důvěrou, když ukazuje něco jiného než to, co vidí zákaznický servis nebo sklad. Na portálu je zboží skladem, ale ve skutečnosti není. Stav objednávky je „zpracovává se“, zatímco už byla předána dopravci. Faktura není ke stažení, protože byla vytvořena v jiném systému.

Proto je třeba již na začátku návrhu určit vlastníka každého kritického údaje. Ceny obvykle spravuje ERP nebo cenový systém. Údaje o skladových zásobách mohou pocházet z podnikového systému nebo ze skladového systému. Zdroj stavu dodávky může být logistický partner, aplikace pro plánování dopravy nebo interní skladový proces. Dokumenty musí mít také jasné místo: smlouvy, doklady, technické listy, certifikáty kvality a reklamace by neměly být v několika nezávislých složkách.

Není nutné zobrazovat všechny údaje v reálném čase. Denní synchronizace technického dokumentu, který se mění zřídka, může být dostatečná. U skladových zásob nebo stavu objednávky však může být zpoždění obchodním rizikem. Správné řešení vždy závisí na rychlosti daného procesu, důsledcích chyb a očekáváních zákazníků.

3. Oprávnění je obchodní pravidlo, ne dodatečné nastavení

V B2B prostředí nemusí být zákazník nutně jediným uživatelem. Nákupčí může objednávat, finanční pracovník může stahovat faktury, vedoucí pobočky může vidět pouze objednávky své jednotky a ředitel společnosti může požadovat kompletní přehled. Pokud tyto role nejsou předem naplánovány, portál buď uvolní příliš mnoho informací, nebo bude nepoužitelně rigidní.

Model oprávnění musí odpovídat organizační realitě. Kdo může vidět smluvní ceny? Kdo může zadávat objednávky? Je nutné interní schválení nad určitou částku? Má mateřská společnost přístup ke všem dceřiným společnostem? Co se stane, když zaměstnanec u zákazníka odejde?

To je zároveň otázka bezpečnosti, obchodu a provozu. Zvláště pokud jsou na portálu dostupné individuální ceny, platební informace, historie objednávek nebo citlivé technické dokumenty. Pravidelná revize oprávnění proto není administrativní zátěží, ale úkolem pro zajištění kontinuity podnikání.

4. První verze by neměla umět všechno

Jedním z nejdůležitějších praktických pravidel návrhu B2B zákaznického portálu je, že první vydání by mělo řešit jasně vymezený problém. Příliš široký projekt může vést k dlouhé době vývoje, mnoha výjimkám a obtížnému zavádění.

Dobrým prvním cílem může být například samoobslužný přístup k historii objednávek a fakturám, zjednodušení opakovaných objednávek nebo přehledné zobrazení stavu dodávky. To jsou funkce, u kterých lze měřit dopad: kolik e-mailů a telefonátů přišlo dříve, kolik minut trvalo odeslání dokumentu, kolik chyb způsobilo ruční zadávání objednávek.

Složitější prvky - například konfigurovatelné produkty, odlišné pracovní postupy pro jednotlivé partnery, zpracování reklamací nebo individuální žádosti o nabídku - mohou být zařazeny do pozdější fáze. Ne proto, že by byly méně hodnotné, ale protože je vhodné je prioritizovat na základě skutečných zkušeností s používáním.

5. Plánujte i výjimky

Normální proces objednávky zřídka představuje největší výzvu. Problémy se objevují u výjimek: částečné dodávky, náhradní produkty, překročení úvěrového limitu, změněný termín, vrácení zboží, odlišná dodací adresa nebo sporná faktura. Pokud musí zákazník kvůli těmto věcem vždy psát e-mail, není to samo o sobě neúspěch. Ne všechny výjimky je třeba automatizovat.

Otázkou je, zda portál jasně ukazuje, co se stalo, jaký je další krok a kdo za něj odpovídá. Například reklamační formulář je málo, pokud odesílatel nedostane číslo případu, stav nebo časový rámec pro odpověď. Žádost o změnu také snižuje interní zátěž pouze tehdy, pokud se správné informace dostanou ke správnému týmu bez ručního kopírování dat.

6. U integrací záleží i na chybové cestě

Mnoho společností již má ERP, CRM, e-shop, fakturační, skladový systém a spojení s dopravci. Otázkou není, zda lze vše nahradit, ale mezi kterými systémy by měl zákaznický portál zprostředkovávat a s jakými pravidly.

Při navrhování integrace nestačí nakreslit úspěšný přenos dat. Je třeba také zaznamenat, co se stane, pokud se objednávka nedostane do ERP, pokud stav dorazí se zpožděním z partnerského systému nebo pokud je v produktovém kmeni chybný údaj. Kdo dostane oznámení? Jak lze chybu opravit? Existuje protokol a sledovatelná historie událostí? Kdy je nutná lidská kontrola?

Tato část je méně viditelná, ale díky ní je portál spolehlivý. Objednávka, která se ztratí v tichosti, nebo neviditelná synchronizační chyba mohou poškodit vztahy se zákazníky více než nový digitální rozhraní.

7. Pro zavedení jsou potřeba interní odpovědné osoby

Zákaznický portál není pouze IT projekt. Může se týkat prodeje, zákaznického servisu, financí, logistiky a skladu. Pokud jsou rozhodnutí činěna pouze z pohledu vývoje, snadno se opomenou obchodní pravidla, která dnes zkušený kolega drží v hlavě.

Je vhodné jmenovat správce procesu, který nejen schvaluje funkce, ale je také odpovědný za provozní cíl. Stejně důležitý je pilot s malou skupinou skutečných zákazníků. Není třeba měřit pouze to, zda se mohou přihlásit, ale také zda je méně dotazů, rychlejší objednávky, srozumitelnější stav a kde se zasekávají.

Nelze vynechat ani interní tým. Pokud portál přidává nové úkoly zákaznickému servisu nebo nevyjasňuje zpracování výjimek, práce se pouze přesune na jiný kanál. Cílem dobrého zavedení je, aby kolegové poskytovali méně opakovaných informací a věnovali více pozornosti záležitostem, které skutečně vyžadují hodnotu.

8. Výsledek měřte provozními ukazateli

Návštěvnost a přihlášení jsou užitečná data, ale nedokazují, že portál zlepšil fungování podniku. Je třeba jít blíže k procesu. Lze měřit počet ručních zadání objednávek, množství dotazů na stav, poměr chyb v objednávkách, dobu zpracování žádostí o dokumenty a zatížení zákaznického servisu.

Na základě ukazatelů se může ukázat, že úzké místo není na rozhraní portálu. Možná jsou údaje o zásobách nepřesné, pravidla schvalování příliš pomalá nebo údržba zákaznické databáze nedostatečná. To není selhání projektu, ale cenná diagnóza toho, kde se informace skutečně zasekávají.

Dobrý zákaznický portál není digitální výkladní skříň. Je to kontrolovaný provozní bod, kde si zákazník může samostatněji vyřizovat rutinní záležitosti a podnik může pracovat s spolehlivějšími daty, méně ručními přenosy a jasnějšími odpovědnostmi. Dalším užitečným krokem proto nemusí být příprava specifikace vývoje, ale zjištění, který zákaznický proces dnes způsobuje nejvíce opakované práce a nejistoty.