Prisskemaer: Niveauer, faktureringsperioder og regler

Et prisskema omdanner et kommercielt tilbud til strukturerede, sammenlignelige fakta. En køber kan se, hvad hvert niveau koster, hvornår opkrævningen gentages, og hvad der ændrer sig ved næste niveau, uden at skulle rekonstruere aftalen ud fra etiketter, fodnoter og checkout-tekst. En maskine kan knytte hvert beløb til den korrekte valuta, faktureringsperiode, abonnement, inkluderinger, ekskluderinger og verifikationsdato.

Virksomheden og abonnementerne ovenfor er illustrative. Strukturen er produktionsmodellen: valutaen er skrevet som en ISO 4217-kode, gentagelsen og faktureringsgrundlaget er separate fakta, grænser bruger tal, fravær er eksplicitte, og billedteksten bærer datoen for, hvornår de kommercielle fakta blev kontrolleret.

Hvorfor dette element er vigtigt

Prissætning skaber beslutningspres, fordi en læser samtidig tester overkommelighed, egnethed og risiko. Hvis “79 $/måned” faktisk betyder en årlig opkrævning på 948 USD, eller hvis den nødvendige API er et betalt tilvalg, er den tilsyneladende pris ikke beslutningsprisen. At holde kvalifikationer ved siden af beløbet lader købere sammenligne niveauer på de samme dimensioner og afslører overraskelser før checkout.

Det anbefalede niveau må ikke være det eneste komplette niveau. Visuel fremhævning kan guide opmærksomhed, men manglende fakta tvinger læseren til at antage, at den fremhævede mulighed er bedre. Tillid kommer fra symmetrisk oplysning: ethvert niveau angiver sit beløb eller tilbudsstatus, periode, forpligtelse, kernegrænser, væsentlige inkluderinger og ekskluderinger.

Maskinekstraherbarhed er evnen hos en crawler, assistent, feed eller publiceringssystem til at bevare forholdet mellem en kendsgerning og dens emne. Et visuelt kort, der deler “79”, “pr. måned”, “faktureres årligt” og “Growth” op i ikke-relaterede beholdere, overlader dette forhold til inferens. Semantiske overskrifter eksponerer den stabile udsagn: “Growth koster USD 79 pr. måned ækvivalent og opkræves som USD 948 årligt.”

Pris er usædvanligt volatil, fordi kampagner, skatter, valutaer, pakker og regionale regler ændrer sig. Verifikationsdatoen er derfor en del af elementet, ikke dekoration: den angiver, hvornår påstanden blev kontrolleret, og skaber en opdateringsudløser.

Hvornår skal det bruges

Brug et prisskema, når to eller flere købbare niveauer, pakker, abonnementer, serviceniveauer eller volumenbånd deler kommercielle vilkår. Et enkelt produkt kan også bruge det, når varianter ændrer pris, kvantitet, løbetid eller inkluderet omfang. Det er især nyttigt, når faktureringsrytmen afviger fra det normaliserede sammenligningsbeløb, såsom “USD 20 pr. måned, opkræves USD 240 årligt.”

Brug det til afgrænsede fakta: abonnementsnavn, valuta, beløb, faktureringsperiode, minimumskvantum, prøvevilkår, inkluderede enheder, overforbrugspris og ekskluderinger. Forklar, hvem hvert abonnement passer til, eller hvordan brug måles, i tilstødende prosa.

Flere næsten-korrekte tilfælde kræver et andet element:

• Hvis blokken vurderer produkter på kvalitet, hastighed, support eller et andet ikke-kommercielt kriterium uden at præsentere købbare vilkår, skal du i stedet bruge en sammenligningstabel .
• Hvis én kampagne har en udløbsdato, berettigelsesregel, kupon og handlingsopfordring, skal du bruge en tilbudsboks . Opret ikke et falsk andet niveau blot for at opnå et prisopsætning.
• Hvis kun én stabil pris og én købsenhed skal angives, skal du bruge en mærket prislinje inden for det tilhørende produkt- eller servicekomponent. En tabel med fire kolonner tilføjer friktion uden at forbedre genfinding.
• Hvis et tilbud kræver afhængige input såsom pladser, lagerplads og kontraktlængde, skal du bruge en lommeregner med et prisoversigt.
• Hvis hver kunde modtager et forhandlet tilbud, skal du vise prissætningsgrundlaget og forespørgselsvejen i prosa eller et enkelt skræddersyet niveau. Opfundne “fra”-priser er ikke gennemsigtighed.
• Hvis blokken viser produktspecifikationer uden en købshandling eller kommercielle vilkår, er det en spec-tabel, selv når en række tilfældigvis indeholder en pris.

Elementets skriveregler har forrang: vælg elementet efter dets formål, ikke efter dets overskrift, kortstil eller antal kolonner. En blok, hvis opgave er at eksponere niveaudelte kommercielle vilkår, forbliver et prisskema, selvom temaet gengiver det som kort.

Hvor skal det placeres

Placer det primære prisskema efter at siden har navngivet produktet, målgruppen og værditilbuddet, men før detaljerede indvendinger, udtalelser og den endelige handlingsopfordring. På en dedikeret prisside er det normalt det første væsentlige afsnit efter introduktionen. På en produkt- eller serviceside placeres det efter omfangsforklaringen og før købsdetaljer.

Placer forudsætningsbestemt prissætningslogik umiddelbart over tabellen. Hvis priser ekskluderer moms, kræver en årlig forpligtelse, forudsætter fem pladser eller kun gælder i én region, angiv da denne betingelse før eller i billedteksten. Placer længere brugs- og overforbrugsdefinitioner direkte efter tabellen. Brug aldrig en fodnote til en kendsgerning, der ændrer det tilsyneladende beløb.

Hold abonnementsnavn, pris, valuta, rytme, omfang, verifikationsdato og kilde som én enhed. Placer det ikke ved siden af en nedtællingstimer, testimonial-karrusel, ikke-relateret datatabel eller modstridende kampagne. Adskil ikke beløbet fra “faktureres årligt,” placer ikke en CTA mellem et niveauoverskrift og dets ekskluderinger, eller gentag forskellige priser længere nede på siden.

På mobil bevares denne rækkefølge: abonnementsnavn, pris og faktureringsgrundlag, inkluderede elementer, ekskluderede elementer, derefter handling. En matrix kan scrolle inden for et mærket område; kort bør stables uden at adskille ekskluderinger fra deres abonnement.

Anatomi

Den mærkede illustration identificerer disse dele:

1. Billedtekst: navngiver produktet, markedet og prissætningskonteksten, så tabellen stadig giver mening, når den ekstraheres.
2. Niveau navn: bruger det officielle abonnements- eller pakkenavn, ikke en improviseret målgruppeetiket.
3. Pris: viser et numerisk beløb eller den eksplicitte status “Gratis,” “Skræddersyet tilbud” eller “Kontakt salg.”
4. Valuta: bruger en ISO-kode såsom USD, EUR eller GBP, når et valutabeløb er til stede; et symbol kan forekomme derudover.
5. Normaliseret periode: understøtter sammenligning, såsom pr. måned eller pr. 1.000 forespørgsler.
6. Faktureringsgrundlag: angiver, hvad der faktisk opkræves og hvornår, såsom “USD 948 faktureres årligt.”
7. Inkluderede elementer: navngiver de afgørende kapaciteter, mængder og serviceniveauer, der leveres til den pågældende pris.
8. Ekskluderede elementer: angiver, hvad en rimelig køber kunne forvente, men ikke vil modtage, inklusive betalte tilvalg.
9. Handling: bruger en specifik tilgængelig etiket såsom “Start Growth-prøveperiode” frem for at gentage “Vælg” på hvert niveau.
10. Verifikationsdato: registrerer den præcise dato, hvor beløbene og pakkerne blev kontrolleret mod den godkendte kilde.
11. Skatte- og gebyrnote: angiver, om viste priser inkluderer gældende skat, og identificerer væsentlige obligatoriske gebyrer.
12. Kilde: identificerer faktureringskataloget, den godkendte prisseddel eller den kommercielle ejer.

“Gratis” betyder ingen pengeopkrævning under de angivne betingelser, ikke en prøveperiode, der senere fakturerer. “Skræddersyet tilbud” betyder intet offentligt fast beløb, ikke nul. “Ikke inkluderet” betyder fraværende; “Tilvalg” betyder sælges separat og bør angive sin pris eller tilbudsvej, når kendt.

Designeksempler

Hver variant bevarer valuta, periode, faktureringsgrundlag, omfang, verifikationsdato og tilgængelige relationer.

Standard niveaukort: brug til to til fire abonnementer med korte funktionssæt. Hvert kort er et uafhængigt mærket niveau med tilsvarende felter justeret.

Funktionsmatrix: brug, når tre til fem niveauer deler mange grænser. Abonnementsnavne er kolonneoverskrifter og kriterier er rækkeoverskrifter. Gentag pris og fakturering nær handlingen i en lang tabel, og giv ikoner tekstaekvivalenter.

Forbrugsbånd: brug ved angivne mængdetærskler. Intervaller skal være udtømmende og ikke-overlappende: “1–10.000,” derefter “10.001–50.000.” Angiv, om prissætningen er gradueret, volumenbaseret eller en fast pakke, da hver producerer en forskellig faktura.

Hybrid fast og skræddersyet: brug, når selvbetjeningsniveauer sidder ved siden af et forhandlet abonnement. Det skræddersyede niveau har stadig brug for sit grundlag, minimumsforpligtelse, omfang og kontaktaktion. Brug aldrig “0” eller en bindestreg for et ukendt beløb.

Parametre

Kontrakten adskiller overordnede indstillinger fra niveaudata, fordi valuta og verifikation normalt gælder for samlingen, mens pris, fakturering og omfang tilhører ét niveau. “Kilde” betyder, hvor rendereren henter parameteren, ikke hvor den kommercielle påstand blev undersøgt.

Ved forbrugsprissætning kan period være en enhed såsom 1000-requests i stedet for en tidsvarighed. Den synlige etiket skal stadig læses naturligt. En normaliseret månedlig ækvivalent kan vises, men billing skal angive det beløb, der faktisk opkræves, forpligtelsen og faktureringsrytmen.

Syntaks og kodeeksempler

Alle tre notationer mapper til de samme ordnede niveauer og kommercielle felter. Det bærbare direktiv er den kanoniske forfatters form; Hugo og WordPress er adaptere, ikke separate definitioner.

Bærbart Markdown-direktiv

:::price-table{caption="Northstar-abonnementer" variant=cards currency=USD market=US verified=2026-08-27 tax-note="Priser ekskluderer gældende skat"}
## Abonnementer til voksende teams

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

Inkluderet: 1 workspace; 3 brugere; e-mail-support.
Ekskluderet: API-adgang; revisionslog.
CTA: [Start Starter-prøveperiode](https://example.com/signup/starter)
::

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

Inkluderet: 5 workspaces; 15 brugere; API-adgang; revisionslog.
Ekskluderet: Single sign-on.
CTA: [Start Growth-prøveperiode](https://example.com/signup/growth)
::

Kilde: godkendt faktureringskatalog, revision 2026-08-27.
:::

Den første overordnede overskrift mapper til title. Hver elementoverskrift mapper til tier.name; elementattributter bærer kompakte typede værdier; mærkede brødtekstlinjer mapper til inkluderinger, ekskluderinger og handling. Periode bruger en ISO 8601-varighed, når den repræsenterer tid: P1M betyder én måned og P1Y betyder ét år.

Hugo shortcode

Den tiltænkte adapter bruger kun navngivne parametre og bevarer de samme indlejrede felter. Dette eksempel dokumenterer mappingen; det kræver ikke, at en artikel forfatter opretter en ny shortcode.

{{< price-table caption="Northstar-abonnementer" variant="cards" currency="USD" market="US" verified="2026-08-27" taxNote="Priser ekskluderer gældende skat" >}}
  {{< price-tier name="Starter" price="29" period="P1M" billing="USD 29 faktureres månedligt" ctaLabel="Start Starter-prøveperiode" ctaUrl="https://example.com/signup/starter" >}}
  Inkluderet: 1 workspace; 3 brugere; e-mail-support.
  Ekskluderet: API-adgang; revisionslog.
  {{< /price-tier >}}
  {{< price-tier name="Growth" price="79" period="P1M" billing="USD 79 faktureres månedligt" recommended="true" ctaLabel="Start Growth-prøveperiode" ctaUrl="https://example.com/signup/growth" >}}
  Inkluderet: 5 workspaces; 15 brugere; API-adgang; revisionslog.
  Ekskluderet: Single sign-on.
  {{< /price-tier >}}
  Kilde: godkendt faktureringskatalog, revision 2026-08-27.
{{< /price-table >}}

Rendereren skal producere en <table> med tilhørende overskrifter til en matrix- eller forbrugsvariant. En kortvariant skal bruge en mærket liste eller sektioner, hvis overskrift, pris, inkluderinger, ekskluderinger og handling deler én tilgængelig gruppe. Den må ikke flade dataene ud i anonyme kolonner.

WordPress-blok

<!-- wp:amicited/price-table {"caption":"Northstar-abonnementer","variant":"cards","currency":"USD","market":"US","verified":"2026-08-27","taxNote":"Priser ekskluderer gældende skat"} -->
  <!-- wp:amicited/price-tier {"name":"Starter","price":"29","period":"P1M","billing":"USD 29 faktureres månedligt","included":["1 workspace","3 brugere","E-mail-support"],"excluded":["API-adgang","Revisionslog"],"ctaLabel":"Start Starter-prøveperiode","ctaUrl":"https://example.com/signup/starter"} /-->
  <!-- wp:amicited/price-tier {"name":"Growth","price":"79","period":"P1M","billing":"USD 79 faktureres månedligt","included":["5 workspaces","15 brugere","API-adgang","Revisionslog"],"excluded":["Single sign-on"],"ctaLabel":"Start Growth-prøveperiode","ctaUrl":"https://example.com/signup/growth","recommended":true} /-->
  <p>Kilde: godkendt faktureringskatalog, revision 2026-08-27.</p>
<!-- /wp:amicited/price-table -->

Den registrerede blok bør redigere niveaudata som felter og gengive semantisk HTML på serveren. Forfattere må ikke genopbygge elementet med generiske kolonner, et skærmbillede eller manuelt justerede afsnit, fordi disse former kasserer den fælles kontrakt.

Eksempler

Godt: opkrævning og omfang er eksplicitte

Skat: priser ekskluderer gældende salgsskat. Kilde: illustrativ godkendt prisseddel.

Dette virker, fordi de normaliserede månedlige beløb er parret med de faktiske årlige opkrævninger, grænser bruger tal, og forventede ekskluderinger er navngivet. En køber kan beregne forpligtelsen uden at åbne en tooltip. En maskine kan binde hvert beløb og begrænsning til et abonnement gennem række- og kolonneoverskrifterne.

Dårligt: det attraktive tal har ingen kontrakt

*Vilkår gælder.

Dette fejler af flere uafhængige årsager. Valutaen udledes fra et symbol, /md siger ikke, om køberen faktureres månedligt eller årligt, og asterisken skjuler det væsentlige vilkår. Flueben har ingen tekststatus, “Support” har ingen kanal eller serviceniveau, og “Alt du behøver” er ikke en verificerbar inkludering. “Ring til os” identificerer hverken et skræddersyet tilbud eller forklarer prissætningsgrundlaget. Der er ingen ekskluderinger, grænser, skattenote, kilde, marked eller verifikationsdato. Etiketterne “God” og “Bedst” erstatter også overtalelse for officiel abonnementsidentitet.

Skemamarkup og tilgængelighed

Et prisskema leverer strukturerede data kun for et berettiget, ægte tilbud. Et Offer kan bære price, priceCurrency, url, availability og en ægte gyldig-til-dato. Forbind flere ægte tilbud til det samme produkt eller den samme tjeneste; brug AggregateOffer kun for en sandfærdig lav-til-høj rækkevidde eller tilbudssamling. Et priskort-layout alene retfærdiggør ikke skema.

Brug en prisspecifikation kun, når den præcist udtrykker kontrakten. Hold årlig opkrævning, månedlig ækvivalent, minimumskvantum og overforbrugslogik adskilt i kildedata. Synligt indhold og struktureret output skal stemme overens. Udela numerisk pris for “Skræddersyet tilbud”; brug kun nul for et ægte gratis tilbud.

Skema gentager en synlig påstand; det beviser ikke friskhed. Generer side og struktureret output fra den samme godkendte kilde og sammenlign dem under QA. Markér aldrig en kampagne som permanent, opfind ikke validThrough, eller eksponer en anden valuta.

En matrix har brug for en billedtekst, abonnementskolonneoverskrifter, kriterierækkeoverskrifter og scope-attributter. Indpak en bred tabel i et navngivet, tastaturfokuserbart område og lad dette område scrolle, når reflow ville ødelægge relationer.

Kortlayout har brug for ækvivalent gruppering. Gør hvert niveau navn til en overskrift og hold dets pris, fakturering, lister og CTA i én mærket sektion. Skriv “Inkluderet,” “Ikke inkluderet,” “Tilvalg” og “Anbefalet” i tekst frem for at stole på position, farve eller ikoner. En faktureringskontakt skal være tastaturbetjenelig, annoncere tilstand, bevare fokus og opdatere både viste og opkrævede beløb.

Skriveregler

Pristekst er kort, fordi købere skanner den under usikkerhed, men korthed må ikke slette kontrakten. Angiv årsagen til hver begrænsning, før du anvender den:

• Stabile navne forhindrer misforståede abonnementer. Brug det officielle niveau navn på ét til fem ord. Omdøb ikke “Business Plus” til “Bedste værdi” i overskriften; anbefaling er en separat etiket.
• Eksplicitte beløb forhindrer falske sammenligninger. Skriv ISO-valutakoden og tallet sammen, såsom “EUR 49.” Hvis skat, obligatoriske gebyrer eller regionale begrænsninger ændrer det betalbare beløb, angiv dem i elementet.
• Rytme bestemmer forpligtelse. Hold den normaliserede periode til én klar enhed og faktureringsgrundlaget på to til tolv ord. “Pr. måned, faktureres årligt til EUR 588” er klart; “fra EUR 49/md*” er det ikke.
• Tal gør grænser testbare. Brug tre til otte afgørende inkluderinger pr. niveau og kvantificér brugere, projekter, lagerplads, forespørgsler, opbevaring eller svartid. Erstat “rigelige grænser” med den faktiske tærskel.
• Navngivne ekskluderinger forhindrer antagelseskløfter. Inkludér én til fem ekskluderinger, når en rimelig køber kunne forvente dem. Angiv “Single sign-on: ikke inkluderet” eller “Implementering: betalt tilvalg,” ikke en bindestreg.
• Parallelsprog forbedrer skanning. Brug det samme navneord og enhed på tværs af niveauer: “5 brugere,” “20 brugere,” “Ubegrænsede brugere,” frem for “Lille team,” “20 pladser” og “Ingen begrænsning.”
• En anbefaling har brug for en oplyst årsag. Brug højst ét anbefalet niveau og forklar den faktuelle egnethed, såsom “Til teams, der har brug for API-adgang.” Brug ikke falsk knaphed, pulserende badges eller en uforklaret “Mest populær”-påstand.
• Volatilitet kræver ejerskab. Vis én præcis verifikationsdato og én primær kilde. Skriv ikke “Priser korrekte ved udgivelse,” fordi udgivelse kan være måneder eller år tidligere.
• Kompakte celler bevarer genfinding. Hold hver inkludering eller ekskludering på to til otte ord, hvor det er muligt. Flyt kvalifikationer længere end én sætning under tabellen og link dem tilbage med en præcis etiket.

Placer aldrig udtalelser, konkurrentpåstande, juridiske vilkår, kuponer, nedtællinger eller uunderstøttede besparelser inde i niveaudata. Beviser, juridiske detaljer og kampagner hører til i deres egne elementer eller tilstødende prosa. Beregn kun besparelser ud fra en verificeret baseline og total.

Posttyper, der bruger det

Feltet postTypes i front matter er kilden til dette forhold. Hver anførte posttype bruger elementet til en specifik beslutning, ikke blot fordi siden nævner penge.

QA-tjekliste

• Matcher blokkens formål et prisskema under forrangsreglen?
• Bruger hvert niveau sit officielle navn og identificerer en numerisk pris, Gratis eller Skræddersyet tilbud?
• Er hvert pengebeløb parret med en ISO-valutakode og gældende marked?
• Er både den normaliserede periode og det beløb, der faktisk faktureres, eksplicitte?
• Er årlige totaler, minimumsforpligtelser, opsætningsgebyrer, overforbrug, skattebehandling og betalte tilvalg synlige, når de er relevante?
• Bruger inkluderinger og ekskluderinger parallelle, kvantificerede etiketter på tværs af niveauer?
• Er forbrugsbånd udtømmende, ikke-overlappende og identificeret som gradueret, volumen eller fastpakke-prissætning?
• Er verifikationsdatoen præcis, synlig og knyttet til en godkendt kildeejer?
• Viser sideindhold, checkout- eller faktureringsdata og strukturerede data de samme kommercielle fakta?
• Associerer semantisk markup hver pris og funktion med det korrekte niveau?
• Er tabelbilledtekster, overskrifter, scopes, kortetiketter, kontakt-tilstande og CTA-etiketter tilgængelige?
• Kan elementet flyde eller scrolle inden for sit eget mærkede område uden vandret scrolling på sideniveau?
• Understøttes farve eller ikonografi af tekst frem for at bære Inkluderet, Ekskluderet eller Anbefalet alene?
• Er et skræddersyet tilbud udeladt fra numerisk prisskema frem for kodet som nul?
• Er kampagner, udtalelser, juridisk tekst og lange forklaringer uden for de kanoniske niveaudata?
• Har nogen genberegnet årlige ækvivalenter, besparelsespåstande, mængdegrænser og overforbrugseksempler?

Et prisskema er kun udgivelsesklart, når både en køber og en maskine kan rekonstruere det samme tilbud ud fra det. Hvis en af dem skal gætte valutaen, forpligtelsen, omfanget eller friskheden, er elementet ufuldstændigt.