Plano de Ação — Curto Prazo e Alto Impacto (Semanas 1 e 2)

Objetivo: reverter em curtíssimo prazo o quadro de caminhões presos em oficinas — tanto os da esteira de novas vendas quanto os de drivers ativos — com qualidade de entrega que zere as quebras "na esquina". Período: Semana 1 = 20–26/07 · Semana 2 = 27/07–02/08. Planos detalhados: um documento por frente — ver índice ao final.

Disposição das forças (a partir de segunda 20/07)

Cadência de guerra: ponto de controle diário do trio Arcson+Douglas+Robert (manhã) · report diário de progresso à diretoria no grupo · checkpoints 2x/dia com oficinas · problemas fora do processo reportados no grupo Slack do plano crítico.

Semana 1 — Estancar e enxergar (20–26/07)

Critério de sucesso da semana 1: sabemos onde está cada truck e quando sai (calendário confiável); zero truck de cliente parado > 2 dias em shop sem ação definida (estoque de 40 caindo rumo a zero); zero truck entregue reprovando na saída; entregas estáveis em 4/dia que não voltam; churn contido abaixo de 20.

Semana 2 — Consolidar e acelerar (27/07–02/08)

Critério de sucesso da semana 2: esteira previsível ponta a ponta no Nexus, indicadores em tempo real para a diretoria, STL alinhado, e capacidade de entrega crescendo sem sacrificar qualidade.

Índice dos planos detalhados

1. Status 100% + donos + calendário realista
2. Contrato ativo em shop + virada FleetNet
3. Qualidade: inspeção, diagnóstico e stress test
4. Presença nas oficinas + cadência
5. Priorização da fila + despressurização
6. Entregas 4/dia até regularizar
7. Churn: entrada controlada + esteira no Nexus
8. Comercial: BFTO
9. Retenção com CX
10. Semana 2: PM/PTI, medição e produção

Frente 1 — 100% dos trucks com status + donos + calendário realista

Dono: Arcson · Prazo crítico: segunda 20/07 EOD Por quê: com 100% dos trucks com status e esteiras previstas, o calendário passa a mostrar a previsão realista de cada entrega — e a empresa sabe onde está de verdade. Sem essa visibilidade não há gestão de fila nem cobrança objetiva de oficina.

Estado de partida (o que já temos)

• Nexus manutenção em dev: nexus.billor.dev/tms/maintenance, carga Fleetio→Nexus validada — 172 trucks posicionados, 0 unmapped (15/07).
• 13 fluxos padronizados + master workflow documentados, de/para Fleetio→Nexus, planilha Pipelines-Stages validada 14/07.
• Donos por pipeline definidos: Recon=Kadu · Rescue/Swaps/Reserve/Load Rescue=Corso · PM/PTI/DOT=Jonathann/Deivid · Road assistance=Senna · Post-sale=Emerson · Preditiva=Luke.

Gaps a fechar segunda

1. Recarga fresca Fleetio→Nexus (dados de 15/07 já envelheceram; rodar nova carga manual de manhã).
2. Trucks/trailers sem status ou com status legado — varrer exceções e posicionar 100% (incluir trailers, diretriz José Moreira 11/07).
3. Donos sem confirmação: New truck/trailer (Ana/Corso [CONFIRMar]) · Accidents (aguardando reunião do Guilherme) · Yard care (dono nominal) · esteira in-house DC e truck reprovado (mínimo viável: criar as duas esteiras com estágios simples e owner provisório).
4. Calendário de entregas: para cada truck da esteira de vendas, previsão de disponibilidade = estágio atual + SLAs restantes (incluindo o novo SLA de stress test da Frente 3). Publicar visão por dia para Carol/Adri e para o report diário.
5. Status dos trucks com contrato ativo em shop entra na mesma varredura (alimenta a Frente 2).

Passo a passo (segunda 20/07)

Definition of done

• 0 trucks/trailers sem esteira+estágio+owner no Nexus.
• Calendário v1 com previsão de entrega por truck (com margem por nível L1–L5) publicado.
• Lista das exceções que não fecharam com nome de quem destrava e prazo.

Riscos

• Dados Fleetio desatualizados na origem → mitigar com validação dos donos por esteira (quem conhece o truck corrige na hora).
• Trailers historicamente fora do controle → aceitar v1 com menos precisão, marcar [CONFIRMAR] e fechar na semana.

Frente 2 — Dono dos trucks com contrato ativo em shop (≤ 4 dias) + FleetNet

Dono do plano: Arcson · Owner do processo (proposto): Senna (Maintenance Support / Road Assistance), com Emerson Por quê: trucks com contrato ativo que entram em shop hoje não têm dono: ninguém organiza a fila com as oficinas nem garante o limite de 4 dias parado (teto da compensação). Além do custo, é a maior fonte de frustração do driver — o problema não é o truck quebrar, é não conseguir ajuda rápida da Billor para resolver. Indicador oficial da frente: trucks de clientes parados > 2 dias em shop — de 60 unidades caiu para 40; meta: zerar, com ação definida para cada ativo (plano por caminhão). O teto de 4 dias segue como limite duro da compensação; o alerta e a atuação começam em 2 dias.

Desenho do processo (v1)

1. Gatilho: truck com contrato ativo entra em shop (road assistance, corretiva, resgate) → abre automaticamente card na esteira "Active Contract in Shop" no Nexus com cronômetro visível: alerta em D+2, teto em D+4.
2. Owner nominal: Senna. Time de Suporte Manutenção faz o follow-up operacional (tem densidade de gente; treinar onde faltar qualificação — encaminhamento já validado).
3. Rotina diária por truck em shop: contato com a oficina (estimate? peça? previsão?), atualização de status no Nexus, comunicação proativa ao driver (ele nunca fica sem resposta).
4. Escalonamento: D+2 sem previsão → Senna aciona oficina alternativa/dealer; D+3 → alerta Douglas (pressão presencial/logística); D+4 estourado → red flag no report diário do trio + avaliar truck reserve para o driver.
5. Alçadas: N1 autoriza até US$ 3.5k (FleetNet); acima disso segue Estimate Approval (Red Flag ≥ US$ 5k).
6. Indicador de frota em manutenção (Cauê + Ediane): visão oficial de cada truck em manutenção — há quanto tempo, em qual shop e por qual problema — alimentando o report diário e a priorização.

Virada FleetNet — driver aciona direto, nós monitoramos

A mudança estrutural desta frente: o driver passa a contatar a FleetNet diretamente, e nós mantemos visibilidade total via API de eventos. Efeito em cadeia:

1. Alivia a demanda do Suporte à Manutenção — o N1 deixa de ser gargalo de abertura/despacho de chamados;
2. Suporte assume papel proativo — o tempo liberado vai para pressão e acompanhamento das oficinas: boa execução dos serviços, custo justo e retorno do truck ≤ 4 dias para a atividade;
3. Cronômetro automático — eventos FleetNet integrados à esteira "Active Contract in Shop" fazem o aging contar sozinho, sem depender de digitação;
4. Canais do driver: ligação direta para a FleetNet + acionamento pelo Billor APP (implementação a validar com Caio e Eduardo, time mobile).

Sequência prazo → preço: esta semana o contato ativo do time do Senna com as oficinas mira a execução no prazo esperado (retorno ≤ 4 dias); na semana 2, com o histórico coletado (tempos, estimates, requebras), o time passa a brigar por preço competitivo.

Call segunda 20/07 (já agendada) — pautas: (a) acionamento direto pelo driver com nosso monitoramento via API de eventos (documentação da API de eventos já em mãos); (b) subir limite fintech para US$ 5–10k para evitar aditivos; (c) levar nossos acordos comerciais 30/60/90 para eles operarem.

Agenda da semana

Definition of done

• Senna formalizado e comunicado (área + oficinas sabem quem cobra).
• 100% dos trucks de contrato ativo em shop na esteira com cronômetro e última atualização ≤ 24h.
• Zero caso estourando 4 dias sem escalonamento registrado.
• 100% dos trucks parados > 2 dias com ação definida por ativo (o quê, quem, próxima data) — estoque atual de 40 caindo rumo a zero.
• Driver recebe atualização diária (mesmo que "sem novidade, previsão X").
• Integração FleetNet implantada até o fim da semana, com drivers acionando diretamente (ligação + Billor APP).
• Time do Senna operando o contato ativo com oficinas com alvo em prazo (semana 2: histórico vira insumo para negociar preço).
• Lista de trucks de cliente em shop com ETA disponibilizada para CX/retenção — a atuação sobre o truck é desta frente; a retenção do driver (Frente 9) consome o ETA.

Riscos

• Senna sobrecarregado (acumula road assistance) → suporte operacional distribuído no time de Suporte Manutenção, Senna gerencia.
• FleetNet demorar no acordo → rotina manual de follow-up não depende do acordo; API entra quando disponível.

Frente 3 — Qualidade: teste de chegada + stress test de saída

Dono: Douglas (presencial no DC a partir de terça), com Emerson (post-sale/QA) e mecânicos/inspetores Por quê: trucks estão saindo de manutenção e quebrando na saída ou no momento da entrega — sinal de inspeção mal feita. O processo precisa de dois testes (na chegada e no retorno), com tempo adequado, qualidade, processo claro e gente qualificada. Casos-símbolo: truck #1327 (estado interno inaceitável, itens sem funcionar) e driver deslocado JAX→STL para receber truck em péssimo estado.

Os dois portões

Portão A — Inspeção de CHEGADA (antes de ir para manutenção)

• Todo truck que chega (churn, resgate, retorno de shop externo) passa por inspeção de entrada no dia da chegada: diagnóstico completo documentado (foto/checklist via tablet — modelo locadora, alinhado na reunião DC 14/07).
• Resultado alimenta a estimativa/escopo → evita "novos problemas descobertos após a 1ª leva de reparos" (caso 1427) e acelera o estimate.

Portão B — Stress test + QA de SAÍDA, direto dentro da shop

• Atuação em duas pontas: (1) inspeção/diagnóstico de entrada que não deixa escapar itens de reparo — grande parte da demora atual vem de descobertas tardias que não estavam no diagnóstico inicial; (2) QA/stress test robusto e intenso executado direto dentro da shop, antes da retirada — mesmo que demore mais — para evitar o deslocamento ao DC e o retorno com problemas (iguais ou novos).
• Pós-conserto: stress test — pressão no sistema, esforço de peso, road test + inspeção completa (mecânica, elétrica, ar, luzes) + estado interno/limpeza (o caso #1327 reprovaria no cheiro/visual).
• Objetivo do portão: zero retorno com problema — nem na saída do DC, nem nos primeiros 30 dias de uso pelo driver.
• Tempo de verdade no SLA: se levar 1 dia inteiro, leva — entra no SLA e no calendário da Frente 1.
• QA reprovou → truck NÃO entra na agenda de entrega; reentra como TOP PRIORITY na Churn Entry (regra REV01) e o driver recebe outra unidade.
• Quem assina: inspetor de qualidade ≠ mecânico que executou (double check, definido na estrutura do DC 14/07).

Modelo de inspeção e diagnóstico

1. Inspeção e diagnóstico (modelo já praticado hoje — o reforço é no rigor): inspeção ampla (~50 itens) gera flags → diagnóstico aprofunda cada flag e abre a ordem de serviço. Inspeção não é diagnóstico — a primeira é rápida e abrangente, o segundo é profundo e direcionado; nada pode escapar entre uma e outro.
2. Responsabilização do inspetor: adesivo de inspeção no truck com dados e assinatura de quem atestou as condições (ex.: pneus) — accountability rastreável em caso de falha ou acidente.
3. Forms padronizados: validar e consolidar os formulários existentes (Delivery Inspection, Journey 2026 V2 — com fluxo, fotos, documentos, selos IFTA e assinaturas) como padrão corporativo em todas as localidades, integrados ao aplicativo em desenvolvimento.
4. Piloto de inspeção avançada fora do DC: inspecionar antes de movimentar reduz um volume estimado de 20–40% das movimentações; testar e ajustar as perguntas dos formulários direto no celular.
5. Inspetor residente na ponta + perfil de recrutamento (incluindo ex-drivers), treinamento interno e política de auditoria/feedback.
6. Métrica de rework: hoje ~90% dos retornos são problemas novos e ~10% recorrência do item consertado — sinal de falha de inspeção/diagnóstico; vira indicador de desempenho por inspetor.
7. Testador de trailer de 7 vias (~US$ 2 mil, testa 100% incl. pressurização): encontrar e adquirir com urgência, 1 por DC, para teste diário de trailers no daily care sem depender de acoplar um truck — especificação validada junto com o time de manutenção; Ana pesquisa/compra com prioridade adiantada.

Processo ideal do DC (Emerson)

• Emerson desenha o processo ideal do DC (sem se limitar pelo quadro atual de pessoas), em duas linhas numeradas por etapa: driver e truck.
• Processos prioritários do desenho: recondicionamento de ativo, retorno de third party e verificação diária de qualidade — os três com inspetor residente na ponta.

Passo a passo

Registro no Nexus

• Checklist de chegada e de saída anexados ao card do truck; estágio "Final Inspection/QA" obrigatório antes de "Available".
• Campo de reprovação com motivo → alimenta métrica de causas (insumo para PM/PTI da semana 2 e para a medição de quebras em 30 dias).

Definition of done

• 100% das entregas da semana com QA de saída registrado.
• 100% das chegadas com inspeção de entrada no dia.
• Zero truck entregue quebrado na saída/entrega na semana.
• SLA do teste final dimensionado com dado real e incorporado ao calendário.
• Forms de inspeção validados/consolidados como padrão e adesivo de responsabilização em uso nos primeiros trucks.
• Processo ideal do DC entregue pelo Emerson (linhas driver/truck) com os três processos prioritários detalhados.
• Testador de 7 vias pesquisado/encomendado (1 por DC).

Riscos

• Stress test vira gargalo → por isso o teto de 4 entregas/dia (Frente 6) protege a capacidade; medir tempo real antes de rampar.
• Inspetor "carimbar" sem testar → Douglas presente fisicamente na primeira semana; reprovação pós-entrega vira investigação de quem assinou.

Frente 4 — Presença Billor dentro das oficinas + cadência 2x/dia

Dono: Douglas (embed BR Diesel/TUI), com Kadu (cadência/checkpoints) e Emerson Por quê: muitos trucks saem da oficina sem inspeção e chegam ao pátio já com problemas. É preciso ter gente da Billor, com conhecimento de mecânica e processos, dentro das oficinas para garantir a qualidade e a agilidade das manutenções — e reduzir requebras.

Ações

1. Douglas embedded em BR Diesel e TUI (a partir de terça): acompanhar execução, implantar testes/validações/padrões no fornecedor, pressionar prazos truck a truck ("fico dentro da BR e TUI para garantir que estamos executando os serviços para quebrar menos os caminhões").
2. Checkpoints 2x/dia com cada oficina (agora travados em agenda fixa): - Fim da manhã: como foi a manhã + programação da tarde; - Fim do dia: como foi o dia + programação da manhã seguinte; - Responsável pela rotina: Kadu (com Senna/Savoy no acompanhamento de shops externos); - Saída de cada checkpoint: lista de liberação com data/hora por truck, atualizada no Nexus → alimenta o calendário (Frente 1).
3. Gestor local de manutenção / inspetor por oficina (estrutura discutida em 14/07 no desenho do DC): definir na semana quem faz esse papel de forma permanente quando Douglas sair de cena — candidato interno ou contratação; Douglas indica após os primeiros dias in loco.
4. Nenhum truck sai de oficina sem inspeção de retirada — mini-checklist de saída do shop aplicado por quem retira (antes do Portão B no yard, Frente 3). Reprovou no shop → volta na hora, não ocupa transporte/slot do yard.
5. Feedback estruturado aos fornecedores: requebras e reprovações por oficina viram pauta do checkpoint; acordos de prazo por nível L1–L5.
6. Relatório por oficina: métricas de rework/retrabalho, prazos (previsto × realizado × cumprimento), quantos trucks da conta simultaneamente e tempo médio de permanência — apresentado ao dono de cada oficina. Cobrança no escritório: Arcson → Ana Plassmann.
7. Capacidade mapeada: levantar quantos trucks a BR Diesel atende simultaneamente e calcular tempos médios por dados de entrada/saída — base para acordo de carga e calendário com cada oficina.
8. Expansão da rede: Ana Plassmann e Zé acionados para apresentar novos parceiros de oficina nas regiões dos DCs e balancear a carga entre fornecedores.

Agenda da semana

Definition of done

• Agendas 2x/dia acontecendo com registro (mesmo que 10 min).
• Previsão de liberação por truck com desvio conhecido (previsto × realizado).
• Zero truck retirado de oficina sem checklist de retirada.
• Diagnóstico de gargalo por oficina documentado (insumo para a Frente 5 e para decisão de dealers).

Riscos

• Oficina tratar checkpoint como formalidade → Douglas presente na primeira semana muda o tom; requebras viram dado na mesa.
• Dependência do Douglas → papel permanente definido até o fim da semana 1.

Frente 5 — Priorização da fila de shop + despressurização

Donos: Arcson (regra/sistema) + Douglas (execução física) + Kadu (fila/recon) Por quê: as oficinas estão priorizando trucks pesados/caros que ocupam slots por semanas, enquanto os simples (giro rápido) esperam; e o recover operacional está misturado com o recover para vendas — entregamos 10, mas só 4 servem para sales. A fila precisa de regra única de priorização e de válvulas de escape.

Regra de priorização (v1 — aplicar já na fila atual)

Ordem de prioridade dentro de cada oficina/slot: 1. Truck com contrato ativo em shop (Frente 2 — cronômetro de 4 dias correndo, compensação $$); 2. Truck com cliente/venda vinculada aguardando manutenção (compromisso do Arcson na divisão do Douglas: reduzir esse estoque durante a semana); 3. Simples primeiro em paralelo aos pesados: slots reservados para L1/L2 (≤ 4 dias) — giro rápido alimenta as 4 entregas/dia; L4/L5 não podem monopolizar a capacidade; 4. Reprovados no QA reentram TOP PRIORITY (regra REV01).

Marcação obrigatória no Nexus: finalidade do recover (Sales × Operacional × Reserve) — para a conta de "entregues para sales" fechar com a meta.

Despressurização — dealers e shops alternativos

• Proposta já colocada ao grupo (Arcson 18/07): usar dealers para a fila que está esperando slot em TUI/BR Diesel. Custo/hora maior, mas HH efetivamente trabalhada ≈ equivalente (time interno $40/h com muito tempo empenhado — visto in loco pelo Douglas), com garantia de entrega e qualidade.
• Passos: (seg) levantar 2–3 dealers/shops com capacidade imediata + tabela de preço; (ter) enviar lote piloto de 3–5 trucks L1–L3 da fila parada; (qui) comparar custo total e lead time reais × parceiros atuais → decidir escala.
• Critério de envio: truck parado aguardando slot > 2 dias E nível ≤ L3 E (contrato ativo OU cliente vinculado).

Peças e matriz de execução

• Controle de estoque de peças: JAX opera sem estoque (compras ad hoc, que engasgam o reparo); STL tem container de peças. Mapear o estoque, definir responsável, ferramenta e prazo de implantação do controle — replicando o modelo de STL em JAX.
• Matriz de decisão local × parceiro × dealer: para cada tipo de serviço, definir onde executar considerando custo, SLA e qualidade; o que estiver engasgado nos partners move para dealer (especialmente em JAX), mesmo com custo maior, para desobstruir o fluxo.

Classificação da fila (pré-requisito)

• Aplicar a classificação pedida pelo José Moreira (09/07) em todos os trucks em shop: PM / PTI / corretiva simples / média / pesada + nível L1–L5 → prazo estimado com margem. Sai da varredura da Frente 1 (segunda).

Agenda da semana

Definition of done

• Fila de cada oficina ordenada pela regra e visível no Nexus.
• Liberações diárias incluem L1/L2 (não só pesados).
• Contagem "entregues para sales" separada de "recover operacional" no report diário.
• Decisão fundamentada sobre dealers (escala, mantém piloto ou descarta) com números.

Riscos

• Regra bonita no papel, fila física não muda → é exatamente o que a presença do Douglas + checkpoints 2x/dia resolvem.
• Dealer piloto capturar os fáceis e inflar custo → limitar ao critério de envio e comparar custo total por truck equivalente.

Frente 6 — Fluxo de entregas ≤ 4/dia com qualidade

Dono: Douglas (com Carol/Adri na agenda e time de vendas no discurso) Por quê: as entregas novas foram reduzidas para 4/dia porque o volume atual estava gerando problemas — trucks entregues com defeito e agendas não cumpridas. O teto protege a capacidade real de entregar com qualidade (stress test da Frente 3) enquanto os problemas são atacados e resolvidos; regularizado o quadro, o volume de entregas sobe novamente (Frente 14). Com a agenda cheia, a venda é empurrada para a semana seguinte — perder lead custa menos que perder driver por truck quebrado.

Estado de partida

• Douglas já reuniu Carol e Adri (18/07): 25 drivers agendados (incluindo os em hotel) — redistribuição para máx. 4/dia em andamento; time alinhado.
• MKT: verba BFD reduzida (~US$ 500/dia por ~30 dias), direcionada a BFTO (Frente 8 absorve a demanda comercial).

Regras da semana

1. Teto: 4 entregas/dia somando JAX+STL; agenda cheia → empurra para a semana seguinte; sem exceção sem aval do trio.
2. Só entra na agenda truck com QA de saída aprovado (Frente 3). Agenda é puxada pelo calendário da Frente 1, não pelo desejo comercial.
3. Escassez a favor: vendas seleciona apenas drivers experientes nesta fase (menor risco de churn precoce e de mau uso).
4. Drivers em hotel primeiro na redistribuição (custo diário + experiência do driver).
5. Comunicação proativa com os reagendados: motivo (garantia de qualidade), nova data firme, e compensação/hotel quando aplicável — evitar novos casos "Everton" (driver irritado sem resposta).
6. Buffer: manter 1–2 trucks QA-aprovados de reserva por dia para no-show/reprovação de última hora.

Agenda da semana

Definition of done

• Nenhum dia com >4 entregas; nenhuma entrega sem QA registrado.
• 25 agendados redistribuídos e comunicados.
• Zero quebra na saída/entrega na semana.
• Insumo para semana 2: dado real de capacidade (tempo de stress test, taxa de reprovação) para a decisão de rampada do teto (Frente 14).

Riscos

• Pressão comercial para furar o teto → o teto é regra desta fase; desvios só com validação no report diário.
• Perda de leads → aceita nesta fase; BFTO (Robert) compensa a receita não dependente da esteira.
• Driver reagendado escalando conflito → script de comunicação + hotel/compensação padronizados com Carol/Adri.

Frente 7 — Churn: entrada controlada + avaliação prévia + esteira no Nexus

Donos: Douglas (chegadas/avaliação em JAX) + João (fluxo de churn/CX) + Arcson (mapeamento no Nexus) + Robert (redução do churn — Frente 9) Por quê: o volume de churn entrando precisa caber na capacidade de reposição (< 4/dia); o time de CX está sobrecarregado, operando no modo reativo e com as preventivas em queda; e a lista do que volta de churn (devolvido pelo driver ou resgatado pelo time do Corso) precisa estar mapeada na ferramenta para não gerar atrasos nem trucks órfãos.

Três pontas do problema

A) Entrada física em JAX (Douglas)

• Toda chegada de churn (devolução do driver ou resgate do Corso) passa pela inspeção de entrada no dia (Portão A, Frente 3) → diagnóstico + classificação L1–L5 + finalidade (sales/operacional/reserve) na entrada, não semanas depois.
• Chegadas escalonadas para não afogar o yard (coordenar com o calendário de resgates do Corso).
• João já enviou a lista de churn no grupo Net (18/07) → usar para prever o que entra de estoque e priorizar.

B) Esteira no Nexus (Arcson)

• Douglas indicou que já existe workflow disso → validar com João na segunda e ligar as pontas: churn CX/resgate → Churn Entry (recon) já existe no master workflow; o que falta é a lista viva de "a caminho" (driver return agendado + resgates do Corso) dentro do Nexus com previsão de chegada.
• Cada unidade da lista com: origem (devolução × resgate), local atual, previsão de chegada, responsável pelo transporte → zero truck "sumido" entre o churn e a Churn Entry.

C) Volume e preventivas (João + Robert)

• Meta: churn de entrada < 4/dia; churn semanal < 20 (meta do Robert na divisão do Douglas).
• Papo do trio com o João (segunda): entender a sobrecarga, tirar o modo "quem grita mais alto" e voltar régua nas preventivas (ligações ativas de CX, hoje em ~30% do combinado).
• Ações de retenção com prazo de resposta rápido (Robert).

Agenda da semana

Definition of done

• 100% das chegadas de churn com inspeção de entrada no dia e card no Nexus.
• Lista "a caminho" (devoluções + resgates) viva no Nexus, sem unidades órfãs.
• Churn semanal medido e reportado (meta <20/w); preventivas de CX voltando a subir.

Riscos

• João sem banda → o papel do trio é destravar/priorizar com ele, não adicionar cobrança; sinalizar no report diário se precisar de gente.
• Resgates do Corso chegando em lote → coordenação de calendário na Frente 4/checkpoints.

Frente 8 — Comercial: virar o time para o BFTO

Dono: Robert (com apoio do Douglas no MKT e na transição do time de vendas) Por quê: enquanto a esteira de manutenção se recupera, a empresa não pode depender de entregas de trucks para gerar receita. O BFTO é o produto que não depende da esteira de entregas — é para onde o time comercial vira nesta fase, com apoio do Douglas na campanha e na transição.

Ações

1. Robert assume a operacionalização do BFTO com acompanhamento diário das atividades: contrato, placa do caminhão (nossa ou do driver), adesivos, liberação de trailer, tipo de truck e ajustes no CRM. Douglas transfere a cobrança diária do BFTO para o Robert e libera agenda para as oficinas.
2. Virar o time comercial para o BFTO — kickoff na segunda cedo (alinhamento Robert + definição de atividades) com metas claras da semana (pipeline, conversões); discurso e materiais ajustados ao novo produto.
3. Apoio do Douglas — verba de MKT: reduzir a campanha BFD para ~US$ 500/dia (~30 dias) e direcionar o budget para BFTO (já iniciado por Douglas em 18/07).
4. BFD remanescente com escassez: os poucos slots de entrega (teto 4/dia — Frente 6) vendidos com conceito de escassez, só drivers experientes — sem gerar fila nova que a esteira não suporta.
5. Rampagem monitorada: pipeline BFTO reportado no ponto de controle diário do trio; se o produto não rampar na velocidade necessária, ajustar oferta/canal ainda na semana 1 e reportar cedo no status diário.

Agenda da semana

Definition of done

• Robert operando a rotina diária do BFTO (contrato, placa, adesivos, liberação de trailer, tipo de truck, CRM).
• Time comercial operando BFTO com metas e pipeline visível.
• Campanha MKT redirecionada e no ar.
• Vendas BFD limitadas aos slots do teto de 4/dia, com drivers experientes.
• Leitura clara ao fim da semana: BFTO sustenta a receita do período de recuperação ou precisa de ajuste?

Riscos

• BFTO não rampar rápido o suficiente → melhor descobrir na semana 1; ajustar oferta/canal e sinalizar cedo no report.
• Time comercial resistir à virada (pipeline BFD parado) → a virada é regra desta fase; escassez do BFD vira argumento de venda, não frustração.

Frente 9 — Retenção: segurar o churn junto com o João (CX)

Dono: Robert, colado no João (manager de CX) Por quê: cada driver que sai devolve um caminhão que entra na fila de recondicionamento — churn alto pressiona ainda mais a esteira de reparo que estamos tentando desafogar. Segurar retenção é proteger a própria recuperação da manutenção. Meta: churn < 20/semana, com rapidez na execução das ações de retenção; preventivas de CX (ligações ativas) de volta ao patamar combinado — hoje rodam em ~30%.

Ações

1. Meta explícita: churn < 20/semana, medido e reportado no ponto diário do trio.
2. Colar no João (CX): call na segunda para entender a sobrecarga, sair do modo reativo ("quem grita mais alto") e voltar a régua nas preventivas — ligações ativas para identificar problema antes de virar devolução.
3. Priorizar os drivers de maior risco: quem está com truck em shop. A esteira da Frente 2 (contrato ativo em shop) alimenta a lista — sem truck, sem receita e frustração alta é a receita do churn. Retenção proativa com previsão real de retorno do truck (nunca promessa vazia).
4. Rapidez: resposta a driver em risco em horas, não dias; playbook de retenção com alçadas claras (hotel, compensação, truck reserve quando disponível).
5. Elo com a Frente 7: driver retido = caminhão que NÃO entra na fila de recon; cada retenção bem-sucedida é medida também como alívio da esteira.
6. Política de comunicação com drivers (com João): firmeza e clareza no que está contratado — "é o que foi contratado e está acordado"; sem promessas não documentadas nem exceções manuais (ex.: pagamentos fora do fluxo). Tudo que for acordado entra no sistema, e para de circular loop interno com informações fora do escopo contratado.
7. Política para drivers problemáticos: retenção não é a qualquer custo — driver que gera risco ou custo recorrente não é retido; o ativo é priorizado para drivers confiáveis. Casos fora de política são encerrados com firmeza e registrados.

Agenda da semana

Definition of done

• Churn da semana < 20 (ou plano de correção se estourar).
• 100% dos drivers com truck em shop cobertos por ação proativa de retenção.
• Preventivas de CX de volta ao patamar combinado (saindo dos ~30%).
• Tempo de resposta a driver em risco medido em horas.

Riscos

• João sem banda → papel do Robert é destravar e priorizar com ele, não só cobrar; sinalizar no report diário se faltar gente.
• Retenção esbarrar no problema real (truck parado sem previsão) → por isso o elo com a Frente 2 é obrigatório: sem ETA do truck, retenção não se sustenta.

Frentes 10–14 (Semana 2) — PM/PTI, medição em tempo real, Nexus produção, STL e rampada

Período: 27/07–02/08 · Pré-requisito: semana 1 estabilizada (status 100%, QA rodando, fila ordenada, cadência com oficinas)

10. PM/PTI — reduzir as pancadas do recondicionamento (Arcson + Jonathann/Deivid)

Por quê: grande parte da fila de shop nasce de manutenção corretiva que a preventiva pegaria antes. Reduzir falhas de PTI/PM reduz as pancadas que o recondicionamento toma na sequência. - Ativar os novos fluxos desenhados pelo Jonathann (já transcritos e documentados): Novo PTI (Minor/Major/Emergência + block next load), Novo PM (thresholds 3.5k/1k/overdue + block), Fluxo de liberação (desbloqueio + contingência >10% da frota). - Follow-up automatizado do PTI via Motive (missing/invalid/defect) — mensageria já validada (API V2, 10/07); ligar no serviço interno de mensageria da Billor. - Fechar a régua do PM (divergência "milhagem <5k" × "-30k overdue até +3.5k") com Jonathann/Deivid. - Defect do PTI → abertura de serviço com caminho claro (road assistance × work order) — dúvida aberta de 11/07.

11. Medição em tempo real — eficiência, tempo e custo (Arcson)

Por quê: gestão em tempo real de eficiência, tempo e custos — enxergar o desvio no dia, não no fechamento da semana. - Painel no Nexus: aging por truck/etapa, SLA previsto × realizado por esteira, custo por reparo (estimates aprovados), throughput por oficina, quebras ≤30 dias pós-entrega com rota de volta (pedido de 07/07: de onde veio, que tipo de quebra). - Report diário automático no grupo (substituir prints manuais). - Indicadores de vida útil por peça (alternador, radiador, pneus etc.): estudo tempo de rodagem × trocas a partir da base de service do Fleetio, para saber quando trocar cada item — insumo da preventiva e da matriz local × parceiro × dealer. Prioridade menor: task para assim que a poeira baixar (pós-estabilização da semana 1). - Semente do "painel de controle central da empresa" — o Nexus é esse painel.

12. Nexus manutenção em produção + sync tempo real (Arcson + SRE/time API Fleetio)

• Sair da carga manual: Fleetio→Nexus automático (SRE + responsável API Fleetio, já acordado 15/07); na sequência, retorno Nexus→Fleetio.
• Nexus como fonte oficial de status (fim dos controles paralelos/prints); "Nexus para fornecedores" entra no desenho para oficina atualizar status direto.
• Caminho de descontinuação do Fleetio "sem quebrar pratinhos" mapeado (com avaliação da Fullby/TUI).

13. Replicar padrão JAX → STL (Douglas + John Mallas)

• STL tem os mesmos sintomas (caso do driver voado 19/07; "dificuldade de tirar trucks dos shops de Jax e STL").
• Levar: checklists de chegada/saída, cadência 2x/dia com oficinas locais, regra de priorização, esteira no Nexus.
• John Mallas como ponta local (já acionado) — a replicação começa já na semana 1 (o que funcionar em JAX é imediatamente testado em STL e vice-versa); a semana 2 consolida o padrão. Douglas orienta remoto/visita conforme necessidade.

14. Rampar entregas com segurança (Douglas + Arcson)

• Critérios para subir o teto de 4/dia: quebra pós-entrega ~0 na semana 1 · fila de shop caindo · tempo de stress test conhecido e absorvido no SLA · calendário batendo (previsto × realizado >80%).
• Proposta de novo teto baseada em dados no fim da semana 1, levada para validação no report diário; drivers reagendados/lista de espera absorvidos primeiro.

Definition of done (semana 2)

• PTI/PM novos rodando com follow-up automático; % PTI missing/invalid caindo.
• Painel de indicadores em tempo real no ar, report diário automático.
• Sync Fleetio→Nexus automático em produção.
• STL operando com o mesmo padrão de JAX.
• Decisão de rampada tomada com dados.

Action Plan — Short Term & High Impact (Weeks 1 and 2)

Goal: reverse, in the shortest possible time, the backlog of trucks stuck in shops — both the new-sales pipeline and active drivers' trucks — with delivery quality that eliminates "breaks around the corner". Period: Week 1 = Jul 20–26 · Week 2 = Jul 27–Aug 02. Detailed plans: one document per workstream — see the index at the end.

Deployment of forces (starting Monday 07/20)

War cadence: trio's daily checkpoint Arcson+Douglas+Robert (morning) · daily progress report to the board in the group · 2x/day checkpoints with shops · out-of-process issues reported in the critical-plan Slack group.

Week 1 — Stop the bleeding and gain visibility (Jul 20–26)

Week 1 success criteria: we know where every truck is and when it comes out (reliable calendar); zero customer trucks parked > 2 days in a shop without a defined action (stock of 40 driven toward zero); zero delivered trucks failing at the gate; deliveries steady at 4/day that don't come back; churn held below 20.

Week 2 — Consolidate and accelerate (Jul 27–Aug 02)

Week 2 success criteria: end-to-end predictable pipeline in Nexus, real-time indicators for the board, STL aligned, and delivery capacity growing without sacrificing quality.

Detailed plans index

1. Status 100% + owners + realistic calendar
2. Active contract in shop + FleetNet shift
3. Quality: inspection, diagnosis and stress test
4. Shop presence + cadence
5. Queue prioritization + depressurization
6. Deliveries at 4/day until normalized
7. Churn: controlled intake + Nexus pipeline
8. Sales: BFTO
9. Retention with CX
10. Week 2: PM/PTI, measurement and production

Workstream 1 — 100% of trucks with status + owners + realistic calendar

Owner: Arcson · Critical deadline: Monday 07/20 EOD Why: with 100% of trucks carrying a status and every pipeline forecast, the calendar shows a realistic delivery forecast — and the company knows where it truly stands. Without that visibility there is no queue management and no objective shop accountability.

Starting point (what we already have)

• Nexus maintenance in dev: nexus.billor.dev/tms/maintenance, Fleetio→Nexus load validated — 172 trucks positioned, 0 unmapped (07/15).
• 13 standardized flows + master workflow documented, Fleetio→Nexus mapping, Pipelines-Stages spreadsheet validated 07/14.
• Pipeline owners defined: Recon=Kadu · Rescue/Swaps/Reserve/Load Rescue=Corso · PM/PTI/DOT=Jonathann/Deivid · Road assistance=Senna · Post-sale=Emerson · Predictive=Luke.

Gaps to close on Monday

1. Fresh Fleetio→Nexus reload (the 07/15 data is already stale; run a new manual load in the morning).
2. Trucks/trailers without status or with legacy status — sweep exceptions and position 100% (include trailers — José Moreira's directive, 07/11).
3. Unconfirmed owners: New truck/trailer (Ana/Corso [CONFIRM]) · Accidents (pending Guilherme's meeting) · Yard care (nominal owner) · in-house DC pipeline and rejected truck (minimum viable: create both pipelines with simple stages and a provisional owner).
4. Delivery calendar: for each truck in the sales pipeline, availability forecast = current stage + remaining SLAs (including the new stress-test SLA from Workstream 3). Publish a per-day view for Carol/Adri and the daily report.
5. Status of active-contract trucks in shop enters the same sweep (feeds Workstream 2).

Step by step (Monday 07/20)

Definition of done

• 0 trucks/trailers without pipeline+stage+owner in Nexus.
• Calendar v1 with a delivery forecast per truck (with L1–L5 level margin) published.
• List of unresolved exceptions with the name of who unblocks each one and a deadline.

Risks

• Stale Fleetio data at the source → mitigate with owner validation per pipeline (whoever knows the truck fixes it on the spot).
• Trailers historically out of control → accept a less precise v1, tag [CONFIRM] and close during the week.

Workstream 2 — Owner for active-contract trucks in shop (≤ 4 days) + FleetNet

Plan owner: Arcson · Process owner (proposed): Senna (Maintenance Support / Road Assistance), with Emerson Why: active-contract trucks entering a shop have no owner today: nobody organizes the queue with the shops or guarantees the 4-day downtime limit (the compensation ceiling). Beyond the cost, it's the driver's biggest frustration — the problem isn't the truck breaking, it's not getting fast help from Billor to solve it. Official metric for this workstream: customer trucks parked > 2 days in a shop — down from 60 units to 40; target: zero, with a defined action per asset (plan per truck). The 4-day ceiling remains the hard compensation limit; alerting and action start at 2 days.

Process design (v1)

1. Trigger: an active-contract truck enters a shop (road assistance, corrective, rescue) → a card opens automatically in the "Active Contract in Shop" pipeline in Nexus with a visible countdown: alert at D+2, ceiling at D+4.
2. Nominal owner: Senna. The Maintenance Support team runs the operational follow-up (there's enough staff density; train where qualification is missing — direction already validated).
3. Daily routine per truck in shop: contact the shop (estimate? part? ETA?), update status in Nexus, proactive communication to the driver (he is never left without an answer).
4. Escalation: D+2 with no ETA → Senna engages an alternative shop/dealer; D+3 → alert Douglas (on-site/logistics pressure); D+4 breached → red flag in the trio's daily report + evaluate a reserve truck for the driver.
5. Approval limits: N1 authorizes up to US$ 3.5k (FleetNet); above that follows Estimate Approval (Red Flag ≥ US$ 5k).
6. Fleet-in-maintenance indicator (Cauê + Ediane): official view of every truck in maintenance — for how long, at which shop and for which problem — feeding the daily report and prioritization.

FleetNet shift — driver dispatches directly, we monitor

The structural change in this workstream: the driver starts contacting FleetNet directly, while we keep full visibility through the events API. Chain effect:

1. Relieves the Maintenance Support workload — N1 stops being the bottleneck for opening/dispatching tickets;
2. Support becomes proactive — the freed-up time goes into pressing and following the shops: good service execution, fair cost and truck back to activity in ≤ 4 days;
3. Automatic countdown — FleetNet events integrated into the "Active Contract in Shop" pipeline make aging count by itself, with no manual typing;
4. Driver channels: direct call to FleetNet + dispatch through the Billor APP (implementation to validate with Caio and Eduardo, mobile team).

Deadline → price sequence: this week, Senna's team's active contact with the shops targets on-time execution (truck back in ≤ 4 days); in week 2, with the collected history (times, estimates, re-breaks), the team starts fighting for competitive pricing.

Call Monday 07/20 (already scheduled) — agenda: (a) direct driver dispatch with our monitoring via events API (events API documentation already in hand); (b) raise the fintech limit to US$ 5–10k to avoid addendums; (c) transfer our commercial agreements (30/60/90 billing) for them to operate.

Week agenda

Definition of done

• Senna formalized and announced (the area and the shops know who follows up).
• 100% of active-contract trucks in shop on the pipeline with countdown and last update ≤ 24h.
• Zero cases past 4 days without a registered escalation.
• 100% of trucks parked > 2 days with a defined action per asset (what, who, next date) — current stock of 40 driven toward zero.
• Driver gets a daily update (even if "no news, ETA is X").
• FleetNet integration live by end of week, with drivers dispatching directly (call + Billor APP).
• Senna's team running active shop contact targeting deadlines (week 2: history becomes the input to negotiate price).
• List of customer trucks in shop with ETA made available to CX/retention — acting on the truck belongs to this workstream; driver retention (Workstream 9) consumes the ETA.

Risks

• Senna overloaded (he also runs road assistance) → operational load distributed across the Maintenance Support team; Senna manages.
• FleetNet slow on the agreement → the manual follow-up routine doesn't depend on the deal; the API comes in when available.

Workstream 3 — Quality: arrival test + outbound stress test

Owner: Douglas (on-site at the DC from Tuesday), with Emerson (post-sale/QA) and mechanics/inspectors Why: trucks are leaving maintenance and breaking at the gate or at delivery — a sign of poor inspection. The process needs two tests (on arrival and on return), with adequate time, quality, a clear process and qualified people. Symbol cases: truck #1327 (unacceptable interior condition, items not working) and a driver moved JAX→STL to receive a truck in terrible condition.

The two gates

Gate A — ARRIVAL inspection (before going to maintenance)

• Every truck that arrives (churn, rescue, return from an external shop) goes through an inbound inspection on the day of arrival: full documented diagnosis (photos/checklist via tablet — rental-company model, aligned in the DC meeting 07/14).
• The result feeds the estimate/scope → avoids "new problems discovered after the first round of repairs" (case 1427) and speeds up the estimate.

Gate B — Stress test + outbound QA, directly inside the shop

• Acting on both ends: (1) inbound inspection/diagnosis that doesn't let repair items slip — much of today's delay comes from late discoveries that weren't in the initial diagnosis; (2) a robust, intense QA/stress test executed directly inside the shop, before pickup — even if it takes longer — avoiding the trip to the DC and the return with problems (same or new).
• Post-repair: stress test — system pressure, weight load, road test + full inspection (mechanical, electrical, A/C, lights) + interior condition/cleanliness (case #1327 would fail on smell/visual alone).
• The gate's goal: zero returns with problems — neither at the DC gate nor in the driver's first 30 days of use.
• Real time in the SLA: if it takes a full day, it takes a full day — it goes into the SLA and into the Workstream 1 calendar.
• QA failed → the truck does NOT enter the delivery schedule; it re-enters as TOP PRIORITY at Churn Entry (REV01 rule) and the driver gets another unit.
• Who signs off: quality inspector ≠ the mechanic who did the work (double check, defined in the DC structure 07/14).

Inspection and diagnosis model

1. Inspection and diagnosis (the model already practiced today — the reinforcement is in rigor): broad inspection (~50 items) raises flags → diagnosis goes deep on each flag and opens the work order. Inspection is not diagnosis — the first is fast and wide, the second is deep and targeted; nothing can slip between the two.
2. Inspector accountability: inspection decal on the truck with the data and signature of whoever attested the conditions (e.g., tires) — traceable accountability in case of failure or accident.
3. Standardized forms: validate and consolidate the existing forms (Delivery Inspection, Journey 2026 V2 — with flow, photos, documents, IFTA stickers and signatures) as the corporate standard across all locations, integrated into the app under development.
4. Advanced inspection pilot outside the DC: inspecting before moving cuts an estimated 20–40% of movements; test and adjust the form questions directly on the phone.
5. Resident inspector at the edge + recruiting profile (including former drivers), internal training and an audit/feedback policy.
6. Rework metric: today ~90% of returns are new problems and ~10% recurrence of the repaired item — a sign of inspection/diagnosis failure; becomes a per-inspector performance indicator.
7. 7-way trailer tester (~US$ 2k, tests 100% incl. pressurization): find and acquire urgently, 1 per DC, for daily trailer testing in daily care without coupling a truck — specification validated with the maintenance team; Ana researches/buys with expedited priority.

Ideal DC process (Emerson)

• Emerson designs the ideal DC process (not constrained by current headcount), in two step-numbered lines: driver and truck.
• Priority processes in the design: asset reconditioning, third-party return and daily quality check — all three with a resident inspector at the edge.

Step by step

Recording in Nexus

• Arrival and outbound checklists attached to the truck's card; "Final Inspection/QA" stage mandatory before "Available".
• Rejection field with reason → feeds the causes metric (input for week 2's PM/PTI and for 30-day breakdown tracking).

Definition of done

• 100% of the week's deliveries with outbound QA registered.
• 100% of arrivals inspected on the same day.
• Zero trucks delivered broken at the gate/delivery during the week.
• Final-test SLA sized with real data and incorporated into the calendar.
• Inspection forms validated/consolidated as the standard and the accountability decal in use on the first trucks.
• Ideal DC process delivered by Emerson (driver/truck lines) with the three priority processes detailed.
• 7-way tester researched/ordered (1 per DC).

Risks

• Stress test becomes a bottleneck → that's what the 4/day delivery cap (Workstream 6) protects; measure real time before ramping.
• Inspector "rubber-stamping" without testing → Douglas physically present the first week; post-delivery failure triggers an investigation of who signed off.

Workstream 4 — Billor presence inside the shops + 2x/day cadence

Owner: Douglas (embedded at BR Diesel/TUI), with Kadu (cadence/checkpoints) and Emerson Why: many trucks leave the shop without inspection and arrive at the yard already showing problems. Billor people with mechanical and process knowledge must be inside the shops to guarantee repair quality and speed — and reduce re-breaks.

Actions

1. Douglas embedded at BR Diesel and TUI (from Tuesday): follow execution, implement tests/validations/standards at the vendor, push deadlines truck by truck ("I'll stay inside BR and TUI to make sure the services we execute make the trucks break less").
2. Checkpoints 2x/day with each shop (now locked as fixed agendas): - End of morning: how the morning went + afternoon schedule; - End of day: how the day went + next morning's schedule; - Routine owner: Kadu (with Senna/Savoy following external shops); - Output of every checkpoint: release list with date/time per truck, updated in Nexus → feeds the calendar (Workstream 1).
3. Local maintenance manager / inspector per shop (structure discussed 07/14 in the DC design): define during the week who takes this role permanently once Douglas steps out — internal candidate or hire; Douglas nominates after the first days on site.
4. No truck leaves a shop without a pickup inspection — a mini exit checklist applied by whoever picks it up (before Gate B at the yard, Workstream 3). Failed at the shop → goes back on the spot; doesn't consume transport or a yard slot.
5. Structured feedback to vendors: re-breaks and rejections per shop become checkpoint agenda items; deadline agreements per L1–L5 level.
6. Per-shop report: rework metrics, deadlines (forecast × actual × compliance), how many of our trucks simultaneously and average dwell time — presented to each shop's owner. Office follow-up: Arcson → Ana Plassmann.
7. Capacity mapped: measure how many trucks BR Diesel handles simultaneously and compute average times from in/out data — the basis for load and calendar agreements with each shop.
8. Network expansion: Ana Plassmann and Zé engaged to bring in new shop partners in the DC regions and balance the load across vendors.

Week agenda

Definition of done

• 2x/day agendas happening with a record (even if 10 minutes).
• Release forecast per truck with known deviation (forecast × actual).
• Zero trucks picked up from a shop without the pickup checklist.
• Bottleneck diagnosis per shop documented (input for Workstream 5 and the dealer decision).

Risks

• Shop treats the checkpoint as a formality → Douglas's presence in week 1 changes the tone; re-breaks become data on the table.
• Dependency on Douglas → permanent role defined by the end of week 1.

Workstream 5 — Shop queue prioritization + depressurization

Owners: Arcson (rule/system) + Douglas (physical execution) + Kadu (queue/recon) Why: shops are prioritizing heavy/expensive trucks that occupy slots for weeks while the simple, fast-turnover ones wait; and operational recover is mixed with sales recover — we deliver 10, but only 4 serve sales. The queue needs a single prioritization rule and relief valves.

Prioritization rule (v1 — apply to the current queue now)

Priority order within each shop/slot: 1. Active-contract truck in shop (Workstream 2 — 4-day countdown running, compensation $$); 2. Truck with a customer/sale attached waiting for maintenance (Arcson's commitment in Douglas's division: shrink this stock during the week); 3. Simple ones first, in parallel with the heavy ones: slots reserved for L1/L2 (≤ 4 days) — fast turnover feeds the 4 deliveries/day; L4/L5 cannot monopolize capacity; 4. QA rejects re-enter TOP PRIORITY (REV01 rule).

Mandatory tag in Nexus: recover purpose (Sales × Operational × Reserve) — so the "delivered for sales" count reconciles with the target.

Depressurization — dealers and alternative shops

• Proposal already on the table (Arcson 07/18): use dealers for the queue waiting for a slot at TUI/BR Diesel. Higher hourly cost, but effectively worked hours ≈ equivalent (internal team $40/h with lots of idle time — seen on site by Douglas), with delivery and quality guarantees.
• Steps: (Mon) shortlist 2–3 dealers/shops with immediate capacity + price table; (Tue) send a pilot batch of 3–5 L1–L3 trucks from the stalled queue; (Thu) compare real total cost and lead time × current partners → decide on scale.
• Sending criterion: truck waiting for a slot > 2 days AND level ≤ L3 AND (active contract OR customer attached).

Parts and execution matrix

• Parts inventory control: JAX runs with no stock (ad hoc purchases that stall repairs); STL has a parts container. Map the inventory, assign an owner, tool and implementation deadline — replicating the STL model in JAX.
• Local × partner × dealer decision matrix: for each service type, define where to execute based on cost, SLA and quality; whatever is stalled at partners moves to a dealer (especially in JAX), even at higher cost, to unclog the flow.

Queue classification (prerequisite)

• Apply the classification requested by José Moreira (07/09) to every truck in shop: PM / PTI / simple / medium / heavy corrective + L1–L5 level → estimated timeline with margin. Comes out of the Workstream 1 sweep (Monday).

Week agenda

Definition of done

• Each shop's queue ordered by the rule and visible in Nexus.
• Daily releases include L1/L2 (not just heavy ones).
• "Delivered for sales" counted separately from "operational recover" in the daily report.
• Data-driven decision on dealers (scale, keep piloting, or drop) with numbers.

Risks

• Nice rule on paper, physical queue doesn't change → that's exactly what Douglas's presence + 2x/day checkpoints solve.
• Dealer pilot cherry-picks the easy ones and inflates cost → restrict to the sending criterion and compare total cost per equivalent truck.

Workstream 6 — Delivery flow ≤ 4/day with quality

Owner: Douglas (with Carol/Adri on scheduling and the sales team on the narrative) Why: new deliveries were reduced to 4/day because the current volume was generating problems — trucks delivered with defects and schedules not being met. The cap protects the real capacity to deliver with quality (Workstream 3 stress test) while the problems are attacked and solved; once the picture normalizes, delivery volume ramps back up (Workstream 14). With a full schedule, sales push to the following week — losing a lead costs less than losing a driver to a broken truck.

Starting point

• Douglas already met Carol and Adri (07/18): 25 drivers scheduled (including those in hotels) — redistribution to max 4/day under way; team aligned.
• MKT: BFD budget reduced (~US$ 500/day for ~30 days), redirected to BFTO (Workstream 8 absorbs the commercial demand).

Rules for the week

1. Cap: 4 deliveries/day across JAX+STL; full schedule → pushes to the following week; no exception without the trio's sign-off.
2. Only trucks with approved outbound QA enter the schedule (Workstream 3). The schedule is pulled by the Workstream 1 calendar, not by commercial pressure.
3. Scarcity working for us: sales selects experienced drivers only in this phase (lower risk of early churn and misuse).
4. Drivers in hotels first in the redistribution (daily cost + driver experience).
5. Proactive communication with the rescheduled: reason (quality assurance), firm new date, and compensation/hotel where applicable — avoid new "Everton" cases (angry driver with no answer).
6. Buffer: keep 1–2 QA-approved backup trucks per day for no-shows/last-minute rejections.

Week agenda

Definition of done

• No day with >4 deliveries; no delivery without registered QA.
• The 25 scheduled drivers redistributed and informed.
• Zero breakdowns at the gate/delivery during the week.
• Input for week 2: real capacity data (stress-test time, rejection rate) for the cap ramp-up decision (Workstream 14).

Risks

• Commercial pressure to break the cap → the cap is the rule for this phase; deviations only with sign-off at the daily report.
• Lead loss → accepted for this phase; BFTO (Robert) offsets with revenue that doesn't depend on the pipeline.
• Rescheduled driver escalating conflict → communication script + standardized hotel/compensation with Carol/Adri.

Workstream 7 — Churn: controlled intake + upfront evaluation + Nexus pipeline

Owners: Douglas (arrivals/evaluation in JAX) + João (churn/CX flow) + Arcson (Nexus mapping) + Robert (churn reduction — Workstream 9) Why: incoming churn volume must fit the replacement capacity (< 4/day); the CX team is overloaded, running in reactive mode with preventives falling; and the list of what returns from churn (driver return or Corso-team rescue) must be mapped in the tool to avoid delays and orphan trucks.

The three ends of the problem

A) Physical intake in JAX (Douglas)

• Every churn arrival (driver return or Corso rescue) goes through the same-day inbound inspection (Gate A, Workstream 3) → diagnosis + L1–L5 classification + purpose (sales/operational/reserve) at intake, not weeks later.
• Arrivals staggered so the yard doesn't drown (coordinate with Corso's rescue calendar).
• João already sent the churn list in the Net group (07/18) → use it to forecast incoming stock and prioritize.

B) Nexus pipeline (Arcson)

• Douglas indicated a workflow for this already exists → validate with João on Monday and connect the ends: churn CX/rescue → Churn Entry (recon) already exists in the master workflow; what's missing is the live "in transit" list (scheduled driver returns + Corso rescues) inside Nexus with arrival forecast.
• Each unit on the list with: origin (return × rescue), current location, arrival forecast, transport owner → zero trucks "lost" between churn and Churn Entry.

C) Volume and preventives (João + Robert)

• Target: churn intake < 4/day; weekly churn < 20 (Robert's target in Douglas's division).
• The trio's talk with João (Monday): understand the overload, kill the "loudest scream" mode and bring back discipline on preventives (CX active calls, currently at ~30% of the agreed volume).
• Retention actions with fast response times (Robert).

Week agenda

Definition of done

• 100% of churn arrivals with same-day inbound inspection and a card in Nexus.
• "In transit" list (returns + rescues) live in Nexus, no orphan units.
• Weekly churn measured and reported (target <20/w); CX preventives climbing back up.

Risks

• João with no bandwidth → the trio's role is to unblock/prioritize with him, not add pressure; flag it in the daily report if people are needed.
• Corso rescues arriving in batches → calendar coordination in Workstream 4/checkpoints.

Workstream 8 — Sales: shift the team to BFTO

Owner: Robert (with Douglas supporting on MKT and the sales-team transition) Why: while the maintenance pipeline recovers, the company can't depend on truck deliveries for revenue. BFTO is the product that doesn't depend on the delivery pipeline — that's where the sales team turns in this phase, with Douglas supporting the campaign and the transition.

Actions

1. Robert takes over BFTO operationalization with daily follow-up of the activities: contract, truck plate (ours or the driver's), decals, trailer release, truck type and CRM adjustments. Douglas hands the daily BFTO follow-up to Robert and frees his agenda for the shops.
2. Shift the sales team to BFTO — early-Monday alignment with Robert (activity definition) and kickoff with clear weekly targets (pipeline, conversions); pitch and materials adjusted to the new product.
3. Douglas's support — MKT budget: cut the BFD campaign to ~US$ 500/day (~30 days) and redirect the budget to BFTO (already started by Douglas on 07/18).
4. Remaining BFD sold with scarcity: the few delivery slots (4/day cap — Workstream 6) sold on scarcity, experienced drivers only — without creating a new queue the pipeline can't support.
5. Monitored ramp-up: BFTO pipeline reported at the trio's daily checkpoint; if the product doesn't ramp fast enough, adjust offer/channel still in week 1 and report early in the daily status.

Week agenda

Definition of done

• Robert running the daily BFTO routine (contract, plate, decals, trailer release, truck type, CRM).
• Sales team operating BFTO with visible targets and pipeline.
• MKT campaign redirected and live.
• BFD sales limited to the 4/day-cap slots, experienced drivers only.
• Clear read by end of week: does BFTO sustain revenue through the recovery period, or does it need adjustment?

Risks

• BFTO not ramping fast enough → better to find out in week 1; adjust offer/channel and flag it early in the report.
• Sales team resisting the shift (BFD pipeline frozen) → the shift is the rule for this phase; BFD scarcity becomes a sales argument, not a frustration.

Workstream 9 — Retention: hold churn down with João (CX)

Owner: Robert, working side by side with João (CX manager) Why: every driver who leaves returns a truck straight into the reconditioning queue — high churn puts even more pressure on the repair pipeline we're trying to unclog. Holding retention protects the maintenance recovery itself. Target: churn < 20/week, with fast retention actions; CX preventives (active calls) back to the agreed level — currently at ~30%.

Actions

1. Explicit target: churn < 20/week, measured and reported at the trio's daily checkpoint.
2. Stick with João (CX): Monday call to understand the overload, exit reactive mode ("loudest scream") and restore discipline on the preventives — active calls to catch problems before they become returns.
3. Prioritize the highest-risk drivers: those with a truck in a shop. The Workstream 2 pipeline (active contract in shop) feeds the list — no truck, no income and high frustration is the recipe for churn. Proactive retention backed by a real truck-return ETA (never an empty promise).
4. Speed: response to an at-risk driver in hours, not days; retention playbook with clear approval limits (hotel, compensation, reserve truck when available).
5. Link with Workstream 7: a retained driver = a truck that does NOT enter the recon queue; every successful retention is also measured as pipeline relief.
6. Driver-communication policy (with João): firmness and clarity on what is contracted — "it is what was contracted and agreed"; no undocumented promises and no manual exceptions (e.g., payments outside the flow). Everything agreed goes into the system, and internal loops with out-of-scope information stop circulating.
7. Policy for problem drivers: retention is not at any cost — a driver who generates recurring risk or cost is not retained; assets are prioritized for reliable drivers. Out-of-policy cases are closed firmly and recorded.

Week agenda

Definition of done

• Week's churn < 20 (or a correction plan if it blows past).
• 100% of drivers with trucks in shop covered by proactive retention action.
• CX preventives back to the agreed level (up from ~30%).
• Response time to at-risk drivers measured in hours.

Risks

• João with no bandwidth → Robert's role is to unblock and prioritize with him, not just push; flag it in the daily report if people are missing.
• Retention hitting the real problem (truck stuck with no ETA) → that's why the link with Workstream 2 is mandatory: without a truck ETA, retention doesn't hold.

Workstreams 10–14 (Week 2) — PM/PTI, real-time measurement, Nexus production, STL and ramp-up

Period: Jul 27–Aug 02 · Prerequisite: week 1 stabilized (100% status, QA running, queue ordered, shop cadence in place)

10. PM/PTI — reduce the blows hitting reconditioning (Arcson + Jonathann/Deivid)

Why: a large share of the shop queue is born from corrective maintenance that preventive care would have caught earlier. Reducing PTI/PM failures reduces the blows reconditioning takes downstream. - Activate the new flows designed by Jonathann (already transcribed and documented): New PTI (Minor/Major/Emergency + block next load), New PM (3.5k/1k/overdue thresholds + block), Release flow (unblock + contingency >10% of the fleet). - Automated PTI follow-up via Motive (missing/invalid/defect) — messaging already validated (API V2, 07/10); plug into Billor's internal messaging service. - Close the PM selection rule (divergence "mileage <5k" × "-30k overdue to +3.5k upcoming") with Jonathann/Deivid. - PTI defect → service opening with a clear path (road assistance × direct work order) — open question since 07/11.

11. Real-time measurement — efficiency, time and cost (Arcson)

Why: real-time management of efficiency, time and cost — see the deviation same-day, not at week close. - Nexus panel: aging per truck/stage, forecast × actual SLA per pipeline, cost per repair (approved estimates), throughput per shop, breakdowns ≤30 days post-delivery with the route back (07/07 request: where it came from, what kind of failure). - Automatic daily report in the group (replacing manual screenshots). - Per-part useful-life indicators (alternator, radiator, tires etc.): a mileage × replacement study from the Fleetio service base, to know when to replace each item — input for preventive maintenance and the local × partner × dealer matrix. Lower priority: a task for once the dust settles (post week-1 stabilization). - Seed of the "company-wide central control panel" — Nexus is that panel.

12. Nexus maintenance in production + real-time sync (Arcson + SRE/Fleetio API team)

• Leave manual loads behind: automatic Fleetio→Nexus (SRE + Fleetio API owner, agreed 07/15); then the Nexus→Fleetio write-back.
• Nexus as the official source of status (end of parallel controls/screenshots); "Nexus for vendors" enters the design so shops update status directly.
• Fleetio decommissioning path mapped "without breaking dishes" (including the Fullby/TUI evaluation).

13. Replicate the JAX standard → STL (Douglas + John Mallas)

• STL shows the same symptoms (the driver flown on 07/19; "hard to get trucks out of the Jax and STL shops").
• Bring over: arrival/outbound checklists, 2x/day cadence with local shops, prioritization rule, Nexus pipeline.
• John Mallas as the local point person (already engaged) — replication starts in week 1 already (what works in JAX is immediately tested in STL and vice versa); week 2 consolidates the standard. Douglas guides remotely/visits as needed.

14. Ramp deliveries safely (Douglas + Arcson)

• Criteria to raise the 4/day cap: post-delivery breakage ~0 in week 1 · shop queue shrinking · stress-test time known and absorbed in the SLA · calendar accuracy (forecast × actual >80%).
• New cap proposal based on data at the end of week 1, taken for validation at the daily report; rescheduled drivers/waitlist absorbed first.

Definition of done (week 2)

• New PTI/PM running with automated follow-up; % of missing/invalid PTIs falling.
• Real-time indicator panel live, automatic daily report.
• Automatic Fleetio→Nexus sync in production.
• STL operating on the same standard as JAX.
• Ramp-up decision made with data.