Cases

Cada curso passa por uma esteira com cinco frentes: Projetos (relação com o cliente), Conteúdo/Design Instrucional, Audiovisual (gravação), Criação (assets) e Pós-Produção (edição e finalização).

Em pouco tempo, o time passou por Notion, ClickUp, de volta ao Notion, além de testes com Jira. As migrações aconteceram no meio da operação, com cliente e prazo correndo. O ponto de virada foi perceber que o problema não estava em qual ferramenta escolher, e sim em tentar encaixar o processo da Versa em uma estrutura pensada para outro tipo de empresa.

O problema não era falta de recurso nas ferramentas. Era o modelo de dados delas: tudo virava uma tarefa do mesmo tamanho, e a Versa não trabalha assim.

O trabalho da Versa muda de tamanho conforme avança na esteira. Conteúdo trata cada aula individualmente; Audiovisual e Criação conseguem trabalhar com blocos de informação; na Pós-Produção, o trabalho volta a ser por aula.

Ferramentas de mercado escolhem uma granularidade e impõem a todos. O VERSA OS mantém um único card que percorre todos os times, mas cada time o enxerga e o distribui no tamanho em que de fato trabalha.

A decisão de construir foi aprovada pela liderança em setembro de 2026, depois de uma apresentação aberta ao time. O caminho de mercado já tinha sido testado mais de uma vez; o que mudou foi o custo de construir: com desenvolvimento assistido por IA, um sistema sob medida deixou de exigir um time de engenharia dedicado.

O VERSA OS troca a passagem de bastão manual por gatilhos: quando uma etapa termina, a próxima é liberada sozinha. Uma aprovação do cliente libera Gravação e Assets ao mesmo tempo; uma reprovação volta para o roteiro e conta como nova versão.

Durante os testes, qualquer pessoa deixa uma sugestão no ponto exato da interface em que sentiu a fricção: um lápis aparece ao passar o mouse, e a sugestão fica atrelada ao botão ou à tela em que nasceu. Uma IA classifica as sugestões e recomenda o que deve entrar nas próximas sprints; o time responsável decide e implementa.

O VERSA OS foi escrito 100% com Claude Code, por um time sem engenharia dedicada. O papel humano foi decidir o que construir e por quê; a IA escreveu o código. Roteiros, vídeos e dados sensíveis continuam no Google Drive: o sistema só organiza, mostra e incorpora.

Construir com IA não dispensa produto. Sem um modelo claro de como o trabalho flui, a IA só acelera a construção da ferramenta errada.

A apresentação para o time mostrou o que o discovery não tinha capturado. Nada foi refeito, mas boa parte do sistema mudou de forma: a importação da proposta deixou de ser obrigatória, surgiu um botão para acrescentar entregável no meio do projeto, uma página do cliente passou a liberar o material só depois do OK interno, e os alertas de atraso foram revistos depois de assustarem quem abriu a alfa.

O maior aprendizado: a pergunta certa não era "qual ferramenta usar", e sim "qual é a unidade de trabalho de cada time".

Fase final de desenvolvimento, em testes paralelos com representantes de cada time; entra 100% em produção em janeiro de 2027. Ainda não há números de resultado. A medição já está embutida: tempo com o cliente, tempo em fila e de execução por time, ajustes internos × versões com cliente e capacidade por ilha.

Nomes de clientes e de pessoas estão desfocados nas telas.

Problema: o feedback de revisão chega sem estrutura e passa por uma tradução manual entre e-mail e Notion. Isso gera versões extras, esconde pedido novo dentro de ajuste e deixa aprovações travando outras etapas sem que ninguém veja.

Solução: o cliente revisa direto no produto e marca cada ponto como correção, nova solicitação ou dúvida, com timecode e dizendo se aquilo trava alguma etapa. O sistema separa os caminhos sozinho.

A Versa produz cursos para educação corporativa, e cada cliente chega com marca, linguagem e critérios próprios. Coordeno a pós-produção, um time de 9 pessoas entre edição, motion e design, e mais de uma área participa de cada entrega: Conteúdo escreve o roteiro, Criação define a proposta visual e a Pós monta os vídeos.

No último ano, padronizei processos que rodavam desconectados. O lead time de um projeto de 1 hora caiu de cerca de 14 para 8 dias, e as versões por entrega caíram de 4 para 2,4. Ainda assim, 2,4 versões é muita volta, e a revisão era o pedaço do fluxo que eu ainda não tinha atacado de frente.

Nomes de clientes e de pessoas estão anonimizados neste case.

Comecei separando o que eu sabia do que eu achava que sabia. Afunilei o escopo logo cedo: em vez da gestão de produção inteira, só revisão e aprovação, porque é ali que o lead time trava. Uma suposição minha caiu logo no começo: eu achava que faltava minutagem nos comentários.

O problema não era falta de minutagem: era o feedback não ter forma, e uma pessoa só fazendo a ponte entre o cliente e a equipe. Cheguei nisso por três caminhos.

Quatro perfis tocam a mesma entrega, cada um com uma dor diferente. A gestora de projetos é a primeira usuária: é ela quem mais sofre com o problema e o ponto onde ele se forma.

Como podemos fazer o feedback chegar a quem executa já separado por tipo, com os critérios do cliente à mão e com o que bloqueia o quê visível para todos?

Com o cliente fora, a gestora continuaria recebendo por e-mail e registraria no formato estruturado. Seria mais fácil de adotar, porque mudar hábito de cliente é o mais difícil. Com o cliente dentro, ele revisa por um link e já deixa o feedback classificado, o que elimina a tradução manual.

Escolhi o cliente dentro. A tradução manual é a raiz dos três insights, e mantê-la só deixaria o problema mais organizado. Para reduzir o risco de adoção, o cliente entra por link, sem criar conta, e cada tipo de ponto vem com uma frase curta explicando o que ele significa.

Numa tela cheia de versões, prazos e comentários, a interface precisa sumir para a decisão aparecer. Por isso o Crivo tem uma linguagem minimalista: preto e branco como base, muito respiro, cantos generosos e uma única cor de marca (azul-marinho), com cores de estado para nova solicitação, aprovado e bloqueio.