Kliento savitarnos portalas: kada jo tikrai reikia?

Kliento savitarnos portalas yra prisijungimu apsaugota erdvė, kurioje jūsų klientai patys pamato statusą, įkelia dokumentus, parašo žinutę ir atlieka veiksmus, nesiųsdami jums dar vieno el. laiško. Tai vieta, kur kliento kelionė tęsiasi po to, kai kontaktų forma jau užpildyta.

Daugelis įmonių ilgai išsiverčia su el. paštu, bendrais aplankais ir šiek tiek rankinės priežiūros. Tai veikia, kol nustoja veikti. Kai dokumentai išsibarstę po ilgus el. laiškų siūlus, klientai vėl ir vėl klausia to paties, o niekas tiksliai nežino, kieno eilė daryti kitą žingsnį, tada el. paštas jau tapo sistema. Tik prasta.

Wevo kuria kliento savitarnos portalus kaip individualias webaplikacijas: su prisijungimu, vaidmenimis, dokumentų srautu, statusu ir integracija su sistemomis, kurias jau naudojate. Šiame straipsnyje apžvelgiu, kada toks portalas iš tikrųjų apsimoka ir ką jis turėtų apimti.

Kas yra kliento savitarnos portalas?

Kliento savitarnos portalas yra prisijungimu apsaugota erdvė, kurioje klientai patys mato informaciją, įkelia failus, seka statusą, siunčia žinutes ar atlieka su bendradarbiavimu susijusias užduotis. Tai ne nauja svetainė. Tai darbo erdvė, kuri perima estafetę, kai vieša svetainė jau atliko savo darbą ir lankytojas tapo klientu.

Buhalterinė įmonė vienoje vietoje gali kaupti sąskaitas, terminus ir parašus. Statybos įmonė gali rodyti eigą, nuotraukas ir sprendimus po apžiūros. Didmenininkas gali leisti nuolatiniams klientams patiems matyti užsakymus, sąskaitas ir pristatymo statusą. Nekilnojamojo turto valdytojas gali dalintis sutartimis, sąskaitomis ir gedimų pranešimais su nuomininkais. Visus šiuos atvejus vienija tai, kad kažkas vyksta po pirmojo kontakto ir kad tas kažkas kartojasi.

Kada klientai turėtų prisijungti patys?

Savitarnos portalas yra tinkamas sprendimas, kai klientams dažnai reikia statuso, dokumentų, žinučių ar veiksmų po pirmojo kontakto. Jei visas bendravimas su klientu tėra vienas pardavimas ir šiek tiek pagalbos, el. pašto ilgai pakaks. Bet jei klientas grįžta vėl ir vėl paklausti, pasidalinti ar sekti eigą, portalas atsiperka sutaupytu laiku.

Štai signalai, kurių ieškau, kai įmonė svarsto, ar jau atėjo laikas. Jei atpažįstate tris ar daugiau, atsakymas paprastai yra taip.

• El. paštas tampa archyvu: dokumentai, žinutės ir sprendimai išsibarstę po ilgus siūlus, kurių niekas nebesuranda.
• Klientai patys klausia apie statusą: darbuotojai vis atsako į tą patį, nes statuso niekur nesimato.
• Failai siunčiami nesaugiai: jautrūs ar svarbūs dokumentai keliauja per atsitiktinius kanalus ir laikinas saugyklas.
• Atsakomybė neaiški: niekas nežino, ar kitas žingsnis priklauso klientui, įmonei ar darbuotojui.

Atkreipkite dėmesį, kad nė vienas iš šių signalų nesusijęs su technologijomis. Jie susiję su kasdiene trintimi. Portalas tampa atsakymu, kai ta trintis pakankamai didelė, kad kainuoja jums valandas kas savaitę, o klientai pradeda jausti, kad priežiūra chaotiška.

Ką kliento savitarnos portalas sutaupo?

Labiausiai nuvertinama nauda yra mažiau el. laiškų ir skambučių apie dalykus, kuriuos klientas galėjo pamatyti pats. Kai statusas ir dokumentai matomi, dingsta didelė dalis klausimų. Darbuotojams nebereikia būti gyva žinių knyga. Klientams nebereikia laukti atsakymo darbo valandomis dėl dalyko, kurį jie tiesiog norėjo patikrinti.

Tas pats principas slypi ir vertinant individualų sprendimą ar standartinę programą. Savitarnos portalą verta kurti, kai pasikartojančio darbo pakankamai daug ir kai tas darbas būdingas būtent jums. Jei jis toks pat kaip visų, standartinis paketas tai padarys greičiau ir pigiau.

Vaidmenys ir prieiga: kas ką mato?

Savitarnos portalo patikimumą lemia prieigos valdymas. Pirmiausia kartu su klientu apibrėžiu ne ekranus, o vaidmenis: kas yra klientas, kas darbuotojas, kas administratorius ir ar yra išorinių partnerių, kuriems reikia ribotos, laikinos prieigos. Kai vaidmenys aiškūs, likusią portalo dalį sukurti teisingai tampa daug lengviau.

Nekilnojamojo turto valdytojo atveju nuomininkas mato savo sutartis ir sąskaitas, o pastato prižiūrėtojas mato gedimų pranešimus, bet nemato finansų. Buhalterinės įmonės atveju verslo klientas mato savo sąskaitas, o išorės auditorius gauna prieigą prie apibrėžto duomenų rinkinio apibrėžtam laikotarpiui. Esmė paprasta: niekas neturėtų matyti ar galėti daugiau, nei jam reikia.

1. Apibrėžkite, kurie klientai turėtų prisijungti ir ką jiems ten reikia daryti.
2. Sukurkite vaidmenis klientui, darbuotojui, administratoriui ir galimiems išoriniams partneriams.
3. Nuspręskite, kokius dokumentus, žinutes ir statuso laukus turėtų matyti kiekvienas vaidmuo.
4. Suplanuokite saugų prisijungimą, žurnalus ir duomenų minimizavimą dar prieš pradedant kurti.
5. Sukurkite pirmąją versiją aplink dažniausiai naudojamas užduotis ir plėskite pagal realų naudojimą.

Dokumentai ir statusas: savitarnos portalo šerdis

Kai klausiu įmonės, ką portalas visų pirma turėtų išspręsti, beveik visada atsakymas yra dokumentai ir statusas. Klientas nori pats įkelti ir vėl surasti failus. Įmonė nori parodyti, kur yra užklausa. Abu nori nespėlioti. Čia savitarnos portalas duoda naudą greičiausiai, ir dažniausiai čia rekomenduoju pradėti.

Statybos įmonė, nuolat skelbianti eigos nuotraukas ir sprendimus, išvengia dešimčių klausimų apie statusą kiekviename projekte. Buhalterinė įmonė, rodanti, kokių dokumentų trūksta prieš terminą, išvengia priminimų rato. Geras dokumentų srautas nėra archyvas. Tai bendras supratimas, kas jau padaryta ir kas dar liko.

Statusas veikia geriausiai, kai jis konkretus. Ne „vykdoma“, o „laukiama jūsų dokumentų“ arba „paruošta pasirašyti“. Aiškus statusas pasako klientui kitą žingsnį be nė vieno papildomo klausimo. Tai ta pati logika, kuri slypi už geros individualios webaplikacijos: sistema turi pašalinti spėliojimą. Jei jis tiesiog persikelia pas kitą darbuotoją, nieko nelaimėjote.

Integracijos: savitarnos portalas negali stovėti vienas

Portalas, kuris atrodo moderniai, bet kuriame darbuotojai vis tiek rankiniu būdu kopijuoja duomenis toliau, tik perkėlė darbą kitur. Tikra nauda atsiranda, kai portalas kalbasi su sistemomis, kurias jau naudojate: CRM, apskaitos, dokumentų saugyklos, mokėjimų ir pranešimų sistemomis.

Didmenininkas nori, kad portale pateiktas užsakymas atsidurtų užsakymų sistemoje be rankinio įvedimo. Buhalterinė įmonė nori, kad įkelti dokumentai automatiškai susietųsi su teisingu klientu apskaitos sistemoje. Būtent tokie ryšiai skiria gražų fasadą nuo įrankio, kuris taupo laiką. Kaip saugiai kuriamos integracijos su mokėjimų, apskaitos ir CRM sistemomis, plačiau rašau API integracijoje mokėjimams ir CRM.

Saugumas ir prisijungimas

VDAI (Valstybinė duomenų apsaugos inspekcija) pabrėžia integruotos duomenų apsaugos ir duomenų minimizavimo principus, įtvirtintus BDAR. Todėl savitarnos portalas turėtų būti kuriamas su vaidmenimis, prieiga ir žurnalais nuo pat pradžių, o ne pritvirtinamas vėliau. Kai klientai prisijungia ir dalinasi dokumentais, saugumas tampa pamatų dalimi, o ne kontroliniu sąrašu pačioje pabaigoje.

• Saugus prisijungimas su teisingu slaptažodžių ir sesijų tvarkymu.
• Vaidmenys ir prieiga, kad niekas nematytų daugiau, nei turėtų.
• Svarbių veiksmų žurnalai, kad būtų atsekama, kas ką padarė.
• Duomenų minimizavimas: rinkite tik tai, ko portalui reikia.
• Aiškios trynimo procedūros, kai kliento santykiai pasibaigia.

Prieš prijungdami portalą prie esamos svetainės, patikrinkite, ar pati svetainė šiuo požiūriu tvarkinga. Nemokama svetainės saugumo analizė parodo, ar formos, prieigos ir serverio nustatymai jau atlaiko papildomą, prisijungimu apsaugotą erdvę, ar pirmiausia reikia sutvarkyti pamatus.

Dažniausios klaidos, kurias matau, nėra sudėtingos saugumo spragos. Tai kasdieniai sprendimai, kurie susikaupia. Štai spąstai, kurių saugausi.

• Per daug funkcijų: portalas tampa sunkus, kol klientai dar neišmoko pagrindinės eigos.
• Per silpnas prieigos valdymas: klientai gali matyti ar daryti daugiau, nei turėtų.
• Per mažai pranešimų: niekam nepranešama, kai kažkas įkelta ar pakeista.
• Prasta integracija: portalas atrodo moderniai, bet darbuotojai vis tiek turi kopijuoti duomenis.

Taip wevo kuria kliento savitarnos portalą

Pradedu nuo vaidmenų ir dažniausiai naudojamų užduočių. Ilgas pageidavimų sąrašas lieka antram etapui, kai jau matyti, kas naudojama kasdien. Pirmoji versija apima tai, ką klientai daro kiekvieną savaitę: prisijungia, randa dokumentus, mato statusą, siunčia žinutę. Vėliau plečiame remdamiesi tuo, kaip portalas naudojamas. Prielaidos apie tai beveik visada klysta. Portalas, augantis kartu su poreikiu, tampa ir pigesnis prižiūrėti, ir lengvesnis klientams išmokti.

Kliento savitarnos portalas yra teisingas kitas žingsnis, kai kliento kelionė tęsiasi po kontaktų formos, o el. paštas nebėra pakankamai gera darbo erdvė. Jei norite tai sukurti teisingai nuo pat pradžių, portalas priklauso individualių sistemų reikalavimams. Taip gausite sprendimą, atlaikantį ir klientus, ir saugumą, ir tolesnį augimą.