Qu'est-ce qui fait partie de la portée d'un portail client?

Un portail peut sembler simple depuis l'extérieur : une page de connexion, un tableau de bord et quelques formulaires. Sa portée dépend de ce que ces écrans permettent aux gens de faire et de ce qui arrive aux informations par la suite.

Pour définir un nouveau portail, travaillez à travers le parcours client et les responsabilités du personnel derrière. L'écran compte à lui seul manquer une grande partie de l'application réelle.

Commencez par la raison de retour du client

Un portail utile a un but répété. Un client peut vérifier une demande, récupérer un document ou effectuer une action requise.

Si le portail porte sur les demandes de service, définissez la demande et ses états. Un tableau de bord devient plus facile à concevoir une fois que vous savez quels enregistrements il doit expliquer.

Séparer les rôles

Un client peut avoir besoin de voir ses propres dossiers. Un membre du personnel peut avoir besoin de voir le travail assigné. Un administrateur peut contrôler les utilisateurs et la configuration.

Le champ d'application doit établir des règles d'accès et la manière dont les comptes deviennent autorisés. Examiner si un compte représente une personne, une entreprise ou un groupe avec plusieurs utilisateurs.

Pour la première version, inclure les rôles qui sont nécessaires. Ne pas ajouter un éditeur de permissions élaboré à moins que quelqu'un ait une raison définie pour l'utiliser.

Suivre un enregistrement tout au long du processus

Prenez une demande de service illustrative. Le client la crée, le personnel l'examine, les informations manquantes sont demandées et une décision ou un état d'achèvement est enregistré.

À chaque étape, demandez qui peut agir, quelle information est requise et ce que la personne suivante voit. Une demande peut-elle être modifiée après la soumission? Peut-elle être retirée? Un examinateur a-t-il besoin d'une raison de rejet?

Ces questions font partie de la portée parce qu'elles modifient le comportement de l'application. Elles ne doivent pas être traitées comme de petits détails visuels à résoudre après le développement.

Décider comment les mises à jour sont communiquées

Un changement d'état peut apparaître sur le tableau de bord, déclencher un courriel ou exiger une action du client. Ce sont des caractéristiques distinctes. Une notification a besoin d'un événement, d'un destinataire et d'un message définis, ainsi que d'une décision sur les informations qui ne devraient pas y figurer.

Vous pouvez limiter la conception de la notification initiale. Un statut clair dans la demande et un courriel nécessaire peuvent être plus appropriés que des notifications prometteuses pour chaque changement. Le choix approprié dépend du flux de travail.

Traiter les documents comme un flux de travail

Un bouton de téléchargement soulève des questions sur les types de fichiers, la taille, la propriété, la visibilité, l'examen et la suppression.

Le partage public, la signature électronique et la version complexe des documents sont des exigences distinctes, et non des conséquences automatiques de l'ajout de téléchargements.

Soyez précis sur les autres systèmes

Une connexion à la facturation, un CRM ou une autre application a besoin d'une règle d'enregistrement et de mise à jour définie. Le portail affiche-t-il des informations, les crée ou les modifie-t-il?

Une première version peut utiliser un processus manuel convenu le cas échéant. L'important est de rendre ce choix visible plutôt que de décrire le portail comme entièrement intégré lorsqu'une étape dépend encore d'une personne.

Décrire le test d'acceptation

Pour un workflow de demande de base, un test peut vérifier qu'un client peut créer une demande, ne peut pas accéder au dossier d'un autre client, voit une mise à jour du personnel et reçoit la notification convenue. Le personnel doit être capable de traiter des informations incomplètes sans perdre le dossier.

Cet exemple ne prescrit pas la fonctionnalité de chaque portail. Il montre comment un workflow complet peut être vérifié des deux côtés.

Qu'est-ce qui tend à élargir le projet?

Plus de types d'utilisateurs, de multiples organisations par compte, de paiements, de messageries en temps réel, d'intégrations bidirectionnelles et de rapports complexes introduisent des décisions supplémentaires.

La conversation budgétaire la plus utile commence avec le premier flux de travail complet et les dépendances dont il a réellement besoin. Une liste attrayante de fonctionnalités n'est pas encore une portée de livraison.

Explorer le développement d'applications web personnalisées ou discuter de votre portail.