Como recusar um pedido fora do escopo sem perder o cliente?

Não recuse: precifique. Diga que dá para fazer, mostre o impacto em horas e prazo e deixe a decisão com o cliente. Transformar "não" em "sim, custa X e atrasa Y" mantém a relação e protege o projeto.

E se o cliente disser que aquilo já estava incluso?

Volte ao documento de escopo assinado. Se estiver lá, é sua responsabilidade entregar. Se não estiver, mostre a lista original e trate como aditivo, é exatamente para isso que a lista nominal de entregas existe.

Quantas mudanças pequenas eu devo absorver de graça?

Um pequeno espaço de cortesia (algo como 5% do total de horas) evita atrito por bobagem e é bom negócio. Passando disso, registre cada item, mesmo os pequenos, o acúmulo de "coisinhas" é o que mais consome margem.

Escopo que cresce: como lidar sem perder o cliente

Escopo cresce em praticamente todo projeto de software, e isso não é falha do cliente nem sua: é o efeito natural de ver o sistema funcionando e entender melhor o que se quer. O que quebra o projeto não é a mudança, é a mudança executada sem registro, sem prazo novo e sem valor novo. A solução é um processo simples e aplicado desde o primeiro dia, não uma conversa difícil no terceiro mês.

Como reconhecer que o escopo está crescendo

Os sinais aparecem cedo e são quase sempre os mesmos:

"Já que você está mexendo aí...", a frase que mais custa dinheiro na indústria.
Pedidos que chegam por canais informais: áudio de WhatsApp, comentário em reunião, mensagem solta.
Requisitos que "sempre existiram" mas não estão em lugar nenhum escrito.
Uma funcionalidade que era uma tela virando um módulo com permissões, relatório e exportação.
Novos participantes na reunião trazendo demandas de outra área.
Você trabalhando mais horas por semana do que estimou, sem mudança formal nenhuma.

Se você não consegue dizer, hoje, quantas horas já foram consumidas por itens fora da lista original, o escopo já está crescendo sem controle.

O processo que resolve: registrar, estimar, aprovar

Toda solicitação nova passa pelo mesmo caminho, sem exceção:

Receber sem julgar. "Boa ideia, vou avaliar o impacto e te retorno." Nunca diga sim na hora nem não na hora.
Registrar por escrito. Um item numerado, com descrição do que o cliente quer e por quê.
Estimar horas e impacto no prazo. Os dois juntos. Prazo importa mais que valor para muitos clientes.
Enviar para aprovação. Curto: item, valor, prazo adicional, data limite para decidir.
Só executar depois do aceite escrito. E-mail respondido com "aprovado" basta.

O ponto psicológico importante: você não está dizendo não. Está devolvendo a decisão para quem paga, com a informação necessária. Cliente racional decide bem quando enxerga o custo.

Como comunicar sem soar burocrático

A forma importa tanto quanto o processo. Compare:

Ruim: "Isso está fora do escopo."
Bom: "Dá para fazer. São cerca de 12 horas e empurra a entrega em uma semana. Fica R$ X. Quer que eu inclua agora ou deixamos para a fase 2?"

A segunda versão faz três coisas: confirma que é possível, mostra o custo real e oferece uma alternativa que não é "não". A opção "fase 2" é a mais útil do repertório, ela preserva a ideia do cliente sem estourar o projeto atual.

Faixas de impacto: como classificar cada pedido

Tipo de mudança	Exemplo	Tratamento
Ajuste trivial	Trocar texto, cor, ordem de campo	Absorver, dentro da cortesia
Refinamento	Melhorar validação de um formulário já previsto	Absorver se pequeno; registrar sempre
Item novo pequeno	Um filtro, um campo com regra, uma exportação	Aditivo simples, aprovação por e-mail
Item novo grande	Novo perfil de usuário, novo relatório com regras	Aditivo formal, com prazo revisado
Mudança estrutural	Trocar regra de negócio central, nova integração	Renegociar cronograma e possivelmente o contrato

Registrar até o que você absorve de graça tem um efeito prático: no fim do projeto, você mostra uma lista de itens entregues sem cobrança. Isso constrói mais boa vontade do que qualquer desconto.

O papel do documento de escopo original

Nada disso funciona sem a base: uma lista nominal do que está incluso e, principalmente, do que está fora. Sem esse documento, toda discussão vira memória contra memória, e quem perde é quase sempre o dev.

O documento não precisa ser longo. Precisa ser específico: telas por nome, integrações por sistema, perfis de usuário, relatórios, e uma seção "não incluso nesta fase" com os itens que você já sabe que vão ser pedidos.

Reunião semanal curta resolve mais que contrato longo

A maior parte do aumento descontrolado de escopo vem de falta de conversa, não de má-fé. Uma reunião de 20 a 30 minutos por semana, com pauta fixa, evita quase todo o problema:

O que foi entregue desde a última.
O que está em andamento.
Itens novos solicitados e o status de cada um (estimando, aguardando aprovação, aprovado, na fase 2).
Riscos e pendências do lado do cliente.

Publique isso em um e-mail curto depois da reunião. Esse e-mail semanal é a melhor prova documental que existe, e não parece burocracia porque tem função óbvia.

Quando o cliente não aceita o processo

Existe o cliente que se recusa a formalizar mudanças e trata cada aditivo como má vontade. Nesse caso, você tem três caminhos:

Mudar o modelo de cobrança para hora ou retainer mensal. Se o escopo é aberto por natureza, o preço tem que ser aberto também.
Reduzir a exposição: contratos menores, entregas mais curtas, ciclos de dois a quatro meses em vez de um projeto de nove.
Encerrar com elegância ao fim do escopo atual, sem renovar.

Absorver escopo indefinido em preço fechado não é dedicação, é subsídio. E cliente que aprende que "coisinhas" saem de graça vai pedir cada vez mais, sem perceber que está causando problema.