Como registrar alterações pedidas pelo cliente sem perder prazo, preço e versão

O cliente aprova a primeira versão.

No dia seguinte pede:

“Só muda essa parte.”

Depois vem outra mensagem.

E mais uma.

Uma semana depois, ninguém sabe se o projeto atual ainda corresponde ao orçamento original, qual versão está valendo e se o prazo continua possível.

O problema não é o cliente pedir mudança. Projetos mudam.

O problema é a mudança entrar na execução antes de ser registrada e avaliada.

Pedido de alteração precisa virar uma decisão: o que muda, qual impacto, quem aprova e qual versão passa a valer.

Correção, revisão e mudança de escopo não são iguais

Antes de reagir, classifique.

Correção

Algo entregue não corresponde ao que foi combinado.

Exemplos:

• erro de digitação;
• arquivo faltando;
• cor diferente do briefing aprovado.

Revisão prevista

O contrato ou proposta já inclui rodadas de ajuste.

Exemplo:

• duas rodadas de correção em layout.

Mudança de escopo

O cliente pede algo que não fazia parte do combinado.

Exemplos:

• acrescentar uma nova página;
• trocar público;
• produzir material extra;
• refazer estrutura aprovada;
• adicionar formato.

Sem essa distinção, todo pedido parece “pequeno”.

Volte ao escopo original

Antes de responder:

1. abra a proposta;
2. confira entregáveis;
3. confira limites;
4. veja o que foi aprovado;
5. veja revisões previstas;
6. identifique o ponto exato que está mudando.

A Asana define escopo como os limites que estabelecem metas, prazos e entregáveis. Independentemente da ferramenta, essa lógica ajuda autônomos a separar mudança legítima de expectativa não registrada.

Registre cinco informações

Toda mudança relevante precisa responder:

1. o que foi pedido;
2. quem pediu;
3. quando;
4. qual impacto;
5. qual foi a decisão.

Exemplo:

26/08 — cliente pediu incluir página “Sobre”. Não estava no escopo. Impacto: +2 dias e R$ 250. Aprovado por WhatsApp às 15h40. Novo prazo: 02/09.

Isso evita discutir memória depois.

Não execute antes de avaliar impacto

Um pedido pode mexer em:

• prazo;
• custo;
• qualidade;
• dependência;
• ordem;
• revisão;
• material já aprovado.

Mesmo quando a mudança parece simples.

A documentação sobre pedidos de alteração da Asana destaca justamente a necessidade de analisar impacto em entregáveis, preço e cronograma antes da implementação.

Avalie prazo

Pergunte:

• muda a quantidade de trabalho?
• exige nova aprovação?
• depende de arquivo do cliente?
• desfaz algo pronto?
• muda a ordem das tarefas?
• ocupa tempo reservado a outro projeto?

Não responda automaticamente:

“Sem problema.”

Se existe impacto, diga.

Avalie preço

Mudança de escopo pode exigir novo valor.

Mas nem toda alteração é cobrança adicional.

Use critérios:

• estava incluída?
• é correção de erro seu?
• faz parte da rodada?
• acrescenta entregável?
• aumenta horas?
• exige terceiro?
• substitui algo ou adiciona?

O objetivo não é cobrar por cada clique. É impedir que o projeto cresça sem que ninguém perceba.

Avalie dependências

Exemplo:

O cliente pede trocar todas as fotos.

Isso pode exigir:

• receber novas imagens;
• revisar licença;
• refazer cortes;
• alterar layout;
• refazer exportação;
• repetir revisão mobile.

O pedido é uma frase.

O impacto é uma cadeia.

Confirme por escrito

Depois de avaliar, devolva:

“Consigo incluir a nova página. Ela não fazia parte do escopo inicial. O acréscimo é de R$ 250 e o prazo passa de 31/08 para 02/09. Se estiver de acordo, me confirme por aqui que atualizo o projeto.”

A confirmação precisa ser simples.

Não esconda alteração importante num áudio difícil de localizar.

Atualize o registro principal

WhatsApp pode guardar a conversa.

O projeto precisa guardar a decisão.

Atualize:

• escopo;
• prazo;
• valor;
• versão;
• checklist;
• status.

Assim, quando voltar ao trabalho, você não precisa reler tudo.

Veja também Como organizar pedidos, prazos e entregas sem depender da memória.

Controle versões

Evite:

• final.pdf;
• final2.pdf;
• final-agora.pdf;
• final-certo.pdf.

Use padrão simples:

cliente-projeto-v01

cliente-projeto-v02

cliente-projeto-aprovado

Ou data quando fizer sentido.

O importante é saber:

• qual é a atual;
• qual foi enviada;
• qual foi aprovada.

Não apague a versão aprovada anterior imediatamente

Se a mudança for contestada depois, a versão anterior ajuda a reconstruir a decisão.

Guarde de forma organizada enquanto houver necessidade do projeto.

Depois aplique política de arquivo e descarte adequada.

Mudanças em vários canais precisam ser consolidadas

Exemplo:

• uma no WhatsApp;
• outra no e-mail;
• comentário no Instagram;
• áudio;
• ligação.

Responda:

“Vou consolidar todos os ajustes numa única lista e te envio para confirmação.”

Isso reduz:

• duplicidade;
• contradição;
• esquecimento;
• retrabalho.

O guia Atendimento em vários canais aprofunda essa centralização.

Crie rodadas de revisão

Em trabalhos criativos, defina:

• quando o cliente envia ajustes;
• como envia;
• quantas rodadas existem;
• quando a rodada é considerada consolidada;
• o que acontece com pedidos posteriores.

Uma rodada não precisa significar burocracia.

Pode ser:

“Envie todos os ajustes desta versão numa única mensagem até quarta.”

Como dizer que saiu do escopo

Não use tom defensivo.

Em vez de:

“Isso não estava no contrato.”

Prefira:

“A proposta atual cobre X e Y. O pedido de Z acrescenta uma entrega nova. Posso incluir como adicional por R$ X, com novo prazo em Y.”

Você descreve a mudança.

Quando substituir em vez de acrescentar

Às vezes o cliente quer algo novo, mas aceita retirar outro item.

Exemplo:

trocar dois posts por um vídeo.

Se o esforço for equivalente e fizer sentido, o escopo pode ser reequilibrado.

Registre.

E quando o cliente pede urgência depois da mudança?

Mudança pode consumir a folga que existia no cronograma.

Se o cliente quer manter o prazo original, existem três possibilidades:

• reduzir outro item;
• aprovar custo de urgência quando isso fizer sentido e tiver sido combinado;
• aceitar novo prazo.

O que não funciona é fingir que o novo trabalho não ocupa tempo.

Caso completo

Uma copywriter foi contratada para página de vendas, três e-mails e uma rodada de revisão.

Cliente aprova estrutura.

Depois pede quatro anúncios, nova persona e mais dois e-mails.

A profissional não começa.

Registra:

novos entregáveis fora do escopo.

Avalia impacto.

Propõe:

• adicional;
• novo prazo;
• ou manter escopo original.

Cliente escolhe adicionar apenas dois anúncios.

A decisão é registrada.

O projeto continua claro.

Checklist de mudança

• pedido registrado;
• escopo original conferido;
• tipo classificado;
• impacto em prazo avaliado;
• impacto em preço avaliado;
• dependências avaliadas;
• decisão comunicada;
• cliente confirmou;
• controle atualizado;
• versão correta identificada.

O que evitar

• começar antes da aprovação;
• dizer “é rapidinho” sem avaliar;
• cobrar adicional por correção que é responsabilidade sua;
• aceitar alteração por áudio e esquecer;
• manter arquivos sem versionamento;
• mudar prazo sem comunicar;
• executar dez mensagens soltas como se fossem uma rodada organizada.

Plano de ação para hoje

1. Escolha um projeto ativo.
2. Abra o escopo original.
3. Liste mudanças já pedidas.
4. Classifique: correção, revisão prevista ou mudança de escopo.
5. Registre impacto.
6. Confirme qualquer decisão ainda ambígua.
7. Renomeie a versão atual de forma inequívoca.

Como controlar mudanças sem burocracia excessiva

Crie um registro de mudança independente do arquivo final

Não confie apenas no nome da versão.

Mantenha um quadro:

Esse histórico mostra por que o projeto mudou.

Defina uma pessoa que aprova

Em empresas, várias pessoas podem comentar.

Pergunte no início:

quem dá a aprovação final?

Se três pessoas mandam pedidos independentes, você pode terminar executando ordens conflitantes.

Procedimento:

1. receber comentários;
2. consolidar;
3. devolver lista;
4. aprovação pelo responsável;
5. executar.

Trate mudança urgente como exceção explícita

Cliente pode pedir:

“Preciso hoje.”

Antes de aceitar, verifique:

• o que será interrompido;
• impacto em outros clientes;
• custo de prioridade;
• possibilidade real;
• qualidade.

Urgência do cliente não cria capacidade automaticamente.

Se aceitar, registre prazo especial.

Evite “ajuste ilimitado” por ausência de regra

Quando proposta não define revisão, cada nova mensagem pode parecer incluída.

Para próximos trabalhos, esclareça:

• quantidade de rodadas;
• prazo para enviar ajustes;
• forma de envio;
• o que é nova entrega.

Isso não torna atendimento rígido. Torna expectativa previsível.

Mudança também pode reduzir o escopo

Nem toda alteração acrescenta.

Cliente pode decidir:

• retirar uma página;
• reduzir quantidade;
• abandonar um formato.

Registre o efeito no preço e prazo quando aplicável.

Não presuma que redução de trabalho gera automaticamente reembolso ou alteração contratual; siga o que foi combinado.

Como documentar por e-mail depois de uma ligação

Depois da conversa:

“Confirmando o que combinamos na ligação de hoje: vamos substituir X por Y, manter o valor e mover a entrega para sexta. Se algo estiver diferente do que você entendeu, me avise antes de eu seguir.”

Isso transforma fala em registro recuperável.

Crie um limite de “mudanças em análise”

Não comece tudo ao mesmo tempo.

Use status:

• solicitado;
• em análise;
• aguardando aprovação;
• aprovado;
• executando;
• concluído.

Uma alteração só entra na fila de execução depois de aprovada.

Caso de conflito entre versões

Cliente comenta uma versão antiga.

Não aplique cegamente.

Responda:

“Esse comentário está sobre a v02. A versão atual é v04 e já incorpora duas alterações posteriores. Vou comparar antes para não reintroduzir algo que já foi removido.”

Controle de versão evita regressão.

Indicador para melhorar propostas futuras

Se muitos projetos recebem a mesma mudança fora do escopo, talvez ela deva entrar na oferta padrão.

Exemplo:

todos pedem adaptação mobile adicional.

Talvez sua proposta não esteja descrevendo a entrega com clareza.

Mudança registrada vira aprendizado comercial.

Defina um orçamento de mudança

Em projetos maiores, você pode reservar:

• horas;
• rodada;
• quantidade;
• percentual de contingência.

Isso não significa vender “alteração ilimitada”.

Significa reconhecer que mudança existe.

Faça estimativa de impacto antes de responder

Uma técnica simples:

• menos de 30 min;
• até 2 h;
• meio dia;
• um dia;
• mais de um dia.

Use para avaliar.

Não envie ao cliente necessariamente.

É ferramenta interna.

Registre o que não mudou

Ao aprovar uma alteração, confirme:

os demais itens permanecem conforme proposta.

Isso evita interpretar a nova mensagem como reabertura do projeto inteiro.

Mudança de direção estratégica

Algumas alterações são tão grandes que deveriam virar novo projeto.

Sinais:

• público mudou;
• produto mudou;
• objetivo mudou;
• canal mudou;
• mais de metade do trabalho precisa ser refeita.

Nesses casos, pare e reproponha.

Como lidar com retrabalho causado por atraso do cliente

Cliente entrega material depois do prazo.

Se isso afeta cronograma:

“Recebi hoje. Como a janela original passou, o novo prazo é X.”

Não tente absorver automaticamente.

Registre.

Aprovação tácita é arriscada

Evite:

“Se não responder, vou considerar aprovado.”

A menos que isso esteja claramente previsto e seja adequado ao contexto.

Prefira confirmação positiva em etapas críticas.

Use uma lista de decisões abertas

Além das mudanças, registre decisões pendentes:

• foto;
• título;
• preço;
• data;
• cor.

Projeto parado muitas vezes não precisa de mais trabalho.

Precisa de resposta.

Encerramento

Ao final:

1. versão final;
2. escopo entregue;
3. pendências encerradas;
4. aprovação;
5. arquivos;
6. data.

Isso cria corte claro entre projeto e pós-venda.

Para projetos recorrentes, transforme o histórico de alterações em insumo para a próxima proposta. Se clientes pedem sempre uma segunda adaptação, talvez o escopo deva incluí-la ou excluí-la de modo mais explícito. Se a primeira rodada traz mudanças estruturais demais, talvez a etapa de briefing esteja superficial. O registro permite melhorar o processo anterior à execução.

Também vale definir uma regra para materiais que chegam depois de uma aprovação. Se uma nova foto, texto ou dado modifica uma peça já concluída, trate isso como alteração e avalie impacto. “Só trocar o arquivo” pode exigir nova exportação, nova revisão e nova publicação.

Perguntas frequentes

Toda alteração aumenta preço?

Não.

Preciso de aprovação por escrito?

Registre principalmente quando muda escopo, prazo ou valor.

WhatsApp serve?

Serve para confirmar, mas atualize também o controle principal.

Muitas mudanças pequenas?

Consolide em rodadas.

Pedido fora do escopo?

Explique e apresente opções.

Fontes consultadas

• Asana — Guia rápido para definir o escopo do projeto
• Asana — Formulários de pedidos de alteração
• Asana — Modelo de formulário para pedidos de mudança
• Asana — O que são desvios de escopo

Resumo prático

• mudança é normal;
• mudança não registrada vira confusão;
• compare sempre com escopo;
• avalie prazo, preço e dependências;
• peça confirmação;
• atualize o registro principal;
• controle versões;
• consolide alterações;
• trate mudança de escopo como nova decisão.

Um projeto não precisa permanecer idêntico ao primeiro dia. Ele precisa permanecer rastreável quando muda.

Vídeo relacionado

Como tratar as mudanças em projetos

▶Reproduzir no site

Fonte:Robson Camargo