Sobre o projeto
O produto do cliente é o SaaS na esfera B2B, que opera no formato de assinatura. O usuário se cadastra, passa autorização, reabastece sua conta e usa o serviço.
Nossa tarefa é ajudar o cliente a "coletar" análises. Para fazer isso, foi necessário construir processos de call center, implementar CRM e “reunir” análises de ponta a ponta por indicadores-chave.
Estrutura do processo
Antes de fazer análises, você precisa preparar um cenário para coletá-las: estruturar processos de vendas e configurar integrações com serviços. Encontramos vários problemas nos processos:
- Os gerentes eram distraídos por estágios desnecessários do funil de vendas e seu trabalho não era monitorado de forma alguma;
- Os relatórios de vendas eram baixados manualmente do painel de administração todos os dias;
- Houve poucos eventos de conversão para coletar análises.
A seguir, fizemos um mapa com a estrutura de interação de todos os sistemas.
Mostra a lógica que os eventos devem seguir e em que etapas o analista está indo. Pegamos os principais dados do CRM e os correlacionamos com os dados de publicidade e conversões. Colocando-o junto no myBI, renderizando-o no Power BI.
Funis de vendas
As vendas ao cliente foram conduzidas no Enybox CRM, nós as transferimos para amoCRM para facilidade de integração. Conseguimos reunir a lógica de vendas em três funis.
Três funis sucessivos
O primeiro funil é a consulta. Eu precisava trazer o cliente para se cadastrar na plataforma. O segundo funil corrige os primeiros pagamentos. Em seguida, o usuário confirmou seu registro. E nós, por sua vez, comemoramos o momento do pagamento e a cada nova reposição.
Como a análise deveria funcionar
| "Eventos" iniciais | "Eventos" finais |
|---|---|
| Formulário de feedback | Formulário de feedback |
| Registro no serviço | Registro no serviço |
| Primeiro depósito | |
| Teste (opcional com um pequeno reabastecimento) | |
| Recargas repetidas | |
| Recusa de uso (aquecimento pelo OP) |
Para que o sistema analítico funcione normalmente, você precisa coletar todos os eventos = marcar ações de conversão. Os eventos já entraram no sistema analítico, mas inicialmente eram apenas dois tipos, o que não é suficiente para relatórios.
Exibindo dados
Exemplo de painel
Após coletar os dados das conversões, foi necessário fazer um relatório a partir delas. A principal ferramenta de visualização de dados é o Microsoft Power BI.
No momento da conversão, um ID separado foi gerado no site para sincronizar os sistemas de publicidade e CRM. Por esse ID, vinculamos os dados de despesas e receitas. Portanto, correlacionamos os dados e pudemos construir relatórios sobre eles.
Economia da unidade. Retenção
O gráfico de retenção contínua do serviço de 1 a 12 meses de
retenção mostra o quanto os usuários estão engajados no aplicativo e com que frequência eles retornam a ele. Mas devido ao fato de o serviço funcionar na forma de reposição, tive que mudar esse indicador para retenção de rolagem. Mostra o mesmo que retenção, mas implica que toda vez que o usuário não reabasteceu a conta, ele também utilizou o serviço.
Conversão para o primeiro depósito
A conversão era altamente dependente do número de novos clientes e do início de seus pagamentos. Nos primeiros 9 meses, recebemos cerca de 430 novos registros e 90 pagamentos de novos usuários todos os meses. A conversão para compra no mês do registro foi de 20%, segundo dados de 12 meses.
Além de indicadores padrão
Houve a oportunidade de ver análises sobre os toques do cliente, tanto no momento de uma simples transição para o site, quanto no momento do registro e demais pagamentos. Acumulamos dados para encontrar o maior número de cadeias de conversão: O
usuário viu o anúncio → foi ao site → depois de um tempo entrou e olhou no contexto → cadastrado, mas não pagou → aqueceu com uma carta → ofereceu um test drive → testado → o OP “deu o primeiro pagamento” → 3 anos pagamentos estáveis.
Algo deu errado
No início, os iniciadores do projeto adiaram o início até o outono (eles se inscreveram na primavera). Essas "lacunas" no trabalho ocorreram mais de uma vez. Mas nós não pensamos sobre isso e tomamos isso como certo. Os principais problemas eram a comunicação e a burocracia nos processos de nossos clientes. É assim que você pode descrever todo o período de trabalho em um projeto:
Desenvolvimento lento
As lacunas no desenvolvimento devem-se à estrutura de trabalho do cliente. Trabalhamos em conjunto com a equipe do cliente e algumas tarefas só puderam ser realizadas por ele devido à alta segurança dos processos.
Perdeu dois sprints - perdeu um mês
Todos os gerentes e desenvolvedores de seu lado trabalharam em iterações de duas semanas. Mas eles constantemente colocam nosso projeto por último em prioridade e muitas vezes nossas tarefas não caem no "sprint".
Comunicação deficiente e falta de experiência
Durante o projeto, o gerente do cliente (parte interessada) mudou cinco vezes. Provavelmente, todo mundo conhece a sensação de quando o projeto em que você está trabalhando de repente deixa de ser interessante para o cliente. Mas mesmo isso pode ser resolvido.
Era mais difícil lidar com a incompetência das partes interessadas. Um deles era um grande executivo que conhecia bem seu produto. Mas ele nem mesmo entendia os princípios básicos da construção de processos de vendas. Passamos várias reuniões para persuadi-lo a remover o estágio com o status “Como vai você?” Do funil de vendas.
Imagine um funil de vendas como a imagem acima. Em um estágio, os gerentes precisam descobrir "como está o cliente". O que você acha que acontecerá com a análise de conversão desse funil?
Os gerentes descobrirão “como você está” do cliente em vez de movê-lo pelo funil, o status não é trivial. Não é óbvio quando colocá-lo: após o primeiro contato ou após a qualificação. Como resultado, os negócios "saltam" para frente e para trás ao longo do funil ou apenas ficam parados, em vez do movimento sequencial.
Durante o processo de venda, é impossível definir estágios intermediários nos quais os negócios se acumulam. Do contrário, todas as análises se tornarão uma bagunça e os gerentes perderão muitos contatos.
Fakapas do nosso lado
Não levamos em consideração a largura de banda do sistema. Para um evento de plataforma no pico, enviamos até 10 solicitações para amoCRM para executar a lógica dos processos de negócios.
100.000 eventos por dia * 10 solicitações para amoCRM = 1.000.000 solicitações por dia
1.000.000 solicitações por dia / 10 solicitações por segundo (limite AMO) = 100.000 segundos = ± 27 horas
Resultado: a sincronização nunca terminará
inicialmente selecionado amoCRM, como “repassar” o limite de requisições ao sistema. Porém, ao longo do desenvolvimento do projeto, os requisitos e funções aumentaram e "chegamos" ao limite.
Escolhemos a ferramenta errada. O AmoCRM não é fisicamente adequado para lidar com um grande número de solicitações.Além disso, o erro foi que desenvolvemos tudo em GO, e um especialista foi o responsável por isso. Quando ele saiu, havia uma montanha de código legado que ninguém conseguia entender. Mas, infelizmente, ou felizmente, isso não foi necessário.
Tudo quebrado de novo
Este caso é outro exemplo de um projeto que foi enterrado em aprovações e um monte de gerenciamento desnecessário.
Não tínhamos conhecimento técnico. Para o cliente - estabilidade na gestão e vontade de finalizar o projeto.
Mas isso é experiência. Graças a ele, agora tais tarefas parecem tão triviais quanto possível, e já reproduzimos uma solução semelhante em outro projeto.
Como o fracasso pode ser evitado
Para não repetir esses casos no futuro, destacamos os aspectos que devem ser observados ao trabalhar com clientes corporativos.
- : ; . , .
- . — . — . . .
- . KPI — .
- Pense no futuro. Mesmo ao desenvolver um MVP, você precisa examinar os gargalos que podem surgir no futuro. O projeto está sempre em expansão e é importante fornecer uma estrutura para não reescrever todo o código do zero.
O autor do artigo é Fyodor Anisimov, comerciante LAND PRO.