Transformando uma operação fragmentada em um sistema que conecta venda, execução e financeiro.
O problema não era desenhar um CRM. Era fazer a informação sobreviver ao caminho inteiro — do Lead ao pagamento — sem ser reconstruída em cada handoff, sem misturar responsabilidades e sem perder contexto entre módulos.
Uma decisão local podia gerar consequências em várias partes do produto.
Contract, Job, Scheduling, Dispatch, Invoice e Payroll não eram fluxos independentes. Alterar uma regra em um ponto podia impactar operação, financeiro, comunicação e experiência do cliente.
Estruturar o sistema antes de aprofundar a interface.
Mapeei entidades, relações, estados, exceções, permissões e handoffs; transformei essa lógica em fluxos, padrões de interação, automações e uma linguagem consistente entre módulos.
O produto precisava funcionar como um sistema, não como uma coleção de telas.
O processo começava em aquisição e vendas, mas não terminava quando uma proposta era aceita. A informação precisava seguir para contrato, criação do Job, agendamento, despacho, execução, faturamento e payroll. Foi aí que a pergunta mudou: em vez de “qual tela vem depois?”, passei a trabalhar em “qual entidade é responsável por esta decisão e o que ela precisa preparar para a próxima?”.
Lead, Pipeline, Estimate e Proposal precisavam compartilhar contexto e preparar a transição para operação.
Job, Scheduling e Dispatch passaram a representar responsabilidades distintas dentro do mesmo serviço.
Triggers, condições e ações automatizam handoffs sem transformar o usuário em memória operacional.
Mapear do Lead ao pagamento tornou os handoffs visíveis.
A jornada revelou onde o contexto mudava de dono: Sales entrega para Operations; Operations produz evidência para Finance; Finance fecha o ciclo e alimenta a relação com o cliente. Esse mapeamento também mostrou que nem todas as etapas deveriam ter a mesma obrigatoriedade.
Nem toda Proposal precisava virar Contract antes de virar Job.
Separar Proposal, Contract e Job evitou transformar o contrato em uma dependência técnica obrigatória. Para serviços que exigiam formalização, o caminho continuava Proposal → Contract → Job. Quando o vínculo contratual não era necessário, a Proposal aceita podia originar o Job diretamente.
O que estamos oferecendo, por qual valor e em quais condições comerciais.
Quando existe um vínculo formal, quais regras e termos precisam persistir ao longo da relação.
Qual trabalho precisa realmente acontecer, onde, quando e com quais requisitos operacionais.
O Pipeline precisava mostrar o próximo movimento, não apenas o estágio.
Organizei as oportunidades para que valor, origem, prioridade, tempo no estágio e próxima ação fossem legíveis sem abrir cada registro. A Proposal Performance complementa essa visão: não basta saber que a proposta foi enviada; o time precisa entender se ela foi visualizada e como o cliente interagiu com o documento.
Automação deixou de ser um recurso isolado e passou a conectar o ecossistema.
Modelei o Workflow em torno de uma lógica simples de entender e extensível: Trigger → Condition → Action → Outcome. Isso permite automatizar handoffs como Proposal aceita, criação de Contract ou Job, notificações operacionais, validações após execução e follow-ups financeiros.
Princípio: automatizar a consequência de um evento sem esconder do usuário o que aconteceu, por que aconteceu e qual foi o próximo passo.
Job, Scheduling e Dispatch precisavam ser separados para reduzir ambiguidade operacional.
Um Job define o que precisa acontecer e onde. Scheduling responde quando. Dispatch responde quem executará, considerando disponibilidade, capacidade, conflitos e necessidade de reassignment. Misturar essas responsabilidades em uma única tela aumentaria a carga cognitiva e dificultaria a evolução das regras de operação.
Customer, service, address, checklist, instructions, requirements e status do trabalho.
Data, horário, duração, recorrência, janela de execução e disponibilidade temporal.
Equipe, capacidade, conflito, assignment, reassignment e acompanhamento operacional.
O contexto não podia desaparecer quando o canal ou a fonte de dados mudava.
Dois problemas diferentes tinham a mesma raiz: perda de contexto. No Inbox, a comunicação precisava permanecer conectada ao registro e ao histórico do cliente. Na importação, dados externos precisavam entrar no sistema com mapeamento explícito, revisão e tratamento de inconsistências.
Quando o produto cresce, estados e exceções passam a ser parte da arquitetura.
Padronizei 44 flags e estados para que diferentes módulos falassem a mesma linguagem. O objetivo não era criar uma biblioteca de badges, mas tornar situações operacionais previsíveis: pending, approved, rejected, assigned, conflict, overdue, paid, failed e outras condições precisavam ter semântica, comportamento e critérios consistentes.
O principal resultado foi transformar regras dispersas em uma arquitetura de produto coerente.
O case não depende de uma métrica isolada para demonstrar impacto. A evidência mais forte está na escala e na consistência do sistema entregue: módulos que compartilham contexto, responsabilidades de domínio separadas, Workflow Automation atravessando etapas, 44 estados padronizados e um Design System capaz de sustentar a evolução do produto.
Em sistemas operacionais, uma boa tela não corrige uma arquitetura mal conectada.
Proposal, Contract, Job, Scheduling e Dispatch ficaram mais claros quando suas responsabilidades deixaram de competir.
Quanto mais o sistema executa sozinho, mais importante explicar estados, exceções, histórico e consequência.
Mais do que organizar telas, o projeto organiza informação, decisão e continuidade entre Sales, Operations, Finance e People.