O objetivo

Atualmente trabalhamos com banco de dados ao invés de planilhas. Dessa forma, conseguimos fazer consultas diferentes dentro de um banco de dados com várias tabelas, filtrar as tabelas da melhor forma possível e criar visualizações específicas para ter análises mais precisas. Para isso, utilizamos a linguagem SQL dentro do que chamamos de “querys”. As querys são códigos que transmitem a nossa linguagem humana para a máquina, fazendo com que nosso banco de dados entenda a tabela que queremos e traga para nós apenas os dados necessários.

A query flow_BI foi criada na intenção de retratar as informações de passagem entre etapas de forma que seja possível extrair a quantidade de tempo que os deals ficaram em cada uma delas no Pipedrive, mais conhecida como “duração da etapa”.

Além disso, a query ainda consegue trazer o ciclo de vendas e jornada do deal. Sendo ciclo de vendas o tempo que o deal fica entre call feita e encerramento do ciclo (Ganho, Perda ou exclusão).

O ETL

Extract, Transform and Load. Isso é popularmente conhecido como ETL dentro do mundo dos analistas de dados. Trata-se do processo de extrair dados de uma fonte, transformar e modelar esses dados para que eles fiquem limpos e por fim carregar esses dados para um banco de dados.

Todos esse processo pode ser feito por um único software. No caso, o software utilizado foi o Pentaho, que consegue fazer todo o processo de ETL.

O processo de ETL nesse caso acabou sendo um pouco complexo. Isso ocorre pois as informações que queremos estão em bases diferentes, sendo necessário fazer o que chamamos de join. Esse comando é responsável por relacionar duas tabelas e trazer informações com base em um campo em comum, no caso o Id.

A primeira tabela traz para nós informações de entrada e saída das principais etapas. Porém, nessa query não é possível trazer a entrada de Lead_Outbound, MQL_MKT e a data de fechamento do deal (que é o momento onde ele dá won, lost ou é excluído). Para isso foi necessário fazer uma outra query.

Já essa tabela traz para nós as informações de criação do deal (add_time) e fechamento do deal (close_time)

O processso como um todo irá então trazer em uma tabela única as informações das etapas junto com close time e add time de acordo com o id, que é o vínculo das duas tabelas.

Regras de negócio

Para calcular a duração da maioria das etapas, o processo trabalha de forma simples:

  • Duração = data de saída na etapa - data de entrada na etapa

Porém, para Lead_Outbound, MQL_MKT, Jornada do deal e Ciclo de venda foram necessárias algumas alterações específicas no ETL.

  • Lead_Outbound e MQL_MKT

As durações respectivamente são calculadas da seguinte forma

Duração_Lead_Outbound = data de saída na etapa - add_time(canal outbound)

Duração_MQL_MKT = data de saída na etapa - add_time(canal mkt e indicação)

Sendo assim, foi necessário dividir os deals que estão no canal de outbound e nos canais de MKT e indicação para conseguir criar os campos de entrada de cada uma das etapas (no caso, dividir um campo com add_time no canal outbound e outro com add time nos canais de mkt e indicação).

Essa divisão foi feita na segunda etapa. Assim conseguimos criar os campos de Entrada_Lead_Outbound e Entada_MQL_MKT.

  • Ciclo de vendas

Para o ciclo de vendas, o cálculo utilizado foi o seguinte:

Ciclo de vendas = close_time - Entrada_Call_Feita_Sales

Sendo assim, ambos os campos precisam ter informações preenchidas para que o ciclo de vendas seja calculado. O que ocorre é que alguns deals ainda estão em aberto, portanto o close_time pode ser nulo. Esse campo será preenchido quando houver alguma mudança no status do deal (won,lost,exlcuído). Por conta disso foi necessário um ajuste na query.

A query de close time traz para nós uma condição e dois campos. Um deles é o close_timereal, que é o campo sem nenhuma modificação, com os valores null quando o deal estiver em aberto.

Outro campo é o close_time. Nesse campo, a condição é a seguinte:

Se o campo for nulo, a data retornada será a do dia atual (now). Se o campo estiver preenchido, irá retornar o próprio valor.

Assim, para os deals em aberto no funil de vendas que passaram por call done, teremos o ciclo de vendas até o dia atual. Por exemplo. Deal entrou na etapa de call done dia 01/09/2021 e ainda está em aberto no dia 09/09/2021. Seu ciclo de vendas será de 8 dias, mesmo em aberto. E atualizará a cada dia.

Problemas que podem ocorrer nesse campo:

  1. O deal não passou por call done no funil de vendas: nesse caso não terá nenhum valor. O campo PRECISA de uma referencia para comparar com o close_time. A referencia que usamos é a entrada em call feita. Se esse campo não estiver preenchido, nada pode ser feito.

  2. O deal deu ganho em 2021 e passou por call done em 2020: a query que traz a entrada em call done consegue puxar dados apenas de 2021. Portanto, se existir deals que entraram em call done em 2020, o ciclo de vendas não retornará nenhum valor. Esse é um problema d banco de dados e limite de processamento, que estamos tentando resolver.

  • Jornada do deal

Esse campo irá ser calculado da seguinte forma:

Jornada do deal = close_time - add_time

Lembrando que, se o deal estiver em aberto, seu close time usado para o cálculo será o dia atual. Portanto esse campo não deve estar nulo nunca.

Tabela e atualizações

A terceira etapa é responsável por fazer os cálculos, ajustar os dados para o formato de data, e enviá-los para a planilha pentaho_flowbi.

Esse processo atualmente está rodando no pentaho_server, na minha máquina local (Felipe). A rotina do processo é de 1 em 1 hora à partir do momento que a máquina é iniciada até o momento que é desligada.