Contexto da pesquisa prévia
Havia participado de uma pesquisa quantitativa e qualitativa anteriormente com minha líder de então e com o time de pesquisa, com o objetivo de explorar o modelo de pagamento pós-pago (lembrando que os bundles são pré-pagos) e entender quais problemas esse modelo resolvia, para quem resolvia e quais os potenciais ganhos.
Esse contexto é importante, pois usamos alguns dos dados dessa pesquisa ao considerar a implementação do Pix.
Detalhes da pesquisa
O processo de pesquisa foi pautado nas seguintes etapas:
Levantar pesquisas anteriores relacionadas a métodos de pagamento
Sintetizar as informações dessas pesquisas
Fazer um benchmarking considerando o modelo de negócio do GetNinjas
Fazer um benchmark sobre assinaturas e modelos pós pago
E realizar um formulário exploratório sobre o assunto com os usuários
Obtivemos os seguintes resultados:
Highlights
A ideia de pós-pago não se mostrou interessante para os profissionais que já converteram na plataforma
A ideia de pós-pago se mostrou mais interessante para profissionais novos na plataforma
A quantidade de moedas que vem em um bundle se mostrou insuficiente para liberar pedidos em alguns cenários
De volta ao problema
Quando o MRR começou a diminuir, revisamos essa pesquisa e outras pesquisas anteriores com o objetivo de encontrar soluções para aumentar a compra de bundles por parte dos profissionais.
Método de pagamento atual
Naquela época, o GetNinjas operava com pagamentos via cartão de crédito e boleto. Embora o Pix já estivesse se tornando popular no país, ainda não o tínhamos integrado ao sistema.
Avaliando a mudança de modelo de negócio
Conforme mencionado na pesquisa acima, o modelo de pagamento pós-pago mostrou-se interessante para novos clientes e era algo que estávamos considerando incluir na plataforma. No entanto, algumas definições precisavam ser feitas antes de alterarmos o modelo de pagamento da plataforma.
E agora?
Aqui que os estudos das pesquisas anteriores se fizeram importante.
Um insight muito importante
Quando a pandemia de Covid-19 começou, muitas pessoas ficaram desempregadas. Constatamos em nossas pesquisas regulares que muitos usuários acabaram comprometendo seus cartões de crédito devido à falta de emprego recente. Essas pessoas se cadastraram no GetNinjas para encontrar serviços como uma fonte de renda durante esse momento sombrio da nossa história recente.
Nesse período, observamos que a queda nas compras de bundles ocorreu por diversos motivos, incluindo:
Falta de confiança em desbloquear um pedido e não fechar com o cliente.
Abstenção de comprar bundles devido à relutância em comprometer o cartão de crédito em um momento de incerteza profissional.
Relação dos insights com a solução
No que diz respeito à questão da confiança em liberar um pedido, isso foi abordado separadamente e exigiu um esforço maior. Portanto, não abordarei isso neste caso.
Agora, falando sobre não comprometer o cartão de crédito:
Surge uma hipótese
Como precisávamos mitigar o problema da diminuição do MRR, reuni membros da equipe e outros profissionais de design e negócios para uma dinâmica de How Might We. Durante essa dinâmica, surgiu uma hipótese cujo teste parecia ser rapidamente validável:
Se enfatizarmos métodos de pagamento que não dependam do cartão de crédito, mais usuários comprarão bundles.
Foi com base nessa hipótese que implementamos o Pix na plataforma.
Métodos de pagamento que não comprometem o cartão
Tínhamos três possibilidades para validar esta hipótese:
Investir no boleto,
Investir na transferência, ou
Trazer o Pix para a plataforma.
Enfrentamos obstáculos técnicos e de negócios nos dois primeiros modelos, e foi aí que o Pix se destacou. Pois proporcionava uma forma de pagamento sem a espera pela confirmação do boleto e dispensava investimentos em tecnologias de validação de transferência bancária. Como já tínhamos acesso à tecnologia para validar o Pix recebido, decidimos avançar com a implementação.
Estruturando a solução
Comecei desenhando um fluxo de usuário para a solução e me baseei em alguns pontos para garantir uma experiência positiva:
O profissional precisa ser informado quando está ficando sem moedas.
O profissional deve ser alertado antes de ficar sem moedas suficientes para desbloquear um pedido.
Precisamos simplificar o processo de compra sem interromper a jornada na loja de pedidos.
Fiquei atento a dois problemas que identifiquei em outro teste de usabilidade, como estes:
O usuário precisa sair da loja de pedidos para comprar bundles, correndo o risco de perder o pedido que encontrou.
Falta de notificações sobre a quantidade de moedas disponíveis, resultando na incapacidade de desbloquear um pedido quando necessário.
Com isso, a estrutura ficou assim:
Desenhando a solução a solução
Após validar logicamente o fluxo de pagamento, iniciei o design da solução. Novamente, baseei-me em algumas observações que fiz em outros benchmarks:
Os usuários precisam ser informados sobre o novo método de pagamento.
Eles precisam entender como funcionam as notificações quando o bundle está acabando.
A loja de moedas
A loja de moedas funcionava da seguinte maneira:
Você seleciona o pacote de bundles desejado.
Procede para o fluxo de pagamento. Este fluxo de pagamento, como mencionado anteriormente, aceitava cartão de crédito e boleto.
Assim:
Inclui então o card de pagamento via pix.
Como se tratava de um novo método de pagamento, optei por destacar essa nova funcionalidade. Incluí um banner destacado após encontrar essa ideia em uma pesquisa rápida de referências.
A loja de moedas então ficou dessa forma:
Definimos o prazo de 1 mês com esse destaque para os usuários se acostumarem com a novidade.
Renovar meu pacote
Como mencionado anteriormente, também era necessário lembrar o usuário de renovar o pacote contratado. Por isso, introduzi a opção de ativar ou desativar essa notificação no momento da compra do bundle.
Como padrão de negócio, a opção de lembrete de renovação já estaria marcada. No entanto, permiti que o usuário tivesse a opção de recusar a notificação.
Notificação
Para simplificar o fluxo, era importante não retirar o usuário da visualização de pedidos para renovar seu pacote de moedas. Portanto, implementei uma forma de notificar sobre as moedas sem interromper o fluxo e sem que a notificação passasse despercebida:
Esse card seguiria algumas regras para aparecer, mas é importante focar principalmente em como ele surgiria. Para evitar poluir a loja de pedidos, já que não havia uma central de notificações, coloquei o card no meio da loja com o seguinte comportamento:
A cada quatro pedidos visualizados, o card apareceria. Isso criaria um 'incômodo necessário', incentivando os usuários a comprar. A loja de pedidos agora ficaria assim:
*Coloquei em 3º na imagem só para exemplificar como ficaria sem precisa de uma imagem maior.
E assim ficou o fluxo
Loja de moedas
Pagamento
Loja de pedidos
Renovação
Confirmação
Hora de testar
Para testar nossa hipótese, propus um teste A/B para analisar a conversão.
Segmentamos 50% dos usuários gerais para o grupo de teste e 50% para o grupo de controle. Esse teste teve duração de um mês para garantir relevância estatística.
Resultado do teste
O grupo de teste apresentou um aumento de 20% na compra de bundles.
Dos usuários do grupo de teste, 60% ativaram a notificação de recompra de moedas.
Conclusão
Com uma pequena mudança na percepção de como os usuários se relacionavam com os métodos de pagamento, conseguimos, em um teste simples, aumentar a compra de bundles. Esse resultado nos levou a disponibilizar para toda a base a estrutura que incluía o pagamento com Pix.
No mês seguinte, tivemos um aumento geral de 12% no MRR apenas com o método Pix. Isso nos levou a associar e replicar a notificação nos outros métodos de pagamento para verificar se haveria impacto no negócio, mas isso é outro caso.
Curtiu o que viu? Entre em contato comigo, vamos bater um papo!
Lucas Almeida