Demonstration build
Beacon Plumbing & Air
Beacon Plumbing & Air is a made-up business we built to demonstrate the work. The site is live and you can try it. The numbers shown on it are illustrative sample data.
The problem
Beacon Plumbing & Air fields both true emergencies, a burst pipe, a dead furnace in January, and routine scheduled service on the same phone line, with no way for a caller to signal which one they had before someone picked up.
What we built
A single triage question up front, is this an emergency, routes to one of two branches: an emergency branch offering the next same-day two-hour dispatch windows, or a scheduled branch offering AM/PM windows across the next five business days for plumbing, HVAC, or water-heater work. Emergency windows are clamped to a 7am to 9pm service day and must start at least 90 minutes out, rolling over to 7:00 AM the next day if none fit; the copy is explicit that these are dispatch windows, not guaranteed arrival times. On top of that sits the findability work: a page for each of the four towns served, each carrying a fact true of that place and nowhere else, structured data built as objects and serialised rather than hand-typed, and an audit at /found that grades the site's own pages and publishes the result.
Decisions & why
One triage question decides everything downstream, instead of a service-type menu first.
The distinction that matters to Beacon's dispatcher is urgency, not which trade it is. Asking that first routes a burst pipe straight to the emergency branch instead of burying it under a service-picker.
Emergency windows are clamped between 7am and 9pm and required to start at least 90 minutes from now.
A dispatch window offered with no lead time is a window a truck can't make. The clamp keeps every offered window inside hours a tech can realistically be sent, rolling to the next morning rather than ever quoting one the crew can't keep.
The emergency copy is framed around capability, not a guarantee, 'dispatch windows, not guaranteed arrival times.'
An emergency plumber can't promise an exact minute and mean it every time. Saying plainly what the window is, and isn't, is more trustworthy than a precise-sounding promise that erodes the first time traffic or a prior job runs long.
The scheduled branch's availability uses its own deterministic, hash-seeded implementation rather than importing Oakline's.
Each demo needs to stand alone as something a prospective client can read start to finish, without one demo secretly depending on another's internals to function.
The findability page audits the site instead of advertising a ranking.
Every demo here is deliberately noindex, so any ranking claimed on one would be invented, and the service's own copy promises no guaranteed-#1 nonsense. What /found shows instead is the work: it grades the real pages, it can report a failure, and it keeps three rows that a fictitious business simply cannot pass, including a verified Google Business Profile.
Four town pages that each say something true about that town, checked automatically.
A page per place only works when each one earns it, and the usual fake is one paragraph copied with the name swapped. The build compares every pair of pages word for word and fails if the closest two share more than 60% of their wording, so the demo cannot quietly become the thing it warns about.
The result it aims for
The build aims to get a caller with a real emergency onto the right branch in one question, to make an offered dispatch window one the crew can keep, and to show the findability work as something a visitor can check rather than a graph going up.
This is the goal the build is designed to hit, not a measured client outcome.