How the Ledgerline page was made

The concept

Ledgerline Tax & Advisory is an invented registered tax agent practice in Osborne Park: four people, about 180 small-business clients, fixed monthly fees. The visitor it is built for owns a Perth trade or services company turning over $150k to $2m and is late, annoyed and quietly worried — a BAS behind, a company return not started, an accountant who never rings back.

The page has one job: a booked twenty-minute call. Professional-services leads are the most valuable category on our demand ledger, so the form leads and the phone follows — the opposite of the trade pages in this collection, where the call button wins.

Why this converts

The proof element — a fixed-fee estimate

Three plain-language controls: what you trade as, turnover a year, people on the payroll. They resolve to one monthly figure ex GST, its annual equivalent, and a four-line list of exactly what that fee covers, rewritten per scenario so the list is never generic.

The arithmetic is a base plus two additions, held in whole dollars so no cell can produce a floating-point cent:

The twelve-month strip

Beside the figure, twelve identical bars — July to June — because the argument of a fixed fee is that every month is the same height. Their height is the fee mapped onto the estimate’s own range, and the dashed rule above them is labelled Top of this estimate — $545 a month. At the ceiling the bars reach it exactly; at rest the gap between the bars and that rule is the second read, and it says something a practice rarely says out loud: this is as expensive as we get.

The rule and its label are HTML, not SVG. Drawn inside the fixed viewBox at 8.5 user units the label rendered at about 7 px on a 375 px phone; set in real CSS pixels it measures 11 px at every width from 375 to 1440.

The handoff

A button under the estimate carries the scenario to the enquiry form: it writes the configuration and both figures into a banner above the fields, selects the matching entity option and seeds the notes box. It is deliberately not applied on page load — a cold visit starts with an empty form, so an empty submit still validates honestly, and nobody arrives to find a machine has answered questions on their behalf. Change the estimate after carrying it and the banner follows.

Palette

Cool ledger, no cream. The banned AI default of cream, high-contrast serif and terracotta would have made this page look like every other accountant template; a blue-grey paper with a single verdigris accent reads as columns and reconciliation instead. Every ratio below is measured, not estimated.

Type

Newsreader 500/600 for headings. A paper-and-ledger serif that does not become the cream-and-terracotta cliche on a cool blue-grey ground, and it lets the headline carry one italic line — — fixed monthly, Osborne Park. — which is the page’s single typographic move.

Public Sans 400–700 for body, forms and every figure, with tabular numerals on throughout. A fee table with wandering digits reads amateur to an accountant faster than to anyone else, and the estimate’s $290 is set in Public Sans 700 at a size nothing else on the page comes near.

Body is 17 px at 375 px and inputs are 16 px, which is the size below which iOS zooms a form field on focus.

Conversion decisions

Why the form leads and the phone follows

On the trade pages in this collection the call button wins, because a blocked drain is decided in sixty seconds. An accountant is not. This visitor is comparing two or three practices over a week, often at night, and the thing they most want to avoid is being sold to on the phone by someone they have not decided about yet. So the hero button reads Book a 20-minute call and goes to the form; the number sits beside it as an outline button, in the masthead, in the form aside and in the sticky bar, so nobody who wants to ring is ever more than one tap away.

Why the fee is on the page at all

Most practices hide it, and the reason given is that every client is different. That is true and it is also why the estimate carries a sentence saying what it assumes and what would move it. Publishing a range you will stand behind converts better than a contact form, because it removes the one question that stops the enquiry being sent.

Why these six fields

Name, phone and email are the callback. Entity decides who in a four-person practice takes the call. Roughly how far behind are you is the field that earns its place: it sorts a tidy switcher from a three-year catch-up before anyone picks up the phone, and its options include Honestly, I don’t know because that is a real answer and refusing it costs enquiries. The sixth box is optional. Nothing asks for turnover — the estimate already offered a way to say it without being asked.

The confirmation

Nothing is sent anywhere; the panel is drawn in the browser and says so. It commits to a call before the end of the next business day, greets the sender by first name, and gives an out for the genuinely urgent case — a director penalty notice, a garnishee — because a page that promises the same response time to everyone is not believable to the person who needs it today.

Local SEO we would implement for the real business

The live page emits WebPage, WebSite and CreativeWork only, and says in the schema that it is a demonstration. Ledgerline does not exist, so shipping a business or a review graph for it would be dishonest markup in a real index.

For a real practice we would ship the block below, alongside a verified Google Business Profile, consistent name/address/phone across every citation, and one page per service and per suburb rather than one page carrying all of it.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "AccountingService",
  "name": "<the practice>",
  "image": "https://example.com.au/img/office.jpg",
  "url": "https://example.com.au/",
  "telephone": "+61 8 XXXX XXXX",
  "priceRange": "$$",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "<street>",
    "addressLocality": "Osborne Park",
    "addressRegion": "WA",
    "postalCode": "6017",
    "addressCountry": "AU"
  },
  "geo": { "@type": "GeoCoordinates", "latitude": -31.90, "longitude": 115.81 },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "08:30", "closes": "17:00"
  }],
  "areaServed": [
    { "@type": "City", "name": "Perth" },
    { "@type": "AdministrativeArea", "name": "Western Australia" }
  ],
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Compliance and advisory",
    "itemListElement": [
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Company compliance" } },
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "BAS preparation and lodgement" } }
    ]
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "<from the real review feed>",
    "reviewCount": "<from the real review feed>"
  },
  "review": [{
    "@type": "Review",
    "author": { "@type": "Person", "name": "<a real, consenting client>" },
    "reviewRating": { "@type": "Rating", "ratingValue": "5" },
    "reviewBody": "<their own words, published with permission>"
  }]
}
</script>

AccountingService is the precise schema.org type here — a subtype of FinancialService and therefore of LocalBusiness — and it is worth using the precise one rather than the generic parent. The rating and review fields are left as placeholders on purpose: they get filled from a real feed with real permission, never written by hand.

What would change for the real client

Xero is almost certainly already there, and the page is written around that: the practice works in the client’s file, on the client’s subscription. Behind it we would wire Dext for receipt and bill capture, and FYI (or Karbon) for document management and job workflow, so “your call returned the same business day” is a workflow rule rather than a promise. The enquiry form would post into that job workflow and open a lead job, not an inbox.

The rest is content the real practice owns: their photographs of four actual people instead of the drawn map, their own review feed instead of demo copy, their real tax agent number and ABN instead of the placeholder patterns, and their calendar — Calendly, or a booking widget on their practice-management system — behind the twenty-minute call, so the form becomes a booked slot rather than a callback promise.

Everything else on this page is production-ready as it stands: one file, no framework, no image requests, no cookie banner because there is nothing to consent to.

Techniques

One self-contained HTML file. No libraries, no build step, no raster images: every visual is CSS, inline SVG or type. Two Google Fonts, a data-URI favicon, and about 60 KB on the wire before compression.

The estimate is a set of native radio inputs in three fieldsets, styled as chips, so it is keyboard-operable and screen-reader-legible for free — arrow keys move between chips and reprice the card. The result region is aria-live="polite". The twelve-month strip is a single inline SVG whose bar geometry is written as attributes and eased with a CSS transition on y and height; the settled geometry was checked against the attributes to be certain the stylesheet never overrides them.

There is no animation loop. The entrance is a two-step CSS stagger that runs once on load and settles, which means the page is genuinely at rest by the time any screenshot is taken — no frame counter, nothing to drift. window.__accountant exposes the estimate’s inputs and outputs as plain numbers for verification.

Three iteration passes

This build inherited an unverified draft from a session that was interrupted mid-task: an index.html on disk, no guide, no passes run, nothing checked. The first job was to read it against the spec and re-derive its arithmetic before changing a line of it. The structure and most of the copy survived; the list below is what did not.