- Defina o “desconto padrão” e o que é exceção (e por quê)
- Crie faixas de desconto com alçadas (vendedor, líder, diretoria) e critérios objetivos
- Exija justificativa curta e padronizada apenas quando sair do padrão
- Registre auditoria: aprovador, data/hora, motivo e anexos
- Mantenha o fluxo dentro do pipeline sem inflar etapas e sem “deal parado”
1) Alinhe o que é desconto e onde ele mora no CRM
Padronize os campos: preço de tabela, preço proposto, valor do desconto (R$) e desconto (%). Evite campo livre. Se houver itens (múltiplos produtos), defina se o desconto é por item, por proposta, por contrato ou por condição comercial.
2) Defina faixas de aprovação com base em regra, não em feeling
Crie 3–5 faixas no máximo (ex.: até X% autoaprovado; de X% a Y% líder; acima de Y% diretoria). Se você não tiver um número “oficial”, comece com faixas provisórias e ajuste com dados reais de margem e win rate ao longo das semanas.
3) Modele o fluxo sem aumentar etapas no pipeline
Em vez de criar uma etapa “Aguardando aprovação” que vira estacionamento, use um status/flag (ex.: “Aprovação pendente”) e um SLA interno. O deal continua na etapa real (negociação/proposta), mas fica visível em relatórios e alertas.
4) Crie a solicitação de desconto como objeto ou registro relacionado
Registre a solicitação separadamente do negócio quando houver reaprovação, histórico e anexos. Campos úteis: faixa solicitada, motivo padronizado, observação curta, concorrente (se aplicável), impacto estimado, anexos (proposta/print), e link para o deal.
5) Padronize motivos de desconto (sem virar campo inútil)
Limite motivos a opções realmente acionáveis (ex.: concorrência, volume, renovação, contrato anual, condição de pagamento). Inclua “Outro (justificar)” para os casos raros. Se a lista virar um cemitério de opções, ninguém usa e você perde o aprendizado.
6) Automatize roteamento e notificações do jeito certo
Ao acionar a solicitação, o CRM deve atribuir automaticamente ao aprovador correto (alçada) e notificar em um canal consistente (e-mail ou tarefas). Evite ping em múltiplos lugares. Se houver férias/substituição, defina regra de backup para não travar.
7) Exija evidência só quando necessário
Para descontos fora do padrão, peça anexos ou justificativa estruturada. Para descontos dentro da faixa autoaprovada, não crie burocracia: registre automaticamente e siga o jogo. Regra prática: evidência é para exceção, não para rotina.
8) Garanta trilha de auditoria e governança
Registre “quem aprovou”, “quando”, “qual desconto” e “qual justificativa”. Bloqueie alterações manuais pós-aprovação (ou registre nova solicitação). Permissões (RBAC/ABAC) devem impedir que o vendedor aprove a si mesmo ou edite o aprovador.
9) Meça o que está travando: tempo de aprovação e taxa de exceção
Crie relatórios simples: solicitações por faixa, tempo médio até aprovação, % de exceções e impacto no ciclo de vendas. Se o tempo de aprovação explodir, o problema geralmente é alçada mal definida, falta de substituto ou solicitação mal preenchida.
Arquitetura recomendada: o que vira campo, o que vira fluxo
A tentação é resolver aprovação de desconto com um campo “Desconto (%)” e uma etapa “Aguardando aprovação”. Funciona por uma semana — até aparecerem reaprovações, descontos por item, e a velha pergunta: “quem aprovou isso?”.
Uma arquitetura robusta costuma separar: (1) valores no deal (o que impacta forecast), (2) a solicitação de desconto (o processo e o histórico), e (3) o controle de acesso (quem pode pedir, aprovar e editar).
| Decisão | Quando usar | Risco comum | Como evitar |
|---|---|---|---|
| Campo no Deal (desconto final) | Quando o desconto é simples e único por negócio | Edição sem rastro após aprovação | Travar edição ou registrar mudanças via nova solicitação |
| Objeto/registro de Solicitação de Desconto | Quando há reaprovação, anexos, múltiplas tentativas e auditoria | Virar burocracia para casos simples | Acionar apenas para exceções e faixas que exigem alçada |
| Etapa no pipeline: “Aguardando aprovação” | Só se aprovação for parte inevitável do processo em quase todos os deals | Deal estacionado e funil distorcido | Preferir status/flag + SLA + alertas |
Modelo de faixas (alçadas) que costuma funcionar na prática
Não existe faixa universal, porque depende de margem, ticket, estratégia e concorrência. Mas existe uma boa prática: poucas faixas, critérios objetivos e exceção bem definida.
Se a empresa ainda não tem política de desconto madura, comece com faixas provisórias e ajuste com base em dados de aprovações e perdas (não em opiniões isoladas).
- Faixa 1: desconto padrão (autoaprovado e registrado automaticamente).
- Faixa 2: desconto moderado (líder aprova; justificativa curta obrigatória).
- Faixa 3: desconto agressivo (diretoria/financeiro aprova; justificativa + evidência).
- Exceção: deals estratégicos (rota especial, com motivo padronizado e auditoria reforçada).
Como evitar o pior cenário: aprovação que vira gargalo e mata o ritmo
A aprovação de desconto dá errado quando mistura três coisas: alçada confusa, formulários longos e ausência de substituição. Resultado: o vendedor para de pedir aprovação do jeito certo e passa a “dar um jeito” fora do CRM.
Dois antídotos funcionam: (1) automação de roteamento por regra clara e (2) um SLA interno realista, acompanhado em relatório. Se a aprovação não acontece no tempo esperado, a falha tem nome: falta de dono e falta de regra.
Perguntas frequentes
Vale a pena criar etapa “Aguardando aprovação de desconto” no pipeline?
Como impedir que o vendedor altere o desconto depois que foi aprovado?
Aprovação de desconto deve envolver Financeiro sempre?
Quais métricas mostram se a política de desconto está saudável?
Leia também
Como criar motivos de perda e ganho no CRM (sem virar campo inútil)
Guia prático para desenhar, configurar e governar motivos de perda/ganho no CRM, com lista de categorias, regras de preenchimento e como transformar isso em ação comercial.
Ler →
Como criar campos obrigatórios no CRM sem travar o time (e sem virar guerra com vendas)
Guia prático para definir quais campos devem ser obrigatórios no CRM, em que etapa exigir, como validar sem atrapalhar o vendedor e como manter qualidade de dados com governança leve.
Ler →
Como criar alertas de deal rotting no CRM (sem virar spam nem microgestão)
Passo a passo para configurar alertas de deal rotting no CRM com regras por etapa, prazos realistas, escalonamento e métricas que evitam ruído e microgestão.
Ler →
Como configurar permissões e perfis no CRM sem travar o time (e sem virar terra de ninguém)
Guia prático para definir perfis, papéis e permissões no CRM com segurança e fluidez: o que restringir, o que liberar e como auditar sem burocracia.
Ler →