Pilar C: Avaliação técnica aprofundada Avançado

Como testar uma plataforma e-commerce B2B com dados reais: guia de PoC em 2 semanas

Guia prático para conduzir uma PoC (Prova de Conceito) de plataforma e-commerce B2B com dados reais em 2 semanas: o que preparar, o roteiro semana a semana, cenários obrigatórios de teste e critérios de aprovação.

Para: Gerentes de TI, gerentes de projetos, analistas de e-commerce, diretores de tecnologia 11 min de leitura

Como testar uma plataforma e-commerce B2B com dados reais: guia de PoC em 2 semanas

Uma demo de plataforma B2B mostra o melhor cenário possível, com os melhores dados, conduzida por quem conhece o sistema de trás para frente. A PoC (Prova de Conceito) mostra como a plataforma se comporta com seus dados, no seu contexto, com suas regras de negócio.

A diferença entre os dois é a diferença entre uma test drive em pista fechada e um dia de uso real no trânsito da cidade.

A maioria das empresas contrata plataformas B2B com base em demos. As que conduzem uma PoC estruturada raramente se arrependem — porque ou confirmam a escolha com muito mais confiança, ou descobrem problemas antes de assinar o contrato.

Este guia descreve como conduzir uma PoC de 2 semanas que realmente testa o que importa.


Por que demos não são suficientes — o caso para a PoC

Demos têm três limitações estruturais que nenhum fornecedor vai admitir explicitamente:

Dados sintéticos e limpos: a demo usa um catálogo de 200 produtos perfeitamente formatados, 5 clientes fictícios com dados perfeitos, e preços simples sem exceção. Seu catálogo real tem 8.000 produtos, alguns com códigos duplicados, descrições inconsistentes e múltiplas unidades de medida. O comportamento da plataforma com seus dados reais pode ser muito diferente.

Fluxos ideais: a demo mostra o pedido funcionando perfeitamente. Nunca mostra o que acontece quando o produto está sem estoque no momento do checkout, quando o cliente não tem crédito disponível, quando o CFOP do produto é incomum ou quando a integração com o ERP falha temporariamente.

Performance controlada: a demo acontece com um banco de dados vazio, conexão de internet excelente e um usuário. Seu portal vai ser acessado por 200 clientes simultâneos, com catálogo de 15.000 SKUs sincronizando com o ERP a cada 5 minutos.

Uma PoC bem conduzida testa exatamente o que a demo oculta.


O que preparar antes de iniciar a PoC

A PoC falha quando começa sem preparo adequado. Os fornecedores que querem "ir logo para o teste" sem preparação prévia frequentemente querem esconder que a configuração vai demorar mais do que prometido.

Dados a preparar (responsabilidade do contratante)

Amostra de clientes: selecione 30 a 50 clientes reais para a PoC. A amostra deve incluir:

  • 5 clientes com tabelas de preço diferentes entre si
  • 3 clientes com histórico de pedido mínimo diferente do padrão
  • 2 clientes com restrição de crédito ou condição especial de pagamento
  • 2 clientes novos (sem histórico de pedido)
  • Clientes de estados diferentes (para testar CFOP interestadual)

Exporte do ERP os dados desses clientes: CNPJ, razão social, endereço fiscal, endereço de entrega, tabela de preço, condição de pagamento, limite de crédito, representante associado.

Amostra de produtos: selecione 200 a 500 produtos para a PoC. Inclua:

  • Produtos com estoque zero
  • Produtos com múltiplas unidades de medida
  • Produtos com tabela de preço diferente por cliente
  • Produtos com desconto por volume
  • Produtos com restrição de acesso por perfil de cliente (se existir)
  • Produtos com imagem e produtos sem imagem (para ver como a plataforma trata os dois)

Tabelas de preço: exporte as tabelas de preço dos clientes da amostra para os produtos da amostra. Se existirem descontos por volume, inclua a estrutura de descontos.

Regras de negócio documentadas: antes de começar a PoC, documente por escrito:

  • Regras de pedido mínimo (por valor, por quantidade, por cliente)
  • Regras de aprovação de pedido (se existirem)
  • Regras de visibilidade de catálogo por perfil de cliente
  • Regras de CFOP por tipo de operação e destino

Acesso a preparar (responsabilidade do fornecedor)

Ambiente de PoC: instância dedicada ou ambiente de sandbox, isolada de qualquer dado de produção, com performance equivalente ao ambiente de produção (não uma instância compartilhada degradada).

Conector de ERP em modo leitura: para a PoC, você precisa testar a integração com o ERP real — não com dados importados manualmente. O conector deve conseguir ler estoque e preço do ERP. Operações de escrita (enviar pedido para o ERP) podem ser feitas em ambiente de homologação do ERP.

Usuários de teste: criar 5 logins com perfis diferentes (cliente A com tabela X, cliente B com tabela Y, representante, administrador, aprovador).


Roteiro semana a semana

Semana 1: configuração e integração básica

Dias 1–2: importação de dados e configuração inicial

Fornecedor importa a amostra de clientes e produtos no ambiente de PoC. Configura grupos de cliente, tabelas de preço, regras de pedido mínimo e permissões de catálogo conforme as regras documentadas.

Você valida: todos os 500 produtos aparecem no portal? Com as informações corretas (nome, código, unidade de medida)? Produtos sem imagem estão sinalizados de alguma forma?

Dias 2–3: integração de estoque e preço

Conector é configurado para ler estoque e preço do ERP. Você executa os primeiros testes de validação:

Teste de estoque:

  • Produto X tem 80 unidades no ERP → portal deve mostrar 80 disponíveis
  • Altere o estoque no ERP para 20 unidades → portal deve refletir em até 5 minutos
  • Zere o estoque no ERP → portal deve mostrar indisponível antes de 10 minutos

Teste de preço:

  • Acesse o portal com login do cliente A → o preço do produto Y deve ser o da tabela A
  • Acesse com login do cliente B → preço do mesmo produto deve ser diferente (tabela B)
  • Altere a tabela de preços no ERP → portal deve refletir em tempo real

Dias 4–5: fluxo de pedido básico

Configure o endpoint de envio de pedidos para o ERP de homologação. Execute o primeiro fluxo completo:

  1. Login com usuário de teste
  2. Busca por produto no catálogo
  3. Adição ao carrinho
  4. Checkout com condição de pagamento correta
  5. Confirmação do pedido
  6. Verificar que o pedido chegou ao ERP de homologação com todos os campos corretos

O que verificar no pedido no ERP:

  • Código do cliente correto (não só o CNPJ — o código interno do ERP)
  • Tabela de preço usada correta
  • Condição de pagamento correta
  • Endereço de entrega correto
  • Representante associado correto
  • CFOP correto para o tipo de operação

Se o pedido não chegou ou chegou com dados incorretos, pause a PoC e resolva antes de continuar. Um fluxo de pedido quebrado invalida todos os testes seguintes.

Semana 2: cenários de exceção e validação completa

Dias 6–7: cenários de exceção

Os cenários de exceção são onde a maioria das plataformas mostra suas limitações. Execute cada um e documente o resultado:

Cenário 1: pedido abaixo do mínimo Monte um pedido que não atinge o valor mínimo configurado. O que acontece? O sistema bloqueia com mensagem clara? A mensagem informa quanto falta para atingir o mínimo? O cliente consegue finalizar o pedido sem atingir o mínimo? (não deveria)

Cenário 2: produto sem estoque no checkout Monte um carrinho com produto disponível. Antes de finalizar o pedido, zere o estoque desse produto no ERP. Finalize o pedido. O que acontece? O sistema identifica a indisponibilidade? Permite finalizar mesmo assim? Bloqueia? Com qual mensagem?

Cenário 3: cliente sem crédito disponível Acesse com o login de um cliente com crédito zero ou negativo. Tente fazer um pedido. O sistema bloqueia antes do checkout? Com mensagem clara? O pedido entra em fila de aprovação especial ou simplesmente não passa?

Cenário 4: produto com desconto por volume Configure um produto com desconto por volume (até 10 unidades: preço X; acima de 10: preço Y). Adicione 8 unidades ao carrinho — o preço deve ser X. Aumente para 12 — o preço deve mudar para Y automaticamente. Isso funciona em tempo real ou só ao finalizar?

Cenário 5: aprovação de pedido (se configurado) Monte um pedido acima do limite de aprovação. O pedido entra no fluxo de aprovação? O aprovador recebe notificação? Aprovando o pedido, ele é enviado ao ERP? Rejeitando, o solicitante é notificado com o comentário?

Cenário 6: produto com restrição de perfil Acesse com usuário de um perfil que não tem acesso a determinada categoria. Esses produtos não devem aparecer no catálogo nem ser acessíveis por URL direta.

Dias 8–9: integração de status e notificações

Teste de status de pedido: Com um pedido no ERP de homologação, altere o status (aprovado → em separação → faturado). Quanto tempo leva para o portal refletir cada mudança? O cliente logado vê a atualização de status sem precisar recarregar a página?

Teste de notificações:

  • Pedido confirmado: cliente recebe e-mail de confirmação? Representante recebe notificação?
  • Mudança de status: cliente é notificado quando o pedido é faturado?
  • Pedido aguardando aprovação: aprovador recebe notificação em quanto tempo?

Dias 10–11: performance e usabilidade

Teste de busca com catálogo completo: Importe o catálogo completo (não só a amostra de 500 — o catálogo real). Execute buscas com termos ambíguos, termos parciais, códigos de produto. A busca retorna resultados relevantes em menos de 2 segundos?

Teste em mobile: Acesse o portal pelo smartphone. Navegue pelo catálogo, adicione produtos ao carrinho, execute o checkout. O layout está adequado? Imagens carregam em velocidade razoável em 4G?

Teste de carga básico (se o fornecedor disponibilizar): Solicite ao fornecedor um relatório de performance com 20–50 usuários simultâneos navegando e fazendo pedidos. Tempo de resposta degradou significativamente?

Dias 12–14: documentação e decisão

Preencha a matriz de resultados (veja abaixo), reúna a equipe interna envolvida no teste, apresente os resultados e tome a decisão: avançar para proposta comercial, avançar com ressalvas (lista de itens que precisam ser resolvidos antes do contrato), ou não avançar.


Documentando os resultados da PoC

Para cada cenário testado, registre:

Cenário Resultado esperado Resultado obtido Status Observações
Estoque atualiza em 5 min Sim Sim, em 3 min
Preço por cliente correto Sim Divergência no cliente C Tabela C não importou corretamente
Pedido abaixo do mínimo bloqueado Sim Bloqueou, msg clara
Produto sem estoque no checkout Bloquear Permitiu finalizar Crítico — oversell possível

Os itens com status ✗ são classificados em:

  • Bloqueador crítico: impede o go-live. Precisa ser resolvido antes do contrato ou com SLA definido em contrato.
  • Bloqueador importante: precisa ser resolvido antes do go-live, mas pode ser aceito com comprometimento formal do fornecedor.
  • Melhoria desejável: não impede o go-live, mas deve ter prazo de resolução no plano de projeto.

Critérios de aprovação: o que precisa funcionar para avançar

Critérios de aprovação obrigatórios (todos precisam passar):

  • Sincronização de estoque com latência abaixo do acordado
  • Preço correto para todos os clientes da amostra
  • Fluxo de pedido completo (portal → ERP) sem erro nos 10 pedidos de teste
  • Produtos sem estoque bloqueados no checkout
  • Pedido abaixo do mínimo bloqueado com mensagem clara
  • Clientes sem crédito bloqueados antes do checkout

Critérios de aprovação com margem (pelo menos 4 dos 6 precisam passar):

  • Performance de busca abaixo de 2 segundos com catálogo completo
  • Status de pedido atualizado em até 15 minutos
  • Notificações de pedido chegando dentro de 5 minutos
  • Portal funcional em mobile para fluxo de pedido básico
  • Aprovação de pedido funcionando conforme fluxo configurado
  • Catálogo com restrições de acesso funcionando corretamente

Se um critério obrigatório não passou, não avance para o contrato sem resolução documentada. Avançar com a esperança de que o fornecedor vai resolver depois do contrato é um dos erros mais comuns — e mais custosos — em projetos de e-commerce B2B.


Como comparar resultados entre fornecedores

Se você está avaliando mais de um fornecedor, execute a PoC com os mesmos dados e os mesmos cenários em cada um. A comparação objetiva fica muito mais clara quando o contexto é idêntico.

Pontos de comparação objetivos:

  • Latência de sincronização de estoque (tempo medido, não declarado)
  • Número de cenários de exceção que passaram sem ajuste
  • Tempo de configuração para chegar ao fluxo de pedido funcionando
  • Número de erros ou comportamentos inesperados durante a PoC
  • Qualidade e velocidade das respostas do time técnico durante o teste

A PoC também revela aspectos intangíveis que importam muito na prática: a equipe técnica do fornecedor está presente e proativa durante o teste? Quando um problema aparece, a resposta vem em horas ou dias? O fornecedor documenta os problemas encontrados ou tenta minimizá-los?

Esses indicadores comportamentais durante a PoC são preditores confiáveis do que vai ser o suporte pós-implantação.


A FastChannel disponibiliza ambiente de PoC com os dados reais do cliente — incluindo integração com ERP em modo de homologação e suporte técnico durante as 2 semanas de avaliação. Para iniciar uma PoC, visite fastchannel.com.

Leia também