Um estudo de caso sobre a solução preventiva de problemas de clientes por meio de seu comportamento

Um recurso que recentemente entrou em nosso roteiro de produtos no Visibuild foi a capacidade de exportar vários PDFs para o Visis por meio de qualquer página de localização do projeto , apropriadamente chamada Exportações de PDF em massa. Dadas as nossas atualizações anteriores que permitiram aos usuários a capacidade de filtrar o Visis com base em um local escolhido, a próxima etapa lógica foi capacitar os usuários a exportar esses dados.

Nota: Uma Visi é o termo amplo que usamos para descrever Tarefas, Inspeções ou Problemas dentro do produto”

Trabalhar em uma startup apresenta desafios interessantes para quem trabalha no desenvolvimento de produtos, e iniciar um novo projeto exige que nossa equipe se una e realinhe o recurso e seu lugar em nossa lista de prioridades, principalmente devido ao pequeno tamanho de nossa equipe de produto!

Entrar no mercado rapidamente e levar seu produto à paridade de recursos competitivos e construir o fosso “por que somos diferentes” requer priorização implacável, bem como alguns cronogramas criativos e curtos de lançamento de recursos com disposição para avançar ou girar rapidamente perceber.

Entrar no mercado rapidamente e elevar seu produto à paridade de recursos competitivos e construir o fosso “por que somos diferentes” requer uma priorização implacável.

Para cada recurso de produto que iniciamos, nós, como equipe, fazemos algumas estimativas de melhor esforço em torno de algumas compensações importantes:

• Tempo de colocação no mercado.
• Validação de recursos.
• Ciclos de feedback do usuário final.

Na Visibuild, trabalhamos em estreita colaboração com nossos clientes e permanecemos transparentes para que possamos estar no pulso e priorizar o que precisa ser feito da maneira mais eficaz possível. Depois que essas decisões são tomadas, a equipe interna trabalha em conjunto para reunir a visão do recurso e trabalhar de trás para frente para dividir o objetivo final em partes acionáveis ​​que ajudam a agregar valor ao cliente o mais rápido possível. Parte desse processo inclui nossos esforços para prever coisas que podem dar errado, como podemos rastrear preventivamente esses resultados e também como podemos avançar no caso de o problema ser considerado um “quebra de negócio” na promessa que o recurso faz.

Um recurso que desenvolvi recentemente foi a capacidade de os clientes exportarem em massa PDFs de nossos clientes “Visis” (um termo universal que abrange inspeções, problemas, tarefas e relatórios de não conformidade do projeto).

Esse recurso foi muito solicitado e queríamos dividir o resultado final em iterações que nos permitissem disponibilizar o recurso aos usuários mais rapidamente.

Dividimos as iterações para esse recurso em duas partes:

1. A primeira iteração introduziria a interface do usuário voltada para o cliente no aplicativo da Web e utilizaria o fluxo de back-end que já tínhamos para enviar por e-mail exportações de PDF para um único Visi como um anexo de e-mail.
2. A segunda iteração se concentraria na substituição dos arquivos zip enviados por e-mail pelos PDFs, armazenando esses arquivos zip remotamente e substituindo o anexo do e-mail por um link para os downloads.

À medida que os usuários começam a usar mais nosso recurso, a probabilidade de encontrar esse problema aumenta significativamente. Alguns dos fatores envolvidos (que poderíamos identificar) incluiriam o número de anexos para um Visi, bem como a quantidade de Visis solicitada para a exportação.

Dada essa suposição conhecida ao definir nossa primeira iteração, limitamos as exportações em massa para um máximo de cinquenta Visis que poderiam ser solicitados para exportação de uma só vez. Esse limite não foi projetado para limitar nossos clientes, mas sabíamos que medir isso e aplicar o limite nos daria a oportunidade de lançar o recurso mais cedo e coletar estatísticas de uso para nos ajudar a tomar uma decisão informada na segunda iteração para mover para os links de download. O limite não impediria a possibilidade de falha devido ao tamanho do anexo ser grande, mas, dada a natureza arbitrária do tamanho do anexo PDF, achamos que certamente ajudaria a reduzir o risco de muitas exportações com falha.

A decisão do limite deu à nossa equipe de produto algum espaço para respirar, o que, por sua vez, nos deu a chance de aumentar a solução para a segunda iteração de substituição dos PDFs compactados, ao mesmo tempo em que agregamos valor aos clientes mais rapidamente.

Estatísticas da adoção antecipada

Na Visibuild, nosso objetivo é permitir que o feedback do cliente e as ações rastreadas conduzam a direção do nosso produto.

Dadas as limitações acordadas do anexo de e-mail para a primeira iteração, o rastreamento foi adicionado para visualizar quais projetos estavam usando o novo recurso, quantos Visis eles estavam tentando exportar como parte da solicitação e uma maneira de capturar os erros se as exportações tornou-se muito grande para anexos de e-mail.

Acontece que, mesmo na primeira semana , as exportações a granel foram usadas para exportar em lotes maiores do que inicialmente previsto.

O gráfico acima mostra o número de Visis solicitados para geração de PDF por solicitação. Na primeira semana, houve alguns sinais iniciais de que os usuários estavam exigindo toda a extensão do limite de exportação limitado do novo recurso.

Na primeira semana, houve alguns sinais iniciais de que os usuários estavam exigindo toda a extensão do limite de exportação limitado do novo recurso.

Uma solicitação até conseguiu se deparar com o cenário exato que queríamos evitar: falha no envio de um e-mail porque o anexo do arquivo ZIP atingiu o limite de tamanho.

Nossa equipe de suporte trabalhou para garantir que a exportação com falha fosse fornecida ao usuário que fez a solicitação, mas também identificamos e entendemos antes do lançamento que problemas como esse seriam caros para nossa equipe de suporte se continuassem a ocorrer, principalmente como recurso a adoção só aumentaria exponencialmente .

Por fim, tivemos apenas uma falha nas primeiras cem solicitações. Nossa decisão de lançar a primeira iteração ainda funcionou a nosso favor. Entregamos valor aos clientes em 99% das solicitações . Dito isto, esse uso inicial, o feedback direto do cliente e o primeiro incidente foram referências que informaram nossa decisão de antecipar a próxima iteração de usar links de download em vez de anexos na lista de prioridades.

O uso inicial, o feedback direto do cliente e o primeiro incidente foram referências que informaram nossa decisão de antecipar a próxima iteração.

Avançando para a segunda iteração

No final da primeira iteração, o fluxo de trabalho para exportar vários Visis pode ser simplificado no seguinte gráfico de estado:

A solução técnica acordada para levar isso adiante para a próxima iteração significava que as seguintes alterações deveriam ser feitas:

1. Apresente uma maneira de rastrear o estado de um trabalho de exportação em massa, ou seja, o trabalho está pendente, em andamento, concluído ou rejeitado?
2. Certifique-se de que as notificações ocorram para trabalhos bem-sucedidos e malsucedidos para manter o usuário final informado.
3. Crie um mecanismo seguro para armazenar e acessar arquivos ZIP exportados.

Essa solução significava que resolveríamos o problema em relação aos tamanhos dos anexos, além de sermos mais proativos em informar aos clientes se houve um problema ocorrido durante o processo de exportação em massa.

A solução final

Depois de trabalhar com o restante da equipe de produto para definir a próxima iteração da experiência do usuário, implementamos um conjunto atualizado de fluxos de e-mail para manter o usuário informado. Também definimos, implementamos e rastreamos um conjunto de estados em que o trabalho poderia estar e como poderíamos refletir melhor isso por meio da interface do usuário em nossa página de download de exportação para garantir que quaisquer outros problemas fossem identificados e resolvidos por nossos equipe de produto.

O novo fluxo começaria com o usuário solicitando uma nova exportação e a notificação de sucesso posicionando o prazo para a exportação para dar ao usuário uma ideia melhor de quanto tempo as exportações podem levar.

Assim que a exportação for concluída com êxito e estiver pronta para download, um e-mail atualizado fornecerá o link em vez de um anexo. Isso resolve nosso problema no problema de dimensionamento de anexos que encontramos. O link direcionaria o usuário para nossa página de download de novas exportações, que forneceria informações sobre o estado atual da exportação e um link para baixar a exportação caso ela estivesse pronta (e não expirada).

Clicar no link de download forneceria a página de download para o usuário baixar o PDF.

Juntamente com o link de download, incluímos o tempo até que o link expire. A decisão foi tomada para garantir que definissemos o link como “expirado” após 14 dias, visto que os PDFs exportados geralmente passam para um estado obsoleto logo após a exportação.

Essa nova abordagem com a expiração integrada nos permitiu pensar nos custos de hospedagem dessas solicitações de exportação de PDF como arquivos ZIP remotos. Isso nos ajudou a orçar o novo recurso em grande escala, com nosso back-end configurado para remover automaticamente esses arquivos ZIP obsoletos e economizar nos custos de dados que não seriam mais usados.

Essa nova abordagem com a expiração integrada nos permitiu pensar nos custos de hospedagem dessas solicitações de exportação de PDF como arquivos ZIP remotos. Isso nos ajudou a orçar o novo recurso em grande escala.

Em caso de falha, também tínhamos um e-mail definido para informar ao usuário que ocorreu um problema para resolver o problema de falhas “silenciosas” que faziam com que os clientes entrassem em contato conosco sobre problemas. Isso nos permitiu ser proativamente transparentes com um cliente, além de dar a ele a opção de entrar em contato conosco para obter mais informações, se desejar.

A peça final do quebra-cabeça era manter a interface do usuário para nossa página de download de exportação informativa com os diferentes estados de trabalho em que ela poderia estar. Para nós, isso significava garantir que o usuário fosse informado se um trabalho estivesse na fila, em andamento, com falha, expirado ou em um estado de erro inesperado.

Alguns desses estados foram representados na interface do usuário da seguinte forma:

Graças à interface do usuário atualizada, pudemos garantir que os usuários pudessem verificar o andamento de qualquer solicitação de exportação e entender onde essa solicitação se encontra em qualquer estágio do ciclo de vida do trabalho.

O ciclo de vida atualizado do nosso novo fluxo ao longo do tempo pode ser simplificado e resumido da seguinte forma:

Este fluxo fornece uma visão geral do ciclo de vida de todas as nossas exportações de PDF à medida que ocorrem para exportações de PDF único, exportações de PDF em massa (mais de uma exportação de PDF em uma solicitação) e o fluxo de falha para exportações de PDF único e em massa conforme esses fluxos são executados hora extra.

Recontagem, resultado e resultados

No momento da redação deste artigo, nossa iteração no recurso foi enviada e acompanhamos de perto o resultado e os resultados.

Para recontar, começamos com a primeira iteração focada em levar a capacidade aos clientes, mantendo o final em mente para entender as próximas etapas, mantendo o roteiro fluido o suficiente para executar essas etapas no momento apropriado. Depois de considerar a análise de uso e o feedback do cliente, promovemos a implementação de nossa segunda iteração no roteiro.

Esta segunda iteração teve como objetivo final resolver e contornar o problema dos tamanhos dos anexos e trabalhar para desbloquear o limite rígido de exportação do Visi que definimos para os clientes . Fizemos isso migrando nossa abordagem anterior de anexar diretamente arquivos ZIP exportados a e-mails como anexos e, em vez disso, optamos por usar uma solução de armazenamento temporário e links para download.

Graças a esta última iteração, atenuamos com sucesso esses problemas e não recebemos mais solicitações relacionadas a exportações com falha devido ao tamanho do anexo.

Desde o lançamento desta nova iteração, a adoção do recurso aumentou mais de 370% . Nossa decisão de avançar a iteração no roteiro provavelmente evitou algumas dores de cabeça e conversas difíceis com nossos clientes.

Este projeto mostrou a mentalidade colaborativa que compartilhamos na empresa. Ao manter o final em mente, reconhecemos preventivamente possíveis armadilhas nas iterações iniciais, bem como reforçamos o valor de nossa empresa para dinamizar e resolver quaisquer problemas de alto risco e problemáticos, caso ocorram antes do previsto.

Ao manter o final em mente, reconhecemos preventivamente possíveis armadilhas nas iterações iniciais, bem como reforçamos o valor de nossa empresa para dinamizar e resolver quaisquer problemas de alto risco e problemáticos, caso ocorram antes do previsto.

As duas iterações do recurso de exportação de PDF em massa que foram abordadas nesta recontagem demonstram a importância de enviar o valor antecipadamente e tomar decisões com base no uso do cliente.

Deparar-se com o problema de usuários que desejam aproveitar ao máximo um recurso é um bom problema. Como costuma ser dito em nossos escritórios de equipe, “Enviar para aprender”.