Checkout B2B: como funciona o fluxo de aprovação multinível de pedidos

Em qualquer plataforma de e-commerce B2B bem construída, o checkout é o componente mais complexo — e o mais diferente do B2C. Enquanto no varejo o checkout é uma sequência linear de 3 a 5 passos que termina com o pagamento, no B2B o checkout pode ser o início de um fluxo que envolve múltiplas pessoas, múltiplas validações e múltiplos sistemas antes de um pedido efetivamente se tornar um compromisso de entrega.

Este artigo explica como funciona o fluxo de aprovação multinível no e-commerce B2B, como configurar as regras corretamente e quais os erros mais comuns que comprometem a experiência do comprador e a operação do fornecedor.

Por que o checkout B2B é fundamentalmente diferente do B2C

No B2C, quem compra e quem paga é a mesma pessoa. A decisão é individual, imediata e o processo de pagamento — cartão, PIX — é o mecanismo de confirmação.

No B2B, o processo de compra é fundamentalmente diferente em três dimensões:

Autoridade de compra é delegada, não individual. O gerente de compras de um supermercado tem autoridade para aprovar pedidos até R$ 10.000. Acima disso, o diretor financeiro precisa aprovar. Acima de R$ 50.000, o CEO precisa validar. Esse fluxo de autoridade existe independente de usar portal ou WhatsApp — o que muda é que o portal pode automatizá-lo.

Pagamento não acontece no momento da compra. No B2B, o pagamento geralmente acontece dias ou semanas depois — via boleto, transferência, financiamento. O checkout não é encerrado pelo pagamento, mas pela confirmação do pedido dentro das condições comerciais negociadas.

O pedido pode precisar passar por múltiplos sistemas antes de ser faturado. Análise de crédito, verificação de estoque, validação fiscal, aprovação do representante — cada um desses passos pode ser um checkpoint no fluxo do pedido.

Os perfis de aprovador no e-commerce B2B

Para configurar um fluxo de aprovação corretamente, é preciso primeiro entender quais perfis de aprovador existem e qual é o papel de cada um.

Do lado do comprador (a empresa que está comprando)

Solicitante: o usuário que monta e envia o pedido. Pode ser o próprio gerente de compras ou um usuário operacional (comprador júnior, gestor de loja, almoxarife). O solicitante frequentemente não tem autoridade para aprovar o próprio pedido acima de determinado valor.

Aprovador interno do comprador: o superior hierárquico que valida o pedido antes de ele ser enviado ao fornecedor. Em redes de franquias, pode ser o gerente regional. Em distribuidoras com múltiplos centros, pode ser o gerente financeiro de cada centro.

Aprovador de compras centralizado: em empresas com departamento de compras centralizado, existe uma camada adicional de aprovação que verifica se o fornecedor está na lista de fornecedores aprovados, se o preço está dentro da política de compras e se o produto está dentro do contrato vigente.

Do lado do fornecedor (a empresa que está vendendo)

Análise de crédito automática: o sistema verifica se o cliente tem limite de crédito disponível para o valor do pedido. Se sim, aprovação automática. Se não, bloqueio ou encaminhamento para análise manual.

Aprovação do representante: em alguns modelos comerciais, o representante precisa validar pedidos da sua carteira — especialmente pedidos incomuns (produto diferente do mix habitual, quantidade muito acima da média, desconto especial solicitado).

Aprovação do back-office: para pedidos com condições especiais que o sistema não consegue validar automaticamente — cliente com restrição de crédito que está dentro do prazo de carência, produto com disponibilidade parcial que o cliente aceitou de forma diferenciada.

Configurando as regras de aprovação

A configuração do fluxo de aprovação é onde a maioria dos projetos de e-commerce B2B erra — tanto por excesso (colocar aprovação onde não é necessário, criando atrito desnecessário) quanto por falta (deixar sem aprovação situações que deveriam ser validadas).

Regras por valor do pedido

A regra mais comum e mais simples de configurar. Define limiares de valor acima dos quais o pedido precisa de aprovação adicional.

Exemplo de configuração típica:

• Até R$ 2.000: aprovação automática (dentro do limite do solicitante)
• R$ 2.001 a R$ 10.000: requer aprovação do gerente de compras do comprador
• Acima de R$ 10.000: requer aprovação do diretor financeiro do comprador

Cada nível de aprovação tem:

• Prazo máximo para aprovação (ex: 24 horas úteis)
• Ação se o prazo vencer sem resposta (escalação automática ou cancelamento do pedido)
• Canal de notificação (e-mail, push notification no app, SMS para aprovações urgentes)

Regras por categoria de produto

Algumas empresas têm políticas de compra específicas para determinadas categorias — produtos de alto risco regulatório, itens de alto valor unitário, produtos importados com processo aduaneiro especial.

Exemplo: um distribuidor de insumos industriais pode ter aprovação automática para consumíveis rotineiros mas exigir aprovação adicional do responsável técnico para equipamentos acima de determinado valor ou para insumos controlados.

A plataforma B2B precisa permitir que a regra seja definida por categoria (não só por produto específico) — porque o catálogo muda com frequência e manter regras produto a produto é inviável.

Regras por fornecedor ou por contrato

Em empresas com departamento de compras centralizado, pode existir regra de aprovação vinculada ao status do fornecedor:

• Fornecedor homologado com contrato vigente: aprovação automática dentro dos parâmetros do contrato
• Fornecedor homologado sem contrato ativo: aprovação manual pelo departamento de compras
• Fornecedor não homologado: bloqueio automático (o pedido não pode ser feito)

Essa configuração é especialmente relevante para redes de franquias — onde a franqueadora quer garantir que os franqueados comprem exclusivamente dos fornecedores homologados para itens críticos.

Regras híbridas (combinação de critérios)

Os cenários mais comuns na prática combinam múltiplos critérios:

• Pedido acima de R$ 5.000 E de categoria de equipamentos: aprovação do gerente técnico E do financeiro
• Primeiro pedido de um cliente novo: aprovação do representante responsável pela conta
• Pedido com desconto solicitado acima de 15%: aprovação do gerente comercial do fornecedor

A plataforma B2B precisa suportar lógica booleana nas regras (AND, OR) — não só limiares simples.

O fluxo de aprovação na prática: o que o comprador vê

Um fluxo de aprovação bem implementado não deve parecer burocrático para o comprador. Deve ser transparente e eficiente.

Experiência ideal para o solicitante

1. O solicitante monta o pedido normalmente e clica em "Finalizar pedido"
2. O sistema verifica automaticamente: esse pedido requer aprovação? (Sim, está acima de R$ 10.000)
3. O sistema exibe mensagem clara: "Seu pedido foi enviado para aprovação do Gerente de Compras. Você receberá uma notificação quando for aprovado ou se houver alguma questão."
4. O solicitante pode acompanhar o status do pedido na tela de pedidos: "Aguardando aprovação"
5. Quando aprovado (ou rejeitado, com comentário), o solicitante recebe notificação

Experiência ideal para o aprovador

1. O aprovador recebe notificação por e-mail e/ou push: "Novo pedido aguardando sua aprovação: [resumo do pedido, valor, solicitante]"
2. Um clique abre a tela de aprovação — com detalhes completos do pedido, histórico do cliente, saldo de crédito disponível e itens aguardando aprovação
3. O aprovador pode aprovar, rejeitar (com comentário obrigatório) ou solicitar ajuste ao solicitante
4. A ação do aprovador é registrada com timestamp e pode ser auditada

O que NÃO deve acontecer

• O pedido some silenciosamente "para aprovação" sem que o solicitante saiba onde está
• O aprovador recebe um e-mail sem link direto para a tela de aprovação
• A aprovação expira sem notificação e o pedido é cancelado sem que ninguém saiba
• Não existe histórico de quem aprovou o quê e quando

Auditoria: o que precisa ficar registrado

O fluxo de aprovação no e-commerce B2B tem implicações de compliance e auditoria que muitas empresas ignoram durante a implementação e lamentam depois.

Registro mínimo obrigatório por pedido

• Quem criou o pedido (usuário, data/hora)
• Todos os aprovadores que precisavam aprovar e o status de cada aprovação
• Quem aprovou (ou rejeitou), com data/hora e comentário quando aplicável
• Qualquer modificação no pedido após a criação (quem modificou, o quê, quando)
• Versão final aprovada dos dados do pedido (itens, quantidades, preços)

Por que isso importa

Para auditorias fiscais: o fisco pode questionar pedidos com desconto especial — o registro de quem aprovou e por quê é a documentação de suporte.

Para disputas comerciais: se um cliente questionar um pedido ("eu não autorizei esse pedido"), o log de aprovação mostra exatamente quem autorizou, quando e de qual dispositivo/IP.

Para controle interno: em empresas com departamento de compras centralizado, o registro de todas as aprovações permite identificar compras fora da política, fornecedores não homologados que conseguiram passar pedidos e inconsistências no processo.

Integração do fluxo de aprovação com o ERP

O pedido só deve entrar no ERP para faturamento após a aprovação final. Isso parece óbvio, mas tem uma implicação técnica importante: a integração precisa tratar o pedido como um objeto com estados (rascunho → aguardando aprovação → aprovado → enviado ao ERP → em processamento → faturado), e o envio ao ERP só acontece na transição "aprovado → enviado ao ERP".

Isso significa que o ERP pode (e deve) receber apenas pedidos já aprovados — não pedidos em qualquer estado de aprovação. O ERP não é o lugar para gerenciar o fluxo de aprovação; a plataforma B2B é.

Exceção: quando a análise de crédito é feita pelo próprio ERP. Nesse caso, o pedido aprovado internamente pela empresa compradora é enviado ao ERP para análise de crédito do fornecedor — e pode ser bloqueado nessa etapa antes do faturamento.

Erros de configuração mais comuns

Erro 1: aprovação obrigatória para todos os pedidos Algumas empresas, com medo de perder controle, colocam aprovação para todos os pedidos independentemente do valor. Resultado: a equipe de aprovação passa o dia aprovando pedidos de R$ 200 de clientes recorrentes. A adoção do portal despenca porque o processo ficou mais burocrático que o WhatsApp.

Solução: aprovação automática para pedidos dentro de parâmetros normais (valor abaixo do limite, cliente ativo com histórico consistente, sem solicitação de desconto especial). Aprovação apenas para exceções.

Erro 2: notificações que ninguém vê O sistema envia e-mail de notificação de aprovação para um alias de e-mail que ninguém monitora. O pedido fica parado por 3 dias até o cliente ligar perguntando o status.

Solução: validar os canais de notificação com usuários reais antes do go-live. Configurar alerta para pedidos aguardando aprovação há mais de X horas sem ação.

Erro 3: falta de prazo de expiração para aprovação Pedido fica indefinidamente "aguardando aprovação" sem que nada aconteça. O cliente não sabe se o pedido foi confirmado e não tem visibilidade.

Solução: toda aprovação tem prazo máximo. Ao expirar, o sistema escalona automaticamente para um aprovador alternativo ou cancela o pedido com notificação ao solicitante.

Erro 4: regras de aprovação que contradizem a política comercial O sistema requer aprovação do gerente para descontos acima de 10%, mas o contrato com esse cliente especifica desconto fixo de 12%. Cada pedido desse cliente gera uma aprovação desnecessária.

Solução: a plataforma deve reconhecer descontos contratuais e não acionar aprovação quando o desconto está dentro do contrato vigente.

Erro 5: log de auditoria inexistente ou inacessível A empresa não consegue responder "quem aprovou esse pedido em março?" porque o log não existe ou está em uma área do sistema inacessível para o time financeiro.

Solução: log de auditoria acessível por gestores (não só pelo time de TI), com exportação para relatório e filtros por período, usuário e tipo de evento.

Como testar o fluxo de aprovação antes do go-live

O fluxo de aprovação é um dos componentes mais difíceis de testar porque envolve múltiplos usuários, notificações e estados. Um roteiro de teste mínimo:

Cenário 1: pedido abaixo do limite de aprovação → deve ser aprovado automaticamente e ir para o ERP sem intervenção humana.

Cenário 2: pedido acima do limite de aprovação → notificação deve chegar ao aprovador correto, dentro do prazo, pelo canal configurado.

Cenário 3: aprovação realizada pelo aprovador → pedido deve avançar para o próximo nível (se houver) ou ser enviado ao ERP.

Cenário 4: rejeição com comentário → solicitante deve receber notificação com o comentário do aprovador.

Cenário 5: prazo de aprovação expirado → sistema deve acionar a ação configurada (escalação ou cancelamento) e notificar as partes relevantes.

Cenário 6: aprovador modifica o pedido antes de aprovar → modificação deve ser registrada no log com identidade do aprovador e os dados originais preservados.

Cenário 7: cliente sem crédito disponível → pedido deve ser bloqueado antes mesmo de entrar no fluxo de aprovação, com mensagem clara para o solicitante.

Não passe para o go-live sem ter executado todos esses cenários com usuários reais — não apenas com a equipe de TI fazendo os testes.

A FastChannel suporta fluxo de aprovação multinível configurável por valor, categoria e perfil de usuário — com log de auditoria completo e integração com o ERP apenas após aprovação final, sem desenvolvimento customizado. Saiba mais em fastchannel.com.