Por que consolidar, e qual é o problema central
Há três semanas o time opera em modo de guerra sobre a esteira de manutenção. As iniciativas nasceram em momentos diferentes — kickoff, reuniões de processo, análises de dados, planos de ataque semanais — e ficaram espalhadas. Este plano junta tudo e fixa o alvo comum.
Arquitetura-alvo: uma base de controle central no Nexus
Hoje a operação vive em quatro controles paralelos — Zendesk, Fleetio, planilhas e telefone (CloudTalk). O alvo é uma estrutura de dados central no Nexus que unifica o status de cada ativo e vira a base sobre a qual tudo o mais é construído: interfaces por área, workflows e calendários.
As duas bases que centralizamos primeiro
| Base | Área que a alimenta | O que registra |
|---|---|---|
| Zendesk | Suporte Manutenção | Tickets de Road Side / Support / Breakdown — o acionamento do driver na estrada |
| Fleetio | Manutenção | Inspeções, work orders, status do ativo, red flag, service history e custo |
Decisão estratégica (12/07): o Zendesk será substituído pelo sistema de workflows — o intake passa a ser o próprio Nexus. O Fleetio futuramente também entra no Nexus (o gap de ingestão vira roadmap de produto, não integração externa).
Fechar o gap de registro (pré-requisito de dado)
Hoje a maior parte das quebras de estrada não chega ao sistema de manutenção: as WOs de estrada zeraram no Fleetio e o custo vive espalhado em EFS/cartão/fintech.
- Toda quebra (ticket Road Side ou chamada) gera Issue/WO no Fleetio com VMRS — automatizável via trigger Zendesk → Fleetio API.
- Sem isso não há custo por quebra, nem warranty recovery, nem loop de qualidade de volta ao DC.
- Padronizar o marco de entrega (transição de status) como fonte confiável.
Sequenciamento — curto prazo e fase 2
As quatro áreas são tratadas com a mesma profundidade neste plano, mas a construção é sequenciada. Primeiro a base e as duas interfaces de maior dor e volume; depois as duas restantes e as camadas de workflow e calendário.
- Base de controle central — centralizar Zendesk + Fleetio no Nexus, de/para de status e sync em tempo real (fim dos 4 controles paralelos).
- Interface do time de Suporte Manutenção no Nexus — migrar Road Assistance do Zendesk; FleetNet com acionamento direto do driver; indicador de frota em manutenção.
- Interface do time de Manutenção no Nexus — módulo de maintenance no TMS: pipelines N1–N4, calendário de previsibilidade e analytics de SLA.
- Interface de Asset Management — rescue, in-transit, reserve, swaps, tracking e decisão recolocar × vender.
- Interface do Delivery Center (DC) — recebimento, inspeção/qualidade, peças/estoque, entrega técnica (JAX ↔ STL).
- Camada de workflows completa — 15 fluxos encadeados + alçadas + Estimate Approval.
- Calendários e medição em tempo real — previsibilidade de retorno, custo por quebra, predictive maintenance.
Suporte Manutenção
Maintenance Support / Road Assistance — reparo on-site e roadside de trucks em contrato ativoInterface Nexus: agora Base: Zendesk Owner do processo: Senna (N2) + Suporte N1 + FleetNet
Missão & escopo
Atender o driver com contrato ativo que quebra na estrada: acionar reparo (partner shop, dealer ou road side), acompanhar prazo, autorizar dentro da alçada e devolver o truck à operação o mais rápido possível.
Dores mapeadas
- Atendimento hoje é reativo; o driver frustra-se menos pela quebra e mais por não conseguir ajuda da Billor.
- ~40 trucks de cliente parados >2 dias em shop, sem dono claro do acompanhamento.
- Gap de registro: a quebra vive só no Zendesk/telefone e não vira WO no Fleetio → sem custo, sem garantia, sem loop de qualidade.
Interface Nexus a construir (curto prazo)
- Migrar Suporte Manutenção / Road Assistance do Zendesk para o Nexus — fim dos controles paralelos.
- Fila de trucks em manutenção com aging, shop e problema; ação definida por ativo.
- FleetNet: driver aciona direto (ligação + Billor APP) e nós monitoramos.
- Scripts de atendimento N1 e Shop; PM pós-reparo casado com o histórico.
Alçada de autorização (definida)
≤ US$ 3.5k: autonomia N1 / driver via FleetNet · > US$ 3.5k: escala Senna (N2) · ≥ US$ 5k: Manutenção N3 valida · limite fintech US$ 10k (cobra só o usado).
Workflow-âncora e encadeamentos
| Workflow (Nexus) | Gatilho | SLA / regra | Encadeia para |
|---|---|---|---|
| M-07 maint-road-assistance | Driver quebra na estrada → form "Maintenance Support" (Zendesk hoje → webhook/Nexus) | Estrada sem shop 1 dia · sob shop = níveis L1–L5 · split Waiting Estimate / Authorization | >3 dias em shop → maint-truck-reserve · acidente → Accidents |
| Entrada cross-área | safety-pti-defect (Safety) confirma defeito | Driver notificado via Motive → liga no Suporte | abre o chamado de road assistance |
Manutenção
Reconditioning — trucks/trailers retornados voltam ao stock de venda; gestão de reparos externos; PM / PTI / DOT / preditivaInterface Nexus: agora Base: Fleetio Owners: Kadu (recon) · Jonathann/Deivid (PM/DOT)
Missão & escopo
Executar o reconditioning de trucks/trailers retornados para recolocá-los no stock disponível ao Sales. Triagem interno × externo, coleta e limpeza de quotes, decisão de reparo, acompanhamento, inspeção final, reconciliação de despesa e aprovação de invoices. Sub-processos: PM, PTI e Predictive.
Dores mapeadas
- Lead-time gap: vendas pedem ~40/semana, stock pronto ~22; pressão diária por unidade.
- Estimate em 8 dias (meta 48h); ~400 invoices na fila.
- Quebras pós-recon — a maior dor financeira (caso emblemático: oil pan mal trocado → US$ 58k de engine failure).
- Comparação WO × inspection manual; quotes inflados sem evidência padronizada.
Interface Nexus a construir (curto prazo)
Novo módulo Maintenance dentro do TMS (/tms/maintenance), modelado na UX de Deliveries/Analytics do CRM, porém asset-cêntrico:
- Pipelines N1–N4 + estimate, churn return, new truck, reserve return (defaults do quadro: 13 estimate · 5 N1 · 11 N2 · 10 N3 · 4 N4).
- Calendário de previsibilidade — quando cada truck volta a available, com índice de confiança e auto-postergação.
- Analytics — trucks em manutenção, dias médios até available, % de SLA, trucks fora do SLA.
- Fleetio → Nexus: de/para de status por stage (172 trucks, 0 unmapped).
Régua de níveis e alçadas (vigente)
| Nível (L = N) | SLA | Significado |
|---|---|---|
| Estimate | 48h (meta) | Quote em andamento (nosso ou da shop) |
| N1 / L1 | ≤ 2 dias | Simples (PM service + buffer de peças) |
| N2 / L2 | 2–4 dias | Intermediário |
| N3 / L3 | 4–6 dias | Complexo |
| N4 / L4 | 6–10 dias | Pesado |
| N5 / L5 | > 10 dias · MAJOR | Body shop / motor / transmissão |
Alçada recon: < US$ 5k analista · > US$ 5k management (Red Flag ≥ US$ 5k → diretoria). Regra: na dúvida, sobe o nível. Camada futura FMCS v2.0 endurece com block next load em PM/PTI vencidos.
Workflows da área (Nexus)
| Workflow | Papel | Owner |
|---|---|---|
| M-01 maint-recon | Espinha dorsal: churn entry → … → unit available (11 stages) | Kadu |
| M-09 maint-vendor-repair | WO externa com vendor (custom field "Vendor Status", estimate 48h) | Kadu |
| M-10 maint-vendor-rework | Reprovação de inspeção → retrabalho na shop | Kadu |
| M-06b maint-pm-cycle | PM por faixa de milhagem (−30k..+3.5k mi) com load block | Jonathann/Deivid |
| M-06c maint-dot-ticket | Violação DOT do Safety → confirmação de reparo | Jonathann/Deivid |
Asset Management
Ciclo de vida do ativo fora do uso produtivo — recovery, in-transit, storage, telematics, swap e decisão recolocar × venderInterface Nexus: fase 2 Base: Fleetio + Motive Owner: Corso
Missão & escopo
Gerir o ativo em todo o intervalo em que ele não gera receita: trazer de volta trucks/trailers abandonados, gerir in-transit e paid storage, rastrear via telematics, analisar swaps e alimentar a decisão de recolocar no estoque ou vender.
Causa-raiz estrutural
O modelo de Lease Purchase sem down payment deixa o driver com baixo skin in the game → liberdade mental para abandonar o ativo. O abandono tem componente emocional (falta de carga, desânimo) captável pelo CRL antes de acontecer.
Dores & números
- Predatory towing: impound custa US$ 5–6k vs. ~US$ 900 de um tow controlado.
- Swaps de trailer não registrados — caso do driver no 8º trailer sem que a área soubesse do original.
- Roteamento por distância: partner drivers ≤500–700 mi (~US$ 0,80/mi) · drive-away acima (~US$ 0,35/mi).
Workflows da área (a portar na fase 2)
| Workflow | Papel |
|---|---|
| M-02 maint-rescue | Resgate de ativo abandonado/não devolvido (<1000 mi partner · >1000 mi drive-away · impound = sempre partner) |
| M-05 maint-truck-reserve | Truck parado; máx. 15 dias; devolução alvo 2 dias |
| M-04a/b/c replacements & swap | Troca de truck/trailer (unidade antiga entra como churn no recon) |
| M-A1 maint-load-rescue | Swap de carga quando o truck quebra — origem dos trailers perdidos |
| M-03 maint-new-unit | New truck/trailer até available (~3 dias) |
Interface a construir: fila de recovery/in-transit, tracking (Motive + covert GPS), reserve com SLA, e o Decision pool (Zé + Emerson) para ativos sem esteira aguardando decisão de diretoria.
Delivery Center (DC)
JAX & STL — recebimento de churn, inspeção, execução interna/externa, qualidade/entrega técnica, peças e estoqueInterface Nexus: fase 2 Bases: Fleetio + forms de inspeção Owner: Emerson · JAX (Douglas) / STL (John Mallas)
Missão & estrutura organizacional
O DC recebe o churn, inspeciona, decide interno × externo, executa/acompanha e faz a entrega técnica com qualidade. Estrutura preliminar de ~10 pessoas por DC:
- Gestor de ativos com dois focos: Trucks (movimentação/status) e Parts (inventário/esteiras).
- Treinador (daily care), comercial/qualidade, mecânicos.
- Referência: ~95% das manutenções são externas, ~5% na região do DC → segmentar dados por tipo de serviço.
Dores & qualidade
- Quebras "na esquina" por inspeção mal feita — origem "DC Available" quebra 51% vs. Reserve 15% (que já rodou → efeito shakedown).
- Rework: ~90% problemas novos, ~10% recorrência do item consertado → falha de inspeção/diagnóstico.
- Sem controle de estoque de peças em JAX (compra ad hoc); STL tem container de peças.
- Entregas acima do churn não se sustentam sem qualidade.
Processo de qualidade a instituir (já em campo na semana 1)
Portão A — inspeção de CHEGADA
Teste na chegada antes de ir para manutenção; inspeção ampla (~50 itens) gera flags → diagnóstico aprofunda → abre WO.
Portão B — stress test + QA de SAÍDA
Pressão no sistema, esforço de peso, inspeção completa direto na shop; adesivo de responsabilização do inspetor; nenhum truck na agenda sem QA aprovado.
- Forms padronizados (Delivery Inspection / Journey 2026 V2) validados e integrados ao app.
- Release Checklist nos 3 maiores ofensores (pneus, partida/bateria, ar/freios) — truck só vira available com checklist assinado.
- Testador de trailer 7 vias (1 por DC); relatório de rework/prazos por oficina.
Workflow relacionado: M-08 maint-post-sale-delivery (Preparation → Return Inspection). Esteiras novas a desenhar: A4.1 truck reprovado em QA · A4.2 ciclo in-house dos mecânicos.
Camada de Workflows & Automações (Nexus)
15 fluxos padronizados já foram derivados dos processos dos donos e da planilha canônica de validação dos líderes. São a camada que roda sobre a base central — cada um vira pipeline com stages, SLA e owner, encadeados entre si. Fonte canônica em conflito: a planilha de pipelines validada pelos líderes.
| # | Workflow | Área | Owner | Intake hoje → alvo |
|---|---|---|---|---|
| M-01 | maint-recon | Manutenção | Kadu | Chegada de churn → evento dos fluxos 02/04/05 |
| M-07 | maint-road-assistance | Suporte Manutenção | Senna + N1 + FleetNet | Zendesk form → webhook/Nexus |
| M-02 | maint-rescue | Asset Mgmt | Corso | Zendesk → webhook |
| M-03 | maint-new-unit | Asset Mgmt | Ana/Corso [confirmar] | Aquisição/retomada (manual) |
| M-04a/b/c | truck/trailer replacement & swap-road | Asset Mgmt | Corso | Zendesk → webhook |
| M-05 | maint-truck-reserve | Asset Mgmt | Corso | Truck >3d em shop |
| M-06b | maint-pm-cycle | Manutenção | Jonathann/Deivid | Extração semanal Fleetio → API |
| M-06c | maint-dot-ticket | Manutenção | Jonathann/Deivid | Ticket do Safety |
| M-08 | maint-post-sale-delivery | Delivery Center | Emerson [confirmar] | Truck vendido/reservado pelo Sales |
| M-09 / M-10 | maint-vendor-repair / -rework | Manutenção | Kadu | recon → outsourced-repair / inspection-failed |
| M-A1 | maint-load-rescue | Asset Mgmt | Corso | Dispatcher com swap plan via Zendesk |
requestable: true e passam a aparecer no catálogo do Nexus (/workflow/requests) — é assim que o Zendesk é substituído pelo Nexus como intake. Os 5 internos nascem por automação/encadeamento. Pendências transversais vivas: criar o departamento Maintenance no Nexus, resolver owners reais, ingestão do Fleetio no Postgres, webhook Zendesk→Nexus, e validar SLAs 1-a-1 com Kadu/Corso/Senna/Emerson.
Sequência sugerida de adoção
- 1. maint-road-assistance — maior dor/volume, alçada recém-decidida; começa manual via board.
- 2. maint-recon + maint-rescue — espinha dorsal do ciclo do ativo (churn → recon → available).
- 3. maint-truck-reserve + replacements — fluxos driver-facing com regras claras.
- 4. maint-pm-cycle + maint-dot-ticket — dependem menos de owners novos.
- 5. maint-load-rescue + trailer-swap-road — travam a dor dos trailers perdidos.
- 6. maint-new-unit + post-sale-delivery — validar com Ana/Corso e Emerson.
Plano de ataque de curto prazo (Semanas 1–2)
A operação não pode esperar o sistema. Este é o plano de guerra que estanca o sangramento em paralelo à construção da base — Semana 1 (20–26/07) estanca e enxerga; Semana 2 (27/07–02/08) consolida e acelera. Disposição: Arcson na gestão/Nexus (contratos atuais), Douglas no DC/JAX (novos contratos), Robert no comercial (BFTO + retenção).
Semana 1 — Estancar e enxergar
| Frente | Dono | Entrega da semana |
|---|---|---|
| 100% dos trucks com status + donos + calendário realista | Arcson | Todos posicionados no Nexus, cada pipeline com owner, calendário de previsão publicado (Seg 20/07 EOD) |
| Contrato ativo em shop + virada FleetNet | Arcson → Senna | Senna owner do fluxo ativo; parados >2d: 40 → 0; FleetNet implantada |
| Qualidade: teste de chegada + stress test de saída | Douglas (+ QA) | Checklist duplo em JAX; adesivo de responsabilização; forms no app |
| Presença nas oficinas + cadência 2x/dia | Douglas (+ Kadu) | Embedded em BR Diesel/TUI; lista de liberação diária; capacidade mapeada |
| Priorização da fila + despressurização | Arcson + Douglas | Fila ordenada; matriz local × parceiro × dealer; estoque de peças iniciado |
| Entregas ≤ 4/dia até regularizar | Douglas | 25 agendados redistribuídos; zero entrega sem QA aprovado |
| Churn: entrada controlada + esteira no Nexus | Douglas + Arcson | Inspeção de entrada imediata; entrada <4/dia; lista de churn no Nexus |
| Comercial: virar o time para o BFTO | Robert | Time operando BFTO com metas; verba MKT BFD → BFTO |
| Retenção com o João (CX) | Robert + João | Churn < 20/semana; preventivas de volta ao patamar |
Semana 2 — Consolidar e acelerar
| Frente | Dono | Entrega |
|---|---|---|
| PM/PTI — reduzir pancadas do recondicionamento | Arcson (+ Jonathann/Deivid) | Novos fluxos PTI/PM ativados; follow-up via Motive |
| Medição em tempo real | Arcson | Painel Nexus com SLA por etapa, aging e custo; quebras nos 30d pós-entrega |
| Nexus manutenção em produção + sync | Arcson (+ tech) | Fleetio→Nexus automático; início do retorno Nexus→Fleetio |
| Replicar padrão JAX ↔ STL | Douglas (+ John Mallas) | Checklists e cadência consolidados em STL |
| Rampar entregas com segurança | Douglas + Arcson | Subir o teto de 4/dia com base no calendário, se estabilizado |
Indicadores & análise de breakdown
Os números abaixo justificam o plano e, sozinhos, provam por que a base precisa ser integrada. Fonte: Fleetio (service history no BigQuery), Zendesk (tickets do escopo suporte-manutenção) e Motive (fault codes), consolidados por ciclo do ativo.
Funil de quebra pós-saída do DC (visão integrada)
| Cenário | ≤10d | ≤30d | ≤60d |
|---|---|---|---|
| Fleetio (corretiva aberta) | 5,2% | 14,4% | 29,1% |
| Zendesk (ticket) | 2,9% | 7,1% | 16,2% |
| Integrado | 8,0% | 21,0% | 43,2% |
Mensal integrado ≤30d: 13,5 → 19,9 (mar) → 13,9 (mai) → 33,3 (jun, pior mês) → 27,1% (jul). Mediana da 1ª quebra: ~10 dias; 41% na 1ª semana → sinal de inspeção/preparação, não de desgaste.
Principais ofensores (o que quebra)
| Categoria | % das saídas ≤30d |
|---|---|
| Pneus | 42,6% |
| Freios / sistema de ar | 16,1% |
| Elétrica / partida / bateria | 15,8% |
| Motor (check engine, óleo, turbo) | 12,9% |
| Arrefecimento (coolant / overheat) | 10,4% |
| DPF / emissões · A/C-APU · transmissão | 7–8% cada |
Corroborado por fault codes Motive: SPN-111 (coolant level) e aftertreatment. Alarmes automáticos nesses códigos em trucks com ≤30d de entrega são o precursor objetivo mais frequente.
O padrão mais acionável do estudo
Trucks que saem do status "DC Available" quebram em 51%; os vindos de Reserve, só 15% — porque já rodaram e foram validados. O truck recém-preparado no DC sai sem shakedown. Daí as duas contramedidas de maior alavancagem: Release Checklist de saída e shakedown run de 50–100 mi antes de alocar ao driver. Meta 2026: quebra ≤30d abaixo de 30% até setembro, convergindo ao baseline (36%) e abaixo até dezembro.
Report detalhado (interativo, com drilldown): kickoff-oficial/breakdown-analysis/Breakdown-Analysis-2026.html
Governança, owners e fontes
Disposição das forças & cadência
- Arcson — Manutenção & Suporte Manutenção (gestão, Nexus, contratos atuais).
- Douglas — DC/JAX e ponta física (mecânicos, inspetores, oficinas, entregas).
- Robert — Comercial (BFTO) e retenção/churn com o João (CX).
- Donos de esteira: Kadu, Corso, Senna, Emerson, Jonathann/Deivid.
- Cadência de guerra: ponto de controle diário do trio (manhã) · report diário à diretoria · checkpoints 2x/dia com oficinas.
Pendências transversais (não bloqueiam, mas destravam)
- Criar o departamento Maintenance no Nexus e resolver owners reais.
- Ingestão do Fleetio no Postgres do Nexus (hoje sem CDC para eventos).
- Webhook Zendesk → Nexus para criação de card.
- Validar SLAs 1-a-1 com Kadu/Corso/Senna/Emerson.
- Desenhar a pipeline Estimate Approval e as esteiras A4.1/A4.2.
Fontes consolidadas neste documento
Plano de ataque semanas 1–2 e ownership (6-plano-curto-prazo/md/pt-br/) · Síntese de dores Jardel/Douglas (histórico-recente/00-sintese-dores...) · Entendimento de Maintenance e Asset Management (asset-maintenance/entendimento/) · Master Workflow + extração ao vivo do Miro uXjVH980a1I (3-processos-atividades/Maintenance-Asset-Master-Workflow.md) · Plano de implementação do Nexus (nexus-maintenance/MAINTENANCE-PLAN.md) · Análise de breakdown 30d v3.2 (breakdown-analysis/) · Estrutura do DC (DC-FreshStart/) · Lista-mestra de 15 workflows (dev/workflow-builder/workflow-workspace/maintenance/) · Reunião semanal 19/07.
O board do Miro é canvas (sem texto extraível); usamos a extração ao vivo completa de 11/07 já preservada no Master Workflow.