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:
- Login com usuário de teste
- Busca por produto no catálogo
- Adição ao carrinho
- Checkout com condição de pagamento correta
- Confirmação do pedido
- 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.