Fagartikkel

Kundeportal: rask å bygge – dette bør den inneholde

En kundeportal med innlogging, roller og data fra systemene dere har, er ikke lenger et stort prosjekt. Det som avgjør verdien, er hva den inneholder.

For få år siden var en kundeportal en tung investering. Innlogging, rettigheter og integrasjoner mot ERP og CRM var håndarbeid, og mye av budsjettet gikk til det tekniske grunnarbeidet. Med AI i utviklingen er det meste av dette nå gjort på dager.

Det flytter spørsmålet. Når byggingen ikke lenger er flaskehalsen, er det valgene som avgjør verdien: hvilke spørsmål portalen skal svare på, hvem som skal se hva, og hva kundene skal kunne gjøre selv. Slik tar vi de valgene sammen med kundene våre.

Henvendelser fra kunder sortert etter tema, der de hyppigste blir innholdet i portalen

Start med det kundene spør om i dag

Det beste utgangspunktet for en kundeportal er innboksen og telefonloggen til kundeservice. Hvilke spørsmål kommer igjen og igjen? «Hvor er bestillingen min?», «Kan dere sende fakturaen på nytt?», «Hvilken avtale har vi?» Hvert slikt spørsmål er noe portalen kan svare på uten at noen hos dere må gjøre noe.

Lag en liste over de vanligste henvendelsene før dere bestemmer innholdet. Da bygger portalen på faktiske behov, og dere har et tall å måle mot når den er i drift.

Én innlogging som fordeler brukere til ulike roller med ulik tilgang

Bestem hvem som skal se hva

Selve innloggingen er rask å sette opp. Det som krever gjennomtenkning, er rollene. Er brukerne privatpersoner, eller ansatte i kundevirksomheter? I det siste tilfellet trenger dere som regel en administrator hos kunden som kan legge til og fjerne kolleger selv – ellers havner den jobben hos dere.

Rollene avgjør også hva hver bruker får se. En innkjøper trenger ordre og priser, en regnskapsmedarbeider trenger fakturaer. Tenk gjennom dette før dere starter, så blir resten enkelt.

Portalen koblet til et kildesystem, med flere systemer som kobles på

Koble på systemene dataene ligger i

Dataene kundene vil se, ligger nesten alltid i et annet system – ERP, CRM, regnskap eller et fagsystem. Koden som henter og oversetter dataene, var tidligere det dyreste i et portalprosjekt. I dag lages mye av den med AI-assistanse, og en integrasjon kan stå klar på dager.

Spørsmålet er derfor ikke lenger om dere har råd til å koble på et system, men hvilket system som eier sannheten. Står kundeadressen både i CRM og i økonomisystemet, må dere bestemme hvilket system som gjelder – og hvor en endring fra kunden skal havne.

Innsyn og handlinger som to lag med hver sine regler

Innsyn og selvbetjening krever ulike regler

Det er stor forskjell på at kunden kan se noe og at kunden kan endre det. Innsyn – status, historikk, dokumenter – handler bare om hvem som får se hva. Selvbetjening som endrer data i systemene deres, krever regler: hva må godkjennes, hvem får beskjed, og hva skjer når to endrer det samme.

Det er ikke tekniske spørsmål, men forretningsregler dere allerede har – de står bare ikke skrevet ned. Når de er avklart, er selve funksjonen raskt på plass.

Veikart der portalen er i bruk og nye funksjoner legges til underveis

Bygg videre mens den er i bruk

Fordi nye funksjoner er raske å legge til, trenger ikke portalen være komplett før den tas i bruk. Få den ut til kundene, se hva de bruker, og bygg videre fortløpende. Varsler, rapporter og en AI-assistent som svarer ut fra deres egen dokumentasjon, kan komme når dere ser hvor de gir mest.

Følg med på hvor mange som logger inn, hva de ser på, og hvilke henvendelser som forsvinner. Det er det beste grunnlaget for å velge neste steg.

Vi bygger kundeportaler, medlemsportaler og andre portaler rundt systemene kundene våre allerede har. Hva vi gjør og hvordan vi jobber, står på siden om kundeportaler og andre skreddersydde portaler.

Vurderer dere en portal, er en behovsprat et godt sted å starte. Ta gjerne med listen over spørsmålene kundene stiller oftest.