Black Friday 2026: a campanha começa na operação, não no desconto

Uma campanha pode ter uma oferta forte, uma boa verba de mídia e peças criativas. Ainda assim, a venda pode ser perdida em um estoque desatualizado, em uma regra de frete incorreta, em uma tentativa de pagamento sem retorno ou em um pedido que não chega ao ERP.

É por isso que a preparação técnica para a Black Friday não deve começar na semana da promoção. Em 2026, a Black Friday será em 27 de novembro. Quem inicia a revisão da operação com antecedência consegue homologar mudanças, corrigir integrações e medir o funil sem transformar a campanha em um teste direto em produção.

Este guia organiza a preparação em oito frentes: regras da campanha, estoque, integrações, checkout, infraestrutura, observabilidade, funil de vendas e plano de contingência. O objetivo não é criar um checklist genérico, mas indicar o que validar, como validar e qual evidência guardar antes de aumentar o tráfego.

1. Transforme a campanha em regras que os sistemas consigam executar

“Dar 20% de desconto” parece uma definição simples. Para a operação, porém, ainda faltam respostas:

• quais SKUs participam;
• qual é o preço de referência e qual será o preço promocional;
• quando a regra começa e termina;
• se o desconto acumula com cupom, tabela B2B ou condição de pagamento;
• se existe quantidade máxima por cliente;
• qual estoque pode ser comprometido pela campanha;
• quais regiões e modalidades de frete participam;
• como cancelamentos e pagamentos recusados devolvem a disponibilidade ao catálogo.

Registre essas respostas em uma matriz única e versionada. Marketing, atendimento, logística e tecnologia devem consultar a mesma definição — não planilhas diferentes enviadas por mensagens.

Essa matriz também evita um problema frequente: a regra aparecer corretamente na vitrine, mas ser recalculada de forma diferente no carrinho, no gateway ou no ERP.

2. Defina qual sistema é a fonte de verdade de cada dado

Em uma operação integrada, nem todo dado deve ser editado em todos os lugares. Antes da campanha, documente a origem e o sentido de cada sincronização.

Um mapa mínimo deve responder:

• o preço nasce no ERP, na plataforma de e-commerce ou em um motor promocional;
• o estoque é físico, disponível ou reservado;
• quanto tempo uma atualização leva para chegar à loja;
• o que acontece quando a integração falha;
• como o pedido pago é enviado ao ERP;
• qual evento libera o faturamento, a separação e o envio;
• como cancelamento, estorno e expiração devolvem o saldo.

Teste a sincronização com cenários, não apenas com um pedido feliz

Crie casos de homologação que reproduzam situações reais:

1. produto com uma unidade disponível e duas tentativas simultâneas de compra;
2. alteração de preço durante um carrinho aberto;
3. pedido criado, mas pagamento ainda pendente;
4. Pix expirado;
5. pagamento aprovado e falha temporária no envio ao ERP;
6. cancelamento depois da reserva do estoque;
7. reprocessamento do mesmo evento sem duplicar pedido;
8. SKU inexistente ou divergente entre os sistemas.

Para cada cenário, defina o resultado esperado e guarde a evidência: identificador do pedido, horário, status em cada sistema e trecho de log. “Funcionou uma vez” não é critério de homologação.

3. Homologue o checkout brasileiro de ponta a ponta

O checkout precisa ser validado como o cliente realmente o utiliza: no celular, com conexão comum, endereço real, cupom, frete e meio de pagamento. O teste só termina quando o pedido chega corretamente ao sistema que dá continuidade à operação.

Matriz mínima de testes

No Brasil, a compatibilidade não deve ser presumida apenas porque o tema, o módulo ou a plataforma “funciona”. Pix, parcelamento, CPF/CNPJ, regras fiscais e integrações locais formam um conjunto específico. Qualquer atualização próxima da campanha precisa passar pela mesma matriz.

4. Faça teste de carga com um comportamento parecido com o da loja

Testar apenas a página inicial mede pouco. O tráfego de uma campanha pressiona busca, categorias, páginas de produto, carrinho, cálculo de frete, sessão, banco de dados, filas e APIs externas.

Monte um roteiro com proporções próximas da jornada real, por exemplo:

• 45% navegando por categorias e busca;
• 30% abrindo páginas de produto;
• 15% adicionando itens ao carrinho;
• 8% iniciando checkout;
• 2% concluindo um pedido de teste em ambiente controlado.

Os percentuais devem ser ajustados com dados da própria loja. O ponto é evitar um teste artificial em que todos os usuários acessam a mesma URL estática.

O que observar durante o teste

Não use apenas “o site abriu” como resultado. Registre:

• tempo de resposta mediano e percentis p95/p99;
• taxa de respostas 4xx e 5xx;
• uso de CPU e memória;
• conexões e consultas lentas no banco;
• profundidade e atraso das filas;
• taxa de acerto do cache;
• tempo e erro das APIs de pagamento, frete e ERP;
• pedidos duplicados, sessões perdidas ou divergência de total.

O teste deve acontecer em ambiente de homologação representativo. Se qualquer validação controlada for feita em produção, ela precisa ter limite, janela definida, monitoramento e plano de interrupção.

5. Prepare cache e filas sem esconder erro de negócio

Cache reduz trabalho repetido e ajuda páginas de catálogo, mas não pode servir preço, estoque ou sessão incorretos. Revise:

• quais páginas e blocos podem ser armazenados;
• como o cache é invalidado quando preço ou estoque muda;
• se carrinho, conta e checkout estão excluídos de cache compartilhado;
• se CDN e aplicação respeitam cookies e cabeçalhos;
• se a limpeza de cache total pode sobrecarregar a loja no pico.

Na plataforma e nos módulos, identifique também as tarefas executadas em segundo plano: sincronização de catálogo, envio de pedido, e-mail, webhook, atualização de status e geração de documentos. Para cada fila, defina um limite de atraso aceitável e um alerta. Uma fila “rodando” pode estar acumulando milhares de tarefas sem concluir a operação no tempo necessário.

6. Monitore a jornada, e não apenas o servidor

CPU baixa não prova que a loja está vendendo. O servidor pode estar saudável enquanto o cálculo de frete falha ou o pagamento deixa de confirmar pedidos.

Organize o painel de acompanhamento em quatro camadas:

1. Experiência: disponibilidade, tempo de resposta e erros no navegador.
2. Aplicação: exceções, rotas lentas, filas e cron.
3. Integrações: latência, falhas, retentativas e último evento processado.
4. Negócio: carrinhos, checkouts iniciados, tentativas de pagamento, aprovações e pedidos enviados ao ERP.

Use um identificador que permita seguir a mesma operação entre plataforma, gateway e ERP. Sem correlação, a equipe perde tempo procurando um pedido em três sistemas diferentes.

Defina alertas acionáveis

Um alerta útil informa o que mudou e quem deve agir. Exemplos:

• taxa de erro do checkout acima do padrão por cinco minutos;
• queda abrupta entre início de checkout e pagamento;
• fila de pedidos com atraso superior ao limite combinado;
• ausência de confirmação do gateway em uma janela inesperada;
• divergência entre pedidos pagos e pedidos recebidos pelo ERP;
• aumento do tempo de cálculo de frete.

Evite alertas que disparam o tempo todo. Eles treinam a equipe a ignorar justamente o aviso que importa.

7. Configure o funil de vendas antes de comprar mais tráfego

Sem um funil confiável, a campanha responde apenas quanto foi vendido — não onde as oportunidades foram perdidas.

No mínimo, acompanhe:

• visualização de produto;
• adição ao carrinho;
• início do checkout;
• informação de frete;
• seleção ou tentativa de pagamento;
• compra confirmada.

Os nomes podem seguir a ferramenta de análise utilizada; o importante é que cada evento tenha regra clara, não duplique e carregue os parâmetros necessários, como produto, valor, moeda e identificador da transação.

Valide eventos com pedidos de teste

Para cada cenário da matriz de checkout:

1. registre o horário do teste;
2. confirme o evento no navegador ou servidor;
3. verifique se ele chegou à ferramenta de análise;
4. compare valor, itens, cupom e frete com o pedido;
5. confirme que a compra não foi contada duas vezes ao recarregar a página;
6. documente perdas deliberadas, como pagamento recusado ou Pix expirado.

Um funil bem configurado ajuda a separar três problemas que costumam ser misturados: falta de interesse na oferta, fricção na jornada e falha técnica.

8. Preserve SEO e URLs durante a campanha

Evite criar uma página promocional nova a cada ano e depois removê-la. Quando fizer sentido para a estratégia, mantenha uma URL estável, atualize seu conteúdo e retire apenas as condições encerradas.

A página da campanha deve preservar:

• status HTTP e indexabilidade;
• título, descrição e conteúdo coerentes com a página;
• canonical correto;
• links internos a partir de categorias e conteúdos relacionados;
• sitemap atualizado;
• redirecionamentos de URLs antigas equivalentes;
• ausência de bloqueio acidental por `robots.txt` ou `noindex`.

Se a loja também passará por migração de domínio, plataforma ou estrutura de URLs, não concentre todas as mudanças na mesma janela. O Google recomenda preparar e testar o novo site, mapear URLs antigas e novas, aplicar redirecionamentos permanentes e monitorar os dois lados. Quanto menos variáveis mudarem ao mesmo tempo, mais fácil será diagnosticar qualquer perda.

9. Tenha um plano de contingência que caiba em uma página

O plano precisa ser executável sob pressão. Para cada falha crítica, registre:

• como detectar;
• impacto para o cliente;
• primeira ação segura;
• responsável técnico e responsável de negócio;
• critério para desativar uma funcionalidade ou campanha;
• procedimento de retorno;
• mensagem para atendimento e marketing.

Alguns exemplos:

• indisponibilidade de um meio de pagamento;
• cálculo de frete lento ou fora do ar;
• estoque sem sincronização;
• pedidos pagos sem integração ao ERP;
• fila acumulada;
• regra promocional calculada incorretamente.

Backup é parte do plano, mas não é o plano inteiro. Confirme que existe uma cópia recente e que a restauração foi testada. Além disso, mantenha as versões de código, configuração e banco compatíveis com o procedimento de retorno.

Cronograma prático até 27 de novembro

Agosto: mapeamento

• fechar regras, responsáveis e sistemas envolvidos;
• mapear integrações e fontes de verdade;
• inventariar módulos e mudanças pendentes;
• corrigir o funil e estabelecer a linha de base das métricas.

Setembro: implementação e homologação

• desenvolver regras específicas;
• homologar checkout, pagamentos, frete e ERP;
• configurar painéis, logs e alertas;
• validar cache, filas e rotinas agendadas.

Outubro: capacidade e ensaio

• executar testes de carga realistas;
• realizar um pedido completo por cenário;
• simular falhas e retorno;
• treinar responsáveis e ajustar o plano de contingência.

Novembro: congelamento controlado

• limitar mudanças não essenciais;
• revisar a matriz final de campanha;
• confirmar backups, contatos e acessos;
• acompanhar campanha, operação e funil no mesmo painel.

Checklist de saída

Antes de liberar a campanha, a equipe deve conseguir responder “sim” a estas perguntas:

• As regras comerciais estão documentadas e iguais em todos os sistemas?
• Estoque e preço foram validados em cenários de concorrência e falha?
• Pix, cartão, boleto, parcelamento, CPF/CNPJ e frete foram homologados?
• Pedidos pagos chegam ao ERP sem duplicidade?
• A capacidade foi testada com navegação, carrinho e checkout?
• Filas e integrações possuem alertas úteis?
• O funil registra cada etapa sem duplicar compras?
• Existe backup restaurável e procedimento de retorno?
• Atendimento, marketing e tecnologia sabem quem decide durante um incidente?

Preparar agora custa menos do que improvisar no pico

Uma campanha de alta demanda expõe as dependências que ficam invisíveis em dias comuns. O melhor momento para encontrar esses pontos não é quando o anúncio já está rodando.

A AGTI atua na criação e evolução de plataformas de venda, integrações com ERP, checkout, pagamentos, logística, dados e automações. Se a sua operação precisa revisar riscos e prioridades antes da Black Friday, agende um diagnóstico técnico para transformar a preparação em um plano executável.

Agendar um diagnóstico técnico com a AGTI