Pristabeller: Nivåer, faktureringsperioder och regler

En pristabell omvandlar ett kommersiellt erbjudande till strukturerade, jämförbara fakta. En köpare kan se vad varje nivå kostar, när avgiften återkommer och vad som förändras vid nästa nivå utan att rekonstruera erbjudandet från etiketter, fotnoter och kassatext. En maskin kan associera varje belopp med rätt valuta, faktureringsperiod, plan, inkluderingar, undantag och verifieringsdatum.

Företaget och planerna ovan är illustrativa. Strukturen är produktionsmodellen: valutan skrivs som en ISO 4217-kod, återkomsten och faktureringsunderlaget är separata fakta, gränser använder siffror, frånvaro är explicit, och bildtexten bär datumet då de kommersiella uppgifterna kontrollerades.

Varför detta element är viktigt

Prissättning skapar beslutsstress eftersom en läsare samtidigt testar prisvärdhet, passform och risk. Om “79 USD/månad” egentligen innebär en årlig avgift på 948 USD, eller om det nödvändiga API:et är en betald tilläggstjänst, är det angivna priset inte beslutspriset. Att hålla villkoren bredvid beloppet låter köpare jämföra nivåer på samma dimensioner och avslöjar överraskningar före kassan.

Den rekommenderade nivån får inte vara den enda fullständiga nivån. Visuell betoning kan styra uppmärksamheten, men saknade fakta tvingar läsaren att anta att det markerade alternativet är bättre. Förtroende kommer från symmetrisk redovisning: varje nivå anger sitt belopp eller offertstatus, period, åtagande, kärngränser, väsentliga inkluderingar och undantag.

Maskinutdragbarhet är förmågan hos en crawler, assistent, feed eller publiceringssystem att behålla relationen mellan ett faktum och dess ämne. Ett visuellt kort som splittrar “79”, “per månad”, “faktureras årligen” och “Growth” i orelaterade behållare lämnar den relationen till gissning. Semantiska rubriker exponerar det stabila påståendet: “Growth kostar USD 79 per månad motsvarande och debiteras som USD 948 årligen.”

Priser är ovanligt volatila eftersom kampanjer, skatter, valutor, paketeringar och regionala regler förändras. Verifieringsdatumet är därför en del av elementet, inte dekoration: det anger när påståendet kontrollerades och skapar en utlösare för uppdatering.

När ska det användas

Använd en pristabell när två eller fler köpbara nivåer, paket, prenumerationer, tjänstenivåer eller volymband delar kommersiella villkor. En enskild produkt kan också använda den när varianter ändrar pris, kvantitet, löptid eller ingående omfattning. Den är särskilt användbar när faktureringsintervall skiljer sig från det normaliserade jämförelsebeloppet, såsom “USD 20 per månad, debiteras USD 240 årligen.”

Använd den för avgränsade fakta: planens namn, valuta, belopp, faktureringsperiod, minimikvantitet, provperiodsvillkor, ingående enheter, överskottsavgift och undantag. Förklara vem varje plan passar eller hur användning mäts i närliggande text.

Flera närliggande fall behöver ett annat element:

• Om blocket bedömer produkter efter kvalitet, hastighet, support eller annat icke-kommersiellt kriterium utan att presentera köpbara villkor, använd en jämförelsetabell istället.
• Om ett erbjudande har ett utgångsdatum, behörighetsregel, kupong och uppmaning till handling, använd en erbjudanderuta . Skapa inte en falsk andra nivå enbart för att få en prislayout.
• Om endast ett stabilt pris och en köpenhet behöver anges, använd en märkt prisrad inom den tillhörande produkt- eller tjänstekomponenten. En fyrakolumners tabell skapar friktion utan att förbättra hämtbarheten.
• Om en offert kräver beroende indata såsom platser, lagring och kontraktslängd, använd en kalkylator med en prissammanfattning.
• Om varje kund får en förhandlad offert, visa prissättningsgrunden och kontaktvägen i löptext eller en enda anpassad nivå. Påhittade “från och med”-belopp är inte transparens.
• Om blocket listar produktspecifikationer utan en köpaktion eller kommersiella villkor, är det en spec-tabell, även om en rad råkar innehålla ett pris.

Skrivreglerna för element har företräde: välj elementet efter dess syfte, inte efter dess rubrik, kortstil eller antal kolumner. Ett block vars uppgift är att exponera nivåbaserade kommersiella villkor förblir en pristabell även om temat renderar det som kort.

Var ska den placeras

Placera den primära pristabellen efter att sidan har namngett produkten, målgruppen och värdeerbjudandet, men före detaljerade invändningar, vittnesmål och den slutliga uppmaningen till handling. På en dedikerad prissida är den normalt den första väsentliga sektionen efter introduktionen. På en produkt- eller tjänstesida, placera den efter omfattningsförklaringen och före köpdetaljer.

Sätt prissättningslogik som förutsätts omedelbart ovanför tabellen. Om priser exkluderar skatt, kräver ett årligt åtagande, förutsätter fem platser eller endast gäller i en region, ange det villkoret före eller i bildtexten. Lägg längre användnings- och överskottsdefinitioner direkt efter tabellen. Använd aldrig en fotnot för ett faktum som ändrar det angivna beloppet.

Håll planens namn, pris, valuta, intervall, omfattning, verifieringsdatum och källa som en enhet. Placera det inte bredvid en nedräkningstimer, vittnesmålskarussell, orelaterad datatabell eller motstridig kampanj. Separera inte beloppet från “faktureras årligen,” placera inte en CTA mellan en nivårubrik och dess undantag, och upprepa inte olika priser längre ner på sidan.

På mobil, bevara denna ordning: planens namn, pris och faktureringsunderlag, inkluderade artiklar, exkluderade artiklar, sedan åtgärd. En matris kan rullas inuti en märkt region; kort bör staplas utan att separera undantag från sin plan.

Anatomi

Den märkta bilden identifierar dessa delar:

1. Bildtext: namnger produkten, marknaden och prissättningskontexten så att tabellen fortfarande är begriplig när den extraheras.
2. Nivånamn: använder det officiella plan- eller paketnamnet, inte en improviserad målgruppsetikett.
3. Pris: visar ett numeriskt belopp eller den explicita statusen “Gratis,” “Anpassad offert” eller “Kontakta sälj.”
4. Valuta: använder en ISO-kod såsom USD, EUR eller GBP när ett valuta-belopp finns; en symbol kan visas som tillägg.
5. Normaliserad period: underlättar jämförelse, såsom per månad eller per 1 000 förfrågningar.
6. Faktureringsunderlag: anger vad som faktiskt debiteras och när, såsom “USD 948 faktureras årligen.”
7. Inkluderade artiklar: namnger de avgörande funktionerna, kvantiteterna och tjänstenivåerna som tillhandahålls till det priset.
8. Exkluderade artiklar: anger vad en rimlig köpare kan förvänta sig men inte kommer att få, inklusive betalda tillägg.
9. Åtgärd: använder en specifik tillgänglig etikett såsom “Starta Growth-testversion” istället för att upprepa “Välj” på varje nivå.
10. Verifieringsdatum: anger det exakta datum då beloppen och paketeringen kontrollerades mot den godkända källan.
11. Skatt- och avgiftsnot: anger om visade priser inkluderar tillämplig skatt och identifierar materiella obligatoriska avgifter.
12. Källa: identifierar faktureringskatalogen, godkänd prislista eller kommersiella ägare.

“Gratis” betyder ingen monetär avgift under de angivna villkoren, inte en testversion som senare fakturerar. “Anpassad offert” betyder inget offentligt fast belopp, inte noll. “Ingår inte” betyder frånvarande; “Tillägg” betyder säljs separat och bör namnge sitt pris eller offertväg när det är känt.

Designexempel

Varje variant bevarar valuta, period, faktureringsunderlag, omfattning, verifieringsdatum och tillgängliga relationer.

Standardnivåkort: använd för två till fyra planer med korta funktionslistor. Varje kort är en oberoende märkt nivå med motsvarande fält i linje.

Funktionsmatris: använd när tre till fem nivåer delar många begränsningar. Planens namn är kolumnrubriker och kriterier är radrubriker. Upprepa pris och fakturering nära åtgärden i en lång tabell och ge ikoner textekvivalenter.

Användningsband: använd vid angivna kvantitetströsklar. Räckvidder måste vara uttömmande och icke-överlappande: “1–10 000,” sedan “10 001–50 000.” Ange om prissättningen är graderad, volymbaserad eller ett fast paket eftersom varje ger en annan faktura.

Hybrid fast och anpassad: använd när självbetjäningsnivåer sitter bredvid en förhandlad plan. Den anpassade nivån behöver fortfarande sin grund, minimiåtagande, omfattning och kontaktåtgärd. Använd aldrig “0” eller ett streck för ett okänt belopp.

Parametrar

Kontraktet separerar överordnade inställningar från nivådata eftersom valuta och verifiering normalt gäller för samlingen, medan pris, fakturering och omfattning tillhör en nivå. “Källa” betyder var renderaren hämtar parametern, inte var det kommersiella påståendet undersöktes.

För användningsprissättning kan period vara en enhet såsom 1000-requests snarare än en tidsvaraktighet. Den synliga etiketten måste fortfarande låta naturlig. En normaliserad månadsekvivalent kan visas, men billing måste ange det belopp som faktiskt debiteras, åtagandet och faktureringsintervallet.

Syntax och kodexempel

Alla tre notationerna mappar till samma ordnade nivåer och kommersiella fält. Det portabla direktivet är den kanoniska författade formen; Hugo och WordPress är adaptrar, inte separata definitioner.

Bärbart Markdown-direktiv

:::price-table{caption="Northstar plans" variant=cards currency=USD market=US verified=2026-08-27 tax-note="Prices exclude applicable tax"}
## Plans for growing teams

::item{price=29 period=P1M billing="USD 29 billed monthly"}
### Starter

Included: 1 workspace; 3 users; email support.
Excluded: API access; audit log.
CTA: [Start Starter trial](https://example.com/signup/starter)
::

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

Included: 5 workspaces; 15 users; API access; audit log.
Excluded: Single sign-on.
CTA: [Start Growth trial](https://example.com/signup/growth)
::

Source: approved billing catalogue, revision 2026-08-27.
:::

Den första överordnade rubriken mappar till title. Varje objektsrubrik mappar till tier.name; objektsattribut bär kompakta typade värden; märkta brödtextrader mappar till inkluderingar, undantag och åtgärd. Period använder en ISO 8601-varaktighet när den representerar tid: P1M betyder en månad och P1Y betyder ett år.

Hugo-shortcode

Den avsedda adaptern använder endast namngivna parametrar och bevarar samma nästlade fält. Detta exempel dokumenterar mappningen; det kräver inte att en artikel-författare skapar en ny shortcode.

{{< price-table caption="Northstar plans" variant="cards" currency="USD" market="US" verified="2026-08-27" taxNote="Prices exclude applicable tax" >}}
  {{< price-tier name="Starter" price="29" period="P1M" billing="USD 29 billed monthly" ctaLabel="Start Starter trial" ctaUrl="https://example.com/signup/starter" >}}
  Included: 1 workspace; 3 users; email support.
  Excluded: API access; audit log.
  {{< /price-tier >}}
  {{< price-tier name="Growth" price="79" period="P1M" billing="USD 79 billed monthly" recommended="true" ctaLabel="Start Growth trial" ctaUrl="https://example.com/signup/growth" >}}
  Included: 5 workspaces; 15 users; API access; audit log.
  Excluded: Single sign-on.
  {{< /price-tier >}}
  Source: approved billing catalogue, revision 2026-08-27.
{{< /price-table >}}

Renderaren måste producera en <table> med associerade rubriker för en matris- eller användningsvariant. En kortvariant måste använda en märkt lista eller sektioner vars rubrik, pris, inkluderingar, undantag och åtgärd delar en tillgänglig grupp. Den får inte platta ut datan i anonyma kolumner.

WordPress-block

<!-- wp:amicited/price-table {"caption":"Northstar plans","variant":"cards","currency":"USD","market":"US","verified":"2026-08-27","taxNote":"Prices exclude applicable tax"} -->
  <!-- wp:amicited/price-tier {"name":"Starter","price":"29","period":"P1M","billing":"USD 29 billed monthly","included":["1 workspace","3 users","Email support"],"excluded":["API access","Audit log"],"ctaLabel":"Start Starter trial","ctaUrl":"https://example.com/signup/starter"} /-->
  <!-- wp:amicited/price-tier {"name":"Growth","price":"79","period":"P1M","billing":"USD 79 billed monthly","included":["5 workspaces","15 users","API access","Audit log"],"excluded":["Single sign-on"],"ctaLabel":"Start Growth trial","ctaUrl":"https://example.com/signup/growth","recommended":true} /-->
  <p>Source: approved billing catalogue, revision 2026-08-27.</p>
<!-- /wp:amicited/price-table -->

Det registrerade blocket bör redigera nivådata som fält och rendera semantisk HTML på servern. Författare får inte återskapa elementet med generiska kolumner, en skärmbild eller manuellt justerade stycken eftersom dessa former förkastar det delade kontraktet.

Exempel

Bra: avgiften och omfattningen är tydliga

Skatt: priser exkluderar tillämplig försäljningsskatt. Källa: illustrativ godkänd prislista.

Detta fungerar eftersom de normaliserade månadsbeloppen är parade med de faktiska årliga avgifterna, gränser använder siffror och förväntade undantag är namngivna. En köpare kan beräkna åtagandet utan att öppna ett verktygstips. En maskin kan binda varje belopp och begränsning till en plan genom rad- och kolumnrubrikerna.

Dåligt: det attraktiva numret har inget kontrakt

*Villkor gäller.

Detta misslyckas av flera oberoende skäl. Valutan är härledd från en symbol, /mo säger inte om köparen debiteras månadsvis eller årligen, och asterisken döljer den väsentliga termen. Bockmarkeringar har ingen textstatus, “Support” har ingen kanal eller tjänstenivå, och “Allt du behöver” är inte en verifierbar inkludering. “Ring oss” identifierar varken en anpassad offert eller förklarar prissättningsgrunden. Det finns inga undantag, gränser, skattenot, källa, marknad eller verifieringsdatum. Etiketterna “Good” och “Best” ersätter också övertalning med officiell planidentitet.

Schema-markup och tillgänglighet

En pristabell matar strukturerad data endast för ett behörigt, verkligt erbjudande. En Offer kan bära price, priceCurrency, url, availability och ett äkta giltigt-till-datum. Koppla flera verkliga erbjudanden till samma produkt eller tjänst; använd AggregateOffer endast för en sanningsenlig låg-till-hög-intervall eller erbjudandesamling. En priskortslayout i sig själv motiverar inte schema.

Använd en prisspecifikation endast när den korrekt uttrycker kontraktet. Håll årlig avgift, månadsekvivalent, minimikvantitet och överskottslogik åtskilda i källdata. Synligt innehåll och strukturerad utdata måste överensstämma. Utelämna numeriskt pris för “Anpassad offert”; använd noll endast för ett genuint gratis erbjudande.

Schema upprepar ett synligt påstående; det bevisar inte färskhet. Generera sida och strukturerad utdata från samma godkända källa och jämför dem under QA. Märk aldrig en kampanj som permanent, hitta inte på validThrough eller exponera en annan valuta.

En matris behöver en bildtext, kolumnrubriker för planer, radrubriker för kriterier och scope-attribut. Slå in en bred tabell i en namngiven, tangentbordsfokuserbar region och låt den regionen rulla när omflöde skulle förstöra relationer.

Kortlayouter behöver motsvarande gruppering. Gör varje nivånamn till en rubrik och håll dess pris, fakturering, listor och CTA i en märkt sektion. Skriv “Ingår,” “Ingår inte,” “Tillägg” och “Rekommenderas” i text snarare än att förlita dig på position, färg eller ikoner. En faktureringsväxling måste vara tangentbordskontrollerbar, meddela sitt tillstånd, behålla fokus och uppdatera både visade och debiterade belopp.

Skrivregler

Pristext är kort eftersom köpare skummar den under osäkerhet, men korthet får inte radera kontraktet. Ange skälet för varje begränsning innan du tillämpar den:

• Stabila namn förhindrar felaktiga planer. Använd det officiella nivånamnet på ett till fem ord. Döp inte om “Business Plus” till “Bästa värde” i rubriken; rekommendation är en separat etikett.
• Explicita belopp förhindrar falska jämförelser. Skriv ISO-valutakoden och numret tillsammans, till exempel “EUR 49.” Om skatt, obligatoriska avgifter eller regionala restriktioner ändrar det betalbara beloppet, ange dem i elementet.
• Intervall avgör åtagandet. Håll den normaliserade perioden till en tydlig enhet och faktureringsunderlaget till två till tolv ord. “Per månad, faktureras årligen vid EUR 588” är tydligt; “från EUR 49/mo*” är det inte.
• Siffror gör gränser testbara. Använd tre till åtta avgörande inkluderingar per nivå och kvantifiera användare, projekt, lagring, förfrågningar, lagringstid eller svarstid. Byt ut “generösa gränser” mot den faktiska tröskeln.
• Namngivna undantag förhindrar antagandeluckor. Inkludera ett till fem undantag när en rimlig köpare skulle kunna förvänta sig dem. Ange “Enkel inloggning: ingår inte” eller “Implementering: betald tilläggstjänst,” inte ett streck.
• Parallellt språk förbättrar överskådligheten. Använd samma substantiv och enhet över nivåer: “5 användare,” “20 användare,” “Obegränsat antal användare,” snarare än “Litet team,” “20 platser” och “Ingen begränsning.”
• En rekommendation behöver ett redovisat skäl. Använd högst en rekommenderad nivå och förklara den faktiska passformen, såsom “För team som behöver API-åtkomst.” Använd inte falsk brist, pulserande märken eller ett oförklarat “Mest populär”-påstående.
• Volatilitet kräver ägarskap. Visa ett exakt verifieringsdatum och en primär källa. Skriv inte “Priser korrekta vid publicering” eftersom publicering kan vara månader eller år tidigare.
• Kompakta celler bevarar hämtbarhet. Håll varje inkludering eller undantag på två till åtta ord där möjligt. Flytta kvalifikationer längre än en mening nedanför tabellen och länka tillbaka med en precis etikett.

Placera aldrig vittnesmål, konkurrentpåståenden, juridiska villkor, kuponger, nedräkningar eller ogrundade besparingar inuti nivådata. Bevis, juridisk detalj och kampanjer hör hemma i sina egna element eller angränsande text. Beräkna besparingar endast från en verifierad baslinje och totalsumma.

Inläggstyper som använder det

Fältet postTypes i frontmatter är källan till denna relation. Varje listad inläggstyp använder elementet för ett specifikt beslut, inte bara för att sidan nämner pengar.

QA-checklista

• Matchar blockets syfte en pristabell enligt företrädesregeln?
• Använder varje nivå sitt officiella namn och identifierar ett numeriskt pris, Gratis eller Anpassad offert?
• Är varje prisbelopp parat med en ISO-valutakod och tillämplig marknad?
• Är både den normaliserade perioden och det faktiskt debiterade beloppet tydliga?
• Är årliga totalbelopp, minimiåtaganden, installationsavgifter, överskott, skattehantering och betalda tillägg synliga när tillämpligt?
• Använder inkluderingar och undantag parallella, kvantifierade etiketter över nivåer?
• Är användningsband uttömmande, icke-överlappande och identifierade som graderad, volymbaserad eller fast-paketprissättning?
• Är verifieringsdatumet exakt, synligt och kopplat till en godkänd källägare?
• Visar sidinnehåll, kassa- eller faktureringsdata och strukturerad data samma kommersiella fakta?
• Associerar semantisk markup varje pris och funktion med rätt nivå?
• Är tabellbildtexter, rubriker, scopes, kortetiketter, växlingslägen och CTA-etiketter tillgängliga?
• Kan elementet flöda om eller rulla inom sin egen märkta region utan horisontell rullning på sidnivå?
• Stöds färg eller ikonografi av text snarare än att bära Ingår, Ingår inte eller Rekommenderas ensamt?
• Utelämnas en anpassad offert från numeriskt prisschema snarare än kodad som noll?
• Är kampanjer, vittnesmål, juridisk text och långa förklaringar utanför den kanoniska nivådatan?
• Har någon räknat om årliga motsvarigheter, besparingspåståenden, kvantitetsgränser och överskottsexempel?

En pristabell är publiceringsbar endast när en köpare och en maskin kan rekonstruera samma erbjudande från den. Om någon av dem måste gissa valutan, åtagandet, omfattningen eller färskheten, är elementet ofullständigt.