Uma loja VTEX não se orça pelo número de páginas. Ela se orça pelo desenho da operação: quantos canais vendem, de onde vêm os produtos e os preços, quem controla o estoque e por onde o pedido passa depois da compra. A VTEX se apresenta como plataforma para D2C, B2C, B2B e marketplaces, e essa amplitude é justamente o que torna o escopo variável. Duas lojas com o mesmo layout podem ter projetos de tamanhos muito diferentes se uma vende só no site e a outra atende revendas, marketplace e loja física com o mesmo ERP.
Este guia é para quem já está considerando a VTEX e quer chegar à conversa de orçamento com a operação descrita. Se você ainda está decidindo entre ela e outras opções de porte parecido, vale primeiro comparar plataformas para e-commerce empresarial.
O que levantar sobre catálogo, preço, estoque, canais e pedidos?
Cada uma dessas cinco frentes vira configuração, integração ou teste. Descreva cada uma com números aproximados e exemplos reais da sua operação.
Catálogo. A documentação de integração da VTEX organiza o catálogo em árvore de categorias, marcas, especificações (grupos, campos e valores), produtos, SKUs e imagens de SKU. Na prática, levante:
- quantos produtos e quantos SKUs existem, e quantas variações cada produto tem;
- quais atributos o cliente usa para filtrar (tamanho, cor, material, voltagem) e quais são só informativos;
- se há kits, produtos personalizáveis ou anexos (como gravação);
- onde as fichas técnicas e as imagens estão hoje e quem as mantém.
Preço. A VTEX trabalha com preço base e com preços fixos para contextos específicos. Anote se o mesmo SKU tem preços diferentes por canal, por tipo de cliente ou por região, e quem decide esses preços: o ERP, uma planilha comercial ou a própria equipe no painel.
Estoque. O estoque é registrado por armazém (warehouse). Liste quantos depósitos, centros de distribuição ou lojas físicas abastecem os pedidos, com que frequência o saldo muda e qual sistema tem o número correto.
Canais. Aqui entra a política comercial. Segundo a Central de Ajuda da VTEX, ela agrupa configurações de catálogo, preços, promoções, logística, segmentação de clientes e pagamentos, e é preciso criar uma nova quando alguma dessas configurações muda entre canais. A mesma página informa, em consulta de 20/10/2026, que o prazo (SLA) para criação de uma política comercial é de três dias úteis (72 horas) e que o contrato de cada cliente define os parâmetros para contratar políticas adicionais, com regras de cobrança e de isenção. Dois efeitos no projeto: o número de canais com condições próprias precisa estar no escopo desde o início, e o cronograma deve reservar esse prazo antes da configuração de cada canal novo.
Pedidos. Descreva o caminho do pedido depois do pagamento: quem separa, quem fatura, quem emite a nota, quem informa o rastreio. A VTEX documenta quatro eventos que o ERP ou o WMS devolvem à plataforma: alteração de itens, cancelamento, faturamento e rastreamento. Ela também registra duas restrições que afetam o atendimento: o fluxo de pedidos não permite cancelar um pedido já faturado, e cancelamentos não podem ser revertidos.
Quais sistemas participam e quem responde por cada dado?
Depois de descrever a operação, defina o sistema de origem de cada dado. A documentação da VTEX resume a integração completa assim: o back-office envia produtos, preços e estoque para a VTEX e recebe os pedidos dela. Entre os dois fica um middleware, que pode ser uma plataforma de integração de terceiros ou um desenvolvimento próprio. A VTEX alerta que o caminho próprio exige não só construir, mas manter a integração, inclusive nos picos de venda.
| Dado | Sistema de origem mais comum | O que a VTEX recebe ou devolve | Decisão que precisa estar no escopo |
|---|---|---|---|
| Cadastro de produto e SKU | ERP ou PIM | Recebe categorias, marcas, especificações, produtos, SKUs | Quem cria produto novo e em qual sistema |
| Imagens e textos de venda | PIM, DAM ou equipe de e-commerce | Recebe imagens de SKU e descrições | Quem revisa o conteúdo antes de publicar |
| Preço | ERP ou sistema comercial | Recebe preço base e preços por contexto | Se promoções nascem na VTEX ou fora dela |
| Estoque | ERP ou WMS | Recebe saldo por armazém | Frequência de atualização e reserva de segurança |
| Pedido | VTEX | Envia o pedido ao ERP | Em que status o pedido sai e como é confirmado |
| Faturamento e rastreio | ERP, WMS ou transportadora | Recebe nota, código e URL de rastreio | Quem informa o rastreio quando a transportadora não é integrada |
| Clientes | CRM ou base atual | Recebe importação (Master Data) | Quais campos migram e quem consente com o uso |
Essa tabela também separa responsabilidades contratuais. A agência configura a VTEX e testa os fluxos; o fornecedor do ERP ou do conector responde pela parte dele; a equipe da loja mantém cadastro e preços. Quando ninguém é dono de uma linha, o problema aparece no primeiro pedido. O guia sobre os requisitos da integração com ERP detalha o que pedir ao fornecedor do sistema de gestão antes de contratar.
E a vitrine: FastStore ou Store Framework?
A VTEX oferece hoje duas tecnologias de vitrine para lojas novas, FastStore e Store Framework. A terceira, o Legacy CMS Portal, não está mais disponível para lojas VTEX criadas agora, segundo o guia de soluções de storefront. A escolha muda a equipe, o processo de publicação e os aplicativos que funcionam na frente da loja, mas não muda o catálogo, os preços nem o fluxo de pedidos descritos acima. Por isso ela pode ser decidida depois do mapa de operação. Os critérios estão no guia sobre FastStore ou Store Framework na VTEX.
Matriz de requisitos e testes de uma operação demonstrativa
A matriz abaixo é um modelo ilustrativo. Ela descreve uma operação demonstrativa, não um cliente nem um projeto executado: uma marca de calçados que vende no site próprio para consumidor final, atende lojistas revendedores com preço diferente e tem um centro de distribuição e duas lojas físicas. Copie a estrutura e troque as linhas pelos requisitos da sua operação.
| # | Requisito | Sistema responsável | Configuração ou integração na VTEX | Teste de aceite | Critério verificável |
|---|---|---|---|---|---|
| 1 | Produtos com grade de tamanho e cor | ERP | Produto com SKUs por tamanho e cor, especificações de filtro | Importar 20 produtos com grade completa | Todos os SKUs aparecem com filtro de tamanho e cor funcionando |
| 2 | Fotos por cor | Equipe de e-commerce | Imagens vinculadas ao SKU | Trocar a cor na página do produto | A galeria muda para as fotos da cor escolhida |
| 3 | Preço de varejo e preço de revenda | ERP | Duas políticas comerciais, preço por contexto | Consultar o mesmo SKU nos dois canais | Cada canal mostra o preço cadastrado no ERP |
| 4 | Revenda só vê parte do catálogo | Comercial | Produtos restritos à política de revenda | Navegar logado como revendedor e como consumidor | Itens exclusivos aparecem só para o revendedor |
| 5 | Estoque do CD e das lojas | ERP | Armazéns separados, saldo por SKU | Zerar um SKU no ERP | O SKU fica indisponível na loja dentro do intervalo combinado |
| 6 | Retirada em loja física | Operação | Estratégia de envio da política comercial, com a configuração de retirada a validar no contrato e na documentação | Comprar com retirada | O pedido chega ao ERP com a loja de retirada correta |
| 7 | Pedido entra no ERP | Middleware | Feed ou hook de pedidos | Fazer compra paga com cartão de teste | O pedido aparece no ERP com itens, frete e desconto corretos |
| 8 | Faturamento e nota | ERP | Notificação de faturamento | Faturar o pedido de teste | A loja mostra o pedido como faturado, com a nota |
| 9 | Rastreio | Transportadora ou ERP | Código e URL de rastreio na nota | Enviar rastreio do pedido de teste | O cliente vê o link de rastreio no pedido |
| 10 | Troca de item sem estoque | Atendimento | Alteração de pedido | Trocar um SKU antes do faturamento | O valor e os itens ficam iguais nos dois sistemas |
| 11 | Cancelamento | Atendimento | Cancelamento antes do faturamento | Cancelar um pedido não faturado | Status cancelado na VTEX e no ERP, estorno registrado |
| 12 | Pico de pedidos | Middleware | Fila e reprocessamento de falhas | Gerar lote de pedidos de teste em sequência | Nenhum pedido perdido; falhas aparecem em log com reenvio |
Duas colunas fazem essa matriz funcionar. A de sistema responsável diz quem corrige quando o teste falha. A de critério verificável impede que um requisito seja dado como pronto porque “funcionou uma vez”. Antes do orçamento, ela também mostra ao fornecedor o tamanho real do projeto: cada linha com integração representa trabalho de configuração, desenvolvimento ou contratação de conector.
Como definir escopo, homologação e lançamento por critérios verificáveis?
Escopo. Transforme a matriz em uma lista do que entra e do que fica fora da primeira fase. Se a revenda pode esperar, ela sai da fase 1 e as linhas 3 e 4 viram uma etapa posterior, com custo e prazo próprios. Registre também o que é de terceiros: mensalidades de conectores, licenças e o trabalho do fornecedor do ERP.
Homologação. Os testes acontecem antes de a loja ficar pública, com dados de teste e pedidos que não geram entrega real. Combine quem executa cada teste, onde o resultado é registrado e quem assina o aceite. Se a vitrine for em Store Framework, a VTEX documenta espaços de trabalho de desenvolvimento e de produção; em FastStore, um servidor local que não afeta a loja no ar. Em qualquer caso, os fluxos de pedido e ERP precisam ser testados ponta a ponta, não só na tela.
Lançamento. Defina condições objetivas para liberar a loja:
- todas as linhas da fase 1 aprovadas, com evidência (print, número do pedido, registro no ERP);
- catálogo congelado para cadastro durante a virada, com responsável por exceções;
- domínio, certificados e redirecionamentos das URLs antigas prontos, se houver loja anterior;
- plantão combinado para os primeiros dias, com quem acionar em falha de integração;
- critério de recuo: o que acontece se pedidos pararem de chegar ao ERP.
Condições e limites
As informações sobre a VTEX vêm da documentação oficial consultada em 20/10/2026 e podem mudar. Condições comerciais da VTEX, como contrato, cobrança de políticas comerciais adicionais e suporte, dependem do seu contrato com a plataforma e não foram listadas aqui. A matriz é demonstrativa; a sua precisa sair do briefing da operação real. Os testes de pagamento devem usar o ambiente de teste do meio de pagamento escolhido.
Próximo passo
Com a operação mapeada, a próxima decisão técnica é a vitrine: veja como FastStore ou Store Framework na VTEX muda equipe, aplicativos e testes. Se quiser transformar essa matriz em escopo e proposta, com as responsabilidades de cada sistema escritas, conheça a nossa criação de loja na VTEX.
