O que pertence ao escopo de um portal de clientes?

Um portal pode parecer simples de fora: uma página de entrada, um painel e alguns formulários. Seu escopo depende do que essas telas permitem que as pessoas façam e o que acontece com as informações depois.

Para definir um novo portal, trabalhe através da jornada do cliente e as responsabilidades da equipe por trás dele. A tela conta sozinho perder grande parte da aplicação real.

Comece com a razão do cliente para retornar

Um portal útil tem um propósito repetido. Um cliente pode verificar um pedido, recuperar um documento ou completar uma ação necessária. Decida qual propósito importa primeiro.

Em seguida, identificar o registro que carrega esse propósito. Se o portal é sobre solicitações de serviço, definir o pedido e seus estados. Um painel torna-se mais fácil de projetar uma vez que você sabe quais registros ele deve explicar.

Separar os papéis

Um cliente pode precisar ver seus próprios registros. Um membro da equipe pode precisar ver o trabalho atribuído. Um administrador pode controlar os usuários e a configuração. Essas são responsabilidades diferentes, não simplesmente etiquetas de menu diferentes.

O âmbito de aplicação deve estabelecer regras de acesso e como as contas são autorizadas. Considere se uma conta representa uma pessoa, uma empresa ou um grupo com vários utilizadores.

Para a primeira versão, inclua as funções que são necessárias. Não adicione um editor de permissões elaborado, a menos que alguém tenha uma razão definida para usá- la.

Siga um registro através de todo o processo

Faça um pedido de serviço ilustrativo. O cliente cria-o, a equipe revisá-lo, a falta de informações é solicitada e uma decisão ou estado de conclusão é gravado.

A cada passo, pergunte quem pode agir, quais informações são necessárias e o que a próxima pessoa vê. Uma solicitação pode ser editada após a submissão? Pode ser retirada? Um revisor precisa de uma razão para rejeição?

Estas questões pertencem ao âmbito de aplicação porque alteram o comportamento da aplicação, não devendo ser tratadas como pequenos detalhes visuais a resolver após o desenvolvimento.

Decida como as atualizações são comunicadas

Uma alteração de status pode aparecer no painel, ativar um e-mail ou exigir uma ação do cliente. Essas são características distintas. Uma notificação precisa de um evento definido, destinatário e mensagem, bem como uma decisão sobre quais informações não devem aparecer nele.

Você pode manter o design de notificação inicial limitado. Um status claro na aplicação e um e-mail necessário podem ser mais adequados do que notificações promissoras para cada alteração. A escolha apropriada depende do fluxo de trabalho.

Tratar os documentos como um fluxo de trabalho próprio

Um botão de upload levanta perguntas sobre tipos de arquivos, tamanho, propriedade, visibilidade, revisão e remoção. Se um documento precisa de aprovação, o arquivo e a decisão precisam de um relacionamento que o usuário possa entender.

Comece com os documentos que o fluxo de trabalho principal realmente requer. Compartilhamento público, assinatura eletrônica e versão complexa de documentos são requisitos separados, não consequências automáticas da adição de uploads.

Seja preciso sobre outros sistemas

Uma conexão para faturamento, um CRM ou outra aplicação precisa de uma regra definida de registro e atualização. O portal está exibindo informações, criando-as ou mudando-as? Quão atual precisa ser?

Uma primeira versão pode usar um processo manual acordado quando apropriado. O importante é tornar essa escolha visível em vez de descrever o portal como totalmente integrado quando um passo ainda depende de uma pessoa.

Descrever o ensaio de aceitação

Para um fluxo de trabalho de solicitação básico, um teste pode verificar que um cliente pode criar uma solicitação, não pode acessar o registro de outro cliente, vê uma atualização da equipe e recebe a notificação acordada. A equipe deve ser capaz de lidar com informações incompletas sem perder o registro.

Este exemplo não prescreve a funcionalidade de cada portal. Ele mostra como um fluxo de trabalho completo pode ser verificado de ambos os lados.

O que tende a expandir o projeto?

Mais tipos de usuários, várias organizações por conta, pagamentos, mensagens em tempo real, integrações bidirecionais e relatórios complexos introduzem decisões adicionais. Cada uma pode ser justificada, mas cada uma precisa de seu próprio papel no resumo.

A conversa de orçamento mais útil começa com o primeiro fluxo de trabalho completo e as dependências que ele realmente precisa. Uma lista atraente de recursos ainda não é um escopo de entrega.

Explore o desenvolvimento de aplicações web personalizadas ou discutir o seu portal.