Mas, na prática, armadilhas o aguardavam. Vamos conversar sobre o que pode acontecer se você ajustar um pouco o design ou perder o preenchimento do seu modelo. E como consertar tudo.
Eu queria beneficiar novos usuários, mas eles naturalmente não se comportaram conforme o esperado
A principal ferramenta de vendas do Skyeng é um tutorial em vídeo introdutório gratuito com um facilitador. Realizamos aulas em nossa plataforma e acontece que um aluno tenta se conectar a uma chamada, mas seu microfone ou câmera não é capturado.
Isso pode acontecer por dezenas de motivos - de um erro banal em uma notificação no navegador (como nesta imagem) a casos completamente exóticos: por exemplo, uma vez que uma pessoa tentou trabalhar no Tesla e lá seu próprio software que não oferecemos suporte.
Se você não conseguir resolver o problema rapidamente, ocorre uma análise técnica da lição introdutória:
- o aluno permanece negativo,
- a aula do professor é interrompida,
- a escola perde a conversão para pagamento aqui e agora (esta é a principal métrica do nosso departamento), compensa a participação do professor na aula e inicia o processo de transferência da aula.
Todo mundo sofre. Portanto, no ano passado, iniciamos vários projetos para reduzir interrupções técnicas. Cada ideia foi testada: a empresa queria saber se o recurso estava funcionando e se os custos de suporte seriam recuperados.
Uma das soluções que tiveram de ser testadas foi a busca de verificação do equipamento. Originalmente era um widget, aqui estão suas telas principais.
A ideia é simples: não espere o momento de entrar na aula, mas convide o aluno a verificar a câmera e o microfone com antecedência - quando saiu de um aplicativo para treinamento. Se algo der errado, emitiremos um ticket para o suporte técnico, e a galera terá várias horas para resolver o problema.
Quando dividi os usuários em teste e controle, esperava que as pessoas do grupo de teste clicassem no widget e concluíssem a missão. O que poderia dar errado?
No grupo de controle ("A") tudo correu normalmente - as pessoas saíam de um aplicativo e continuavam com seus negócios. Mas após o teste, vimos que a porcentagem de falhas técnicas nos grupos "A" e "B" era semelhante a um centésimo de um por cento. Hmm, todos eles no grupo de teste passaram pela missão, mas não ajudou, ou ninguém entrou? Não sabíamos - não havia registro.
Os dois estágios se fundiram em um, e descobrimos que não podemos separá-los. Tive que reiniciar o teste e registrar o estágio chave “entrou na busca”. Descobrimos que cerca de 10% dos usuários estavam logados nele. Não houve um crescimento significativo na métrica: a busca caiu no esquecimento, a própria verificação do equipamento foi eventualmente incluída na integração durante um redesenho global. E agora eu verifico no início se tenho dados sobre todos os estágios principais do funil.
« - ?». ,
Além dos problemas técnicos, às vezes o aluno simplesmente não aparece naquela aula introdutória muito gratuita - porque ele dormiu demais, saiu voando da cabeça, algo foi transferido, e assim por diante.
Portanto, antes de cada aula, o metodologista precisa encontrar um aluno que esteja pronto para ligar: para isso, o sistema dá a ele vários contatos, e o professor liga para eles. Isso "corrói" 12-15% do tempo que uma pessoa pode gastar em algo mais útil ou agradável.
Parece uma boa oportunidade para automação - deixe o robô ligar. Mas precisamos de um teste A / B: afinal, algumas pessoas, ao ouvirem o robô, podem desligar. A possibilidade de perder algo é óbvia. Fizemos o teste e no início tudo saiu surpreendentemente bem, mas ... Fomos decepcionados pelo perfeccionismo.
Em vários cenários, o robô teve que transferir chamadas para um operador humano: por exemplo, se um aluno quisesse cancelar uma aula, o operador teve que fazer alterações no CRM. E às vezes o robô apenas encontrava interlocutores falantes - o sistema não foi projetado para reconhecimento de fala sério e suporte ao diálogo, aqui também era necessário conectar uma pessoa.
Queríamos tornar a experiência do usuário a mais perfeita possível.
Portanto, decidimos transferir essas chamadas imediatamente para a linha de telefonia de entrada. Mesmo que a pergunta não fosse urgente. Os metodologistas nos mesmos casos disseram: "Você será chamado de volta em 3-5 minutos para reatribuir a aula." E os operadores tiveram tempo para distribuir a carga de trabalho e ajudar a todos.
Os operadores não concordavam com o robô e ele criava picos com várias chamadas urgentes por minuto. O circuito acabou não sendo escalonável.
Nos momentos de pico, a situação lembrava um jogo clássico) Para a foto, graças à Wikipedia e seu colaborador perepelin30 .
Voltamos ao esquema usado pelos metodistas - se uma pessoa expressasse claramente um pedido de transferência, o robô responderia “Ligaremos de volta para você”. Apenas questões potencialmente urgentes foram imediatamente transferidas para as operadoras. Após essas mudanças, o teste teve que ser executado novamente, pois a mudança poderia afetar as principais métricas. E agora, antes de cada experimento, fazemos a pergunta: "Ok, se tudo der certo, podemos fazer o roll out?"
Eu executei o teste, verifiquei se tudo estava indo bem, fui fazer um monte de tarefas atuais
Skyeng tem um público muito legal e crescente - crianças que ensinam matemática e inglês conosco. Mas não podemos dar uma aula introdutória para uma criança se seus pais não estiverem presentes. Não podemos legalmente. Portanto, se a criança se conecta sozinha, a aula é interrompida. Então você sabe: negativo, regravação e assim por diante.
Os pais sempre foram avisados sobre isso oralmente, quando telefonavam, quando era combinado o horário da aula. Mas o tempo passou desde a ligação até a aula e, claro, nem todos se lembraram desse acordo.
Então veio a solução: vamos enviar um lembrete por SMS. Aproximadamente, esse texto foi deixado para os pais mais perto da hora da aula introdutória.
Um aumento no número de aulas introdutórias sem interrupção não significa um aumento na conversão para pagar. Você precisa estimar o ROI. Para fazer isso, vamos conduzir um experimento:
- vamos dividir aleatoriamente todos os pedidos de encaminhamento de crianças em dois grupos,
- não enviaremos nada aos pais do primeiro grupo - eles têm um fluxo regular,
- os pais de outro grupo receberão dois lembretes por SMS: 24 e 1-2 horas antes do início da aula.
Começamos o teste, fizemos a verificação no primeiro dia - e fomos limpar a rotatividade.
Depois de algumas semanas, eu olho para o painel - e lá, além dos grupos de teste e controle, existem alguns outros usuários.
Se quiséssemos dividir 50 por 50, o gráfico vermelho indica claramente que algo deu errado.
Descobriu-se que a culpa era de um bug banal: algo estava errado com os eventos, nem todo mundo estava enviando SMS em gatilhos. O bug foi corrigido, mas o teste teve que ser reiniciado: no final, mesmo que você tenha o design de teste correto, com todos os modelos preenchidos, e assim por diante, isso não significa que o teste será executado sem problemas. E você deve examiná-lo sempre que possível.
PS Eu realmente espero que este texto ajude alguém a cometer menos erros em seus testes. Muito provavelmente você terá ou já tem seus próprios casos engraçados: será legal se você também os compartilhar algum dia!
Postagem pps com base em um relatório na comunidade Rostov IT RnDTech - se você mora em algum lugar do sul do país, participe, os caras estão fazendo uma grande mudança.