Hvad hører ind under en kundeportal?

En portal kan se enkel ud udefra: et tegn-i side, et instrumentbræt og et par former. Dens omfang afhænger af, hvad disse skærme lader folk gøre, og hvad der sker med oplysningerne bagefter.

For at definere en ny portal, arbejde gennem kunderejsen og personalets ansvar bag det. Skærm tæller alene glip af meget af den faktiske anvendelse.

Start med kundens grund til at vende tilbage

En nyttig portal har et gentagne formål. En kunde kan tjekke en anmodning, hente et dokument eller fuldføre en krævet handling. Beslut hvilket formål der betyder noget først.

Hvis portalen handler om serviceanmodninger, skal du definere anmodningen og dens tilstand. Et dashboard bliver lettere at designe, når du ved, hvilke optegnelser det skal forklare.

Separér rollerne

En kunde kan have brug for at se sine egne optegnelser. En medarbejder kan have brug for at se tildelte arbejde. En administrator kan kontrollere brugere og konfiguration. Det er forskellige ansvarsområder, ikke blot forskellige menumærker.

Anvendelsesområdet skal fastlægge adgangsregler og hvordan konti bliver godkendt. Overvej, om en konto repræsenterer en person, en virksomhed eller en gruppe med flere brugere. Denne beslutning kan ændre, hvordan registreringer og tilladelser er organiseret.

For den første version, omfatte de roller, der er nødvendige. Må ikke tilføje en omfattende tilladelser editor, medmindre nogen har en defineret grund til at bruge det.

Følg én rekord gennem hele processen

Tag en illustrativ service anmodning. Kunden opretter det, personale gennemgå det, manglende oplysninger anmodes om, og en afgørelse eller afslutning status er registreret.

Ved hvert trin, spørg hvem der kan handle, hvilke oplysninger der kræves, og hvad den næste person ser. Kan en anmodning redigeres efter indsendelse? Kan den trækkes tilbage? Har en anmelder brug for en grund til afvisning?

Disse spørgsmål hører ind under anvendelsesområdet, fordi de ændrer ansøgningsadfærden. De bør ikke behandles som små visuelle detaljer at løse efter udvikling.

Beslut hvordan opdateringer kommunikeres

En statusændring kan vises på instrumentbrættet, udløse en e-mail eller kræve en handling fra kunden. Disse er forskellige funktioner. En meddelelse har brug for en defineret begivenhed, modtager og besked, samt en beslutning om, hvilke oplysninger der ikke skal vises i den.

Du kan holde den oprindelige anmeldelse design begrænset. En klar in- ansøgning status og en nødvendig e-mail kan være mere egnet end lovende meddelelser for hver ændring. Det passende valg afhænger af arbejdsgangen.

Behandl dokumenter som en arbejdsgang af deres egen

En upload knap rejser spørgsmål om filtyper, størrelse, ejerskab, synlighed, gennemgang og fjernelse. Hvis et dokument har brug for godkendelse, filen og beslutningen har brug for et forhold, som brugeren kan forstå.

Start med de dokumenter den vigtigste arbejdsgang faktisk kræver. Offentlig deling, elektronisk signering og komplekse dokument versioning er separate krav, ikke automatiske konsekvenser af at tilføje uploads.

Vær præcis om andre systemer

En forbindelse til fakturering, en CRM eller et andet program har brug for en defineret record og opdateringsregel. Viser portalen information, opretter den eller ændrer den? Hvor aktuel skal den være?

En første version kan bruge en aftalt manuel proces, hvor det er hensigtsmæssigt. Det vigtigste er at gøre dette valg synligt i stedet for at beskrive portalen som fuldt integreret, når et skridt stadig afhænger af en person.

Beskriv godkendelsestesten

For en grundlæggende anmodning workflow, en test kan kontrollere, at en kunde kan oprette en anmodning, kan ikke få adgang til en anden kundes rekord, ser en personaleopdatering og modtager den aftalte meddelelse. Personalet skal være i stand til at håndtere ufuldstændige oplysninger uden at miste rekorden.

Dette eksempel foreskriver ikke hver portal funktionalitet. Det viser, hvordan en komplet workflow kan kontrolleres fra begge sider.

Hvad har tendens til at udvide projektet?

Flere brugertyper, flere organisationer pr. konto, betalinger, real- time messaging, tovejs integration og kompleks rapportering introducerer yderligere beslutninger. Hver enkelt kan være berettiget, men hver har brug for sin egen rolle i korthed.

Den mest nyttige budget samtale starter med den første komplette workflow og de afhængigheder, det virkelig har brug for. En attraktiv liste over funktioner er endnu ikke en levering omfang.

Udforsk brugerdefinerede web applikation udvikling eller diskutere din portal.