Diagnóstico

O primeiro passo foi fazer algumas alterações no sistema de checkout anterior, de modo a implementar um sistema que pudesse disparar alguns eventos. Com base nesses resultados preliminares, nós poderíamos ter algumas pistas de por onde começar a resolver este problema.

Nos primeiros 6 meses nós analisamos cada conversão, uma a uma, e todo o fluxo de navegação que aquele usuário teve até tomar a decisão de compra. Observamos também que tínhamos uma taxa de desistência muito alta, mas aquela versão do sistema não nos permitia saber quem eram esses desistentes. Sendo assim, reformulamos o processo de checkout.

Solução

Nossa nova solução precisava ser dinâmica e flexível, pois era necessário integrá-la em vários sistemas e sub sistemas que não estavam no mesmo servidor, e nem mesmo eram desenvolvidos na mesma tecnologia. Após o sucesso da descentralização dos serviços do Leis Municipais, iniciada e testada durante a reestruturação do Leis à Sociedade, a equipe estava mais confiante nessa abordagem, e foi natural que essa arquitetura também fosse implementada no sistema de checkout, que acabou sendo embarcado junto a API do sistema de Accounts.

Optou-se por manter um sistema escrito inteiramente em Javascript, onde o plugin deveria montar os elementos no DOM automaticamente sem depender de alterações no HTML das aplicações pré existentes. O evento que acionava o plugin ficava em um atributo nos botões CTA, junto a um código do produto em si.

Os dados dos pacotes, valores e formas de pagamento eram coletadas pela API REST do servidor de accounts, de modo que qualquer alteração nesses dados seria aplicada dinamicamente, e instantaneamente em toda a rede de sistemas do Leis Municipais, incluindo as diversas versões de landing pages.

O sistema foi projetado para funcionar com diferentes gateways de pagamento, pois na época, alguns produto eram processados pelo PagSeguro, outros pelo Mercado Pago, e as negociações com o gateway da CIELO ainda estavam abertas.

Para que nós não tivéssemos que reestruturar todas as landing pages para comportar novos elementos, optamos por uma solução em que seria aberta uma caixa sobrepondo a página para interação com o sistema de pagamentos. Essa solução também se mostrou eficaz nas análises de usabilidade, pois ofuscava os elementos de distração e fixava o foco do usuário exclusivamente na interação com o modal.

Tracking

Apesar de termos alguns dados do comportamento dos usuários, e usado esses dados como base para a nova proposta, era evidente que precisávamos coletar mais informações. Mas como fazer isso, e ao mesmo tempo, simplificar o processo?

Anteriormente nós obrigávamos os usuários a se identificar, dessa forma, fazíamos as associações do usuário ativo com a sessão de navegação. Porém, percebemos que uma grande parcela se perdia na tela de login, alguns por não lembrar a senha, outros por não querer se registrar, e outros por problemas de sistema.

Na nova proposta, nós nos questionamos: Quais informações são realmente necessárias para vender um serviço? Chegamos à conclusão que eram necessários apenas o email do cliente, o plano e os dados de pagamento. Então removemos tudo, inclusive o cadastro.

Assim que o usuário clicava em um botão CTA, era aberto uma caixa sobre a landing page, e uma notificação era lançada no painel de rastreamento.

Antes de mostrar os planos, nós precisávamos identificar a sessão, sendo assim, pedimos apenas o email do usuário. Se fosse um usuário registrado, a navegação era associada ao cadastro dele, se não, era criado um cadastro temporário apenas para o processamento do pagamento. Depois um técnico analisava o caso para detectar se o usuário já existia e usou um outro email, ou era um novo usuário.

Após informar o email, são apresentados pro usuário quais são os planos disponíveis para aquele serviço, e as opções de pagamento desejadas. Caso o usuário desistisse nessa etapa, ficava evidente a desistência pelo valor do plano. Caso o usuário escolhesse algum plano, o sistema apresentava os campos do Gateway em questão, na qual não tínhamos controle, mas se houvesse desistência, ficava evidente um problema de usabilidade por parte do gateway, e um técnico era acionado para ajudar o usuário a fazer o pagamento.

Após a conclusão, se o pagamento fosse por cartão, e esse fosse aprovado, e ainda se o usuário tivesse registro, ele era levado para a página do serviço que exigia a autenticação por senha. Do contrário era informado que o usuário deveria aguardar um email segmentado com instruções sobre como acessar o serviço.