That works until the client raises prices. Then the number exists in six places: three cards, a FAQ answer, the booking form's total, and the meta description. Five of them get updated. The sixth is the one a customer screenshots.

This post covers modelling the pricing page as data instead of layout: the field model, the vehicle class multiplier problem, the Offer schema that makes the numbers machine readable, and what to validate before shipping.

The failure mode is duplication, not design

A price is a fact about the business. Facts belong in one place with one owner.

When a price is typed into a layout, the layout becomes the database, and layouts are the worst database you can pick. They have no validation, no single source of truth, no way to query "which services cost more than $400", and no way to emit structured output.

The fix is ordinary content modelling, applied to something teams routinely skip because it looks like design work.

The field model

Start with the smallest model that covers real variation. For a vehicle service business that means the price is not one number, it is a base plus a class modifier.

type VehicleClass = "sedan" | "midSuv" | "truck" | "threeRow"

interface ServiceTier {
  slug: string
  name: string
  order: number
  basePrice: number          // cents, sedan baseline
  durationMinutes: number
  inclusions: string[]
  depositPercent: number     // 0 disables deposit for this tier
  quoteOnly: boolean         // true suppresses price, renders range instead
  rangeLow?: number
  rangeHigh?: number
}

const CLASS_MULTIPLIER: Record<VehicleClass, number> = {
  sedan: 1,
  midSuv: 1.15,
  truck: 1.25,
  threeRow: 1.35,
}

The multiplier map is the part that saves you. The naive model is one CMS item per tier per vehicle class, which is four tiers times four classes equals sixteen items to keep in sync, and sixteen chances for the truck price on the middle tier to drift. One base price plus one shared multiplier table is two things to maintain.

const priceFor = (tier: ServiceTier, vc: VehicleClass) =>
  Math.round((tier.basePrice * CLASS_MULTIPLIER[vc]) / 100) * 100

Rounding to the nearest dollar at render time keeps $332.35 off the page without storing a rounded value you then cannot recompute.

quoteOnly deserves its own boolean rather than a null price. Full vehicle paint film and multi stage correction cannot be priced from a card, and the renderer needs to branch to a range plus an inspection explanation rather than rendering an empty slot. A null price is ambiguous. A flag is not.

Rendering is now boring

export function TierCard({ tier, vehicleClass }) {
  if (tier.quoteOnly) {
    return (
      <Card>
        <h3>{tier.name}</h3>
        <p>From ${tier.rangeLow} to ${tier.rangeHigh}, set at inspection</p>
        <InclusionList items={tier.inclusions} />
      </Card>
    )
  }

  const price = priceFor(tier, vehicleClass)
  return (
    <Card>
      <h3>{tier.name}</h3>
      <p>From ${price} for {LABEL[vehicleClass]}</p>
      <p>About {Math.round(tier.durationMinutes / 60)} hours</p>
      <InclusionList items={tier.inclusions} />
      {tier.depositPercent > 0 && (
        <p>Reserve with a ${Math.round(price * tier.depositPercent / 100)} deposit</p>
      )}
    </Card>
  )
}

In Framer this maps cleanly onto a CMS collection plus a code component, so the shop owner edits a number in one field and every surface updates. We build Framer sites and booking systems for automotive shops, so this comes up constantly: the client changes prices seasonally and nobody wants that to be a developer ticket.

The deposit line matters more than it looks. Industry data on service bookings puts no-show rates at 15 to 25 percent without a deposit and 3 to 5 percent with one, and reports that 83 percent of consumers accept a deposit on services over $100 (SchedulingKit). That is a business outcome that depends entirely on the price being a computable number rather than a string in a heading.

Making the price machine readable

Once the price is data, emitting schema is a serialisation step rather than a copywriting exercise. Service with nested Offer is the right shape for a bookable service.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Full interior and exterior detail",
  "provider": {
    "@type": "AutoDetailing",
    "name": "Example Detail Co",
    "url": "https://example.com"
  },
  "areaServed": { "@type": "City", "name": "Jacksonville" },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "289.00",
    "priceSpecification": {
      "@type": "PriceSpecification",
      "minPrice": "289.00",
      "maxPrice": "389.00",
      "valueAddedTaxIncluded": false
    },
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/book/full-detail"
  }
}

Two details that trip people up. AutoDetailing is a real schema.org type under AutomotiveBusiness, so use it instead of a generic LocalBusiness. And when the price varies by vehicle class, emit priceSpecification with minPrice and maxPrice rather than picking one number and hoping, because a single price that the page contradicts is worse than no markup.

Generate this from the same model that renders the cards. If the JSON-LD is hand written, it is already stale.

What actually changes

The LLM row is the one that has changed fastest. Assistants answering "how much does a full detail cost near me" are pulling from whatever is parseable. Prose buried in a design layer parses badly. A declared priceSpecification parses exactly.

For context on whether the numbers are even in the right band, a 2026 analysis of 89 mobile operators across four US metros put packages around $158, $278 and $443 (Jobber). Useful as a sanity check on seed data before a client supplies real figures.

Ship checklist

1. Model first, design second. Write the interface before opening the canvas. If a field cannot be named, the page cannot be built.

2. One base price per tier, one shared multiplier map. Never store the same price twice.

3. Flag quote only work explicitly. Branch the renderer, do not null the price.

4. Serialise JSON-LD from the model. No hand written schema blocks.

5. Validate with the Rich Results Test and the schema.org validator. The first tells you what Google accepts, the second tells you what is actually valid. They disagree more often than you expect.

6. Diff the rendered price against the schema price in CI. A one line assertion catches the entire class of drift bugs this post is about.

7. Recheck after a CMS field rename. Renaming a field in a visual CMS silently breaks the serialiser, and nothing on the page looks wrong.

Step six is the one worth the effort. The bug is never that the schema is missing. It is that the schema says $289 while the card says $329, and nobody notices for four months.

Written by the team at Xenon Builds. We build Framer sites and booking systems for automotive shops across the US, which means we spend a lot of time on conversion, page speed and form UX for a very specific kind of small business.

This is a modelling problem, not a UI problem. Here is the shape that works, the state machine underneath it, and the schema that makes the tiers readable to search engines and AI assistants.

Why one table breaks

The naive model looks reasonable. An appointment row carries a customer, a service, a datetime and a status, and recurrence gets bolted on as recurring: true plus an interval.

The trouble is that "cancelled" now means two incompatible things. Cancelling one Tuesday in November is not the same event as cancelling the commercial relationship, but a single status column cannot tell you which happened. Neither can your reporting, which is how a shop ends up with a churn number that does not reconcile against revenue.

The same collision hits every other transition. Pausing a plan should stop future occurrences without touching the two visits already scheduled. Rescheduling one visit should not extend the billing period. Skipping a month may or may not credit the customer, and that is a business rule that has to live somewhere explicit.

Two entities, two lifecycles

Split it. A subscription is a billing relationship. An appointment is a scheduled occurrence that belongs to one. They reference each other and they change state independently.

type SubscriptionStatus =
  | 'active'
  | 'paused'
  | 'past_due'
  | 'cancelled'      // no future occurrences, history retained
  | 'pending'        // checkout started, payment not confirmed

type Tier = 'small' | 'midsize' | 'fullsize' | 'fleet'

interface Subscription {
  id: string
  customerId: string
  tier: Tier
  vehicleIds: string[]          // fleet accounts hold many
  intervalDays: number          // 30, 60, 90
  status: SubscriptionStatus
  currentPeriodEnd: string      // ISO, drives billing not scheduling
  pausedUntil?: string
  skipCreditCount: number       // skipped visits owed back
}

type AppointmentStatus =
  | 'scheduled'
  | 'confirmed'
  | 'completed'
  | 'skipped'        // member moved it, plan unaffected
  | 'no_show'
  | 'voided'         // parent subscription cancelled

interface Appointment {
  id: string
  subscriptionId?: string       // absent for one-off retail bookings
  customerId: string
  vehicleId: string
  startsAt: string
  durationMinutes: number
  status: AppointmentStatus
  rescheduledFrom?: string      // preserves the original slot
}

Two details in there matter more than they look. subscriptionId is optional, which is what lets member visits and walk-in retail bookings share one calendar rather than two systems fighting over the same bay. And rescheduledFrom keeps the original slot as data instead of overwriting it, so you can answer "how often do members move their visit" later without having destroyed the evidence.

The state table

This is the transition matrix worth agreeing on before any UI gets built. Every row here is a bug we have seen shipped as an undefined case.

The row that gets skipped in almost every first implementation is the last one. When the shop cancels, the member is owed something, and if that is not modelled the credit gets handled by a phone call and a discount code, which is fine at three members and unusable at forty.

Generating occurrences: materialise or compute?

Two options. Compute occurrences on the fly from intervalDays, or materialise appointment rows ahead of time.

Computing is tempting because it keeps the data small, but it fails on the first exception. A member who moves one visit two weeks later has permanently broken the arithmetic, so every read now needs an override table, which is just materialised rows with extra steps.

Materialise, but only a short horizon. We generate the next two occurrences per active subscription and top up on completion. That keeps the calendar honest, keeps capacity planning real, and keeps the cost of a cancellation bounded to voiding two rows rather than two years of them.

Run the top-up as an idempotent job keyed on (subscriptionId, startsAt). Retries are guaranteed in this kind of system, and a duplicate booking is a worse failure than a missing one.

What the UI has to expose

Every subscription state needs a visible surface, or support absorbs it.

Pause, skip and reschedule all have to be self-serve. This is a retention feature rather than a convenience: industry subscription data from Recurly's 2026 report, across 2,200 businesses and 76 million subscribers, puts churn reduction from annual commitment at 51 percent, and the mechanism behind numbers like that is friction removal, not loyalty. If moving one visit requires a conversation, some share of members cancel instead of asking.

Source: Recurly, State of Subscriptions 2026

past_due deserves a real state in the interface too. A silent failed payment reads as a cancelled service to the customer and as active revenue to the shop, and the two only reconcile when someone arrives to an unbooked bay.

We build Framer sites and booking systems for automotive shops, so this comes up constantly with detailers moving from one-off jobs to maintenance plans. The build always ends up spending more time on these four states than on the checkout itself.

Making the tiers machine readable

The pricing page for a plan is usually three columns of prose, which is invisible to anything parsing structured data. Emit the tiers as offers with a recurring price specification instead.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "serviceType": "Auto detailing maintenance membership",
  "provider": { "@type": "AutoDetailing", "name": "Example Detailing" },
  "areaServed": { "@type": "City", "name": "Houston" },
  "offers": [
    {
      "@type": "Offer",
      "name": "Mid-size Monthly Maintenance",
      "priceSpecification": {
        "@type": "UnitPriceSpecification",
        "price": "125.00",
        "priceCurrency": "USD",
        "billingIncrement": 1,
        "unitCode": "MON",
        "billingDuration": 1
      },
      "eligibleCustomerType": "https://schema.org/Consumer"
    }
  ]
}

UnitPriceSpecification with unitCode: "MON" is the part that communicates "per month" rather than "one hundred and twenty five dollars, once". Without it a crawler reads a plan as a one-time product, which is exactly the wrong summary for an assistant to hand a user asking what a monthly plan costs.

Published market tiers sit around 100, 125 and 150 dollars by vehicle size for US consumer plans, which is a useful sanity check when modelling test data.

Source: Car Detox membership plans

Implementation order

If you are building this from nothing, this sequence avoids the most rework:

1. Model Subscription and Appointment as separate entities from the first commit. Retrofitting the split after launch means migrating live billing data, which is the one migration nobody wants.

2. Write the state table for your own business rules before the UI. Fill in every cell, including the awkward ones about credits.

3. Build the recurring checkout and the pending to active transition. Nothing else can be tested until a subscription can exist.

4. Materialise a two-occurrence horizon with an idempotent top-up job.

5. Ship pause, skip and reschedule in the same release as the checkout. Launching without them means every exception arrives as a support message.

6. Add the offer schema last, once prices are stable.

The interesting engineering here is not the payment integration. It is accepting that a booking and a billing relationship are two objects with two lifecycles, and that every ambiguity you leave between them eventually shows up as a customer who was charged for a visit that no longer exists.

Written by the team at Xenon Builds. We build Framer sites and booking systems for automotive shops across the US, which means we spend a lot of time on conversion, page speed and form UX for a very specific kind of small business.