Tabela de Preços: Camadas, Períodos de Cobrança e Regras

Uma tabela de preços transforma uma oferta comercial em fatos estruturados e comparáveis. Um comprador pode ver quanto cada camada custa, quando a cobrança se repete e o que muda na camada seguinte, sem precisar reconstruir o negócio a partir de rótulos, notas de rodapé e textos do checkout. Uma máquina pode associar cada valor à moeda correta, período de cobrança, plano, inclusões, exclusões e data de verificação.

A empresa e os planos acima são ilustrativos. A estrutura é o modelo de produção: a moeda é escrita como um código ISO 4217, a recorrência e a base de cobrança são fatos separados, os limites usam números, as ausências são explícitas e a legenda traz a data em que os fatos comerciais foram verificados.

Por que este elemento é importante

A precificação gera pressão de decisão porque um leitor está testando simultaneamente acessibilidade, adequação e risco. Se “USD 79/mês” significa, na verdade, uma cobrança anual de USD 948, ou se a API necessária é um adicional pago, o preço aparente não é o preço da decisão. Manter as qualificações junto ao valor permite que os compradores comparem camadas nas mesmas dimensões e exponha surpresas antes do checkout.

A camada recomendada não deve ser a única camada completa. O destaque visual pode guiar a atenção, mas a ausência de fatos força o leitor a assumir que a opção destacada é melhor. A confiança vem da divulgação simétrica: cada camada informa seu valor ou status de orçamento, período, compromisso, limites principais, inclusões relevantes e exclusões.

A extraibilidade por máquina é a capacidade de um crawler, assistente, feed ou sistema de publicação de reter a relação entre um fato e seu assunto. Um cartão visual que separa “79”, “por mês”, “cobrado anualmente” e “Growth” em contêineres não relacionados deixa essa relação para inferência. Cabeçalhos semânticos expõem a afirmação estável: “Growth custa USD 79 por mês equivalente e é cobrado como USD 948 anualmente.”

O preço é excepcionalmente volátil porque promoções, impostos, moedas, pacotes e regras regionais mudam. A data de verificação é, portanto, parte do elemento, não decoração: ela informa quando a afirmação foi verificada e cria um gatilho de atualização.

Quando usar

Use uma tabela de preços quando duas ou mais camadas adquiríveis, pacotes, assinaturas, níveis de serviço ou faixas de volume compartilharem termos comerciais. Um único produto também pode usá-la quando variantes alteram preço, quantidade, prazo ou escopo incluído. É especialmente útil quando a cadência de cobrança difere do valor de comparação normalizado, como “USD 20 por mês, cobrado USD 240 anualmente.”

Use-a para fatos delimitados: nome do plano, moeda, valor, período de cobrança, quantidade mínima, condições de teste, unidades incluídas, taxa de excedente e exclusões. Explique para quem cada plano é adequado ou como o uso é medido em texto próximo.

Vários casos semelhantes precisam de um elemento diferente:

• Se o bloco julga produtos por qualidade, velocidade, suporte ou outro critério não comercial sem apresentar termos adquiríveis, use uma tabela comparativa em vez disso.
• Se uma promoção tem prazo de validade, regra de elegibilidade, cupom e chamada para ação, use uma caixa de oferta . Não crie uma segunda camada fictícia apenas para obter um layout de precificação.
• Se apenas um preço estável e uma unidade de compra precisam ser informados, use uma linha de preço com rótulo dentro do componente de produto ou serviço correspondente. Uma tabela de quatro colunas adiciona atrito sem melhorar a recuperação.
• Se um orçamento exige informações dependentes, como assentos, armazenamento e prazo contratual, use uma calculadora com resumo de preços.
• Se cada cliente recebe um orçamento negociado, mostre a base de precificação e o caminho de consulta em texto ou em uma única camada personalizada. Valores inventados de “a partir de” não são transparência.
• Se o bloco lista especificações de produto sem uma ação de compra ou termos comerciais, é uma tabela de especificações, mesmo que uma linha contenha um preço.

As regras de redação de elementos têm precedência: escolha o elemento pelo seu propósito, não pelo seu título, estilo de cartão ou número de colunas. Um bloco cuja função é expor termos comerciais em camadas continua sendo uma tabela de preços mesmo que o tema o renderize como cartões.

Onde posicionar

Posicione a tabela de preços principal depois que a página tiver nomeado o produto, o público e a proposta de valor, mas antes de objeções detalhadas, depoimentos e a chamada para ação final. Em uma página de preços dedicada, normalmente é a primeira seção substancial após a introdução. Em uma página de produto ou serviço, posicione-a após a explicação do escopo e antes dos detalhes de compra.

Coloque a lógica de precificação pré-requisito imediatamente acima da tabela. Se os preços excluem impostos, exigem compromisso anual, pressupõem cinco assentos ou se aplicam apenas em uma região, informe essa condição antes ou na legenda. Coloque definições mais longas de uso e excedentes diretamente após a tabela. Nunca coloque em nota de rodapé um fato que altere o valor aparente.

Mantenha o nome do plano, preço, moeda, cadência, escopo, data de verificação e fonte como uma unidade. Não o posicione ao lado de um cronômetro de contagem regressiva, carrossel de depoimentos, tabela de dados não relacionada ou promoção conflitante. Não separe o valor de “cobrado anualmente”, coloque um CTA entre o cabeçalho de uma camada e suas exclusões, ou repita preços diferentes mais abaixo na página.

No celular, preserve esta ordem: nome do plano, preço e base de cobrança, itens incluídos, itens excluídos, depois ação. Uma matriz pode rolar dentro de uma região identificada; cartões devem empilhar sem separar as exclusões do seu plano.

Anatomia

A imagem identificada indica estas partes:

1. Legenda: nomeia o produto, mercado e contexto de precificação para que a tabela ainda faça sentido quando extraída.
2. Nome da camada: usa o nome oficial do plano ou pacote, não um rótulo improvisado de público.
3. Preço: mostra um valor numérico ou o status explícito “Grátis”, “Orçamento personalizado” ou “Fale com vendas.”
4. Moeda: usa um código ISO como USD, EUR ou GBP quando há um valor monetário; um símbolo pode aparecer adicionalmente.
5. Período normalizado: apoia a comparação, como por mês ou a cada 1.000 requisições.
6. Base de cobrança: informa o que é efetivamente cobrado e quando, como “USD 948 cobrado anualmente.”
7. Itens incluídos: nomeia as capacidades, quantidades e níveis de serviço decisivos fornecidos naquele preço.
8. Itens excluídos: informa o que um comprador razoável poderia esperar, mas não receberá, incluindo adicionais pagos.
9. Ação: usa um rótulo acessível específico como “Iniciar teste do Growth” em vez de repetir “Escolher” em todas as camadas.
10. Data de verificação: registra a data exata em que os valores e pacotes foram verificados em relação à fonte aprovada.
11. Nota de impostos e taxas: informa se os preços exibidos incluem imposto aplicável e identifica taxas obrigatórias relevantes.
12. Fonte: identifica o catálogo de faturamento, tabela de preços aprovada ou responsável comercial.

“Grátis” significa nenhum encargo monetário sob as condições informadas, não um teste que depois cobra. “Orçamento personalizado” significa nenhum valor fixo público, não zero. “Não incluído” significa ausente; “Adicional” significa vendido separadamente e deve informar seu preço ou caminho de orçamento quando conhecido.

Exemplos de design

Toda variante preserva moeda, período, base de cobrança, escopo, data de verificação e relações acessíveis.

Cartões de camada padrão: use para dois a quatro planos com conjuntos curtos de funcionalidades. Cada cartão é uma camada identificada independentemente com campos equivalentes alinhados.

Matriz de funcionalidades: use quando três a cinco camadas compartilham muitos limites. Os nomes dos planos são cabeçalhos de coluna e os critérios são cabeçalhos de linha. Repita o preço e a cobrança perto da ação em uma tabela longa e forneça equivalentes textuais para ícones.

Faixas de uso: use em limites de quantidade declarados. As faixas devem ser exaustivas e não sobrepostas: “1–10.000”, depois “10.001–50.000.” Informe se a precificação é progressiva, baseada em volume ou pacote fixo, pois cada uma produz uma fatura diferente.

Híbrido fixo e personalizado: use quando camadas de autoatendimento estão ao lado de um plano negociado. A camada personalizada ainda precisa de sua base, compromisso mínimo, escopo e ação de contato. Nunca use “0” ou um traço para um valor desconhecido.

Parâmetros

O contrato separa as configurações do pai dos dados da camada porque moeda e verificação normalmente se aplicam ao conjunto, enquanto preço, cobrança e escopo pertencem a uma camada. “Fonte” significa de onde o renderizador obtém o parâmetro, não onde a alegação comercial foi pesquisada.

Para precificação por uso, period pode ser uma unidade como 1000-requests em vez de uma duração de tempo. O rótulo visível ainda deve ter leitura natural. Um equivalente mensal normalizado pode ser exibido, mas billing deve informar o valor efetivamente cobrado, o compromisso e a cadência da fatura.

Sintaxe e exemplos de código

Todas as três notações mapeiam para as mesmas camadas ordenadas e campos comerciais. A diretiva portátil é a forma canônica de autoria; Hugo e WordPress são adaptadores, não definições separadas.

Diretiva Markdown portátil

:::price-table{caption="Planos Northstar" variant=cards currency=USD market=US verified=2026-08-27 tax-note="Preços não incluem impostos aplicáveis"}
## Planos para equipes em crescimento

::item{price=29 period=P1M billing="USD 29 cobrado mensalmente"}
### Starter

Included: 1 workspace; 3 usuários; suporte por e-mail.
Excluded: Acesso à API; registro de auditoria.
CTA: [Iniciar teste do Starter](https://example.com/signup/starter)
::

::item{price=79 period=P1M billing="USD 79 cobrado mensalmente" recommended=true}
### Growth

Included: 5 workspaces; 15 usuários; acesso à API; registro de auditoria.
Excluded: Login único (SSO).
CTA: [Iniciar teste do Growth](https://example.com/signup/growth)
::

Source: catálogo de faturamento aprovado, revisão 2026-08-27.
:::

O primeiro título pai mapeia para title. Cada título de item mapeia para tier.name; atributos do item carregam valores tipados compactos; linhas do corpo identificadas mapeiam para inclusões, exclusões e ação. O período usa uma duração ISO 8601 quando representa tempo: P1M significa um mês e P1Y significa um ano.

Shortcode Hugo

O adaptador pretendido usa apenas parâmetros nomeados e preserva os mesmos campos aninhados. Este exemplo documenta o mapeamento; não exige que um autor de artigo crie um novo shortcode.

{{< price-table caption="Planos Northstar" variant="cards" currency="USD" market="US" verified="2026-08-27" taxNote="Preços não incluem impostos aplicáveis" >}}
  {{< price-tier name="Starter" price="29" period="P1M" billing="USD 29 cobrado mensalmente" ctaLabel="Iniciar teste do Starter" ctaUrl="https://example.com/signup/starter" >}}
  Included: 1 workspace; 3 usuários; suporte por e-mail.
  Excluded: Acesso à API; registro de auditoria.
  {{< /price-tier >}}
  {{< price-tier name="Growth" price="79" period="P1M" billing="USD 79 cobrado mensalmente" recommended="true" ctaLabel="Iniciar teste do Growth" ctaUrl="https://example.com/signup/growth" >}}
  Included: 5 workspaces; 15 usuários; acesso à API; registro de auditoria.
  Excluded: Login único (SSO).
  {{< /price-tier >}}
  Source: catálogo de faturamento aprovado, revisão 2026-08-27.
{{< /price-table >}}

O renderizador deve produzir uma <table> com cabeçalhos associados para uma variante de matriz ou uso. Uma variante de cartão deve usar uma lista identificada ou seções cujo título, preço, inclusões, exclusões e ação compartilhem um grupo acessível. Não deve achatar os dados em colunas anônimas.

Bloco WordPress

<!-- wp:amicited/price-table {"caption":"Planos Northstar","variant":"cards","currency":"USD","market":"US","verified":"2026-08-27","taxNote":"Preços não incluem impostos aplicáveis"} -->
  <!-- wp:amicited/price-tier {"name":"Starter","price":"29","period":"P1M","billing":"USD 29 cobrado mensalmente","included":["1 workspace","3 usuários","Suporte por e-mail"],"excluded":["Acesso à API","Registro de auditoria"],"ctaLabel":"Iniciar teste do Starter","ctaUrl":"https://example.com/signup/starter"} /-->
  <!-- wp:amicited/price-tier {"name":"Growth","price":"79","period":"P1M","billing":"USD 79 cobrado mensalmente","included":["5 workspaces","15 usuários","Acesso à API","Registro de auditoria"],"excluded":["Login único (SSO)"],"ctaLabel":"Iniciar teste do Growth","ctaUrl":"https://example.com/signup/growth","recommended":true} /-->
  <p>Source: catálogo de faturamento aprovado, revisão 2026-08-27.</p>
<!-- /wp:amicited/price-table -->

O bloco registrado deve editar dados de camada como campos e renderizar HTML semântico no servidor. Os autores não devem reconstruir o elemento com colunas genéricas, uma captura de tela ou parágrafos alinhados manualmente, pois essas formas descartam o contrato compartilhado.

Exemplos

Bom: o valor e o escopo são explícitos

Impostos: os preços não incluem impostos sobre vendas aplicáveis. Fonte: tabela de preços aprovada ilustrativa.

Isso funciona porque os valores mensais normalizados são emparelhados com os encargos anuais reais, os limites usam números e as exclusões esperadas são nomeadas. Um comprador pode calcular o compromisso sem abrir uma dica de ferramenta. Uma máquina pode vincular cada valor e restrição a um plano por meio dos cabeçalhos de linha e coluna.

Ruim: o número atraente não tem contrato

*Termos se aplicam.

Isso falha por várias razões independentes. A moeda é inferida de um símbolo, /mês não informa se o comprador é cobrado mensal ou anualmente, e o asterisco esconde o termo relevante. Marcas de verificação não têm estado textual, “Suporte” não tem canal ou nível de serviço, e “Tudo que você precisa” não é uma inclusão verificável. “Ligue para nós” não identifica um orçamento personalizado nem explica a base de precificação. Não há exclusões, limites, nota de imposto, fonte, mercado ou data de verificação. Os rótulos “Bom” e “Melhor” também substituem a persuasão pela identidade oficial do plano.

Marcação de esquema e acessibilidade

Uma tabela de preços alimenta dados estruturados apenas para uma oferta elegível e real. Uma Offer pode conter price, priceCurrency, url, availability e uma data genuína de validade. Conecte múltiplas ofertas reais ao mesmo produto ou serviço; use AggregateOffer apenas para uma faixa verdadeira de menor para maior ou coleção de ofertas. Um layout de cartão de preços por si só não justifica esquema.

Use uma especificação de preço apenas quando ela expressar com precisão o contrato. Mantenha o valor anual, equivalente mensal, quantidade mínima e lógica de excedente distintos nos dados de origem. O conteúdo visível e a saída estruturada devem concordar. Omita o preço numérico para “Orçamento personalizado”; use zero apenas para uma oferta genuinamente gratuita.

O esquema repete uma afirmação visível; não comprova atualidade. Gere a página e a saída estruturada a partir da mesma fonte aprovada e compare-as durante o QA. Nunca marque uma promoção como permanente, invente validThrough ou exiba uma moeda diferente.

Uma matriz precisa de legenda, cabeçalhos de coluna de plano, cabeçalhos de linha de critério e atributos scope. Envolva uma tabela larga em uma região nomeada e focável por teclado e permita que essa região role quando a reformatação destruiria relacionamentos.

Layouts de cartão precisam de agrupamento equivalente. Transforme cada nome de camada em um título e mantenha seu preço, cobrança, listas e CTA em uma seção identificada. Escreva “Incluído”, “Não incluído”, “Adicional” e “Recomendado” em texto, em vez de depender de posição, cor ou ícones. Uma alternância de cobrança deve ser operável por teclado, anunciar estado, reter foco e atualizar tanto os valores exibidos quanto os cobrados.

Regras de redação

O texto de preço é curto porque os compradores o escaneiam sob incerteza, mas a brevidade não deve apagar o contrato. Informe a razão de cada restrição antes de aplicá-la:

• Nomes estáveis evitam planos incompatíveis. Use o nome oficial da camada em uma a cinco palavras. Não renomeie “Business Plus” como “Melhor valor” no título; a recomendação é um rótulo separado.
• Valores explícitos evitam comparações falsas. Escreva o código da moeda ISO e o número juntos, como “EUR 49.” Se impostos, taxas obrigatórias ou restrições regionais alterarem o valor a pagar, informe-os no elemento.
• Cadência determina compromisso. Mantenha o período normalizado em uma unidade clara e a base de cobrança em duas a doze palavras. “Por mês, cobrado anualmente a EUR 588” é claro; “a partir de EUR 49/mês*” não é.
• Números tornam os limites testáveis. Use três a oito inclusões decisivas por camada e quantifique usuários, projetos, armazenamento, requisições, retenção ou tempo de resposta. Substitua “limites generosos” pelo limite real.
• Exclusões nomeadas evitam lacunas de suposição. Inclua uma a cinco exclusões quando um comprador razoável poderia esperá-las. Informe “Login único (SSO): não incluído” ou “Implementação: adicional pago”, não um traço.
• Linguagem paralela melhora a leitura. Use o mesmo substantivo e unidade entre as camadas: “5 usuários”, “20 usuários”, “Usuários ilimitados”, em vez de “Equipe pequena”, “20 assentos” e “Sem limite.”
• Uma recomendação precisa de uma razão divulgada. Use no máximo uma camada recomendada e explique a adequação factual, como “Para equipes que precisam de acesso à API.” Não use escassez falsa, emblemas pulsantes ou uma alegação de “Mais popular” sem explicação.
• Volatilidade exige responsabilidade. Mostre uma data de verificação exata e uma fonte primária. Não escreva “Preços corretos na data da publicação”, pois a publicação pode ser meses ou anos antes.
• Células compactas preservam a recuperação. Mantenha cada inclusão ou exclusão em duas a oito palavras sempre que possível. Mova qualificações com mais de uma frase para abaixo da tabela e vincule-as de volta com um rótulo preciso.

Nunca coloque depoimentos, alegações sobre concorrentes, termos legais, cupons, contagens regressivas ou economias não fundamentadas dentro dos dados da camada. Evidências, detalhes legais e promoções pertencem a seus próprios elementos ou texto adjacente. Calcule economias apenas a partir de uma linha de base verificada e do total.

Tipos de post que o utilizam

O campo postTypes do frontmatter é a fonte desta relação. Cada tipo de post listado usa o elemento para uma decisão específica, não apenas porque a página menciona dinheiro.

Checklist de QA

• O propósito do bloco corresponde a uma tabela de preços segundo a regra de precedência?
• Cada camada usa seu nome oficial e identifica um preço numérico, Grátis ou Orçamento personalizado?
• Cada valor monetário está emparelhado com um código de moeda ISO e mercado aplicável?
• O período normalizado e o valor efetivamente cobrado estão ambos explícitos?
• Os totais anuais, compromissos mínimos, taxas de configuração, excedentes, tratamento de impostos e adicionais pagos estão visíveis quando aplicáveis?
• As inclusões e exclusões usam rótulos paralelos e quantificados entre as camadas?
• As faixas de uso são exaustivas, não sobrepostas e identificadas como progressivas, por volume ou pacote fixo?
• A data de verificação é exata, visível e vinculada a um proprietário de fonte aprovado?
• O conteúdo da página, os dados de checkout ou faturamento e os dados estruturados mostram os mesmos fatos comerciais?
• A marcação semântica associa cada preço e funcionalidade à camada correta?
• As legendas da tabela, cabeçalhos, escopos, rótulos dos cartões, estados de alternância e rótulos de CTA são acessíveis?
• O elemento pode ser reformatado ou rolado dentro de sua própria região identificada sem rolagem horizontal em nível de página?
• Cor ou iconografia são apoiadas por texto, em vez de carregar sozinhas os significados de Incluído, Excluído ou Recomendado?
• Um orçamento personalizado é omitido do esquema de preço numérico em vez de codificado como zero?
• Promoções, depoimentos, texto legal e explicações longas estão fora dos dados canônicos da camada?
• Alguém recalculou os equivalentes anuais, alegações de economia, limites de quantidade e exemplos de excedentes?

Uma tabela de preços só é publicável quando um comprador e uma máquina podem reconstruir a mesma oferta a partir dela. Se qualquer um dos dois precisar adivinhar a moeda, o compromisso, o escopo ou a atualidade, o elemento está incompleto.