Prøvetabeller: Nivåer, faktureringsperioder og regler

En prøvetabell gjør et kommersielt tilbud om til strukturerte, sammenlignbare fakta. En kjøper kan se hva hvert nivå koster, når beløpet fornyes, og hva som endres på neste nivå, uten å måtte rekonstruere avtalen fra etiketter, fotnoter og betalingsside-tekst. En maskin kan knytte hvert beløp til riktig valuta, faktureringsperiode, plan, inkluderinger, ekskluderinger og bekreftelsesdato.

Selskapet og planene ovenfor er illustrerende. Strukturen er produksjonsmodellen: valutaen er skrevet som en ISO 4217-kode, gjentakelsen og faktureringsgrunnlaget er separate fakta, begrensninger bruker tall, fravær er tydeliggjort, og bildeteksten bærer datoen da de kommersielle faktaene ble kontrollert.

Hvorfor dette elementet betyr noe

Prissetting skaper beslutningspress fordi en leser samtidig tester betalingsevne, egnethet og risiko. Hvis «$79/måned» faktisk betyr en årlig kostnad på USD 948, eller hvis den nødvendige API-en er et betalt tillegg, er den tilsynelatende prisen ikke beslutningsprisen. Å holde kvalifikasjoner ved siden av beløpet lar kjøpere sammenligne nivåer på samme dimensjoner og avslører overraskelser før betaling.

Det anbefalte nivået må ikke være det eneste fullstendige nivået. Visuell vektlegging kan styre oppmerksomhet, men manglende fakta tvinger leseren til å anta at det fremhevede alternativet er bedre. Tillit kommer fra symmetrisk opplysning: hvert nivå oppgir sitt beløp eller tilbudsstatus, periode, forpliktelse, kjernebegrensninger, vesentlige inkluderinger og ekskluderinger.

Maskinuttrekkbarhet er evnen til en crawler, assistent, feed eller publiseringssystem til å bevare forholdet mellom et faktum og dets emne. Et visuelt kort som splitter «79», «per måned», «fakturert årlig» og «Growth» i urelaterte beholdere overlater dette forholdet til slutning. Semantiske overskrifter avslører den stabile påstanden: «Growth koster USD 79 per måned ekvivalent og faktureres som USD 948 årlig.»

Pris er uvanlig volatil fordi kampanjer, skatter, valutaer, pakking og regionale regler endres. Bekreftelsesdatoen er derfor en del av elementet, ikke dekorasjon: den angir når påstanden ble kontrollert og skaper en oppdateringsutløser.

Når du skal bruke det

Bruk en prøvetabell når to eller flere kjøpbare nivåer, pakker, abonnementer, tjenestenivåer eller volumintervaller deler kommersielle vilkår. Et enkelt produkt kan også bruke det når varianter endrer pris, mengde, løpetid eller inkludert omfang. Det er spesielt nyttig når faktureringsrytme avviker fra det normaliserte sammenligningsbeløpet, for eksempel «USD 20 per måned, fakturert USD 240 årlig.»

Bruk det for avgrensede fakta: planavn, valuta, beløp, faktureringsperiode, minimumsmengde, prøvevilkår, inkluderte enheter, overforbrukspris og ekskluderinger. Forklar hvem hver plan passer for eller hvordan bruk måles i nærliggende prosa.

Flere nesten-treff trenger et annet element:

• Hvis blokken vurderer produkter basert på kvalitet, hastighet, støtte eller et annet ikke-kommersielt kriterium uten å presentere kjøpbare vilkår, bruk en sammenligningstabell i stedet.
• Hvis én kampanje har en utløpsdato, kvalifikasjonsregel, kupong og handlingsoppfordring, bruk en tilbudsboks . Ikke opprett et falskt andre nivå bare for å få en prisoppsett.
• Hvis bare én stabil pris og én kjøpsenhet skal oppgis, bruk en merket prislinje innenfor det tilhørende produkt- eller tjenesteelementet. En firekolonners tabell legger til friksjon uten å forbedre gjenfinning.
• Hvis et tilbud krever avhengige input som seter, lagring og kontraktslengde, bruk en kalkulator med et prissammendrag.
• Hvis hver kunde mottar et forhandlet tilbud, vis prismetoden og forespørselsveien i prosa eller et enkelt tilpasset nivå. Oppdiktede «fra»-priser er ikke åpenhet.
• Hvis blokken lister produktspesifikasjoner uten en kjøpshandling eller kommersielle vilkår, er det en spesifikasjonstabell, selv om én rad tilfeldigvis inneholder en pris.

Skrivereglene for elementer har forrang: velg elementet etter formål, ikke etter overskrift, kortstil eller antall kolonner. En blokk hvis jobb er å presentere nivådelte kommersielle vilkår forblir en prøvetabell selv om temaet viser den som kort.

Hvor du skal plassere det

Plasser den primære prøvetabellen etter at siden har navngitt produktet, målgruppen og verdiforslaget, men før detaljerte innvendinger, attester og den endelige handlingsoppfordringen. På en dedikert prisside er det normalt den første vesentlige delen etter introduksjonen. På en produkt- eller tjenesteside, plasser den etter omfangsforklaringen og før kjøpsdetaljer.

Plasser forutgående prissettingslogikk rett over tabellen. Hvis priser ekskluderer avgifter, krever en årlig forpliktelse, forutsetter fem seter, eller kun gjelder i én region, oppgi denne betingelsen før eller i bildeteksten. Plasser lengre bruks- og overforbruksdefinisjoner rett etter tabellen. Aldri sett et faktum som endrer det tilsynelatende beløpet i en fotnote.

Hold planavn, pris, valuta, rytme, omfang, bekreftelsesdato og kilde som én enhet. Ikke plasser den ved siden av en nedtellingstidtaker, attestkarusell, urelatert datatabell eller motstridende kampanje. Ikke separer beløpet fra «fakturert årlig», plasser en CTA mellom et nivås overskrift og dets ekskluderinger, eller gjenta forskjellige priser lenger ned på siden.

På mobil, behold denne rekkefølgen: planavn, pris og faktureringsgrunnlag, inkluderte elementer, ekskluderte elementer, deretter handling. En matrise kan rulle innenfor et merket område; kort bør stables uten å skille ekskluderinger fra planen.

Anatomi

Den merkede illustrasjonen identifiserer disse delene:

1. Bildetekst: navngir produktet, markedet og prissettingskonteksten slik at tabellen fortsatt gir mening når den er hentet ut.
2. Nivånavn: bruker det offisielle plan- eller pakkenavnet, ikke en improvisert målgruppeetiket.
3. Pris: viser et numerisk beløp eller den eksplisitte statusen «Gratis», «Tilpasset tilbud» eller «Kontakt salg».
4. Valuta: bruker en ISO-kode som USD, EUR eller GBP når et pengebeløp er til stede; et symbol kan vises i tillegg.
5. Normalisert periode: støtter sammenligning, for eksempel per måned eller per 1 000 forespørsler.
6. Faktureringsgrunnlag: angir hva som faktisk faktureres og når, for eksempel «USD 948 fakturert årlig».
7. Inkluderte elementer: navngir de avgjørende funksjonene, mengdene og tjenestenivåene som leveres til den prisen.
8. Ekskluderte elementer: angir hva en rimelig kjøper kunne forvente, men ikke vil motta, inkludert betalte tillegg.
9. Handling: bruker en spesifikk tilgjengelig etikett som «Start Growth-prøveperiode» i stedet for å gjenta «Velg» på hvert nivå.
10. Bekreftelsesdato: registrerer den nøyaktige datoen da beløpene og pakkingen ble kontrollert mot den godkjente kilden.
11. Skatt- og gebyrnotat: angir om viste priser inkluderer gjeldende avgift og identifiserer vesentlige obligatoriske gebyrer.
12. Kilde: identifiserer faktureringskatalogen, den godkjente priskortet eller den kommersielle eieren.

«Gratis» betyr ingen pengeavgift under de angitte betingelsene, ikke en prøveperiode som senere fakturerer. «Tilpasset tilbud» betyr ikke noe offentlig fast beløp, ikke null. «Ikke inkludert» betyr fraværende; «Tillegg» betyr solgt separat og bør oppgi sin pris eller tilbudsrute når den er kjent.

Designeksempler

Hver variant bevarer valuta, periode, faktureringsgrunnlag, omfang, bekreftelsesdato og tilgjengelige relasjoner.

Standard nivåkort: bruk for to til fire planer med korte funksjonssett. Hvert kort er et uavhengig merket nivå med tilsvarende felt justert.

Funksjonsmatrise: bruk når tre til fem nivåer deler mange begrensninger. Plannavn er kolonneoverskrifter og kriterier er radoverskrifter. Gjenta pris og fakturering nær handlingen i en lang tabell, og gi ikoner tekstekvivalenter.

Bruksintervaller: bruk ved angitte kvantumsterskler. Intervallene må være uttømmende og ikke-overlappende: «1–10 000», deretter «10 001–50 000». Oppgi om prising er gradert, volumbasert eller en flat pakke, fordi hver gir en forskjellig faktura.

Hybrid fast og tilpasset: bruk når selvbetjeningsnivåer står ved siden av en forhandlet plan. Det tilpassede nivået trenger fortsatt sin metode, minimumsforpliktelse, omfang og kontaktinformasjon. Bruk aldri «0» eller en bindestrek for et ukjent beløp.

Parametere

Kontrakten skiller overordnede innstillinger fra nivådata fordi valuta og bekreftelse normalt gjelder for samlingen, mens pris, fakturering og omfang tilhører ett nivå. «Kilde» betyr hvor rendreren henter parameteren, ikke hvor den kommersielle påstanden ble undersøkt.

For bruksprising kan period være en enhet som 1000-requests i stedet for en tidsvarighet. Den synlige etiketten må fortsatt leses naturlig. En normalisert månedlig ekvivalent kan vises, men billing må oppgi beløpet som faktisk faktureres, forpliktelsen og faktureringsrytmen.

Syntaks og kodeeksempler

Alle tre notasjonene mapper til de samme ordnede nivåene og kommersielle feltene. Det bærbare direktivet er den kanoniske forfatterformen; Hugo og WordPress er adaptere, ikke separate definisjoner.

Bærbart Markdown-direktiv

:::price-table{caption="Northstar-planer" variant=cards currency=USD market=US verified=2026-08-27 tax-note="Priser ekskluderer gjeldende avgift"}
## Planer for voksende team

::item{price=29 period=P1M billing="USD 29 fakturert månedlig"}
### Starter

Inkludert: 1 arbeidsområde; 3 brukere; e-poststøtte.
Ekskludert: API-tilgang; revisjonslogg.
CTA: [Start Starter-prøveperiode](https://example.com/signup/starter)
::

::item{price=79 period=P1M billing="USD 79 fakturert månedlig" recommended=true}
### Growth

Inkludert: 5 arbeidsområder; 15 brukere; API-tilgang; revisjonslogg.
Ekskludert: Enkel pålogging.
CTA: [Start Growth-prøveperiode](https://example.com/signup/growth)
::

Kilde: godkjent faktureringskatalog, revisjon 2026-08-27.
:::

Den første overordnede overskriften mapper til title. Hver elementoverskrift mapper til tier.name; elementattributter bærer kompakte typede verdier; merkede brødtekstlinjer mapper til inkluderinger, ekskluderinger og handling. Periode bruker en ISO 8601-varighet når den representerer tid: P1M betyr én måned og P1Y betyr ett år.

Hugo shortcode

Den tiltenkte adapteren bruker kun navngitte parametere og bevarer de samme nestede feltene. Dette eksemplet dokumenterer kartleggingen; det krever ikke at en artikkelforfatter oppretter en ny shortcode.

{{< price-table caption="Northstar-planer" variant="cards" currency="USD" market="US" verified="2026-08-27" taxNote="Priser ekskluderer gjeldende avgift" >}}
  {{< price-tier name="Starter" price="29" period="P1M" billing="USD 29 fakturert månedlig" ctaLabel="Start Starter-prøveperiode" ctaUrl="https://example.com/signup/starter" >}}
  Inkludert: 1 arbeidsområde; 3 brukere; e-poststøtte.
  Ekskludert: API-tilgang; revisjonslogg.
  {{< /price-tier >}}
  {{< price-tier name="Growth" price="79" period="P1M" billing="USD 79 fakturert månedlig" recommended="true" ctaLabel="Start Growth-prøveperiode" ctaUrl="https://example.com/signup/growth" >}}
  Inkludert: 5 arbeidsområder; 15 brukere; API-tilgang; revisjonslogg.
  Ekskludert: Enkel pålogging.
  {{< /price-tier >}}
  Kilde: godkjent faktureringskatalog, revisjon 2026-08-27.
{{< /price-table >}}

Rendreren må produsere en <table> med tilhørende overskrifter for en matrise- eller bruksvariant. En kortvariant må bruke en merket liste eller seksjoner hvis overskrift, pris, inkluderinger, ekskluderinger og handling deler én tilgjengelig gruppe. Den må ikke flate ut dataene i anonyme kolonner.

WordPress-blokk

<!-- wp:amicited/price-table {"caption":"Northstar-planer","variant":"cards","currency":"USD","market":"US","verified":"2026-08-27","taxNote":"Priser ekskluderer gjeldende avgift"} -->
  <!-- wp:amicited/price-tier {"name":"Starter","price":"29","period":"P1M","billing":"USD 29 fakturert månedlig","included":["1 arbeidsområde","3 brukere","E-poststøtte"],"excluded":["API-tilgang","Revisjonslogg"],"ctaLabel":"Start Starter-prøveperiode","ctaUrl":"https://example.com/signup/starter"} /-->
  <!-- wp:amicited/price-tier {"name":"Growth","price":"79","period":"P1M","billing":"USD 79 fakturert månedlig","included":["5 arbeidsområder","15 brukere","API-tilgang","Revisjonslogg"],"excluded":["Enkel pålogging"],"ctaLabel":"Start Growth-prøveperiode","ctaUrl":"https://example.com/signup/growth","recommended":true} /-->
  <p>Kilde: godkjent faktureringskatalog, revisjon 2026-08-27.</p>
<!-- /wp:amicited/price-table -->

Den registrerte blokken bør redigere nivådata som felt og rendere semantisk HTML på serveren. Forfattere må ikke bygge om elementet med generiske kolonner, et skjermbilde eller manuelt justerte avsnitt fordi disse formene forkaster den delte kontrakten.

Eksempler

God: kostnad og omfang er eksplisitte

Avgift: priser ekskluderer gjeldende salgsavgift. Kilde: illustrerende godkjent priskort.

Dette fungerer fordi de normaliserte månedlige beløpene er parret med de faktiske årlige kostnadene, begrensninger bruker tall, og forventede ekskluderinger er navngitt. En kjøper kan beregne forpliktelsen uten å åpne et verktøytips. En maskin kan knytte hvert beløp og begrensning til en plan gjennom rad- og kolonneoverskriftene.

Dårlig: det attraktive tallet har ingen kontrakt

| Plan | Pris | Funksjoner | |—:—|—:|—| | Bra | $40/mnd* | ✓ Analyse, ✓ Støtte | | Best | Ring oss | Alt du trenger |

*Vilkår gjelder.

Dette mislykkes av flere uavhengige grunner. Valutaen er utledet fra et symbol, /mnd sier ikke om kjøperen faktureres månedlig eller årlig, og asterisken skjuler det vesentlige vilkåret. Hakekryss har ingen tekststatus, «Støtte» har ingen kanal eller tjenestenivå, og «Alt du trenger» er ikke en verifiserbar inkludering. «Ring oss» identifiserer verken et tilpasset tilbud eller forklarer prismetoden. Det er ingen ekskluderinger, begrensninger, skattenotat, kilde, marked eller bekreftelsesdato. Etikettene «Bra» og «Best» erstatter også overtalelse med offisiell planidentitet.

Skjemamerking og tilgjengelighet

En prøvetabell mater strukturerte data kun for et kvalifisert, ekte tilbud. Et Offer kan bære price, priceCurrency, url, availability og en ekte gyldig-til-dato. Koble flere ekte tilbud til samme produkt eller tjeneste; bruk AggregateOffer kun for en sannferdig lav-til-høy rekkevidde eller tilbudssamling. Et priskort-oppsett alene rettferdiggjør ikke skjema.

Bruk en prisspesifikasjon kun når den nøyaktig uttrykker kontrakten. Hold årlig kostnad, månedlig ekvivalent, minimumsmengde og overforbrukslogikk adskilt i kildedata. Synlig innhold og strukturert utdata må samsvare. Utelat numerisk pris for «Tilpasset tilbud»; bruk null kun for et genuint gratis tilbud.

Skjema gjentar en synlig påstand; det beviser ikke ferskhet. Generer side og strukturert utdata fra samme godkjente kilde og sammenlign dem under QA. Merk aldri en kampanje som permanent, finn opp validThrough, eller eksponer en annen valuta.

En matrise trenger en bildetekst, plankolonneoverskrifter, kriterieradoverskrifter og scope-attributter. Pakk en bred tabell i et navngitt, tastaturfokuserbart område og la området rulle når omflytning ville ødelegge relasjoner.

Kortoppsett trenger tilsvarende gruppering. Gjør hvert nivånavn til en overskrift og hold prisen, faktureringen, listene og CTA-en i én merket seksjon. Skriv «Inkludert», «Ikke inkludert», «Tillegg» og «Anbefalt» i tekst i stedet for å stole på posisjon, farge eller ikoner. En faktureringsveksler må være tastaturbetjent, kunngjøre tilstand, beholde fokus og oppdatere både viste og fakturerte beløp.

Skriveregler

Prisekst er kort fordi kjøpere skanner det under usikkerhet, men kortfattethet må ikke viske ut kontrakten. Oppgi årsaken til hver begrensning før du bruker den:

• Stabile navn forhindrer feilaktige planer. Bruk det offisielle nivånavnet på én til fem ord. Ikke gi nytt navn til «Business Plus» som «Beste verdi» i overskriften; anbefaling er en separat etikett.
• Eksplisitte beløp forhindrer falske sammenligninger. Skriv ISO-valutakoden og tallet sammen, for eksempel «EUR 49.» Hvis avgift, obligatoriske gebyrer eller regionale restriksjoner endrer det betalbare beløpet, oppgi dem i elementet.
• Rytrne bestemmer forpliktelse. Hold den normaliserte perioden til én klar enhet og faktureringsgrunnlaget til to til tolv ord. «Per måned, fakturert årlig ved EUR 588» er tydelig; «fra EUR 49/mnd*» er det ikke.
• Tall gjør begrensninger testbare. Bruk tre til åtte avgjørende inkluderinger per nivå og kvantifiser brukere, prosjekter, lagring, forespørsler, oppbevaring eller responstid. Erstatt «generøse grenser» med den faktiske terskelen.
• Navngitte ekskluderinger forhindrer antagelseshull. Inkluder én til fem ekskluderinger når en rimelig kjøper kunne forvente dem. Oppgi «Enkel pålogging: ikke inkludert» eller «Implementering: betalt tillegg», ikke en bindestrek.
• Parallelt språk forbedrer skanning. Bruk samme substantiv og enhet på tvers av nivåer: «5 brukere», «20 brukere», «Ubegrensede brukere», i stedet for «Lite team», «20 seter» og «Ingen tak.»
• En anbefaling trenger en oppgitt grunn. Bruk høyst ett anbefalt nivå og forklar den faktuelle egnetheten, for eksempel «For team som trenger API-tilgang.» Ikke bruk falsk knapphet, pulserende merker eller en uforklarlig «Mest populær»-påstand.
• Volatilitet krever eierskap. Vis én nøyaktig bekreftelsesdato og én primærkilde. Ikke skriv «Priser korrekte ved publisering» fordi publisering kan være måneder eller år tidligere.
• Kompakte celler bevarer gjenfinning. Hold hver inkludering eller ekskludering på to til åtte ord der det er mulig. Flytt kvalifikasjoner lengre enn én setning under tabellen og lenk dem tilbake med en presis etikett.

Sett aldri attester, konkurrentpåstander, juridiske vilkår, kuponger, nedtellinger eller udokumenterte besparelser inn i nivådata. Bevis, juridiske detaljer og kampanjer hører hjemme i sine egne elementer eller tilstøtende prosa. Beregn besparelser kun fra en verifisert basislinje og total.

Innleggstyper som bruker det

Feltet postTypes i front matter er kilden til dette forholdet. Hver oppførte innleggstype bruker elementet for en spesifikk beslutning, ikke bare fordi siden nevner penger.

QA-sjekkliste

• Samsvarer blokkens formål med en prøvetabell under forrangsregelen?
• Bruker hvert nivå sitt offisielle navn og identifiserer en numerisk pris, Gratis eller Tilpasset tilbud?
• Er hvert pengebeløp parret med en ISO-valutakode og gjeldende marked?
• Er både den normaliserte perioden og beløpet som faktisk faktureres eksplisitte?
• Er årlige totaler, minimumsforpliktelser, oppsettsgebyrer, overforbruk, avgiftsbehandling og betalte tillegg synlige når det er aktuelt?
• Bruker inkluderinger og ekskluderinger parallelle, kvantifiserte etiketter på tvers av nivåer?
• Er bruksintervaller uttømmende, ikke-overlappende og identifisert som gradert, volum eller flat-pakke prising?
• Er bekreftelsesdatoen eksakt, synlig og knyttet til en godkjent kildeeier?
• Viser sideinnhold, betalings- eller faktureringsdata og strukturerte data de samme kommersielle fakta?
• Knytter semantisk merking hver pris og funksjon til riktig nivå?
• Er tabellbildetekster, overskrifter, scopes, kortetiketter, vekslertilstander og CTA-etiketter tilgjengelige?
• Kan elementet flyte om eller rulle innenfor sitt eget merkede område uten horisontal rulling på sidenivå?
• Er farge eller ikonografi støttet av tekst i stedet for å bære Inkludert, Ekskludert eller Anbefalt alene?
• Er et tilpasset tilbud utelatt fra numerisk prisskjema i stedet for kodet som null?
• Er kampanjer, attester, juridisk tekst og lange forklaringer utenfor de kanoniske nivådataene?
• Har noen beregnet på nytt årlige ekvivalenter, besparelsespåstander, kvantumgrenser og overforbrukseksempler?

En prøvetabell er publiserbar bare når en kjøper og en maskin kan rekonstruere samme tilbud fra den. Hvis én av dem må gjette valutaen, forpliktelsen, omfanget eller ferskheten, er elementet ufullstendig.