# Workflow de aprovação por alçada: fim do e-mail perdido

> Workflow de aprovação por alçada: como definir faixas por valor, área e tipo de despesa, com substitutos, prazos e uma trilha que resiste à auditoria.

Fonte: https://pervian.tech/blog/workflow-de-aprovacao-por-alcada · Pervian Tech · publicado em 2026-10-01

O pedido de compra está parado há seis dias. O comprador jura que mandou para o diretor; o diretor diz que não recebeu. Depois de procurar, alguém acha o e-mail na caixa de spam, ou numa conversa de WhatsApp soterrada por cinquenta mensagens de outro assunto. Quando a aprovação finalmente sai, vem como "ok, pode seguir", sem dizer qual versão do orçamento foi aprovada.

Seis meses depois, a auditoria pergunta quem autorizou aquele contrato, com base em qual proposta e se a pessoa tinha poder para aprovar aquele montante. A resposta envolve vasculhar caixas de e-mail de quem já saiu da empresa e torcer para que ninguém tenha apagado nada.

Um **workflow de aprovação por alçada** resolve esse problema com três coisas: uma regra escrita de quem aprova o quê, um sistema que encaminha cada pedido para a pessoa certa automaticamente e um registro que não se perde. Este texto mostra como desenhar cada uma delas.

## Resposta curta: como montar um workflow de aprovação por alçada

1. **Liste os tipos de pedido** que exigem aprovação: compra, despesa, desconto comercial, contrato, pagamento fora do fluxo.
2. **Defina as faixas** de cada tipo, por valor e por risco, e quem aprova em cada faixa.
3. **Combine os critérios**: valor, centro de custo, área e categoria do gasto decidem a rota, não só o montante.
4. **Configure substitutos e prazos**: toda alçada tem um suplente, e todo pedido parado escala sozinho depois de um tempo definido.
5. **Leve a aprovação para onde o aprovador está**, com o contexto completo na tela, inclusive no celular.
6. **Registre tudo**: quem pediu, quem aprovou, quando, qual versão do documento e com qual regra vigente.

## Aprovação por e-mail e WhatsApp: onde ela falha

E-mail e WhatsApp funcionam para conversar. Para aprovar, falham por motivos estruturais, não por falta de disciplina:

- **Não existe regra, só costume.** Quem aprova é quem o solicitante lembrou de copiar. Se ele copiou o gerente errado, o pedido é aprovado por alguém sem alçada e ninguém percebe.
- **O documento aprovado não está amarrado à aprovação.** O "pode fechar" responde a uma mensagem que tinha um anexo. Se o fornecedor mandou um segundo orçamento depois, qual deles foi aprovado?
- **Não há fila.** O aprovador não tem uma lista do que está pendente com ele. Tem uma caixa de entrada misturada com propaganda, cobrança e conversa de equipe.
- **Ninguém sabe onde o pedido está**, nem quanto tempo ele esperou.
- **A prova é frágil.** Mensagem apagada, celular trocado, conta de e-mail desativada quando o funcionário sai. A evidência some junto.

Um auditor não quer saber se alguém disse "sim". Ele quer saber **se a pessoa que disse sim tinha poder para isso, sobre qual documento e em que momento**. Mensagem solta não responde às três perguntas juntas.

## O que é alçada e como definir as faixas

Alçada é o **limite de autoridade** de uma pessoa ou cargo para aprovar um tipo de pedido. O supervisor aprova compras de material de consumo até um teto; acima dele, sobe para o gerente; acima de outro teto, para a diretoria; e alguns casos vão sempre ao conselho ou aos sócios, independentemente do valor.

Na prática, a política de alçadas é uma tabela. Um ponto de partida (os limites de cada faixa são definidos pela sua empresa):

| Faixa | Compras de consumo | Investimento (ativo) | Desconto comercial | Contratos |
|---|---|---|---|---|
| Faixa 1 | Coordenador da área | Gerente da área | Vendedor, até o teto da tabela | Gerente da área |
| Faixa 2 | Gerente da área | Diretor da área | Gerente comercial | Diretor da área + jurídico |
| Faixa 3 | Diretor da área | Diretoria financeira | Diretor comercial | Diretoria + jurídico |
| Faixa 4 | Diretoria financeira | Sócios ou conselho | Diretor comercial + financeiro | Sócios ou conselho |

Algumas decisões que precisam estar claras antes de qualquer linha de código:

- **Os limites são cumulativos ou exclusivos?** Num modelo, o pedido da faixa 3 passa por coordenador, gerente e diretor, em sequência. No outro, vai direto ao diretor. O primeiro dá mais controle; o segundo, mais velocidade. Uma combinação possível é usar o primeiro para investimento e o segundo para compras de consumo.
- **O valor considerado é o do pedido ou o do compromisso total?** Um contrato mensal de doze meses precisa ser avaliado pelo total, senão cabe sempre na menor faixa.
- **Como evitar o fracionamento?** Dividir uma compra grande em várias pequenas para escapar da alçada é um truque conhecido. O sistema pode somar pedidos do mesmo fornecedor e da mesma categoria num período e tratar o conjunto como um pedido só para fins de alçada.

A tabela deve ser aprovada pela diretoria e versionada: o sistema precisa saber qual versão valia na data de cada aprovação.

## Regras por valor, centro de custo e tipo de pedido

Valor sozinho não basta: o mesmo montante pode ser rotina para a manutenção e fora do padrão para o marketing. A rota costuma combinar quatro critérios:

### Valor

Define a faixa e, portanto, o nível hierárquico. A política precisa dizer qual valor conta: com ou sem impostos e frete, e, em compras em moeda estrangeira, convertido por qual cotação e em qual data. Sem essa definição, o mesmo pedido cai em faixas diferentes conforme quem o preenche.

### Centro de custo e área

Define **de quem** é a alçada. Um pedido da filial de Curitiba vai para o gerente de Curitiba, não para o de Recife. Isso exige um cadastro correto de centros de custo e responsáveis, que costuma ser a primeira limpeza do projeto.

### Tipo de pedido e categoria do gasto

Algumas categorias pedem aprovadores adicionais, independentemente da faixa:

- **Tecnologia** (software, licenças, equipamentos): passa pela área de TI, por segurança e padronização.
- **Serviços com acesso a dados pessoais**: passa pelo responsável por privacidade, porque o contrato precisa tratar da LGPD. Os termos exatos devem ser validados com o seu jurídico.
- **Obras e reformas**: passa pela engenharia ou manutenção.
- **Contratos com prazo longo ou multa de rescisão**: passa pelo jurídico.

### Condições de exceção

São regras que forçam um passo extra: fornecedor novo não homologado, compra sem cotação concorrente, pedido fora do orçamento. Se você já estrutura o processo de compras, essas exceções se encaixam no fluxo descrito em [sistema de cotação e compras](https://pervian.tech/blog/sistema-de-cotacao-e-compras), em que a aprovação é uma etapa entre o mapa comparativo e o pedido.

O resultado é uma **matriz de aprovação**: dado um pedido, o sistema calcula os aprovadores e a ordem. O solicitante não escolhe para quem enviar, e essa é a maior mudança em relação ao e-mail.

## Substitutos, férias e prazos de aprovação

O fluxo mais bem desenhado trava no primeiro dia de férias do diretor. Para isso não acontecer, o sistema precisa suportar três mecanismos.

**Substituto cadastrado.** Cada aprovador indica um suplente por período, com data de início e fim. Durante esse intervalo, os pedidos vão ao suplente, e a trilha registra que a aprovação foi feita por delegação, em nome de quem e por qual período. O suplente precisa ter alçada igual ou superior; o sistema não deve permitir delegar para alguém de nível inferior.

**Prazo por etapa.** Cada passo tem um tempo esperado, por exemplo um ou dois dias úteis, definido pela empresa conforme o tipo de pedido. Passado o prazo, o sistema lembra o aprovador; passado um segundo prazo, escala para o nível acima ou para o suplente. O pedido nunca fica parado sem que alguém saiba.

**Regras de urgência.** Pedido urgente tem prazo menor, mas não pula etapa. Urgência que pula alçada vira o caminho padrão.

Decida também os casos menos óbvios:

- O aprovador **pede ajuste**: o pedido volta ao solicitante e, ao ser reenviado, recomeça da etapa em que parou ou do início?
- O aprovador é **o próprio solicitante**: o sistema deve pular para o nível acima, nunca permitir autoaprovação.
- O aprovador **sai da empresa**: os pedidos pendentes com ele são redistribuídos automaticamente.

## Aprovar pelo celular com contexto completo

O aprovador está em reunião, viagem ou visita a cliente. Se aprovar exige abrir o computador e entrar no ERP, o pedido espera.

A solução não é aprovar por WhatsApp. É levar **uma tela de aprovação** ao celular, com notificação, e com tudo o que a pessoa precisa para decidir sem pedir mais informação:

- Resumo do pedido: o quê, para quê, quanto, para qual centro de custo.
- Documentos anexos: orçamentos, mapa comparativo, minuta do contrato.
- Situação do orçamento da área: quanto já foi comprometido no período.
- Histórico do fluxo: quem já aprovou e com quais comentários.
- Botões claros: aprovar, reprovar ou devolver para ajuste, com comentário obrigatório na reprovação.

A notificação pode chegar por e-mail, [push](https://pervian.tech/blog/notificacoes-push-boas-praticas) ou WhatsApp, mas **a decisão acontece dentro do sistema**, com login. A mensagem só avisa e leva ao link.

Uma aplicação web responsiva, instalável no celular, costuma bastar; não é obrigatório [ter aplicativo nas lojas](https://pervian.tech/blog/publicar-app-na-app-store-e-google-play).

## Trilha de auditoria: quem aprovou o quê e quando

A trilha é o que transforma o workflow em evidência. Cada evento do pedido gera um registro que não pode ser editado depois:

| Evento | O que registrar |
|---|---|
| Criação | Solicitante, data e hora, dados do pedido, anexos |
| Cálculo da rota | Versão da política de alçadas aplicada e aprovadores definidos |
| Cada decisão | Aprovador, se agiu por delegação, data e hora, decisão, comentário |
| Alteração do pedido | O que mudou, quem mudou, e se as aprovações anteriores foram invalidadas |
| Escalonamento | Prazo vencido, para quem subiu, data e hora |
| Conclusão | Aprovação final e integração com o ERP ou sistema de destino |

Dois detalhes técnicos fazem diferença na hora da auditoria.

**Aprovação presa à versão do documento.** Se o valor ou o anexo mudar depois de aprovado, as aprovações anteriores precisam cair, e o pedido volta ao fluxo. Sem isso, alguém aprova um orçamento e outro entra no ERP.

**Registro imutável e controle de quem vê o quê.** A trilha não pode ser apagada nem editada por usuário comum, e o acesso a ela também precisa ser controlado. O tema é amplo e tem um texto próprio: [controle de acesso e trilha de auditoria](https://pervian.tech/blog/controle-de-acesso-e-trilha-de-auditoria) explica perfis, permissões e como guardar esses registros.

Com a trilha no lugar, a pergunta do auditor vira um relatório filtrado por período, tipo e faixa.

## Onde aplicar: compras, despesas, descontos, contratos

O mesmo motor de aprovação serve para vários processos. As diferenças estão nas regras de cada um:

- **Compras e requisições.** O caso mais comum. Alçada por valor e centro de custo, com aprovadores extras por categoria.
- **[Reembolso de despesas e adiantamentos](https://pervian.tech/blog/reembolso-de-despesas-automatizado).** Alçada pelo gestor direto, com conferência financeira de comprovantes e regras por tipo de despesa (viagem, alimentação, quilometragem).
- **Descontos comerciais.** O vendedor tem uma margem de negociação; acima dela, o gerente comercial aprova, e acima de outro limite, o financeiro. Aqui a velocidade importa muito: o cliente está esperando a proposta.
- **Contratos.** Aprovação interna antes do envio para assinatura, com jurídico obrigatório em certas condições. A integração com a assinatura eletrônica fecha o ciclo, como mostra o texto sobre [gestão de contratos com assinatura digital](https://pervian.tech/blog/gestao-de-contratos-com-assinatura-digital).
- **Pagamentos fora do fluxo.** Pagamento sem pedido de compra, antecipação a fornecedor, [alteração de dados bancários](https://pervian.tech/blog/automatizar-contas-a-pagar). São os pontos mais sensíveis a fraude e merecem dupla aprovação.

## Sistema pronto, módulo do ERP ou desenvolvimento sob medida

Muitos ERPs têm algum fluxo de aprovação, e [ferramentas de workflow genéricas, como o Pipefy,](https://pervian.tech/blog/pipefy-ou-fluxo-sob-medida) cobrem casos simples. Critérios para decidir:

- **O módulo do ERP resolve** quando a política de alçadas é simples (só valor e área), todos os aprovadores já usam o ERP e o processo está restrito a compras.
- **Uma ferramenta de workflow genérica resolve** quando os processos são poucos, as regras cabem num formulário configurável e não há integração pesada. O mesmo critério vale para plataformas low-code, comparadas em [low-code ou desenvolvimento sob medida](https://pervian.tech/blog/low-code-ou-desenvolvimento-sob-medida).
- **O sob medida faz sentido** quando a matriz combina muitos critérios, quando há vários processos com o mesmo motor de aprovação, quando aprovadores não têm acesso ao ERP, quando a integração com sistemas internos é obrigatória ou quando a exigência de auditoria é alta.

Para testar qualquer opção, pegue cinco pedidos reais e difíceis (com delegação, fracionamento, alteração depois de aprovado) e veja se a ferramenta os representa sem gambiarra.

## Checklist para começar

1. Faça um inventário dos pedidos que hoje são aprovados por e-mail, WhatsApp ou de viva voz.
2. Escreva a política de alçadas atual, mesmo que informal, e valide com a diretoria.
3. Revise o cadastro de centros de custo, áreas e responsáveis.
4. Defina prazos por etapa, regra de escalonamento e política de substitutos.
5. Decida o que invalida uma aprovação (mudança de valor, de fornecedor, de anexo).
6. Escolha um processo para o piloto, geralmente compras, e meça o tempo de ciclo antes e depois.
7. Só então expanda para despesas, descontos e contratos.

## Perguntas frequentes

### Qual a diferença entre alçada e workflow de aprovação?

Alçada é o limite de autoridade de uma pessoa ou cargo para aprovar um tipo de pedido, geralmente organizado em faixas de valor. O workflow de aprovação é o mecanismo que aplica essa política: calcula os aprovadores de cada pedido, encaminha na ordem certa, cobra prazos e registra cada decisão numa trilha de auditoria.

### Como evitar o fracionamento de compras para fugir da alçada?

O fracionamento é evitado quando o sistema soma pedidos do mesmo fornecedor e da mesma categoria dentro de um período e trata o conjunto como um único pedido para fins de alçada. Também ajuda avaliar contratos recorrentes pelo compromisso total, e não pela parcela mensal, para que nada caia sempre na menor faixa.

### O módulo de aprovação do ERP resolve ou precisa de sistema próprio?

Depende da política de alçadas. O módulo de aprovação do ERP resolve quando as regras usam só valor e área, todos os aprovadores já usam o ERP e o processo se limita a compras. Um workflow sob medida faz sentido quando a matriz combina muitos critérios, há vários processos ou existem aprovadores sem acesso ao ERP.

### Quanto tempo leva para implantar um workflow de aprovação por alçada?

Depende das integrações e da complexidade da matriz de aprovação, e o prazo real só fica claro depois do diagnóstico. Começar por um piloto em um único processo, normalmente compras, permite colocar o workflow em uso antes de expandir. A revisão do cadastro de centros de custo e responsáveis costuma ser a primeira etapa.

## Como a Pervian Tech trabalha workflows de aprovação

Na Pervian Tech, começamos por um diagnóstico gratuito: mapeamos quais pedidos passam por aprovação hoje, como as alçadas funcionam de fato e onde os pedidos se perdem. Dele sai a matriz de aprovação escrita e um protótipo navegável da tela de aprovação, inclusive no celular, para validar com quem aprova antes de qualquer desenvolvimento.

O sistema é construído sob medida, como parte do nosso trabalho de [desenvolvimento web](https://pervian.tech/servicos/desenvolvimento-web), integrado ao ERP e aos sistemas que a empresa já usa. Começamos por um processo, normalmente compras, e expandimos o mesmo motor para os demais. Mais detalhes estão na página de [automação de processos](https://pervian.tech/solucoes/automacao-de-processos). O cronograma depende das integrações e da complexidade da matriz, e é definido depois do diagnóstico; o investimento é sob consulta.

Se as aprovações da sua empresa ainda dependem de alguém lembrar de responder um e-mail, [conte como elas funcionam hoje](https://pervian.tech/#contato) e mostramos por onde começar.