Umfang des Kundenportals
Was gehört in den Umfang eines Kundenportals?
Definieren Sie ein Kundenportal durch Rollen, Aufzeichnungen, Entscheidungen und komplette Workflows. Verstehen Sie die Anforderungen, die seinen Entwicklungsumfang verändern.
Ein Portal kann von außen einfach aussehen: eine Anmeldeseite, ein Dashboard und einige Formulare. Sein Umfang hängt davon ab, was diese Bildschirme den Menschen erlauben und was mit den Informationen danach passiert.
Um ein neues Portal zu definieren, arbeiten Sie sich durch die Customer Journey und die Verantwortlichkeiten der Mitarbeiter dahinter. Screen zählt allein viel von der eigentlichen Anwendung.
Beginnen Sie mit dem Grund des Kunden zur Rückkehr
Ein nützliches Portal hat einen wiederholten Zweck. Ein Kunde kann eine Anfrage prüfen, ein Dokument abrufen oder eine erforderliche Aktion abschließen.
Wenn es im Portal um Dienstanfragen geht, definieren Sie die Anfrage und ihre Zustände. Ein Dashboard wird einfacher zu entwerfen, sobald Sie wissen, welche Datensätze es erklären soll.
Die Rollen trennen
Ein Kunde muss möglicherweise seine eigenen Aufzeichnungen sehen. Ein Mitarbeiter muss möglicherweise zugewiesene Arbeiten sehen. Ein Administrator kann Benutzer und Konfiguration kontrollieren. Das sind unterschiedliche Verantwortlichkeiten, nicht nur unterschiedliche Menübeschriftungen.
Der Anwendungsbereich muss Regeln für den Zugang und die Art und Weise festlegen, wie Konten autorisiert werden.Betrachten Sie, ob ein Konto eine Person, ein Unternehmen oder eine Gruppe mit mehreren Benutzern repräsentiert.
Fügen Sie für die erste Version die Rollen hinzu, die notwendig sind.
Folgen Sie einem Datensatz durch den gesamten Prozess
Nehmen Sie eine illustrative Serviceanfrage an. Der Kunde erstellt sie, das Personal überprüft sie, fehlende Informationen werden angefordert und ein Entscheidungs- oder Abschlussstatus wird aufgezeichnet.
Fragen Sie bei jedem Schritt, wer handeln kann, welche Informationen benötigt werden und was die nächste Person sieht. Kann eine Anfrage nach der Einreichung bearbeitet werden? Kann sie zurückgezogen werden? Braucht ein Rezensent einen Grund für die Ablehnung?
Diese Fragen gehören in den Anwendungsbereich, weil sie das Anwendungsverhalten verändern und nicht als kleine visuelle Details behandelt werden sollten, die nach der Entwicklung zu lösen sind.
Entscheiden Sie, wie Updates kommuniziert werden
Eine Statusänderung kann auf dem Dashboard erscheinen, eine E-Mail auslösen oder eine Aktion des Kunden erfordern. Das sind eindeutige Merkmale. Eine Benachrichtigung benötigt ein definiertes Ereignis, einen Empfänger und eine Nachricht sowie eine Entscheidung darüber, welche Informationen darin nicht erscheinen sollen.
Ein klarer Status in der Anwendung und eine notwendige E-Mail können besser geeignet sein als vielversprechende Benachrichtigungen für jede Änderung. Die richtige Wahl hängt vom Workflow ab.
Behandeln Sie Dokumente als eigenen Workflow
Ein Upload-Button wirft Fragen zu Dateitypen, Größe, Besitz, Sichtbarkeit, Überprüfung und Entfernung auf. Wenn ein Dokument eine Genehmigung benötigt, benötigen die Datei und die Entscheidung eine Beziehung, die der Benutzer verstehen kann.
Beginnen Sie mit den Dokumenten, die der Hauptworkflow tatsächlich benötigt. Öffentliches Teilen, elektronisches Signieren und komplexe Dokumentenversionierung sind separate Anforderungen und keine automatischen Folgen des Hinzufügens von Uploads.
Seien Sie präzise über andere Systeme
Eine Verbindung zur Abrechnung, ein CRM oder eine andere Anwendung benötigt eine definierte Aufzeichnungs- und Aktualisierungsregel. Zeigt das Portal Informationen an, erstellt oder verändert es? Wie aktuell muss es sein?
Eine erste Version kann gegebenenfalls ein vereinbartes manuelles Verfahren verwenden. Wichtig ist, diese Wahl sichtbar zu machen, anstatt das Portal als vollständig integriert zu beschreiben, wenn ein Schritt noch von einer Person abhängt.
Beschreibung des Akzeptanztests
Bei einem Basis-Request-Workflow könnte ein Test bestätigen, dass ein Kunde eine Anfrage erstellen kann, nicht auf den Datensatz eines anderen Kunden zugreifen kann, eine Mitarbeiteraktualisierung sieht und die vereinbarte Benachrichtigung erhält.
Dieses Beispiel schreibt nicht die Funktionalität jedes Portals vor, sondern zeigt, wie ein kompletter Workflow von beiden Seiten überprüft werden kann.
Was neigt dazu, das Projekt zu erweitern?
Mehr Nutzertypen, mehrere Organisationen pro Konto, Zahlungen, Echtzeit-Messaging, Zwei-Wege-Integrationen und komplexe Berichterstattung führen zu zusätzlichen Entscheidungen.
Das nützlichste Budgetgespräch beginnt mit dem ersten kompletten Workflow und den Abhängigkeiten, die es wirklich braucht. Eine attraktive Liste von Features ist noch kein Lieferumfang.
Erkunden Sie die Entwicklung benutzerdefinierter Webanwendungen oder Besprechen Sie Ihr Portal.