Klientský portál v praxi: co se opravdu změní v práci se zákazníky

Poznámky ze stavění klientských portálů pro menší a střední firmy — co se doopravdy změní v každodenní práci, které čtyři obrazovky nesou všechnu hodnotu a co jsem napoprvé udělal špatně.

Většina softwaru, který stavím klientům na míru, není nijak efektní. Nejčastěji užitečnou věcí napříč hodně odlišnými firmami se nakonec ukázala ta úplně nejnudnější: dejte jejich zákazníkům přihlášení.

Ne platformu. Přihlášení a čtyři obrazovky za ním.

Tohle jsem se naučil o tom, co se tím doopravdy změní — včetně toho, co mě překvapilo, a toho, co jsem udělal špatně.

Nemění se objem práce

Dřív jsem tyhle projekty prodával na ušetřeném čase. To zarámování je špatně a klienti, kteří si to kvůli tomu koupí, bývají zklamaní.

Dotazy, které portál pohltí, jsou jednotlivě drobné. "Kde je moje objednávka." "Můžete znovu poslat fakturu." "Na jakém termínu jsme se dohodli." Každý je na devadesát vteřin. Když je sečtete a vynásobíte, vyjde číslo, které vedle ceny stavby nevypadá působivě.

Co se opravdu změní, je kdy ta práce probíhá.

Předtím: dvanáct přerušení rozesetých přes celý den, každé přistává uprostřed něčeho jiného a každé stojí návrat do kontextu na obě strany. Poté: tutéž informaci si zákazník vezme ve 22:40 v neděli a nikomu se tím nerozbije úterý dopoledne.

To je reálný nárůst produktivity, který se v tabulce ušetřených minut neobjeví. Projeví se tím, že člověk, který byl celý den v reaktivním režimu, si najednou může naplánovat dopoledne.

Druhotný efekt, který nikdo nečeká

Tohle jsem nepředvídal: portál změní, co ví tým samotného klienta.

Aby šlo zákazníkovi ukázat přesný stav, musí někdo definovat, jaké stavy vůbec existují. Zní to triviálně. Není. Ve většině menších firem odpovídá na "kde je ta zakázka" člověk, který si to rekonstruuje z paměti, ze tří systémů a z odhadu. Žádný kanonický stav neexistuje, protože ho nikdy nikdo nemusel napsát.

Stavba portálu tu definici vynutí. A jakmile stavy existují a někdo je aktualizuje, firma má skoro mimochodem provozní přehled, o kterém už roky mluvila. Nejeden klient měl nakonec větší užitek z vlastního interního pohledu na ta data než ze samotné zákaznické části.

Když o portálu uvažujete: tohle je dnes argument, kterým bych začínal. Ne "vaši zákazníci se obslouží sami", ale "konečně budete vědět, kde co je".

Ty čtyři obrazovky

Každý portál, který jsem postavil a fungoval, obsahuje tyhle — a ty, co drřely na místě, obsahovaly víc:

  1. Stav. Kde ta věc je, jazykem, kterému zákazník rozumí. Ne "rozpracováno" — co se stalo, kdy, a co bude dál.
  2. Dokumenty. Faktury, smlouvy, dodací listy, zprávy. Čisté vyhledání, nulový úsudek — a potichu to zabije celou kategorii e-mailů.
  3. Historie. Co se objednalo, dohodlo nebo dodalo minule. Používá se méně často než ostatní, ale odstraňuje nejhorší úkol — hrabat se rok zpětně v e-mailech kvůli jedné odpovědi.
  4. Jedna akce. Objednat znovu, schválit, nahrát soubor. Přesně jedna, vybraná podle toho, co zákazník nejčastěji chce udělat jako další krok.

Cokoli navíc v první verzi je sázka — a sázka, kterou nemůžete vyhodnotit, protože ještě nemáte data o používání. Vypusťte čtyři obrazovky, měsíc pozorujte a pak přidejte to, po čem lidé opravdu sahají.

Tři věci, které jsem udělal špatně

Hesla. Můj první portál měl běžné přihlášení e-mailem a heslem včetně resetu. Používání bylo mizerné. B2B zákazník se přihlásí nanejvýš jednou za pár týdnů, takže heslo nemá ani ve svalové paměti, ani v prohlížeči — což znamená, že každá návštěva začíná resetovacím e-mailem. Magic links to spravily víc než jakákoli jiná změna. Když se zákazník přihlašuje zřídka, nenuťte ho nic si pamatovat.

Stavy, které byly přesné, ale k ničemu. Jednou jsem stavy v portálu namapoval přímo na interní výrobní stavy, protože to bylo to přesné řešení. Zákazníci viděli "Fáze 3" a volali, co to znamená. Přesné a k ničemu. Zákaznický stav potřebuje vlastní slovník psaný pro někoho, kdo ve firmě nepracuje — a musí říkat, co bude dál, protože to je skutečná otázka schovaná za "kde je moje objednávka".

Předpoklad, že oznámení rovná se používání. Jeden portál jsme spustili e-mailem. Za dva týdny se skoro nikdo nepřihlásil a závěr v místnosti byl, že zákazníci o to nestojí. Stali o to — jen zapomněli, že existuje. Fungovalo něco úplně obyčejného: odkaz šel do každého transakčního e-mailu a do každého podpisu a tým dva měsíce odpovídal na rutinní dotazy větou "právě jsem to aktualizoval v portálu, tady je odkaz". Používání je návyk, který trénujete, ne funkce, kterou nasadíte.

Kdy lidem říkám, ať portál nestaví

Tři situace, kdy jsem řekl ne — nebo měl říct:

  • Ta data ještě neexistují. Když stav zakázky žije v hlavě jednoho člověka, portál ho nemá co ukázat. Tohle je nejdřív systémový projekt a předstírat opak vede k portálu, který ukazuje zastaralé informace a do měsíce zničí důvěru.
  • Zákazníci nakupují jednou ročně. Portály se násobí opakováním. Kdo objednává jednou ročně, vždycky raději napíše e-mail, protože je to pro něj opravdu jednodušší — a má pravdu.
  • Nikdo nepřevezme odpovědnost za přesnost. Selhání po osmnácti měsících není, že se portál rozbije. Je to, že potichu zastará, zákazníci se zařídí podle špatných údajů a výsledek je horší než nic.

Co bych řekl majiteli firmy

Než cokoli jiného, udělejte to počítání. Jeden týden si odčárkujte každou příchozí otázku, na kterou byste odpověděli ukázáním na obrazovku. Když jich je méně než deset týdně, portál nestavte — napište si lepší šablony e-mailů a jděte dál. Když jich je třicet, máte případ — a je silnější, než ty minuty naznačují, protože to, co odstraňujete, není čas, ale roztříštěnost.

A vymezte to na čtyři obrazovky. Každý portál, který jsem viděl selhat — včetně mých — selhal tím, že byl brzy ambiciózní místo toho, aby byl brzy užitečný.