Begynd med det, kunden skal kunne selv
Du vil gerne samle dokumenter, bestillinger eller status i en kundeportal med login. Det kan gøre kontakten med din virksomhed lettere, men først skal du beskrive, hvilke opgaver kunden skal kunne løse. En portal med mange menupunkter er ikke nødvendigvis mere nyttig end en enkel løsning, som besvarer det vigtigste spørgsmål.
Tag udgangspunkt i de henvendelser, du allerede får. Mangler kunderne et dokument, vil de se status på en opgave, eller skal de godkende noget? Vælg én af de opgaver som begyndelse, og følg den fra kundens behov til medarbejderens opfølgning.
Det giver også et bedre grundlag for at afklare adgang. Den person, der må læse en status, skal måske ikke kunne ændre en bestilling eller invitere nye brugere ind.
Beskriv roller med konkrete handlinger
Forestil dig en erhvervskunde med flere medarbejdere. Én skal kunne oprette en bestilling, en anden skal godkende den, og en tredje skal hente dokumentation. Det er et tænkt eksempel, men det viser, hvorfor rollen Kunde kan være for bred.
Skriv for hver opgave, hvem der må se, oprette, ændre og godkende. Notér også, hvilke oplysninger handlingen gælder for. Må en medarbejder se alle virksomhedens afdelinger eller kun sin egen?
Gennemgå reglerne med dem, der håndterer opgaven i dag. Hvis en godkendelse normalt foregår over telefonen, skal du beslutte, hvordan den skal fungere i portalen. Systemet kan ikke selv afgøre, hvem din kunde har bemyndiget til at handle.
Login og rettigheder skal hænge sammen
Login identificerer brugeren; adgangskontrollen afgør, hvad brugeren må gøre. OWASP anbefaler blandt andet mindst mulig nødvendig adgang og kontrol af rettigheder ved hver anmodning. Se deres vejledning om adgangskontrol.
Få udvikleren til at afprøve reglerne med testbrugere fra forskellige kundefirmaer og roller. Kontrollen skal også gælde dokumenter og direkte adresser, ikke kun de knapper, der bliver vist. At skjule et menupunkt er ikke i sig selv adgangskontrol.
Du kan bidrage med eksempler på de grænser, som er vigtige i forretningen. En kunde må eksempelvis kunne hente sin egen ordrebekræftelse, men ikke en anden kundes. Udvikleren skal omsætte reglerne til tekniske kontroller og tests.
Planlæg ændringer i kundens organisation
Hvad sker der, når en medarbejder stopper eller skifter afdeling? Aftal, hvem der kan fjerne adgang, og hvem der følger op, hvis kundens ansvarlige kontaktperson ikke længere er tilgængelig. Det er en del af den daglige administration, som nemt bliver overset i de første skitser.
Tag også stilling til invitationer. Skal nye brugere godkendes, hvem gør det, og hvordan bliver de knyttet til den rigtige kunde? Gennemgå hele forløbet med en testkonto, inden du åbner for selvbetjening.
Hvis kunden kan ændre oplysninger, bør det være klart, hvad ændringen betyder, og hvem der får besked. En ny leveringsadresse kan eksempelvis have betydning for en igangværende ordre. Den situation skal have en aftalt håndtering.
Afprøv én arbejdsgang før næste udvidelse
Invitér et lille antal relevante brugere til at prøve den første opgave. Se, om de kan finde oplysningerne og gennemføre handlingen uden en forklaring ved siden af. Spørg også medarbejderne, om portalen giver bedre overblik eller blot skaber en ny indbakke.
Gem de aftalte adgangsregler, så de kan bruges igen ved nye funktioner. Hvis portalen senere skal forbindes med andre systemer, skal rettigheder og ansvaret for oplysningerne følge med i planlægningen.
Vi beskriver de bredere muligheder i artiklen om webapps. Vil du undersøge en konkret kundeportal, kan du tage udgangspunkt i vores udvikling af apps til web. En kundes opgave og en beskrivelse af, hvem der må hvad, er et godt sted at begynde.
