Hvordan går vi fra en idé om kundeportal til en løsning kundene faktisk bruker?
En kundeportal er nyttig når den løser noe kundene ellers må ringe, sende e-post eller vente på. Denne guiden går fra idé til første versjon i fem steg, med spørsmål, eksempler og en sjekkliste for tilgang, data og universell utforming.
- Passer for
- Virksomheter som vurderer en innlogget løsning for kunder, eller som har en portal som brukes lite.
- Dere ender med
- En første versjon av en kundeportal som løser kundenes vanligste behov, med avklart tilgang, og som er testet med ekte brukere.
- Hvem bør være med
- Kundeservice, noen kunder, den som eier systemene portalen henter data fra, en utvikler og den som har ansvar for personvern.
Før dere begynner
En kundeportal er en innlogget del av nettstedet der kundene selv kan se og gjøre ting, for eksempel følge en ordre, laste ned fakturaer eller melde inn en sak. Målet er at kundene får svar raskere, og at dere får færre rutinehenvendelser.
Mange portaler blir lite brukt fordi de viser det som var lett å bygge, ikke det kundene trengte. Derfor starter denne guiden med kundene og ender med en første versjon dere kan lære av. Eksemplene er tenkte og laget for å illustrere.
Steg 1 av 5
Finn ut hva kundene faktisk spør om
Den beste kilden er henvendelsene dere allerede får. Gå gjennom e-post, telefonnotater og saker fra de siste månedene, og sorter dem etter tema. Det som går igjen oftest, og som kan besvares med informasjon dere allerede har, er gode kandidater for portalen.
Snakk også med noen kunder. Spør hva de bruker tid på i kontakten med dere, ikke hvilke funksjoner de ønsker seg. Ønskelister blir lange; problemer er lettere å prioritere.
- Hvilke fem spørsmål får vi oftest?
- Hvilke av dem kan besvares med data vi allerede har?
- Hva må kundene i dag vente på?
- Hvilke kunder ville brukt en portal, og hvor ofte?
Et servicefirma går gjennom tre måneder med henvendelser. De vanligste temaene er: Når kommer teknikeren? Kan jeg få kopi av fakturaen? Hva er status på saken min? Kan jeg flytte avtalt tid? De tre første kan besvares med data fra systemene firmaet allerede har.
Steg 2 av 5
Avgrens første versjon
Velg de to eller tre behovene som gir mest nytte, og bygg bare dem først. En liten portal som løser noe viktig godt, blir brukt. En stor portal som løser mye halvveis, blir det sjelden.
Skriv ned hva som ikke er med i første versjon, og hvorfor. Det gjør det lettere å si nei til nye ønsker underveis, og gir en naturlig liste til neste runde.
- Hvilke to eller tre behov gir mest nytte for kundene?
- Hva kan vente til neste versjon?
- Hva må kundene kunne gjøre, og hva holder det at de kan se?
Med: se kommende besøk, se status på saker og laste ned fakturaer. Ikke med nå: flytte avtalt tid (krever endringer i planleggingssystemet) og chat (krever bemanning). Flytting av tid vurderes på nytt når portalen har vært i bruk en stund.
Steg 3 av 5
Avklar data, integrasjoner og tilgang
Portalen viser data fra andre systemer, for eksempel ordre-, saks- eller økonomisystemet. Avklar hvilket system som eier hver opplysning, hvordan dataene hentes, og hvor oppdaterte de må være.
Tilgangsstyring er et av de viktigste sikkerhetsspørsmålene: Hver kunde skal bare se sine egne data. Feil i denne typen tilgangskontroll står øverst på OWASPs liste over de mest kritiske sikkerhetsrisikoene i API-er, grensesnittene portalen bruker for å hente data [1]. Bestem også hvordan kundene logger inn, og hvem hos kunden som skal ha tilgang. Behandler en ekstern leverandør personopplysninger for dere, trengs normalt en databehandleravtale [2].
- Hvilke systemer skal portalen hente data fra?
- Hvordan logger kundene inn, og hva skjer når noen slutter hos kunden?
- Kan én bedriftskunde ha flere brukere med ulike rettigheter?
- Hvilke personopplysninger vises, og hvem behandler dem?
En bedriftskunde har tre brukere. Daglig leder skal se fakturaer og alle saker. To ansatte skal bare se saker de selv har meldt inn. Når en ansatt slutter, må kunden selv kunne fjerne tilgangen, eller ha en enkel måte å si fra på.
Steg 4 av 5
Bygg, og test med ekte brukere
Test tidlig med noen få kunder, gjerne med en enkel prototype før alt er ferdig. Gi dem en konkret oppgave, som «finn fakturaen fra mars», og se hvor de stopper opp.
Planlegg også for universell utforming. Likestillings- og diskrimineringsloven gir både private og offentlige virksomheter plikt til universell utforming av sine viktigste IKT-løsninger for brukerne, for eksempel nettsider og apper, med mindre det blir en uforholdsmessig stor byrde [3]. De tekniske kravene og hvilke løsninger som omfattes, står i forskrift, så avklar tidlig hva som gjelder for akkurat deres portal. Universell utforming betyr blant annet at portalen kan brukes med tastatur og skjermleser, og at tekst og kontraster er lette å lese. Det er enklere å bygge inn fra start enn å rette etterpå.
- Klarer testpersonene de viktigste oppgavene uten hjelp?
- Kan portalen brukes med bare tastatur og med skjermleser?
- Fungerer den like godt på mobil?
- Hva ser kunden når data mangler eller et system er nede?
Fire av fem testpersoner fant ikke fakturaene fordi de lå under «Dokumenter». Menyvalget ble endret til «Fakturaer og dokumenter». En testperson som brukte skjermleser, fikk ikke beskjed om at en sak hadde endret status. Det ble rettet før lansering.
Steg 5 av 5
Lanser, mål og forbedre
Lanser gjerne til en mindre gruppe kunder først. Fortell dem hva de kan bruke portalen til, og gjør det lett å gi tilbakemelding. Mål det dere satte som mål: færre henvendelser om temaene portalen dekker, hvor mange som logger inn, og hvilke funksjoner som brukes.
Bestem på forhånd hvem som eier portalen etter lansering, og hvem som følger med på feil, tilganger og oppdateringer. En portal er ikke ferdig når den lanseres. Det er første versjon som er ferdig.
- Hvilke tall viser om portalen hjelper?
- Hvem følger med på feil og tilbakemeldinger?
- Hvordan rydder vi tilganger når kunder avslutter?
- Hva skal neste versjon løse?
Servicefirmaet ser at mange kunder sjekker kommende besøk, men at få laster ned fakturaer. Henvendelser om besøkstid går ned, mens fakturaspørsmålene er like mange som før. Neste versjon prioriterer derfor å sende fakturalenke på e-post i stedet for å bygge mer i portalen.
Sjekkliste før dere starter
0 av 11 på plass. Ingenting lagres eller sendes.
En nyttig kundeportal starter med det kundene allerede spør om. Hold første versjon liten, ta tilgang og universell utforming på alvor fra start, og la bruken avgjøre hva som bygges videre.
Kilder
Les videre
- SystemintegrasjonerVi kobler systemene, så riktige data kommer til riktig sted og avvik blir synlige med en gang, i stedet for at noen taster det samme inn flere ganger.
- AI i produkterVi bygger AI inn i portalen, plattformen eller nettbutikken dere har, så brukerne finner svar, får forslag og gjør ferdig oppgaver uten å lete.
- Hva gode systemintegrasjoner kreverEn integrasjon som virker i en test, er ikke det samme som en integrasjon dere kan stole på i hverdagen. Her er sju krav som skiller de pålitelige fra de skjøre, med eksempler, avveininger og en sjekkliste å bruke før dere bestiller eller bygger.
Vurderer dere en kundeportal?
Start med listen over hva kundene oftest spør om. Den er det beste grunnlaget for å bestemme hva første versjon skal inneholde.
Vil dere heller skrive? Utforsk en idé · Still et spørsmål