Kundeportalens omfang
Hva hører til i omfanget av en kundeportal?
Definer en kundeportal gjennom roller, poster, beslutninger og komplette arbeidsflyter. Forstå kravene som endrer utviklingsområdet.
En portal kan se enkelt ut fra utsiden: en innloggingsside, et dashboard og noen få former. Omfanget avhenger av hva disse skjermene lar folk gjøre og hva som skjer med informasjonen etterpå.
For å definere en ny portal, arbeid gjennom kundeturen og personalet ansvar bak den. Skjermen teller alene mangler mye av den faktiske applikasjonen.
Start med kundens grunn til å returnere
En nyttig portal har et gjentatt formål. En kunde kan sjekke en forespørsel, hente et dokument eller fullføre en nødvendig handling. Bestem hvilket formål som gjelder først.
Deretter identifisere den posten som bærer det formålet. Hvis portalen handler om tjenesteforespørsler, definere forespørselen og dens tilstander. Et dashboard blir lettere å designe når du vet hvilke poster den bør forklare.
Separat rollene
En kunde kan måtte se sine egne poster. Et medarbeidermedlem kan måtte se tildelt arbeid. En administrator kan styre brukere og konfigurasjon. Dette er ulike ansvar, ikke bare ulike menyetiketter.
Omfanget må etablere tilgangsregler og hvordan kontoer blir godkjent. Tenk på om en konto representerer en person, et selskap eller en gruppe med flere brukere. Denne beslutningen kan endre hvordan poster og tillatelser er organisert.
For den første versjonen, inkludere rollene som er nødvendige. Ikke legg til en utførlig autorisasjonsredigering med mindre noen har en definert grunn til å bruke den.
Følg en rekord gjennom hele prosessen
Ta en illustrativ tjenesteforespørsel. Kunden oppretter den, personalet gjennomgår den, manglende informasjon er bedt om og en beslutnings- eller fullføringsstatus er registrert.
På hvert trinn, spør hvem som kan handle, hvilke opplysninger som kreves, og hva neste person ser. Kan en forespørsel redigeres etter innsendelse? Kan den trekkes tilbake? Trenger en anmelder en grunn til avvisning?
Disse spørsmålene tilhører i omfanget fordi de endrer applikasjonsadferden. De bør ikke behandles som små visuelle detaljer for å løse etter utvikling.
Bestem hvordan oppdateringer kommuniseres
En statusendring kan vises på instrumentbordet, utløse en e-post eller kreve en handling fra kunden. De er tydelige funksjoner. Et varsel trenger en definert hendelse, mottaker og melding, samt en beslutning om hvilken informasjon som ikke skal vises i det.
Du kan holde den første varslingsdesignen begrenset. En klar i-søknadsstatus og en nødvendig e-post kan være mer egnet enn lovende varslinger for hver endring. Det riktige valget avhenger av arbeidsflyten.
Behandle dokumenter som egen arbeidsflyt
En opplastingsknapp stiller spørsmål om filtyper, størrelse, eierskap, synlighet, gjennomgang og fjerning. Hvis et dokument trenger godkjenning, trenger filen og beslutningen et forhold som brukeren kan forstå.
Start med dokumentene den viktigste arbeidsflyten faktisk krever. Offentlig deling, elektronisk signering og kompleks dokumentversjon er separate krav, ikke automatiske konsekvenser av å legge til opplastninger.
Vær nøyaktig om andre systemer
En tilkobling til fakturering, et CRM eller et annet program trenger en definert oppførings- og oppdateringsregel. Viser portalen informasjon, oppretter det eller endrer det? Hvordan gjeldende trenger det å være?
En første versjon kan bruke en avtalt manuell prosess når det er aktuelt. Det viktigste er å gjøre det valget synlig i stedet for å beskrive portalen som fullt integrert når et skritt fortsatt avhenger av en person.
Beskriv aksepttesten
For en grunnleggende forespørsel arbeidsflyt, kan en test kontrollere at en kunde kan opprette en forespørsel, kan ikke få tilgang til en annen kundes rekord, se en medarbeideroppdatering og mottar avtalt varsling. Personalet må kunne håndtere ufullstendig informasjon uten å miste rekorden.
Dette eksemplet foreskriver ikke hver portals funksjonalitet. Det viser hvordan en fullstendig arbeidsflyt kan kontrolleres fra begge sider.
Hva har en tendens til å utvide prosjektet?
Flere brukertyper, flere organisasjoner per konto, betalinger, sanntid meldinger, toveis integrasjon og kompleks rapportering introduserer ytterligere beslutninger. Hver kan være berettiget, men hver trenger sin egen rolle i kort.
Den mest nyttige budsjettsamtalen starter med den første komplette arbeidsflyten og avhengighetene den virkelig trenger. En attraktiv liste over funksjoner er ennå ikke et leveringsområde.
Utforsk egendefinert webapplikasjonsutvikling eller diskutere din portal.