Checklist de go-live para e-commerce B2B: 40 pontos antes de abrir para os clientes

Um go-live de e-commerce B2B que vai mal não é só um problema técnico — é um problema comercial e de relacionamento. O cliente que tenta fazer o primeiro pedido pelo portal e encontra preço errado, produto indisponível ou erro na integração vai voltar para o WhatsApp e resistir a tentar de novo por semanas.

O objetivo deste checklist não é garantir perfeição — é garantir que os problemas que afetam a experiência do cliente sejam identificados antes do go-live, não depois.

Organize o checklist em duas categorias: bloqueadores (itens que impedem o go-live se não estiverem funcionando) e desejáveis (itens importantes que devem ter prazo de resolução, mas não impedem o go-live do piloto).

Por que go-lives B2B falham — e como este checklist evita os erros mais comuns

Os go-lives de e-commerce B2B fracassam por algumas razões que se repetem com consistência perturbadora:

Ir ao ar cedo demais por pressão interna. A data do go-live virou compromisso público antes da plataforma estar pronta. O gerente de projeto sente pressão para "abrir" mesmo com pendências relevantes — e o resultado é um go-live com problemas que seriam evitáveis com mais 2 semanas de homologação.

Testar apenas o fluxo feliz. A equipe de testes faz pedidos normais e tudo funciona. Mas ninguém testou o que acontece quando o cliente tenta comprar produto sem estoque, quando o pedido está abaixo do mínimo, quando o cliente não tem crédito disponível. Os cenários de exceção aparecem nos primeiros 48 horas de produção com clientes reais.

Subestimar o onboarding operacional. A plataforma está pronta — mas a equipe de suporte não sabe onde ver pedidos com erro. O representante não sabe como acessar o portal do representante. O back-office não sabe o que fazer quando um pedido não integra. A plataforma funciona; a operação ao redor dela não.

Não ter plano de rollback. Se o go-live der errado, qual é o processo? Quem decide reverter? Como você comunica para os clientes do piloto? Na ausência de um plano, a decisão de reverter é tomada tarde e com mais dano do que necessário.

Bloco 1: integração com ERP

São os 10 itens mais críticos. Qualquer falha neste bloco é bloqueadora de go-live.

1. Sincronização de estoque validada com dados reais

Altere o estoque de 5 produtos no ERP e verifique que o portal reflete a mudança em até 5 minutos
Teste com produto que vai a zero: o portal deve bloquear adição ao carrinho, não só na finalização
Teste com produto que fica negativo no ERP por ajuste: o portal não deve mostrar estoque negativo
Bloqueador: qualquer divergência de estoque entre ERP e portal

2. Tabela de preços correta por cliente

Acesse o portal com login de 5 clientes com tabelas de preço diferentes e verifique que cada um vê o preço correto
Teste produto com desconto por volume: o preço deve mudar conforme a quantidade no carrinho
Verifique produto com preço especial de campanha: só clientes elegíveis devem ver o preço da campanha
Bloqueador: qualquer divergência de preço entre o que o portal mostra e o ERP aplica no faturamento

3. Fluxo completo de pedido — do carrinho ao ERP

Faça um pedido piloto completo: monte carrinho → checkout → aprovação → verificar que o pedido está no ERP
Verifique que todos os campos críticos chegaram corretamente: itens, quantidades, preços, condição de pagamento, endereço de entrega, dados fiscais
Verifique que o pedido no ERP tem o código do representante correto associado
Bloqueador: qualquer pedido que não chega ao ERP ou chega com dados incorretos

4. Status de pedido sincronizado do ERP para o portal

Altere o status de um pedido no ERP (de "em análise" para "aprovado", de "aprovado" para "em separação") e verifique que o portal reflete em até 15 minutos
Verifique que o cliente recebe notificação automática nas transições de status configuradas
Bloqueador: status de pedido desatualizado por mais de 30 minutos

5. Verificação de crédito em tempo real

Faça pedido com cliente sem limite de crédito: deve ser bloqueado antes do checkout com mensagem clara
Faça pedido que consome 100% do crédito disponível: deve passar. Faça outro pedido com mesmo cliente: deve ser bloqueado
Verifique que após pagamento processado no ERP, o limite é restaurado no portal
Bloqueador: pedido aprovado no portal para cliente sem crédito

6. Pedido mínimo aplicado corretamente

Tente finalizar pedido abaixo do mínimo: deve ser bloqueado com mensagem informando o valor faltante
Verifique que a regra de mínimo por SKU (quando existir) também está sendo aplicada
Teste cliente com mínimo diferente do padrão: deve aplicar a regra específica daquele cliente
Bloqueador: pedido abaixo do mínimo sendo aceito pelo portal

7. Tratamento de produto sem estoque

Produto com estoque zero deve aparecer como indisponível — não deve ser possível adicionar ao carrinho
Produto com estoque parcial: cliente tentando pedir 100 unidades quando há 60 deve receber mensagem clara de disponibilidade parcial
Bloqueador: produto sem estoque sendo vendido sem alerta

8. Nota fiscal e dados fiscais

Verifique que os dados fiscais do cliente (regime tributário, endereço fiscal, dados da inscrição estadual) chegam corretamente ao ERP para emissão da NF
Verifique CFOP aplicado para pedidos dentro e fora do estado do fornecedor
Bloqueador: dados fiscais incorretos que impediriam emissão de NF válida

9. Fila de erros de integração monitorada

A fila de pedidos com erro de integração está acessível e visível para a equipe responsável
Alertas automáticos estão configurados: quando um pedido fica em erro por mais de 30 minutos, quem recebe o alerta?
O processo de reprocessamento manual está documentado e a equipe sabe executá-lo
Desejável antes do go-live, bloqueador para expansão além do piloto

10. Teste de carga básico

Simule 20 pedidos simultâneos e verifique que todos são processados sem degradação
Verifique o comportamento do portal durante janelas de atualização de estoque (quando o ERP processa grandes volumes)
Desejável: fundamental para go-live com base grande de clientes

Bloco 2: configuração comercial

Estes 10 itens garantem que as regras de negócio estão corretas. Problemas aqui chegam ao cliente imediatamente.

11. Catálogo correto por perfil de cliente

Cada cliente vê apenas os produtos que tem permissão de comprar
Produtos descontinuados ou inativos não aparecem no catálogo
Produtos novos cadastrados no ERP aparecem no portal em até 1 hora
Bloqueador: cliente vendo produto que não deveria ou não vendo produto que deveria

12. Imagens e descrições dos produtos

Todos os produtos no catálogo têm ao menos uma imagem
Descrições estão em português e sem erros óbvios (conteúdo exportado do ERP pode vir em formato técnico não adequado ao portal)
Especificações técnicas dos produtos estão completas para as categorias onde isso é relevante
Desejável: produtos sem imagem geram baixa conversão mas não impedem o go-live

13. Representante corretamente associado à carteira

Cada cliente está associado ao representante correto no sistema
O representante acessa o portal do representante e vê sua carteira completa
Quando o cliente faz um pedido, o representante recebe notificação
Pedido feito pelo cliente aparece na área do representante com os dados corretos
Bloqueador: cliente sem representante associado ou representante com carteira incorreta

14. Fluxo de aprovação de pedido configurado e testado

Se existe fluxo de aprovação, os aprovadores corretos estão configurados para cada regra
Aprovador recebe notificação quando há pedido aguardando aprovação
Pedido expirado (sem aprovação no prazo) executa a ação configurada (escalação ou cancelamento)
Log de aprovação está sendo gravado
Bloqueador se aprovação for requisito da operação; desejável se for opcional

15. Condições de pagamento por cliente

Cada cliente vê apenas as condições de pagamento aplicáveis ao seu perfil
A condição de pagamento selecionada no portal chega corretamente ao ERP
Clientes com bloqueio de crédito em determinadas condições (ex: somente à vista) não conseguem selecionar condições de prazo
Bloqueador: condição de pagamento incorreta gerando faturamento com prazo errado

16. Histórico de pedidos importado ou disponível

Se houver importação de pedidos históricos do sistema anterior, verificar que estão disponíveis para consulta
Se não houver importação, a política para o cliente está clara: histórico começa do dia do go-live
Desejável: histórico não afeta o go-live mas afeta a experiência do cliente nos primeiros meses

17. Regras de frete configuradas (se aplicável)

Para operações com frete cobrado no portal: as regras de frete por região/peso/valor estão configuradas e validadas
Frete grátis acima de determinado valor está funcionando
Regras de frete por cliente específico (quando existirem) estão aplicadas
Bloqueador se frete é cobrado no portal; desejável se frete é calculado fora do portal

18. Usuários criados e permissões validadas

Os usuários do piloto (clientes e representantes) têm acesso criado e confirmaram que conseguem fazer login
Usuários do back-office têm acesso ao painel administrativo com as permissões corretas
Usuários com perfil de aprovador têm acesso à área de aprovação
Bloqueador: usuários sem acesso no dia do go-live

19. E-mails e notificações transacionais configurados

E-mail de boas-vindas (enviado quando o usuário é criado) com instruções de primeiro acesso
Notificação de pedido recebido para o comprador
Notificação de mudança de status de pedido
Notificação de pedido aguardando aprovação para o aprovador
Remetente configurado com domínio da empresa (não do fornecedor da plataforma)
Desejável: notificações não impedem o go-live mas afetam muito a experiência

20. Relatório de pedidos para o gestor comercial

O gestor consegue ver os pedidos feitos pelo portal, filtrar por período e por cliente
Relatório básico de faturamento pelo canal digital está disponível
Exportação de pedidos para Excel ou CSV funciona
Desejável: o gestor precisa dessas métricas desde o primeiro dia para acompanhar a adoção

Bloco 3: experiência do usuário

Estes 8 itens garantem que a experiência do comprador no portal é adequada para adoção.

21. Busca por produto funciona e retorna resultados relevantes

Busca por nome do produto retorna o produto correto
Busca por código do produto funciona
Busca sem resultado mostra mensagem adequada (não uma tela de erro)
Bloqueador se o catálogo for grande e a navegação por categorias não for suficiente

22. Carrinho persiste entre sessões

Cliente monta carrinho, fecha o navegador, volta em outro momento: o carrinho deve estar salvo
Desejável: perder o carrinho ao fechar o navegador gera frustração mas não impede o pedido

23. Recompra a partir de pedido anterior funciona

Cliente acessa histórico de pedidos e consegue repetir um pedido anterior com um clique
Itens do pedido anterior que não estão mais disponíveis são sinalizados
Desejável: funcionalidade de alto impacto para adoção, mas não bloqueia o go-live

24. Página de acompanhamento de pedido está clara

Após confirmar o pedido, o cliente consegue ver o status atual de forma clara
Rastreamento de entrega está disponível quando o pedido é expedido (ou há link para rastreamento da transportadora)
Desejável: status "em processamento" genérico é tolerável no piloto

25. Portal funciona adequadamente em mobile

Navegação pelo catálogo, adição ao carrinho e checkout funcionam no smartphone sem quebra de layout
Imagens de produto carregam em velocidade aceitável em conexão 4G
Bloqueador se mais de 30% dos usuários esperados usarão mobile para comprar

26. Mensagens de erro são claras e acionáveis

Quando o cliente encontra um erro (produto sem estoque, pedido abaixo do mínimo, crédito insuficiente), a mensagem explica o que aconteceu e o que ele pode fazer
Mensagens de erro técnico (código de erro sem contexto) não aparecem para o usuário final
Bloqueador: mensagens de erro técnico sem contexto causam abandono e chamadas ao suporte

27. Velocidade de carregamento do catálogo

Com o catálogo completo em produção, a página de listagem de produtos carrega em menos de 3 segundos
A busca retorna resultados em menos de 2 segundos
Bloqueador para catálogos grandes; desejável para catálogos pequenos

28. URL do portal está correta e o domínio é da empresa

O portal está acessível no domínio da empresa (não em subdomínio do fornecedor)
Certificado SSL está configurado e válido (https:// sem alerta de segurança)
Bloqueador: portal em domínio do fornecedor impacta a percepção de marca

Bloco 4: segurança e conformidade com LGPD

Estes 6 itens são frequentemente negligenciados em projetos de e-commerce B2B e podem gerar passivo jurídico relevante.

29. Autenticação segura para todos os usuários

Senha com requisito mínimo de complexidade
Bloqueio temporário após tentativas de login incorretas (brute force protection)
Opção de recuperação de senha por e-mail funciona
Bloqueador: portal sem proteção básica contra acesso não autorizado

30. Permissões de acesso validadas por perfil

Usuário comprador não consegue acessar área administrativa
Usuário de uma empresa não consegue ver dados de outra empresa (isolamento de dados por cliente)
Representante A não consegue ver carteira do representante B
Bloqueador: vazamento de dados entre clientes ou perfis

31. Aviso de cookies e política de privacidade

Aviso de cookies está implementado conforme LGPD
Política de privacidade está publicada no portal e acessível antes do login
Desejável: não é bloqueador técnico mas é requisito legal

32. Logs de acesso e auditoria

Logs de login (quem acessou, quando, de qual IP) estão sendo gravados
Logs de ações críticas (pedido criado, aprovado, cancelado) estão sendo gravados
Esses logs são acessíveis pelo administrador do portal
Desejável antes do go-live; torna-se bloqueador para compliance em operações maiores

33. Dados de cartão de crédito não armazenados no portal

Se o portal aceitar pagamento com cartão, os dados devem ser processados por gateway certificado PCI-DSS — nunca armazenados no servidor da plataforma
Bloqueador se o portal aceitar cartão

34. Canal de suporte para incidentes de segurança

Existe um processo documentado para resposta a incidentes de segurança (acesso indevido, vazamento de dados)
O fornecedor tem SLA de notificação para incidentes de segurança (padrão da LGPD: 72 horas)
Desejável: deve ser resolvido dentro dos primeiros 30 dias de operação

Bloco 5: operação e monitoramento

Estes 6 itens garantem que a equipe está pronta para operar o portal a partir do dia 1.

35. Equipe de suporte treinada

A equipe que vai atender dúvidas e problemas dos clientes sabe como navegar no painel administrativo
Sabe como ver os pedidos recebidos pelo portal, incluindo pedidos com erro de integração
Tem um roteiro para as perguntas mais frequentes dos clientes no primeiro acesso
Bloqueador: equipe de suporte sem treinamento no dia do go-live

36. Dashboard de monitoramento configurado

O responsável técnico tem visibilidade da taxa de sucesso de integração em tempo real
Alertas automáticos estão configurados para os eventos críticos (portal fora do ar, fila de erros > 0, latência de estoque > 15 min)
Desejável: fundamental para identificar problemas nas primeiras 48 horas após go-live

37. Processo de contingência documentado

O que fazer se o portal ficar fora do ar? Quem acionar? Em qual prazo?
O que fazer se um pedido não integrar com o ERP? Quem reprocessa manualmente?
O que fazer se um cliente reclamar de preço errado no portal? Quem investiga e em qual prazo?
Bloqueador: sem processo documentado, incidentes viram crises

38. Plano de comunicação para clientes do piloto

Comunicado de lançamento preparado (e-mail ou mensagem) para os clientes do piloto
Canal de suporte dedicado para dúvidas do primeiro acesso informado no comunicado
Bloqueador: go-live silencioso — clientes do piloto precisam ser informados

39. Critérios de rollback definidos

Quais condições acionam a decisão de reverter o go-live?
Quem tem autoridade para tomar essa decisão?
Qual é o processo de comunicação para os clientes caso seja necessário reverter?
Bloqueador: sem critério de rollback, a decisão de reverter será tomada tarde e com mais dano

40. Período de hipersuporte definido

Nas primeiras 2 semanas após o go-live do piloto, existe um período de atenção reforçada da equipe técnica do fornecedor
SLA de resposta durante o hipersuporte é mais rígido que o padrão contratual
Canal de contato direto com o time técnico do fornecedor (não só ticket) para incidentes críticos
Desejável: fundamental para dar confiança à equipe interna nos primeiros dias

Como usar este checklist

Para projetos com piloto: aplique os itens bloqueadores antes do go-live do piloto. Os desejáveis devem ter prazo de resolução dentro das primeiras 4 semanas de operação do piloto — antes da expansão para a base completa.

Para projetos sem piloto (go-live direto com toda a base): todos os bloqueadores e todos os desejáveis críticos (especialmente segurança, monitoramento e contingência) devem estar resolvidos.

Responsabilidades: cada item do checklist deve ter um responsável explícito — fornecedor da plataforma ou contratante. Itens de configuração comercial são quase sempre responsabilidade do contratante; itens de integração técnica são frequentemente compartilhados.

Formato de execução: execute o checklist em uma sessão de homologação com representantes das áreas de TI, comercial e back-office — não apenas com a equipe técnica. Problemas de configuração comercial raramente são encontrados por quem só olha para a integração.

O modelo de rollout gradual: por que é melhor que go-live total

Mesmo com checklist validado, o go-live com 100% da base de clientes ao mesmo tempo tem risco desnecessário. O modelo de rollout gradual reduz esse risco sem atrasar significativamente os benefícios da plataforma.

Fase 1 — Piloto (semanas 1–3): 20 a 50 clientes selecionados. Prioritariamente os clientes mais digitalmente maduros e com relacionamento mais sólido — que vão entender eventuais problemas como parte de um processo de implementação, não como incompetência do fornecedor.

Fase 2 — Expansão controlada (semanas 4–8): 200 a 300 clientes por semana até atingir 60% da base. Seleção por representante ou por região — facilita o treinamento e o suporte.

Fase 3 — Base completa (semanas 9–12): os clientes restantes — incluindo os mais resistentes à mudança digital. Nessa fase, os problemas da plataforma já foram resolvidos e a equipe já tem experiência com as dúvidas mais comuns.

Este modelo permite que os aprendizados de cada fase alimentem a próxima — e garante que o eventual problema que aparece nas primeiras semanas afete 20 clientes, não 800.

Este checklist foi desenvolvido com base nas melhores práticas de implementação do mercado B2B brasileiro, com referência em metodologias de fornecedores como a FastChannel. Para entender como a FastChannel conduz o processo de go-live para cada perfil de operação, visite fastchannel.com.