SLA era simples de comunicar e caro de errar
A proposta do serviço era clara: concluir o atendimento em até 4 horas. Caso contrário, a operação assumiria integralmente o custo de peças e mão de obra. Em outras palavras, cada violação de SLA era também uma perda direta de receita.
Esse desenho criava um risco financeiro imediato. O ticket médio do novo modelo era menor do que o da oficina tradicional, o que aumentava ainda mais a necessidade de controlar desvio, tempo de execução e incidência de atendimentos gratuitos.
Havia também um risco estratégico maior. O piloto local seria usado como referência para expansão a outros mercados. Escalar sem visibilidade sólida sobre custo, SLA e performance comprometeria a confiança da estrutura global no modelo.
O terceiro problema era técnico. O dashboard anterior não oferecia um modelo de dados consistente, os filtros não conversavam entre si e parte da arquitetura dependia de componentes que seriam descontinuados. A operação gerava informação, mas ainda não gerava confiança suficiente para decisões rápidas.
Transformar um piloto operacional em uma estrutura diária de decisão
A resposta foi reconstruir a base analítica antes de discutir escala.
A MATH redesenhou a camada de dados e visualização para que o modelo de serviço móvel deixasse de operar por percepção e passasse a operar com leitura contínua de desempenho. O projeto começou pela reconstrução completa do modelo de dados, corrigindo inconsistências, reorganizando indicadores e garantindo que filtros e métricas respondessem à mesma lógica.
Na camada de uso, as visualizações foram redesenhadas para serem claras, funcionais e úteis no dia a dia da operação, sem ruído analítico. O objetivo não era produzir mais um dashboard. Era dar à operação uma ferramenta confiável para acompanhar SLA, identificar risco financeiro e agir antes que desvios virassem custo.
A arquitetura também foi preparada para transição tecnológica sem atrito. A camada analítica foi mantida em QlikSense, enquanto os pipelines foram organizados para uma migração progressiva ao GCP, sem impacto perceptível para o usuário final. Isso preservou continuidade operacional e devolveu ao cliente mais controle sobre evolução futura.
Outro componente importante foi o Daily Automated Email. Em vez de depender de extrações manuais ou checagens pontuais, a liderança passou a receber uma leitura automática e recorrente do status da operação. Isso criou um fluxo de alinhamento executivo contínuo com baixo esforço humano adicional.
O projeto não criou apenas visibilidade. Criou um modo de acompanhar custo e SLA no mesmo ritmo em que o serviço acontece.
O modelo ganhou controle antes de ganhar escala
O primeiro resultado foi operacional. Mais de 1.500 serviços passaram a ser monitorados ponta a ponta, o que tirou a operação do escuro e colocou o SLA sob observação diária.
O segundo resultado foi de desempenho. O tempo médio de atendimento ficou em 1h32, bem abaixo da promessa de 4 horas. Apenas 2,5% dos atendimentos ultrapassaram o limite, o que reduziu de forma relevante o risco financeiro associado aos chamados gratuitos.
O terceiro resultado foi estratégico. A operação passou a testar a viabilidade do modelo com base em dados confiáveis, não em suposição. Isso permitiu avaliar a expansão internacional com mais critério, sem transformar crescimento em exposição de margem.
O quarto resultado foi institucional. Durante quase um ano de projeto, não houve escalonamentos executivos. Em um contexto com histórico de tensão operacional, esse dado mostra uma mudança importante na relação entre time local, liderança regional e operação analítica.
O quinto resultado foi de legado. O modelo não ficou restrito a um piloto local. Ele se tornou estrutura replicável para outros mercados, com base técnica e operacional suficientemente sólida para sustentar novos desdobramentos do serviço.
