A informação central ficava num quadro de tarefas, num rastreador de chamados e em várias camadas de pasta num drive compartilhado. Para pegar o que um projeto precisava, alguém buscava e depois abria o mensageiro para perguntar o que a busca não tinha achado. Erro e duplicidade eram frequentes.
O briefing parou de se perder entre as ferramentas
Uma produtora de tours em vídeo trocou dados de cliente espalhados em três ferramentas, projetos organizados à mão e passagens de bastão feitas no chat por um sistema conectado em que cada etapa do projeto dispara sozinha e cada ajuste fica no registro do projeto.
Este é um dos cases mais antigos do Jestor. Foi registrado em abril de 2022. A linha de produto e o foco da empresa mudaram desde então, pelo próprio perfil público do fundador. Não sabemos se o sistema descrito aqui ainda roda. Tudo abaixo descreve a operação como era na época do case.
Uma produtora de tours em vídeo cujo gargalo era achar o briefing, não ganhar o trabalho.
A Tour.Video produz tours em vídeo para imóveis e instalações. Demanda havia. O que faltava ao time era um lugar onde o projeto e tudo sobre ele vivessem juntos.
Produção de tours em vídeo
2021Passou pelo Y Combinator (S21)
MichiganSaiu da Universidade de Michigan
Tours em vídeoPara imóveis e instalações
2022Ano em que o case foi registrado
15 minTempo economizado por projeto, no mínimo, pela estimativa da própria empresaCase publicado; sem método de medição, volume nem período.
3Canais que o case nomeia como integrados para mover o processo: Slack, Gmail, Google CalendarSeção "Depois" do case publicado; a contagem é a lista da fonte.
1Kanban em que rodam todos os projetos de ediçãoDescrição do próprio case publicado.
2021Ano em que a empresa passou pelo Y Combinator (S21)Material da própria empresa e perfil público do fundador.
“O Jestor tira 11 de 10 em facilidade de uso. Eu ficaria muito decepcionado se o Jestor sumisse e eu não pudesse mais usar. Tão decepcionado que eu criaria outro Jestor, só para replicar a experiência.”
Amulya ParmarFundador
AntesDepois
- Dado de cliente num quadro de tarefas, num rastreador e em pastas de driveUm conjunto de registros ligados, da venda ao onboarding
- Busca de briefing, referências e arquivos por projetoMaterial anexado ao registro do projeto
- Mensagem perguntando qual é a próxima etapaO sistema manda tarefa ou e-mail quando a etapa vence, com contexto anexado
- Planilha como fluxo, regras não seguidasFluxo definido com etapas no software, seguido porque o software as roda
- Projetos de edição organizados à mãoUm kanban para todos os projetos de edição
- Ajustes discutidos no chatAjustes, mudanças e notificações no registro do projeto
- Integração de novatos por ferramentas defasadas e assíncronasNovatos integrados ao fluxo pelo sistema
O que não foi trocado. Slack, Gmail e Google Calendar ficaram; hoje são pontas das automações, não os lugares onde o processo vive. O trabalho de edição e o produto ficaram. A empresa avaliou outras ferramentas de banco de dados e de documentação antes de escolher; o case registra a visão do time de que uma ferramenta de documentação era forte para documentar e mais fraca para rodar trabalho, o que é descrição de encaixe, não de qualidade.
O gargalo era operacional, não comercial
A Tour.Video produz tours em vídeo para imóveis e instalações: universidades, residenciais de luxo, grandes escritórios, moradia estudantil e multifamiliar, residências para idosos. A empresa saiu da Universidade de Michigan, nos Estados Unidos, passou pelo Y Combinator na turma de verão de 2021 e vendia o produto para administradoras de imóveis, ao lado de um produto irmão de captação de leads. Na época deste case, crescia rápido e contratava o tempo todo.
Um tour em vídeo é um projeto de mídia, e projeto de mídia acumula material: notas de briefing, imagens de referência, rascunhos, pedidos de ajuste, links de entrega. Tudo necessário e tudo fácil de perder. A promessa ao cliente, produção de alta qualidade entregue rápido, depende de o time achar o material certo e a pessoa certa em cada etapa sem procurar.
Por isso o gargalo era operacional, não comercial. Demanda havia. O que faltava ao time era um lugar onde o projeto e tudo sobre ele vivessem juntos, e um mecanismo para a próxima etapa começar sem uma mensagem pedindo.
O processo vivia nas pessoas e nas mensagens
“O Jestor tira 11 de 10 em facilidade de uso. Eu ficaria muito decepcionado se o Jestor sumisse e eu não pudesse mais usar. Tão decepcionado que eu criaria outro Jestor, só para replicar a experiência.”
Não havia processo consistente e escalável. Regras de entrada e busca existiam mas não eram seguidas; o dado saía de sincronia; o time reajustava à mão e ainda assim perdia consistência.
As etapas não eram automatizadas, então cada passagem era uma mensagem, uma espera e uma resposta. Fluxos ordinários eram difíceis de implantar porque cada etapa dependia de alguém lembrar de disparar.
Achar URLs e arquivos de vídeo, mandar mensagem para o editor certo, esperar resposta, discutir ajuste no chat: todo projeto pagava a mesma sobrecarga antes de qualquer edição acontecer.
O padrão: o processo vivia nas pessoas e nas mensagens, e as ferramentas guardavam fragmentos dele. Nada estava quebrado. Mas uma empresa contratando o tempo todo não conseguia integrar gente num processo que não estava escrito em lugar nenhum, e todo projeto novo pagava de novo o custo inteiro de buscar e mensagear.
Item a item, o que fazia cada trabalho antes e o que faz hoje
| O que fazia isso antes | O que faz hoje |
|---|---|
| Dado de cliente num quadro de tarefas, num rastreador e em pastas de drive | Um conjunto de registros ligados, da venda ao onboarding |
| Busca de briefing, referências e arquivos por projeto | Material anexado ao registro do projeto |
| Mensagem perguntando qual é a próxima etapa | O sistema manda tarefa ou e-mail quando a etapa vence, com contexto anexado |
| Planilha como fluxo, regras não seguidas | Fluxo definido com etapas no software, seguido porque o software as roda |
| Projetos de edição organizados à mão | Um kanban para todos os projetos de edição |
| Ajustes discutidos no chat | Ajustes, mudanças e notificações no registro do projeto |
| Integração de novatos por ferramentas defasadas e assíncronas | Novatos integrados ao fluxo pelo sistema |
O que não foi trocado. Slack, Gmail e Google Calendar ficaram; hoje são pontas das automações, não os lugares onde o processo vive. O trabalho de edição e o produto ficaram. A empresa avaliou outras ferramentas de banco de dados e de documentação antes de escolher; o case registra a visão do time de que uma ferramenta de documentação era forte para documentar e mais fraca para rodar trabalho, o que é descrição de encaixe, não de qualidade.
A cadeia, ponta a ponta, para um tour em vídeo
- 1A venda fecha e o registro do cliente é criadoPessoa
Com imóvel, briefing e material de referência.
- 2Um registro de projeto é criado no kanban de edição, ligado ao clienteAutomático
O projeto herda o briefing e os arquivos já anexados ao cliente.
- 3O editor designado recebe tarefa ou e-mail com URLs e arquivos anexadosAutomático
A próxima pessoa não precisa procurar o material.
- 4O editor produz o rascunho e move o projeto para a próxima fasePessoa
O trabalho de edição em si ficou; o que mudou é como ele é passado adiante.
- 5O revisor, e quando cabe o cliente, é notificado por Slack ou e-mailAutomático
Pelos canais em que as pessoas já trabalham.
- 6Pedidos de ajuste são registrados no registro do projetoPessoa
Não ditos no chat.
- 7Cada ajuste registrado cria uma tarefa para o editorAutomático
Com a mudança anexada ao mesmo projeto.
- 8A entrega é marcada, o cliente é notificado e o evento de agenda é criadoAutomático
E o cliente recebe o vídeo pelos canais que já usa.
Os elos difíceis são o 1 e o 6. O projeto só é tão completo quanto o briefing que alguém anexou no começo, e o ajuste só chega ao editor se for registrado no projeto em vez de dito no chat. O desenho aceita os dois e faz deles a versão mais barata possível: um registro para preencher na venda, um campo para escrever a mudança. Tudo no meio é automático porque os dois passos humanos são pequenos o bastante para serem feitos toda vez.
Cada mudança, com a base ao lado
| Indicador | Resultado | De onde sai |
|---|---|---|
| Achar material do projeto | De garimpar três ferramentas para material no registro do projeto | Case publicado, seções "Antes" e "Depois" |
| Passagens de bastão | De mensagem, espera e resposta por etapa para tarefa ou e-mail automático por etapa | Case publicado |
| Consistência de dado | De erro e duplicidade frequentes para registros ligados sem duplicação | Case publicado; a afirmação de "sem duplicação" é do time |
| Onboarding | De ferramentas assíncronas defasadas para integração pelo próprio fluxo | Case publicado |
| Tempo por projeto | No mínimo 15 minutos mais rápido por projeto, pela estimativa da empresa | Case publicado; sem método, volume nem período |
Os 15 minutos são estimativa, e a extrapolação não é adotada. O case afirma que cada projeto fica no mínimo 15 minutos mais rápido e depois multiplica isso em "centenas e milhares de horas" ao longo de meses. O número por projeto é estimativa do próprio time, sem método. O número multiplicado exige um volume de projetos que o case não informa, então este texto não o repete.
"Totalmente automatizado" descreve os disparos, não o trabalho. O case diz que toda etapa acionável é totalmente automatizada. O que é automatizado é a passagem: a tarefa ou o e-mail que diz à próxima pessoa o que fazer e entrega o material. Edição, revisão e ajuste continuam sendo pessoas.
Não existe número de porte na fonte. O case não publicou quantidade de clientes, volume de projetos, receita nem tamanho de time.
O que este case não mede
Vale dizer, porque é o que normalmente aparece inflado.
Toda descrição e a citação do fundador vêm da empresa conforme publicado. Nenhum processo foi observado ou cronometrado de forma independente.
Projetos por mês, horas por projeto antes e depois, prazo de entrega ao cliente, taxa de erro: nada disso aparece na fonte. O único número de tempo é estimativa sem método.
O case foi publicado em abril de 2022. A linha de produto e o foco da empresa mudaram desde então, pelo próprio perfil público do fundador. Não sabemos se o sistema descrito aqui ainda roda.
O case não trazia números no cabeçalho, e por isso a tabela de números acima usa contagens do próprio texto do case.
O case original nomeia as ferramentas substituídas e duas alternativas avaliadas. Este texto nomeia só os três canais mantidos como integração e descreve as demais por categoria.
Nome e cargo aparecem no case do Jestor e batem com o perfil público do fundador; nenhum outro membro do time é citado.
O custo de um processo espalhado é pago em trocas de tela, não em software
| Indicador | Número | Fonte |
|---|---|---|
| Vezes que um trabalhador do conhecimento alterna entre aplicativos e sites por dia | Cerca de 1.200 | Murty, Dadlani e Das, Harvard Business Review, agosto de 2022; 137 usuários, 20 times, 3 grandes empresas, até 5 semanas |
| Tempo por semana gasto se reorientando depois de alternar | Pouco menos de 4 horas, cerca de 9% do tempo de trabalho | Mesmo estudo |
| Parcela das trocas seguidas de outra troca em menos de 11 segundos | 65% | Mesmo estudo |
| Aplicativos SaaS em uso na empresa média | 305 | Zylo, SaaS Management Index 2026 |
Quatro horas por semana é o imposto de reorientação num estudo de empresas grandes e bem equipadas. Um time pequeno com o processo dividido entre quadro de tarefas, rastreador, drive e chat paga o mesmo imposto por pessoa. Os "no mínimo 15 minutos por projeto" do case são uma versão grosseira e não medida do mesmo achado.
Dois terços das trocas no estudo foram seguidas de outra em menos de onze segundos. Esse é o perfil de alguém procurando o que precisa entre ferramentas, exatamente o estado anterior que este case descreve. Colocar o material no registro tira a busca, e as trocas junto.
As 1.200 alternâncias vêm de um estudo com 137 pessoas em três empresas, em 2022. É repetido por aí como média universal. Serve bem como indicação de escala e mal como base de business case; a contagem do próprio time é o número certo a usar.
O cliente é uma empresa americana; os dados de referência são internacionais.
O sistema é feito sob medida e a responsabilidade por ele continua nossa
O arranjo antigo da Tour.Video não era incomum. Era um quadro de tarefas, um rastreador, um drive compartilhado e um chat, cada um bom no que faz e nenhum deles guardando o processo. A pergunta que um sistema sob medida precisa responder é o que acontece no ano dois: um sistema de fluxo que ninguém pode mexer vira o novo quadro de tarefas em três anos, com login.
Um construtor toca cada pedido do começo ao fim, com um sempre em execução.
Um novo fluxo, uma nova automação ou um novo relatório entram pelo mesmo canal, sem virar projeto novo.
Se o que foi construído não está bom, ele é refeito. Revisões ilimitadas dentro da assinatura.
Assento nunca é a régua de cobrança, o que importa quando vendas, editores, revisores e novatos tocam os mesmos registros.
As pessoas aprendem a usar o app delas como aprendem qualquer app, abrindo. Construir, configurar e manter continua do nosso lado.
Exportação completa a qualquer momento, por CSV e API. Conformidade SOC 2, sem taxa de saída. Dá para pausar em um clique e os sistemas continuam rodando.
Metodologia e fontes
As descrições de antes e depois e a citação do fundador vêm do case que o Jestor publicou em abril de 2022, escrito a partir de entrevistas com a empresa. São o relato da própria empresa e não foram auditadas. A citação é usada na íntegra.
Segmentos de cliente e descrição do produto: case publicado e material da própria empresa. Origem universitária e turma do acelerador: perfil público do fundador e publicação de escola de negócios de 2021.
Murty, Dadlani e Das, "How Much Time and Energy Do We Waste Toggling Between Applications?", Harvard Business Review, agosto de 2022. Zylo, SaaS Management Index 2026.
A extrapolação de "centenas e milhares de horas" do case original não é repetida, porque o volume de projetos de que ela depende não é informado. Nenhum prazo de entrega, taxa de erro ou índice de satisfação é afirmado, porque nada disso foi medido.