Wat hoort er in het bereik van een klantenportaal?

Een portaal kan er eenvoudig van buitenaf uitzien: een inlogpagina, een dashboard en een paar formulieren. De reikwijdte hangt af van wat die schermen mensen laten doen en wat er daarna met de informatie gebeurt.

Om een nieuw portaal te definiëren, werk door middel van de customer journey en de medewerkers verantwoordelijkheden achter het. Screen telt alleen missen veel van de werkelijke toepassing.

Begin met de reden van de klant om terug te keren

Een nuttig portaal heeft een herhaald doel. Een klant kan een verzoek controleren, een document ophalen of een vereiste actie voltooien. Beslis eerst welk doel belangrijk is.

Identificeer dan de record die dat doel draagt. Als het portaal gaat over serviceverzoeken, definieer dan het verzoek en de status ervan. Een dashboard wordt makkelijker te ontwerpen zodra u weet welke records het moet uitleggen.

De rollen scheiden

Een klant kan nodig hebben om hun eigen records te zien. Een medewerker moet mogelijk toegewezen werk zien. Een beheerder kan gebruikers en configuratie controleren. Dat zijn verschillende verantwoordelijkheden, niet alleen verschillende menulabels.

Het toepassingsgebied moet regels voor toegang vaststellen en hoe accounts worden toegestaan. Overweeg of een account een persoon, een bedrijf of een groep met meerdere gebruikers vertegenwoordigt. Die beslissing kan de manier waarop records en machtigingen worden georganiseerd veranderen.

Voor de eerste versie, omvatten de rollen die nodig zijn. Voeg geen uitgebreide machtigingen editor tenzij iemand een bepaalde reden heeft om het te gebruiken.

Volg één record door het hele proces

Neem een illustratief serviceverzoek aan. De klant creëert het, het personeel beoordeelt het, ontbrekende informatie wordt gevraagd en een beslissing of voltooiingsstatus wordt geregistreerd.

Bij elke stap, vraag wie kan handelen, welke informatie is vereist en wat de volgende persoon ziet. Kan een verzoek worden bewerkt na indiening? Kan het worden ingetrokken? Heeft een beoordelaar een reden voor afwijzing nodig?

Deze vragen behoren tot het toepassingsgebied omdat ze het toepassingsgedrag veranderen. Ze mogen niet worden behandeld als kleine visuele details om na ontwikkeling op te lossen.

Bepaal hoe updates worden gecommuniceerd

Een statuswijziging kan op het dashboard verschijnen, een e-mail activeren of een actie van de klant vereisen. Dat zijn verschillende kenmerken. Een melding heeft een bepaalde gebeurtenis, ontvanger en bericht nodig, evenals een beslissing over welke informatie er niet in mag verschijnen.

U kunt de eerste notificatie-ontwerp beperkt houden. Een duidelijke in-applicatie status en een noodzakelijke e-mail kan geschikter zijn dan veelbelovende meldingen voor elke wijziging. De juiste keuze is afhankelijk van de workflow.

Documenten behandelen als een eigen workflow

Een uploadknop roept vragen op over bestandstypen, grootte, eigendom, zichtbaarheid, herziening en verwijdering. Als een document goedkeuring nodig heeft, moeten het bestand en de beslissing een relatie hebben die de gebruiker kan begrijpen.

Begin met de documenten die de belangrijkste workflow eigenlijk vereist. Publiek delen, elektronische ondertekening en complexe documentversies zijn aparte vereisten, niet automatische gevolgen van het toevoegen van uploads.

Wees precies over andere systemen

Een verbinding met facturatie, een CRM of een andere applicatie heeft een gedefinieerde record- en updateregel nodig. Geeft het portaal informatie weer, maakt het aan of verandert het? Hoe actueel moet het zijn?

Een eerste versie kan waar nodig gebruik maken van een overeengekomen handmatig proces. Het belangrijkste is om die keuze zichtbaar te maken in plaats van de portal te beschrijven als volledig geïntegreerd wanneer een stap nog steeds afhankelijk is van een persoon.

Beschrijf de acceptatietest

Voor een basisverzoek workflow, een test kan controleren dat een klant een verzoek kan maken, geen toegang tot het dossier van een andere klant, ziet een personeelsupdate en ontvangt de overeengekomen kennisgeving. Personeel moet in staat zijn om onvolledige informatie te verwerken zonder verlies van de record.

Dit voorbeeld schrijft niet de functionaliteit van elk portaal voor. Het laat zien hoe een volledige workflow van beide kanten gecontroleerd kan worden.

Wat heeft de neiging om het project uit te breiden?

Meer gebruikerstypes, meerdere organisaties per rekening, betalingen, real-time messaging, tweerichtingsintegraties en complexe rapportage voeren extra beslissingen in. Elk kan gerechtvaardigd zijn, maar elk heeft zijn eigen rol in de brief nodig.

De meest bruikbare budget conversatie begint met de eerste volledige workflow en de afhankelijkheden die het echt nodig heeft. Een aantrekkelijke lijst van functies is nog geen leveringsscope.

Verkennen van aangepaste webapplicatie ontwikkeling of uw portaal te bespreken.