Comunicação com cliente no freelance dev: o update semanal que acaba com o “como tá?” no WhatsApp (e como dar notícia ruim sem perder o projeto)

Você entrega bem. O código é limpo, o deploy roda sem susto e as tarefas fecham no prazo. Mesmo assim, na terceira semana de projeto, o cliente manda “e aí, como tá?” no WhatsApp às 22h de uma terça. Na quinta, ele liga. Na sexta, pede uma reunião “só para alinhar”. O projeto não está atrasado, mas na cabeça dele está. Aí aparece o primeiro imprevisto de verdade: uma API que não faz o que a documentação prometia, ou uma tela que dobrou de complexidade. Nessa hora você já não tem crédito com o cliente. A conversa vira cobrança, o tom muda e um projeto que ia bem termina azedo. O problema não é técnico. É comunicação com o cliente, e quase ninguém ensina isso para dev.

Por que o cliente acha que o projeto está atrasado quando não está

Cliente não técnico não vê código. Ele não abre o repositório, não lê o PR e não sabe que você passou dois dias resolvendo autenticação. O que ele vê é silêncio. Para quem está pagando, silêncio vira ansiedade, e ansiedade vira microgestão.

Vou te falar como funciona do lado de quem recebe os leads: quando um cliente chega à OCA depois de uma experiência ruim com outro fornecedor, a queixa mais comum não é “o código ficou ruim”. É “o dev sumiu”, “eu nunca sabia em que pé estava”, “descobri o atraso no dia da entrega”. Muitas vezes o código nem era ruim. A relação quebrou antes.

E isso custa dinheiro para você. Cada “como tá?” respondido no meio de uma tarefa leva de 15 a 25 minutos para você retomar o foco. Cinco interrupções por semana dão entre 1h15 e 2h perdidas. Em um projeto de 10 semanas, são 12 a 20 horas que você não fatura. A conta é simples: com a hora entre R$ 120 e R$ 200, isso dá de R$ 1.440 a R$ 4.000 jogados fora por falta de um processo de comunicação.

O update semanal: o modelo de 5 blocos que a OCA usa

A solução não é responder mais rápido. É responder antes de perguntarem. Um update escrito, com dia e hora fixos, acaba com a maior parte das mensagens de “como tá?”. O cliente aprende que toda sexta, às 16h, recebe o estado do projeto. Ele para de perguntar porque sabe quando vai saber.

O modelo tem cinco blocos:

1. O que foi entregue. Em linguagem de negócio e com link para ver funcionando: ambiente de staging, build de teste do app ou um vídeo de 2 minutos gravado da tela.
2. O que vem na próxima semana. De três a cinco itens, no máximo.
3. O que depende do cliente. Acessos, textos e aprovações de layout, com data limite. É o bloco que mais protege o seu prazo.
4. Riscos. Verde, amarelo ou vermelho, com uma frase de explicação. Se está tudo verde, diga isso.
5. Prazo e orçamento. Quanto do previsto já foi consumido e se a data final continua de pé.

Um exemplo, no tamanho real:

Semana 4 de 10. Entregue: cadastro e login funcionando no staging (link) e tela de pedidos com filtros (vídeo de 2 min). Próxima semana: carrinho e cálculo de frete. Depende de você: chave de produção do gateway de pagamento até quarta, 14/10. Riscos: amarelo. A API de frete está instável em homologação, sigo com dados simulados e testo de novo na segunda. Prazo: mantido para 20/11. Horas: 148 de 380 previstas.

Escrever isso leva de 20 a 30 minutos por semana. É o tempo mais bem pago do seu projeto.

Canal certo para cada coisa

WhatsApp serve para urgência e aviso rápido. Decisão vai por escrito, em e-mail ou em um documento compartilhado, de preferência a ferramenta que o cliente já usa. O motivo é prático: se um dia houver discussão sobre escopo ou prazo, um áudio de 3 minutos no WhatsApp não serve como registro. Uma prática que funciona bem: mandar o update por e-mail e um aviso curto no WhatsApp dizendo “update da semana no seu e-mail”.

Mesmo na Revo, que é produto nosso, toda release que mexe no checkout sai com uma nota escrita do que mudou. Um checkout que converte 90% não aguenta surpresa, nem para o próprio time.

Como dar notícia ruim para o cliente sem perder o projeto

Todo projeto tem pelo menos uma notícia ruim. A integração com o ERP não oferece o endpoint de que você precisava. A Apple rejeitou o build. A estimativa da tela de relatórios ficou pela metade. Se o cliente continua confiando em você, não é por causa da notícia. É por quando e como ela chega.

A regra de timing é dura. Atraso avisado com duas semanas de antecedência é ajuste de plano. Atraso avisado no dia da entrega é quebra de confiança. Avise assim que souber, mesmo sem ter a solução pronta.

Para o formato, use quatro passos:

1. O fato. Sem rodeio e sem jargão.
2. O impacto em números. Quantos dias, quantos reais, qual funcionalidade.
3. As opções. Duas ou três, cada uma com o seu custo.
4. A sua recomendação. O cliente contratou um sênior justamente para ter opinião.

Descobrimos hoje que o ERP de vocês não tem API para atualizar estoque, só para consultar. Isso afeta a sincronização automática prevista para a semana 7. Temos três caminhos: (1) sincronizar por planilha exportada uma vez por dia, sem custo extra e sem atraso; (2) integrar pelo banco de dados do ERP, com mais 5 dias de trabalho e cerca de R$ 3.500; (3) pedir ao fornecedor do ERP que libere o endpoint, com prazo dependente deles. Recomendo a opção 1 agora e a 3 em paralelo. Consegue me responder até quinta?

Repare que a mensagem não pede desculpa três vezes nem culpa o ERP. Ela entrega o problema já transformado em uma decisão.

Explicar bug em produção para quem não é técnico

Quando algo quebra em produção, o cliente quer saber quatro coisas, nesta ordem: o que aconteceu, quem foi afetado, se já está resolvido e o que impede que aconteça de novo. Responda as quatro em um parágrafo: “Um erro no cálculo de desconto afetou 12 pedidos entre 14h e 15h30. Já corrigimos e os valores foram ajustados. Adicionamos um teste automático para esse cálculo.” Ninguém precisa saber que foi uma race condition.

As armadilhas de comunicação que queimam o freelancer

• Responder tudo na hora. Parece bom atendimento, mas ensina o cliente que você está sempre de plantão. Combine no início: mensagens respondidas em até 4 horas úteis, e urgência é sistema fora do ar ou pagamento parado.
• Decisão tomada em áudio. O cliente pede uma mudança em um áudio de 4 minutos, você faz, e na entrega ele não lembra de ter pedido. Transforme toda decisão em uma linha escrita: “confirmando o que combinamos no áudio: ...”.
• O eterno “tá quase pronto”. Uma tarefa que passa três semanas 90% pronta é o que mais destrói confiança. Se você não sabe quando termina, diga o que falta e quando vai saber.
• Segurar o problema para resolver no fim de semana. Você vira a noite, não resolve, e o cliente descobre o problema na segunda junto com o atraso. Agora são dois problemas.
• Reunião semanal de uma hora sem pauta. Se o update escrito está bom, a call pode ter 20 minutos e servir só para decisões. Reunião longa sem pauta é hora não faturada para os dois lados.

O que a OCA olha na comunicação antes de repassar um projeto

A OCA aparece no Google e nas IAs quando alguém procura software house ou desenvolvimento de app no Brasil. Isso traz dezenas de leads por dia, mais do que o nosso time consegue atender. Por isso estamos montando uma rede de parceiros: devs e pequenos times sêniores que recebem projetos já qualificados e com escopo conversado.

Quando a gente repassa um projeto, o cliente escolheu a OCA. É o nosso nome que está em jogo. Então, além da parte técnica, olhamos exatamente o que este artigo descreve:

• Você responde dentro do prazo que combinou?
• Manda update escrito sem ninguém precisar pedir?
• Avisa risco cedo, com opções e recomendação?
• Consegue explicar uma decisão técnica para alguém que não programa?

Em troca, o parceiro recebe o que mais falta para quem trabalha sozinho: projeto que chega sem você precisar prospectar, cliente já filtrado e escopo discutido antes. Não prometemos volume nem entrada garantida na rede. Cada projeto vai para o perfil certo, e a avaliação é feita com calma. Mas se você já entrega bem, o seu problema não é técnico, é distribuição. E é a comunicação que faz um cliente repassado virar o próximo projeto. Para ver o tipo de trabalho que fazemos, dá uma olhada nos projetos da OCA em produção.

Seu próximo passo esta semana

Independentemente da rede, faça isto até sexta: pegue o projeto em que você está trabalhando agora e mande ao cliente o primeiro update no modelo de 5 blocos. Defina um dia fixo para os próximos e avise no fim da mensagem: “a partir de agora, toda sexta às 16h você recebe este resumo”. Depois conte quantas mensagens de “como tá?” chegam na semana seguinte. Esse número costuma cair rápido, e o seu foco volta junto.

Se você já trabalha assim e quer receber projetos que chegam pela máquina de demanda da OCA, a conversa começa aqui:

Entre para a rede de parceiros da OCA