Como planejar fluxos digitais seguros voltados ao cliente

O que é

Um fluxo voltado ao cliente pode abranger um portal, um serviço web, uma experiência móvel, um backend, uma API, um provedor de pagamentos, um processo de suporte e uma equipe administrativa. O planejamento deve identificar funções de usuário e limites de acesso; autenticação e recuperação; formulários, arquivos, mensagens, painéis e status; caminhos de pagamento, assinatura, fatura, reembolso, cancelamento e direitos de acesso; titularidade e retenção de dados; integrações com terceiros; e responsabilidade operacional. Também deve decidir se o móvel ou a web é o mais apropriado, se o backend e as APIs existentes estão prontos e quem será responsável por logs, suporte, mudanças e passagem. A revisão de segurança e a entrega de software podem ter escopos separados.

Para Quem É

Este guia ajuda equipes que estão planejando:

• Um portal de clientes ou parceiros, um fluxo de recebimento de solicitações, um painel, uma jornada de pagamento, uma transição web para móvel ou o lançamento de uma aplicação
• Acesso com base em funções, recuperação, arquivos, informações de status, suporte e responsabilidades administrativas
• Uma mudança de produto que envolve backends e APIs existentes, provedores terceiros, estados de faturamento ou dados de clientes
• Um limite mais claro entre descoberta, design, entrega, reforço, revisão e a responsabilidade operacional posterior

O Que Isso Ajuda A Esclarecer

As perguntas de planejamento ajudam a revelar:

• Se usuários, funções, regras de acesso, recuperação de conta, titularidade e retenção de dados são compreendidos antes do início da entrega
• Quais formulários, arquivos, mensagens, painéis, visualizações de status, estados de pagamento e decisões sobre direitos de acesso atravessam os limites entre sistemas
• Se integrações, backend/APIs, entrega móvel, estágio de lançamento, logs, suporte e responsabilidade por mudanças estão prontos para um próximo passo com escopo definido
• Se a equipe precisa de um sprint de portal, uma revisão de pagamentos, uma transição web para móvel, uma revisão de prontidão para lançamento, reforço do site ou um trabalho prévio de descoberta/blueprint

O que está incluído

• Um checklist para compradores que abrange jornadas, funções, acesso, autenticação, recuperação, formulários, arquivos, mensagens, painéis, status, pagamentos, assinaturas, faturas, reembolsos, cancelamentos, direitos de acesso, dados e integrações
• Perguntas de planejamento sobre responsabilidade administrativa, prontidão de backend/API, móvel versus web, estágio de lançamento, logs, suporte, controle de mudanças e passagem
• Uma comparação de quando o Secure Client Portal Sprint, o Subscription & Payment Infrastructure Security, o Secure Web-to-Mobile Launch, o App Launch Readiness e o Website Performance & Security Hardening podem ser relevantes
• Um lembrete de que fluxos, funções, integrações ou responsabilidades pouco claros podem exigir trabalho de descoberta ou de blueprint antes da entrega

O que não está incluído

• Qualquer promessa de segurança, adequação regulatória, aprovação de pagamentos, prevenção de fraudes, receita, aprovação nas lojas, sucesso no lançamento, disponibilidade, desempenho ou operação ininterrupta
• Alegação de que um sprint de portal é uma plataforma SaaS completa, de que a revisão de pagamentos é uma certificação PCI ou uma operação antifraude, ou de que a entrega móvel deixa automaticamente um produto pronto para lançamento
• Sugestão de que o reforço substitui o design da aplicação, o teste de carga, a resposta a incidentes ou as operações contínuas
• Suposição de que entrega de software, revisão de segurança, aprovação do provedor e responsabilidade contínua formam um único escopo automático

Quando Escolher

Use este guia antes que uma mudança voltada ao cliente se transforme em uma lista de funcionalidades desconectadas. Ele é útil quando a equipe está decidindo se vai desenvolver um portal, mudar o acesso, introduzir assinaturas, levar um serviço web para o móvel, preparar o lançamento de uma aplicação ou melhorar um site. Se o fluxo básico, as responsabilidades, as integrações ou as funções de usuário continuarem pouco claros, um trabalho de descoberta ou de blueprint de produto costuma ser mais valioso do que uma implementação precoce. Uma revisão com escopo definido pode vir em seguida, quando uma questão específica de segurança ou de operação estiver pronta.

Nossa abordagem

Mapeie a jornada antes de selecionar o método de entrega. Comece pelo usuário, sua função, a decisão de acesso, os dados que ele fornece ou vê, o sistema responsável pelo próximo estado e a equipe responsável quando algo muda. Acompanhe os estados de pagamento e de direitos de acesso com o mesmo cuidado que as telas da interface. Em seguida, identifique as dependências de provedores e de backend, as necessidades de suporte e de logs, as restrições do móvel, a responsabilidade pelas versões e os requisitos de passagem. Isso mostra se a próxima decisão diz respeito à entrega de um portal, à lógica de pagamentos, ao trabalho de web para móvel, à prontidão para lançamento, ao reforço do site ou a uma descoberta prévia. Também evita que um serviço com escopo definido seja confundido com uma responsabilidade ilimitada de produto, de operações ou de conformidade. Um mapa de fluxos por escrito também pode registrar os caminhos normais e excepcionais: um novo usuário, um pagamento com falha, um cancelamento, uma conta perdida, um arquivo ausente, uma indisponibilidade de fornecedor ou um pedido de suporte. Ele oferece às equipes de produto, operações, engenharia e suporte um lugar comum para identificar responsabilidades antes que um cliente seja afetado. Essa clareza pode reduzir o desvio de escopo em trabalhos de entrega posteriores. À medida que o planejamento avança, revise o mapa sempre que um provedor, modelo de pagamento, função, regra de acesso, API, canal de lançamento ou processo de suporte mudar. Um fluxo que parecia simples em um diagrama pode ter exceções importantes em produção. Registrar essas exceções facilita decidir se o próximo escopo é design, entrega, revisão, reforço, testes ou preparação operacional. Também ajuda o comprador a solicitar as evidências certas aos fornecedores antes de tomar uma decisão. Por fim, use o mapa para decidir o que será medido após a entrega e quem agirá diante de um achado, um pagamento com falha, um sinal do suporte ou um pedido de mudança. Uma passagem é mais sólida quando nomeia um responsável, um ponto de revisão e um limite acordado, em vez de simplesmente listar funcionalidades.

Perguntas Frequentes

Artigos relacionados