Kundportal omfattning
Vad hör till omfattningen av en kundportal?
Definiera en kundportal genom roller, poster, beslut och kompletta arbetsflöden. Förstå kraven som ändrar dess utvecklingsområde.
En portal kan se enkelt ut från utsidan: en inloggningssida, en instrumentpanel och några formulär. Dess omfattning beror på vad dessa skärmar låter människor göra och vad som händer med informationen efteråt.
För att definiera en ny portal, arbeta genom kundresan och personalens ansvar bakom den. Screen räknas ensam missa mycket av den faktiska tillämpningen.
Börja med kundens anledning att återvända
En användbar portal har ett upprepat syfte. En kund kan kontrollera en förfrågan, hämta ett dokument eller slutföra en nödvändig åtgärd. Bestäm vilket syfte som är viktigt först.
Sedan identifiera rekordet som bär det syftet. Om portalen handlar om serviceförfrågningar, definiera begäran och dess stater. En instrumentpanel blir lättare att designa när du vet vilka poster den ska förklara.
Separera rollerna
En kund kan behöva se sina egna register. En personalmedlem kan behöva se tilldelat arbete. En administratör kan styra användare och konfiguration. De är olika ansvarsområden, inte bara olika menyetiketter.
Omfattningen måste fastställa åtkomstregler och hur konton blir auktoriserade. Tänk på om ett konto representerar en person, ett företag eller en grupp med flera användare. Det beslutet kan ändra hur register och behörigheter organiseras.
För den första versionen, inkludera de roller som är nödvändiga. Lägg inte till en utarbetade behörighetsredigerare om någon har en definierad anledning att använda den.
Följ en post genom hela processen
Ta en illustrativ serviceförfrågan. Kunden skapar den, personal granska den, saknas information begärs och ett beslut eller slutförande status registreras.
Vid varje steg, fråga vem som kan agera, vilken information som krävs och vad nästa person ser. Kan en förfrågan redigeras efter inlämning? Kan det dras tillbaka?
Dessa frågor hör till omfattningen eftersom de ändrar applikationsbeteende. De bör inte behandlas som små visuella detaljer för att lösa efter utvecklingen.
Bestäm hur uppdateringar kommuniceras
En statusändring kan visas på instrumentbrädan, utlösa ett e-postmeddelande eller kräva en åtgärd från kunden. De är distinkta funktioner. En anmälan behöver en definierad händelse, mottagare och meddelande, samt ett beslut om vilken information som inte ska visas i den.
Du kan hålla den ursprungliga meddelandedesignen begränsad. En tydlig in-application status och en nödvändig e-post kan vara mer lämplig än lovande meddelanden för varje förändring. Det lämpliga valet beror på arbetsflödet.
Behandla dokument som ett eget arbetsflöde
En uppladdningsknapp väcker frågor om filtyper, storlek, ägande, synlighet, granskning och borttagning. Om ett dokument behöver godkännande, filen och beslutet behöver en relation som användaren kan förstå.
Börja med de dokument som det huvudsakliga arbetsflödet faktiskt kräver. Offentlig delning, elektronisk signering och komplex dokumentversionering är separata krav, inte automatiska konsekvenser av att lägga till uppladdningar.
Var noggrann med andra system
En anslutning till fakturering, en CRM eller en annan ansökan behöver en definierad rekord- och uppdateringsregel. Är portalen som visar information, skapar den eller ändrar den?
En första version kan använda en överenskommen manuell process där så är lämpligt. Det viktiga är att göra det valet synligt snarare än att beskriva portalen som helt integrerat när ett steg fortfarande beror på en person.
Beskriv acceptanstestet
För ett grundläggande förfrågningsarbetsflöde kan ett test verifiera att en kund kan skapa en förfrågan, inte komma åt en annan kunds rekord, ser en personaluppdatering och tar emot den överenskomna anmälan. Personalen måste kunna hantera ofullständig information utan att förlora rekordet.
Detta exempel föreskriver inte varje portals funktionalitet. Det visar hur ett komplett arbetsflöde kan kontrolleras från båda sidor.
Vad tenderar att expandera projektet?
Fler användartyper, flera organisationer per konto, betalningar, realtidsmeddelanden, tvåvägsintegrationer och komplex rapportering inför ytterligare beslut. Var och en kan vara berättigad, men varje behöver sin egen roll i korthet.
Den mest användbara budgetkonversationen börjar med det första kompletta arbetsflödet och de beroenden det verkligen behöver. En attraktiv lista över funktioner är ännu inte ett leveransomfång.
Utforska anpassad webbapplikationsutveckling eller diskutera din portal.