← Voltar ao blog

WooCommerce e regras de envio: quando o checkout tem de acompanhar o negócio

Portes grátis, levantamento, ilhas, peso e produtos com regras diferentes parecem simples até coexistirem no mesmo carrinho. O segredo está em modelar os cenários antes de escrever código.

WooCommerce e regras de envio: quando o checkout tem de acompanhar o negócio

Configurar envios numa loja pequena pode parecer simples: Portugal Continental custa X, acima de determinado valor os portes são grátis e existe uma opção de levantamento.

Depois chegam as exceções.

Um produto só pode ser levantado. Outro só pode ser enviado. Alguns produtos são vendidos ao peso. Para as ilhas existe um limite. Certos artigos têm transportadora própria. E, inevitavelmente, um cliente adiciona ao carrinho dois produtos com regras incompatíveis.

É aqui que o envio deixa de ser uma configuração e passa a ser lógica de negócio.

O erro mais comum: pensar apenas em métodos de envio

WooCommerce organiza os métodos a partir de shipping zones. Cada morada corresponde a uma zona e essa zona disponibiliza métodos como taxa fixa, envio gratuito ou levantamento.

É uma base sólida, mas nem sempre representa todas as regras de um negócio. A geografia responde a “para onde vai a encomenda?”. Muitas lojas também precisam de responder a “o que está dentro do carrinho?” e “que combinações são permitidas?”.

Antes do código, faço uma matriz de cenários

Quando existem regras especiais, tento escrevê-las primeiro em linguagem normal. Por exemplo:

  • Produto A: envio ou levantamento.
  • Produto B: apenas levantamento.
  • Produto C: apenas envio.
  • Portugal Continental: portes grátis a partir de 100 €.
  • Ilhas: transporte disponível apenas até determinado peso.

Depois testo combinações:

  • A sozinho;
  • B sozinho;
  • C sozinho;
  • A + B;
  • A + C;
  • B + C.

É normalmente nesta última parte que aparecem os conflitos que uma configuração simples não resolve.

Carrinhos mistos precisam de uma decisão de negócio

Imagine um produto que só pode ser levantado e outro que só pode ser enviado. Tecnicamente podemos tentar dividir a encomenda em pacotes, mostrar dois métodos ou bloquear a combinação.

Mas qual é a solução correta? Depende da operação.

Se a empresa consegue preparar duas entregas independentes, dividir pode fazer sentido. Se não consegue, a interface deve avisar o cliente antes de chegar ao fim do checkout.

A pior solução é deixar o cliente preencher dados, escolher pagamento e só depois descobrir que aquela encomenda não é possível.

Portes grátis também têm exceções

“Envio grátis acima de 100 €” parece uma regra global. Mas será mesmo?

Algumas perguntas que faço:

  • Aplica-se a todas as zonas?
  • Aplica-se a ilhas?
  • Produtos muito pesados estão incluídos?
  • O valor mínimo é calculado antes ou depois de cupões?
  • Se existe envio gratuito, a taxa paga deve continuar visível?

O WooCommerce permite configurar envio gratuito com condições e organizar métodos por zona, mas regras que cruzam localização, produtos e peso podem exigir configuração adicional ou desenvolvimento personalizado.

Classes de envio ajudam, mas não resolvem tudo

As shipping classes são úteis para agrupar produtos com custos ou características semelhantes. Por exemplo, podemos ter classes para produtos standard, pesados ou com condições específicas e usar essas classes no cálculo das taxas.

Funcionam muito bem quando a diferença é essencialmente de custo. Quando a regra é “este produto nunca pode usar este método”, normalmente é preciso acrescentar lógica para filtrar os métodos disponíveis.

Produtos vendidos ao peso introduzem outra camada

Em alguns negócios, o valor mostrado no carrinho é uma estimativa porque o peso final só é conhecido durante a preparação.

Nesse caso, não basta calcular. É preciso comunicar:

  • preço por kg;
  • peso estimado por unidade;
  • valor estimado no carrinho;
  • possibilidade de ajuste após preparação.

O checkout deve evitar surpresas. Uma regra tecnicamente correta pode continuar a ser uma má experiência se o cliente não perceber de onde veio o valor.

A clareza do checkout faz parte da implementação

Quando escondo ou mostro métodos dinamicamente, preocupo-me também com o texto que acompanha essa decisão.

“Não existem métodos de envio disponíveis” é uma mensagem tecnicamente verdadeira e pouco útil.

É melhor explicar: “Este carrinho contém produtos que apenas podem ser levantados” ou “Para esta morada, o envio deste produto não está disponível”. A pessoa percebe o problema e sabe o que pode fazer.

As regras devem existir num único sítio

À medida que uma loja cresce, é fácil espalhar condições por snippets diferentes: uma no carrinho, outra no checkout, outra no email e mais uma no cálculo de portes.

Isto torna a manutenção arriscada. Sempre que possível, tento centralizar a decisão em funções claras e reutilizar o resultado nas diferentes interfaces.

Também evito depender de nomes visíveis dos métodos de envio quando existe um identificador estável que pode ser usado. O nome que o cliente vê pode mudar; a lógica interna não deve partir por causa disso.

Uma matriz de testes vale tanto como o código

Antes de considerar uma regra concluída, testo pelo menos:

  • cada tipo de produto isoladamente;
  • carrinhos mistos;
  • abaixo, igual e acima do limite de portes grátis;
  • diferentes zonas geográficas;
  • utilizador autenticado e visitante;
  • cupões, quando interferem no valor mínimo;
  • alteração da morada durante o checkout;
  • quantidades e pesos nos limites;
  • mobile e desktop.

É precisamente nos limites que os bugs aparecem: 99,99 €, 100 €, 100,01 €; 1,99 kg, 2 kg, 2,01 kg.

Plugin ou desenvolvimento à medida?

Não tenho uma preferência automática. Se um plugin conhecido resolve a regra de forma clara e sustentável, faz sentido usá-lo. Se a loja tem uma combinação muito específica de regras, adicionar três plugins para tentar aproximar o comportamento desejado pode aumentar a complexidade.

A decisão que procuro é a que deixa o sistema mais fácil de compreender e manter.

A melhor regra de envio é aquela que o cliente consegue entender

Num projeto de e-commerce, o objetivo não é apenas obter o valor certo no final. É garantir que a operação consegue cumprir o prometido e que o cliente percebe as opções apresentadas.

Por isso, quando uma configuração de envios começa a ficar complexa, faço uma pausa no código e volto ao processo:

  • que produtos existem?
  • para onde podem ir?
  • como podem chegar lá?
  • que combinações não são possíveis?
  • o que precisa de ser explicado ao cliente?

Depois disso, a implementação deixa de ser uma coleção de exceções e passa a refletir uma regra que conseguimos explicar.

Leitura adicional

A documentação oficial do WooCommerce explica a base das shipping zones, da entrega gratuita e das taxas fixas e classes de envio.

Continua a ler

Mais notas & ideias