The problem this solves
A regional home-service business—plumbing, electrical, HVAC, and similar trades—typically has separate pages for each service, fields the same phone questions over and over, and runs an intake form that dumps unstructured messages into an inbox for someone to sort by hand.
The approach, in plain terms
Get the basics right first: clear service pages, a working phone number, and a contact form that actually goes somewhere. Only after that foundation works does the system add two optional layers: IntentPath, which automatically routes a request to the right place (for example, flagging an urgent “no heat” call differently from a routine maintenance request), and LeadBrief, which organizes an incoming inquiry into a structured summary instead of a wall of text. Both are enhancements on top of a system that works without them.
How it is actually built
The public-facing service pages are statically generated with Astro, minimizing client-side runtime dependencies and reducing the number of components that can fail during an ordinary page view. When a visitor submits the intake form, a Cloudflare Worker (a small piece of server-side code) checks the submission is valid, Cloudflare D1 (a database) stores it as a structured record, Cloudflare Queues hands off the email notification so the visitor never waits on it, and Cloudflare Turnstile filters out spam bots without showing visitors an annoying puzzle. Optional AI summarization can tidy up a message for the owner to read faster, but it never decides whether something is an emergency, which service area applies, or whether a request is eligible—those decisions stay in fixed, predictable logic and, ultimately, with a human.
What it costs to run, and what happens if a provider goes down
The scenario maps every Cloudflare and Resend (email) allowance used here to a specific, documented free-tier limit, so there is no guessing about when a paid upgrade becomes necessary—see the launch allowances for the exact numbers. Just as important: every dynamic feature has a plain fallback. If a provider has an outage, the service pages keep working and the phone number and a plain-text contact path are always available underneath.
What this scenario excludes
Live technician scheduling or dispatch software, payment processing, and multi-location franchise account management are not part of this scenario. A real engagement would scope those separately once the underlying business systems are known.
What would need to be true to accept this as built
The intake form would need to pass a validation and abuse-control test, the emergency-routing logic would need to be exercised against every defined rule, and the phone-number fallback would need to remain visible and correct with JavaScript disabled—before this scenario could be called complete for a real business.