Hodnotenie vývojára zákazníckeho portálu podľa 8 kritérií

Zákazník požiada e-mailom o kópiu faktúry, telefonicky sa informuje o stave objednávky a iný kolega vyhľadáva údaje k zmluve z Excelu. Medzitým sa zákazník pýta: prečo to všetko nevidí na jednom mieste? Hodnotenie vývojára zákazníckeho portálu v takejto situácii nie je predovšetkým otázkou dizajnu alebo programovania. Rozhoduje sa, či spoločnosť buduje nový, udržateľný prevádzkový kanál, alebo len umiestňuje digitálne rozhranie pred existujúci vnútorný chaos.

Dobre navrhnutý portál môže znížiť opakované dopyty, zlepšiť informovanosť zákazníka a spresniť vnútornú prácu. Zle pripravený portál však generuje nové výnimky, paralelné údaje a zaťaženie podpory. Preto pri výbere vývojára je potrebné skúmať, či partner rozumie, ako sa informácie skutočne pohybujú medzi predajom, zákazníckym servisom, skladom, financiami a zákazníkom.

Prečo nestačí vizuálny návrh a hodinová sadzba?

Na portáloch je rozhranie len tá časť, ktorú vidí zákazník. Prevádzkové riziko je zvyčajne za ním: ktorý systém je vlastníkom údajov, kedy sa aktualizuje stav objednávky, kto môže vidieť faktúru alebo zmluvu a čo sa stane, ak integrácia dočasne nie je dostupná.

Nižšia ponuka na vývoj môže byť niekedy skutočne dobrým obchodným rozhodnutím. Vtedy, ak je proces jednoduchý, je potrebné sa pripojiť k málo systémom a spoločnosť presne pozná svoje požiadavky. Ak však portál musí zobrazovať údaje z ERP, CRM, e-shopu, skladového systému alebo z vlastných záznamov, zdanlivo lacný začiatok môže neskôr priniesť drahé úpravy.

Správny partner netvrdí, že na každú požiadavku treba okamžite vybudovať aplikáciu. Najprv skúma, či zákazník skutočne potrebuje danú funkciu a či je vnútorný proces dostatočne jasný na to, aby sa dal digitalizovať.

Hodnotenie vývojára zákazníckeho portálu s 8 obchodnými otázkami

1. Pýta sa vývojár najprv na proces?

Varovným signálom je, ak sa prvé stretnutie týka výlučne položiek menu, farieb a prihlasovacej obrazovky. Tieto sú potrebné detaily, ale nie sú východiskovými bodmi. Skúsený partner sa pýta: aké zákaznícke dopyty chcú znížiť, aké údaje musí zákazník mať k dispozícii samostatne a ktoré vnútorné kroky spúšťa požiadavka podaná na portáli.

Ak napríklad zákazník zaznamenáva reklamáciu, nestačí vytvoriť formulár. Je potrebné vedieť, kto dostane prípad, aké údaje sú potrebné na prešetrenie, ako sledovať stav a v akých prípadoch je potrebné ľudské rozhodnutie. Z toho vyplýva, či ide o funkciu portálu, vnútorný workflow alebo oboje.

2. Zisťuje, odkiaľ prichádzajú údaje?

„Stav objednávky“ často znamená viacero systémov. Podľa e-shopu je objednávka zaplatená, podľa systému riadenia podniku je v spracovaní, podľa skladu čaká na komisionovanie a podľa kuriérskej služby už bola odovzdaná. Vývojár musí nielen získavať údaje, ale aj spoločne určiť, čo ktorý stav znamená pre zákazníka.

Opýtajte sa, či sa pripravuje mapa zdrojov údajov a model zodpovednosti. Ktorý systém je primárnym záznamom? Ako často sa údaje synchronizujú? Kto skúma odchýlky? Toto nie sú technické drobnosti, ale podmienky dôvery zákazníka.

3. Dokáže rozlíšiť štandard od individuálnej požiadavky?

Nie každý proces, ktorý prináša konkurenčnú výhodu, si vyžaduje individuálny softvér. Niekedy by bolo vhodné existujúce zákaznícke rozhranie systému, len je zle nastavené alebo nie je pripojené k potrebným zdrojom údajov. Inokedy práve špeciálne ceny, servisný proces alebo partnerský systém oprávnení spoločnosti odôvodňujú vlastný portál.

Dobrý vývojár sa nesnaží aplikovať jeden nástroj na všetky problémy. Jasne vysvetľuje, ktoré prvky je vhodné riešiť štandardnými komponentmi a kde je odôvodnený individuálny vývoj. To neskôr ovplyvňuje modifikovateľnosť, náklady a prevádzkové riziko.

4. Ujasňuje oprávnenia a obchodné výnimky?

Na B2B zákazníckom portáli často nie je len jeden používateľ. Môže to byť nákupca, finančný kontakt, vedúci prevádzky a externý partner na tej istej zákazníckej strane. Nie všetci môžu vidieť rovnaké ceny, faktúry, zmluvy alebo servisné údaje.

Pri hodnotení vývojára sa pozrite, ako rieši role, schvaľovacie pravidlá a výnimočné prípady. Čo sa stane pri zlúčení spoločností? Kto môže požiadať o nového používateľa? Aká je kontrola, ak má zákazník viac právnych subjektov? Dobre fungujúci portál nie je bezpečný tým, že má heslo, ale tým, že pravidlá prístupu sú jasné a kontrolovateľné.

5. Má metódu na validáciu požiadaviek?

Mnoho projektov sa oneskorí, pretože objednávateľ a vývojár používajú ten istý výraz, ale rozumejú mu inak. „Úprava objednávky“ môže znamenať zmenu množstva, prepis dodacej adresy, zrušenie, kontrolu úverového limitu alebo ich kombináciu.

Opýtajte sa, ako sa z predpokladov stanú akceptované prevádzkové pravidlá. Používajú procesné diagramy, konkrétne obchodné príklady, prototypy alebo testovateľné akceptačné kritériá? Cieľom nie je množstvo dokumentácie, ale zistenie nedorozumení ešte pred vývojom.

6. Plánuje aj na čas odovzdania, riešenia chýb a prevádzky?

Portál sa nestáva hotovým systémom v deň go-live. Používateľské otázky, problémy s oprávneniami, nové obchodné požiadavky a aktualizácie externých systémov prichádzajú aj neskôr. Ak nie je určená zodpovednosť, monitorovanie, logovanie a riadenie zmien, spoločnosť sa rýchlo opäť uchýli k ručným kontrolám.

Stojí za to konkrétne sa opýtať na model podpory. Kto sleduje chyby integrácií? Ako sa spoločnosť dozvie, ak sa zákazníkovi zobrazia nesprávne údaje? Existuje postup obnovy a testovacie prostredie pre zmeny? Obchodná kontinuita nie je samostatná služba, ale súčasť rozhodnutia o vývoji.

7. Vie hovoriť o bezpečnosti spolu s obchodnými dôsledkami?

Bezpečnosť sa nevyčerpáva tým, že systém funguje na šifrovanom spojení. Zákaznícky portál môže spracovávať obchodné údaje: históriu objednávok, ceny, finančné dokumenty, technické súbory alebo osobné údaje. Neoprávnený prístup nie je len technický incident, ale môže byť aj zmluvným, reputačným a dokonca prevádzkovým problémom.

Spoľahlivá odpoveď je, ak vývojár hovorí o správe prístupu, logovaní, uchovávaní údajov, zálohách a zodpovednosti za aktualizácie. Detaily závisia od odvetvia a citlivosti údajov, ale otázky nemožno odložiť na koniec projektu.

8. Vie určiť merateľný obchodný výsledok?

„Modernejší zákaznícky zážitok“ sám o sebe nestačí na riadenie projektu. Je vhodné na začiatku zaznamenať, akú zmenu očakávajú: zníženie počtu žiadostí o kópiu faktúry, skrátenie času na dohodnutie stavu objednávky, zlepšenie presnosti údajov alebo väčšiu prehľadnosť otvorených servisných prípadov.

Nie všetky výhody sú okamžite merateľné v eurách. Hodnotou je aj to, ak pracovník zákazníckeho servisu nestráca dopoludnie hľadaním, ale môže riešiť zložité prípady. Ukazovatele však pomáhajú rozlíšiť skutočné zlepšenie prevádzky od toho, že jednoducho dostali nové rozhranie pre staré problémy.

Na čo si dať pozor pri čítaní referencie a ponuky?

Referencia je užitočná, ak neukazuje len snímku obrazovky, ale aj vyriešenú prevádzkovú situáciu. Koľko systémov bolo prepojených? Aký model oprávnení bol potrebný? Ako riešili problémy s kvalitou údajov? Čo sa zmenilo v práci zákazníckeho servisu alebo vnútornej administratívy?

Pri ponuke hľadajte aj hranice. Čo presne patrí do vývoja, čo je predpokladom integrácie, kto poskytuje testovacie údaje a čo sa považuje za neskoršiu zmenu? Nejasná ponuka sa môže krátkodobo zdať pohodlná, ale neskôr spôsobuje spory o zodpovednosti a nákladoch.

V prístupe CGAT portál nie je samostatnou digitálnou výkladnou skriňou, ale súčasťou prevádzky spoločnosti. Preto je pred vývojom vhodné sledovať cestu, ktorú skutočne prejde zákaznícka požiadavka a k nej prislúchajúce údaje.

Najlepším ďalším krokom často nie je žiadosť o ponuku od vývojára, ale výber piatich až desiatich bežných zákazníckych požiadaviek. Pozrite sa, odkiaľ začínajú, koľko ľudí je zapojených, v ktorých systémoch sa objavujú a kde je dnes potrebné manuálne prenášať informácie. Ak je tento obraz jasný, hodnotenie vývojára zákazníckeho portálu sa stáva oveľa lepšie podloženým rozhodnutím.