Como reportar progresso para cliente não técnico: o ritual semanal que acaba com a cobrança no WhatsApp (e o formato que a OCA usa)

Você fechou o projeto, recebeu a entrada e começou a codar. Na primeira semana, silêncio bom. Na segunda, chega a mensagem: “E aí, como tá o app?”. Na terceira, o cliente manda áudio às 22h perguntando se “já dá pra ver alguma coisa”. Você está entregando bem, o código está andando, mas o cliente não sabe disso. E o que ele não sabe, ele preenche com ansiedade.

Esse é o cenário mais comum que eu vejo em devs que já dominam a parte técnica. O problema nunca é o código. É que o cliente comprou algo que ele não consegue ver, e ninguém construiu uma janela para ele olhar. Este artigo é sobre construir essa janela sem gastar mais do que uma hora por semana.

A verdade desconfortável: silêncio técnico é lido como abandono

Para você, três dias sem falar com o cliente significa foco. Para ele, significa que o projeto parou. Ele já foi queimado antes, ou conhece alguém que foi: dev que sumiu, agência que entregou metade, sistema congelado com o dinheiro pago. Cada dia sem notícia confirma o medo.

Vou te falar como funciona do lado de quem recebe os leads: uma parcela grande dos clientes que chegam na OCA vem de um projeto que deu errado com outro fornecedor. Quando eu pergunto o que aconteceu, quase nunca a resposta é “o código era ruim”. A resposta é “ele sumiu”, “eu não sabia em que pé estava”, “só descobri o atraso no dia da entrega”. O produto pode até estar razoável. A relação morreu por falta de informação.

A conta é simples. Cliente sem informação fica ansioso. Cliente ansioso cobra. Cobrança interrompe. Interrupção atrasa. Atraso gera mais ansiedade. O ritual de reporte existe para quebrar esse ciclo antes de ele começar, não para apagar incêndio depois.

O formato de status semanal que a OCA usa

Depois de anos ajustando, o que sobrou foi um relatório curto, enviado no mesmo dia e horário toda semana, com cinco blocos. Cabe em uma mensagem de WhatsApp ou em um e-mail de quinze linhas. Leva de vinte a quarenta minutos para escrever, e esse é o tempo mais bem gasto da semana.

1. O que foi feito. Em linguagem de usuário, não de dev. “Cadastro com e-mail e Google funcionando” em vez de “implementei o fluxo de autenticação com OAuth e refresh token”. O cliente precisa reconhecer o que ele comprou.
2. O que vem na próxima semana. Uma ou duas frases. Isso cria expectativa concreta e dá ao cliente a chance de dizer “espera, isso mudou” antes de você gastar cinco dias construindo a coisa errada.
3. Onde eu preciso de você. Decisão pendente, acesso que falta, conteúdo que não chegou. Sempre com prazo e consequência: “se o logo chegar até quarta, a tela inicial entra nesta semana; depois disso, fica para a próxima”. Isso transfere a responsabilidade pelo atraso para quem realmente está segurando.
4. Riscos e desvios. Só quando existem. Prazo apertado, integração que não se comportou como a documentação prometia, dependência de terceiro. Contar cedo custa uma conversa chata de cinco minutos. Contar tarde custa o cliente.
5. Link para ver. Build de teste, ambiente de staging, ou um vídeo de quarenta segundos gravado na tela. Esse bloco vale mais que os outros quatro juntos.

Esse formato roda em todo projeto da OCA e rodou dentro da Revo enquanto a gente construía o produto para os primeiros produtores de evento. Isso não é teoria, é literalmente como a OCA mantém dezenas de clientes ativos sem virar refém do WhatsApp.

Por que dia e horário fixos importam tanto

Previsibilidade elimina a pergunta. Se o cliente sabe que toda sexta às 17h chega o status, ele não pergunta na quarta. E se você atrasar a mensagem de sexta, ele vai perguntar às 18h. Isso é sinal de que o ritual funciona: ele confiou que viria. Trate esse horário como um deploy agendado, não como algo que você faz “quando sobrar tempo”.

Mostre, não descreva: uma build na mão do cliente

Cliente não técnico não entende “a API está pronta”. Ele entende botão que funciona. Então a regra na OCA é: nunca reportar algo como pronto se o cliente não consegue clicar. Se o backend está fechado mas ainda não tem tela, a frase certa é “a base do pagamento está pronta, você vai conseguir testar a compra na semana que vem”.

As ferramentas para isso já existem e custam pouco ou nada:

• Para app mobile em React Native com Expo, uma build de desenvolvimento via EAS ou um canal interno no TestFlight e no Google Play. O cliente instala uma vez e recebe as atualizações.
• Para web em Next.js, um deploy de preview por branch. Cada funcionalidade nova ganha um link que o cliente abre no celular.
• Quando não há nada clicável, um vídeo curto de tela gravado com o que existe. Um minuto de vídeo evita uma hora de reunião.

Na Revo, a gente colocou build semanal na mão de um grupo pequeno de produtores desde o início. O efeito colateral mais valioso não foi a confiança, foi o feedback: bug de fluxo que apareceria na semana dez aparecia na semana três, quando corrigir custava uma tarde. Cliente que testa cedo reclama cedo, e reclamar cedo é barato.

Um canal para urgência, um lugar para decisões

WhatsApp é bom para “o link caiu” e péssimo para “vamos deixar o login por Apple para a fase dois”. Decisão tomada por áudio às 23h desaparece. Três semanas depois, o cliente jura que nunca combinou aquilo, e você não tem como provar.

A solução é um registro de decisões, que pode ser uma página simples no Notion, um documento compartilhado ou um quadro no Trello. Uma linha por decisão, com data: “14/09: login por Apple fica para a fase 2, confirmado pelo cliente”. Esse documento é o que salva a conversa quando o escopo começa a esticar. Ele também é o que permite a alguém entrar no projeto no seu lugar sem precisar de dez reuniões de contexto, e isso pesa muito quando o projeto vem repassado por outra equipe.

Junto com isso, alinhe no kickoff o tempo de resposta. Algo como “respondo mensagens em até um dia útil; problema em produção tem outro caminho, que é este aqui”. Cliente que sabe quando vai ser respondido não manda a mesma pergunta três vezes.

As armadilhas que transformam o reporte em problema

• Reportar em linguagem de dev. “Refatorei o módulo de autenticação” não diz nada para o dono de uma imobiliária. Ele lê isso como “mexeu em algo que já funcionava” e fica com medo. Traduza sempre para o que o usuário final ganha.
• Esconder atraso até a data. Atraso avisado com duas semanas é replanejamento. Atraso avisado no dia é quebra de confiança. Os dois custam o mesmo tempo de desenvolvimento, mas só um custa o cliente.
• Deixar o status virar reunião de uma hora. Status é assíncrono. Reunião só existe quando há decisão a tomar. Uma call de trinta minutos por semana é saudável. Três reuniões não previstas por semana custam meio dia de produção cada uma em troca de contexto, e essa hora não está no seu orçamento.
• Aceitar o “aproveita e faz” dentro do status. O status é exatamente onde nasce o desvio de escopo. O cliente vê a build, empolga e pede “só mais um botãozinho”. Resposta pronta, sem drama: “Anotei. Vou verificar se cabe no escopo atual ou se entra como ajuste separado, e te mando a estimativa até terça”. Você não disse não, e também não trabalhou de graça.
• Prometer data no calor da mensagem. Cliente pergunta “fica pronto sexta?” e você responde “acho que sim” para agradar. Esse “acho” vira contrato na cabeça dele. Responda sempre com o próximo status: “te confirmo na sexta com a build na mão”.

O que isso tem a ver com receber projetos repassados

Quando a OCA repassa um projeto para um parceiro da rede, a competência técnica é a primeira coisa que a gente olha, mas nunca a última. O projeto continua com o nome da OCA na frente do cliente. Então o critério que mais pesa depois do código é exatamente o deste artigo: o dev consegue manter o cliente informado sem que a gente precise ficar no meio?

Um parceiro que manda status semanal, sobe build de teste e registra decisões nos permite repassar o segundo, o terceiro projeto. Um parceiro que entrega bem mas some por dez dias gera um trabalho de gestão que anula a razão de repassar. Se você já faz isso naturalmente, você tem algo que a maioria dos devs tecnicamente bons não tem.

Para deixar honesto o que está em jogo dos dois lados: a OCA espera senioridade técnica na stack do projeto, comunicação previsível e escopo respeitado. O parceiro recebe projeto com escopo já fechado, briefing feito, cliente qualificado e condições de pagamento estruturadas. A prospecção, que é a parte que a maioria dos devs odeia, já foi feita. Ninguém entra na rede automaticamente e ninguém recebe promessa de volume, mas quem entra recebe projeto real, do tipo que aparece no portfólio da OCA.

Entre para a rede de parceiros da OCA

Um passo para esta semana

Independente da rede, faça isto hoje: pegue o projeto que você está tocando agora e mande o primeiro status nos cinco blocos. Marque na agenda o mesmo horário da semana que vem. Se não houver nada clicável para mostrar, grave um vídeo de um minuto da tela e envie junto. Depois, conte quantas mensagens de “e aí, como tá?” você recebe nos próximos sete dias.

Se você já entrega bem, o seu problema não é técnico. Boa parte dele é o cliente não conseguir enxergar o que você entrega. Uma mensagem por semana, no horário certo, com um link para clicar, resolve mais do que qualquer refatoração.