Klient sa do portálu zvyčajne neprihlási preto, aby obdivoval dashboard. Potrebuje zistiť stav, nahrať dokument, potvrdiť termín alebo schváliť podklad. Keď prvá verzia tento krok neskráti, pribudne mu ďalšie heslo a vášmu tímu ďalší kanál.
Začnite preto jednou cestou klienta. Napríklad dodaním podkladov k žiadosti alebo schválením návrhu pred realizáciou. Až potom rozhodujte o chate, platbách, mobilnej aplikácii a ďalších možnostiach.
Tento postup používame pri návrhu klientskych portálov. Pomáha ohraničiť prvú verziu a pripraviť pilot, ktorého výsledok sa dá pozorovať.
Vyberte úlohu, kvôli ktorej klient dnes píše
Prejdite posledné e-maily a telefonáty. Zoskupte otázky podľa toho, čo klient potreboval urobiť. „Ako to vyzerá?“ je iná úloha než „posielam opravenú prílohu“ alebo „kto u nás môže schváliť ponuku?“
Vyberte opakujúcu sa úlohu, pri ktorej existuje jasný začiatok a koniec. Pri dopĺňaní podkladov je začiatkom výzva a koncom prijatie správnej verzie dokumentu. Samotné nahratie súboru ešte nemusí znamenať dokončenie.
Určte aj interného vlastníka. Ak klient urobí svoj krok, niekto vo firme musí vedieť, čo nasleduje. Portál bez nadväzujúceho interného postupu iba presunie nevybavenú požiadavku z e-mailu na inú obrazovku.
Stav musí mať zdroj a význam
Klientovi nepomôže stav „spracúva sa“, ktorý sa nemení celé týždne. Potrebuje vedieť, čo už prebehlo, čo sa deje teraz a či sa čaká naňho. Interné pracovné skratky môžete preložiť do jednoduchšieho jazyka.
Pri každom zobrazovanom stave určte, z ktorého systému pochádza. Ak tím pracuje v CRM, portál má čítať jeho dohodnuté údaje. Ak je zdrojom ručná evidencia, treba vyriešiť jej aktualizáciu skôr než sľúbite aktuálny stav.
Zvážte aj oneskorenie. Údaj synchronizovaný raz denne má inú hodnotu než údaj dostupný okamžite. Klientovi zobrazte čas poslednej aktualizácie tam, kde môže zastaraný údaj ovplyvniť jeho rozhodnutie.
Dokumenty potrebujú viac než tlačidlo nahrať
Pri každom požadovanom dokumente vysvetlite, čo má obsahovať a aké sú povolené formáty či veľkosť. Po nahratí klient potrebuje potvrdenie, že súbor dorazil. Potom môže nasledovať kontrola vaším tímom.
Rozlíšte stavy „nahrané“, „na kontrolu“, „prijaté“ a „treba doplniť“, ak ich váš postup potrebuje. Pri vrátení podkladu musí klient vidieť konkrétny dôvod a ďalší krok. Inak sa pôvodná e-mailová výmena zopakuje v portáli.
Určte, ako sa nahrádza staršia verzia. Pri schvaľovanom návrhu musí byť jasné, ktorú verziu klient potvrdil. Dôležité rozhodnutie nesmie zostať naviazané na súbor, ktorého obsah niekto neskôr potichu zmení.
Najprv firma a rola, potom obrazovka
V B2B portáli môže mať zákazník nákupcu, prevádzkového manažéra a účtovníka. Jeden schvaľuje rozsah, druhý sleduje realizáciu a tretí potrebuje doklady. Zdieľané prihlasovacie údaje tieto rozdiely nezachytia.
Pred návrhom určte, kto pozýva ďalších používateľov a kto odoberie prístup bývalému kolegovi. Zvážte viac pobočiek a prípad, keď človek zastupuje viac klientskych firiem. Tieto vzťahy sa opravujú ťažšie po tom, čo systém používa celý zákaznícky tím.
Oprávnenia musia chrániť údaje aj mimo obrazovky, napríklad pri stiahnutí súboru cez priamy odkaz. OWASP odporúča overovať oprávnenia pri každej požiadavke. Odporúčania pre autorizáciu sú užitočným podkladom pre technickú kontrolu dodávateľa.
Prvá verzia nemusí obsahovať chat
Chat má zmysel iba vtedy, ak ho tím dokáže obsluhovať a správy majú miesto v pracovnom postupe. Inak klient nevie, či má napísať do portálu, odpovedať na e-mail alebo telefonovať.
Pre začiatok môže stačiť komentár ku konkrétnej požiadavke. Jeho výhodou je kontext: obe strany vedia, o ktorý dokument alebo prípad ide. Upozornenie e-mailom klienta privedie späť na správne miesto.
Rovnakú otázku položte pri AI asistentovi. Ak klient potrebuje iba aktuálny termín a zoznam chýbajúcich dokumentov, tieto údaje majú byť viditeľné priamo. Asistent môže neskôr pomôcť s orientáciou v širšom obsahu.
Integrácia má mať jasnú hranicu
Spíšte, ktoré údaje portál číta a ktoré môže meniť. Napríklad stav zákazky iba zobrazuje, no kontaktné údaje klient aktualizuje sám. Pri zmene adresy určte, či sa upraví len kontakt alebo aj už potvrdená objednávka.
Pre prvú verziu overte jednu reprezentatívnu operáciu cez existujúce API. Dohodnite správanie pri chybe a opakovanom odoslaní. Dvojklik klienta nesmie nechtiac vytvoriť dve rovnaké požiadavky.
Logá nástrojov na webe nie sú dôkazom funkčnej integrácie. Potrebujete vidieť konkrétny prenos, správne oprávnenia a použiteľný výsledok. Podklady môžete pripraviť podľa briefu pre softvérové štúdio.
Modelový rozsah prvého portálu
Predstavte si firmu, ktorá od klientov zbiera podklady k zákazke. Prvý rozsah môže obsahovať pozvánku používateľa, zoznam jeho zákaziek, stav jednej zákazky a požadované dokumenty. Klient nahrá súbor a dostane potvrdenie. Tím podklad prijme alebo vráti s vysvetlením.
Do pilotu nemusíte pridávať platby, kalendár, všeobecný chat ani mobilnú aplikáciu. Tieto funkcie majú vlastný prínos, ale nepatria automaticky do každej prvej verzie. Rozhodujte podľa úlohy, ktorú práve overujete.
Novuma ukazuje konkrétne prepojenie rezervácie, záznamov a výsledkov vyšetrení. Emerge predstavuje ďalší typ organizačnej platformy. Referencie pomáhajú pochopiť možnosti, no rozsah vášho portálu odvodíme z práce vašich klientov.
Ako vyhodnotiť pilot
Pozvite malú skupinu klientov, ktorí majú aktuálnu úlohu. Sledujte dokončenie, čas do prijatia podkladu a počet správ potrebných na vysvetlenie. Zapisujte aj dôvody, prečo niekto portál nepoužil.
Počet vytvorených účtov nestačí. Podstatné je, či klient zvládol dohodnutú cestu a či sa práca vášho tímu skutočne zjednodušila. Až podľa toho pridávajte ďalšie možnosti.
Ukážte nám päť opakujúcich sa klientskych otázok. Spoločne vyberieme jednu cestu, ktorá má patriť do prvej verzie, a určíme údaje potrebné na jej dokončenie.
