A ideia da criação de um relatório de pedidos foi pensada no segundo dia do mês de Abril. A partir deste dia eu me dediquei a investigar todos os meses sem exceção, levantando um database extenso que possibilitará uma melhoria na análise de dados e nas tomadas de decisões da equipe durante as reuniões (caso houver). O dashboard foi realizado no Power BI com todos os dados exportados da plataforma do WAPI. Os dados referidos neste caso são pedidos que foram constados com status de "Erro". As métricas para recuperação estará listada abaixo assim como soluções serão apresentadas para sonegação de cancelados. Como um novato, inexperiente, portanto curioso pelo ramo da logística, colocarei fontes de pesquisa e estratégias para não soarem como soluções vindas de minhas imaginações. Como também acostumado em criar bastante tangentes, você poderá acessar cada tópico clicando nos links anexados no ToC acima, assim facilitará a navegação e poderá ignorar paragráfos desnecessários.

Métricas de Recuperação

O conceito claro e nitido das métricas de recuperação é a redução de cancelamentos e perdas. O que se espera é que a cada mês, o número de pedidos com status de erro seja reduzido. Para um aumento exponencial na quantidade destes, seguimos as tais métricas:

1. Alteração do endereço com ferramentas de geolocalização na plataforma.
2. Alterações minimas em detalhes disponibilizados no status erro.
3. Contato com cliente.
4. Comunicação direta com o armazém.

Objetivamente, temos diversos outros fatores benéficos, e um tanto considerados cruciais para utilização destas práticas. Uma delas é a suposição de que um cliente se torne um membro de nossa loja por exemplo. Se o cliente faz compras contigentes, e divulga o nosso trabalho à terceiros, geramos customer fidelity. O que é primordial para diminuições de perdas consecutivas. Ademais, muitas vezes é por conta do próprio cliente que o pedido há de atrasar, e isso deve-se a falta de dados inseridos, ou inseridos erroneamente nos campos de texto da nossa plataforma primária (Shopify). Como opção à mitigar estes falsos positivos, pude aderir o bloqueio de IP addresses de regiões não europeias no aplicativo do COD Form, o qual funcionou perfeitamente desde o mês de Abril. Esta ação pode não ser totalmente eficaz, supondo que o COD Form venha a atualizar o aplicativo e gere uma deseleção do bloqueio de IPs fora da região Européia. Mas, tendo o feature no aplicativo podemos continuar esquivando estes imprevistos.

É por isso que além de perpetuar certificando se houveram endereços inseridos incorretamente na plataforma, truncagens e reavaliações são realizadas constantementes em nossos aplicativos antes de subirem para a integração do WAPI.

Ciente que ainda assim não ficamos longe de erros. Tento viabilizar outras perspectivas para reajustar problemas como o acompanhamento de entregas por exemplo. (do qual não sei se temos ou não um responsável pela inspeção). Pedidos que estão pendentes costumam enviar dados pela corretora de transporte, e é somente acessando a webpage da transportadora que conseguimos saber se houve algum problema. Para isso pensei em criar um script onde consiga dar fetch em cada delivery id e linká-los em uma página somente. Assim poderemos visualizar com mais detalhes o que está acontecendo sem que precise filtrá-los um a um na plataforma do WAPI.

Processo de Certificação

Para parear os pedidos que foram editados nos status de erro, fazemos um bulk de todos os números WH ou "order id" e certificamos a olho nú com os dados exportados juntando as planilhas umas com as outras. Para um exemplo prático e visual segue a imagem de exemplo do que referimos quando "bulkamos" estes pedidos.

Separando por blankspaces conseguimos filtrar os mesmos pedidos que estavam em status error na aba de Fullfilments, cujo o padrão após as edições é transformar os alterados em "Pending". Neste caso, pending seria o "modo de espera", um pedido pendente à ser enviado. O que não é o caso na figura acima. Notoriamente, um mero exemplo utilizado nos filtros dos produtos com erro constatados.

A principal razão desta certificação é para comprovar que não houve Omissão de Dados além de evitar inferências manipuladas. Tal ato é altamente prejudicial e contrário aos princípios de transparência, confiabilidade e eficácia na análise de dados. Além disso, prejudica a credibilidade do dashboard e da organização, sugerindo manipulação ou falta de competência. Tal prática também viola princípios de governança de dados, especialmente por envolver datasets sensíveis como os de endereços e codAmount.

Power BI dashboard

Aqui, deixamos as planilhas mais simplificadas para o uso diário. Os primeiros passos para poder conciliar e fazer relações de dados é exportá-los como dito anteriormente. Após esssa coleção temos de juntar as peças em um campo onde possamos criar matrizes e gráficos sem que terceiros tenham acesso a dados sensíveis ou que dificultem a leitura. Por estes motivos faço truncagem de pedidos por um dataset nomeado editedStatus. Este dataset é o que contém todos os pedidos que foram editados, cancelados e com espaços em branco para o encaminhamento da equipe de comunicação com cliente. Este passo não é necessáriamente considerado o mais importante, visto que, como marcado nas Métricas de Recuperação, para uma reabilitação de pedidos o essencial é o status de "Delivered".

Métricas de Cancelamento

As métricas de cancelamento listadas no relatório abordam três principais causas de pedidos cancelados:

Pedido Fraudulento: Refere-se a pedidos realizados de forma mal-intencionada ou com informações falsas. A solução envolve a implementação de sistemas de verificação e validação de dados para identificar fraudes antes da confirmação do pedido.

Pedido com Endereço Inválido: Ocorre quando o endereço fornecido pelo cliente está incorreto ou incompleto. A solução está na utilização de ferramentas de geolocalização e comunicação com o cliente para corrigir os dados antes do envio.

Falta de Resposta do Cliente: Acontece quando o cliente não responde às tentativas de contato para resolver problemas relacionados ao pedido. A solução é estabelecer canais de comunicação eficientes e persistentes para obter respostas rápidas.

Essas três métricas cobrem as principais razões para cancelamentos. São por causa destes trancafiadores que o número de pedidos não enviados tendem a aumentar.

██╗      ██████╗  ██████╗     ████████╗ █████╗ ██████╗ ██╗     ███████╗
██║     ██╔═══██╗██╔════╝     ╚══██╔══╝██╔══██╗██╔══██╗██║     ██╔════╝
██║     ██║   ██║██║  ███╗       ██║   ███████║██████╔╝██║     █████╗  
██║     ██║   ██║██║   ██║       ██║   ██╔══██║██╔══██╗██║     ██╔══╝  
███████╗╚██████╔╝╚██████╔╝       ██║   ██║  ██║██████╔╝███████╗███████╗
╚══════╝ ╚═════╝  ╚═════╝        ╚═╝   ╚═╝  ╚═╝╚═════╝ ╚══════╝╚══════╝

Como vamos lidar com diferentes tipos de arquivos e com grandes quantidades de dados, resolvi padronizar a nomenclatura de cada um visando a adaptação para quem for manusear as planilhas. Como nossos arquivos serão vistos nas extensões .xls e/ou .pbix pensei em fazer a separação entre o que chamarei de main files, ou arquivos principais, e exports, exportados.

Arquivos príncipais terão pbi no ínicio do nome. Isso é devido a utilização dele para a criação do Dashboard das Estimativas de Recuperação. Em seguida para a identificação de que foi utilizado o dataset editedStatus, o mês, e o dataset estarão em camelCase pós underline (ou underscore). i.e

        
            pbi_01eS.xlsx
            pbi_01eS.pbix
            pbi_01eS.csv
        
    

Todos as exportações de pedidos com status de erro serão extraídas e renomeadas para a abreviação das palavras "error status". Então nestes casos os arquivos serão comumente vistos como:

        
            es_dd-mm-yy.xlsx
            es_dd-dd-mm-yy.xlsx
        
    

        
            ex_dd-mm-yy.xlsx
            ex_dd-dd-mm-yy.xlsx
        
    

Os próximos caracteres como de costume referem-se ao dia, mês e ano em que o arquivo foi exportado. Porém, esses nomes podem variar de acordo com o contexto de filtros utilizados na plataforma. Nestes casos eu costumo fazer sorted by date na própria plataforma para poder conseguir exportar todos e trunca-los no príncipal, e por conta disso como no segundo arquivo, temos dias extras depois do underscore por que os filtros funcionam "in betweeen". O que seria entre os dias X, até o dia Y. Como padrão temos três underscores, diferentes do primeiro que só continha um.

— Mas e se houver a necessidade de somente contatar os clientes (como já aconteceu)?

Nestes casos, criamos um arquivo com o a abreviação de "cc" que refere-se a "contact customer".

        
            cc_dd-mm-yy.xlsx
        
    

Feita esta introdução, eu não espero que entendam 100% a nomenclatura dos arquivos. Saber diferenciar qual é o principal e qual são os exportados já facilita a visibilidade do backlog de quais arquivos estão sendo alterados e quais já foram ou necessitam de dados extras. O log table é a razão pela qual supervisão é importante. Sabendo com quais dados eu estarei manuseando é o método de inspeção que prioriza evitar erros. Todas as alterações podem ser visualizadas no repositório do github ad hoc. A página sofrerá alterações porém cada commit poderá ser revisado através deste link

Janeiro

Fevereiro

Março

Abril

Maio

Junho

Julho

Agosto

Setembro

Outubro

Novembro

Dezembro