Dublin Plumbers Co-op

Plumbing is a two-speed business. Some visitors are mid-emergency and need a phone number in seconds. Others are researching a boiler replacement or bathroom job days or weeks out and want to understand the company before committing to anything.

A single generic "contact us" page cannot serve both without either burying the emergency call action under research content, or making every visitor wade through urgency messaging that does not apply to them.

Copy and page structure were built around intent, not just keywords: "emergency plumber Dublin" behaviour is call-first and time-pressured; "boiler replacement Dublin" or "blocked drain Dublin" behaviour is comparison-first and research-led.

Each of the four planned-work trades — general plumbing, boilers & heating, drains, and pumps & water systems — was treated as its own local search intent with its own dedicated page, rather than folded into one generic services page.

Built on Next.js 16 (App Router) with a deliberate split: the Emergency page is its own richer, motion-driven implementation, because urgency has different design needs to a standard service page.

The four planned-work services instead share one typed, config-driven template (a single React component reading a typed content object per service) — so fixing or improving one part of the template updates all four service pages at once, instead of drifting apart as separate hand-copied pages.

The Emergency page opens with a single decision the visitor actually has to make: is this actively causing damage right now, or can it safely wait for a standard callback? That decision routes straight to a call action or a callback request — not a generic contact form.

A sticky mobile call bar keeps the phone number reachable while scrolling, and every claim on the page (24/7 availability, insurance, gas registration) was checked against the business's own verification data before being allowed onto the page — unverified claims were deliberately left out rather than assumed.

Each of the four planned-work services (Plumbing, Boilers & Heating, Drains, Pumps & Water Systems) is defined as a typed TypeScript content object — hero copy, decision routes, problem cards, FAQs, form fields — rendered through one shared template component.

This is the difference between a page that was "written" and a system that was "built": adding a fifth service, or fixing a layout issue across all of them, is a content change or a single component fix, not four repeated edits.

Every page was built and checked at 360px, 390px, 430px, 768px, 1024px, 1280px and 1440px — mobile layouts were designed for their own composition (stacked hero, full-width map, reordered content) rather than a compressed version of the desktop layout.

A sticky mobile action bar (call / WhatsApp / quote) stays available without covering content or conflicting with in-page sticky elements.

Visual direction follows a documented brand system: Deep Ink and Service Blue for structure and primary actions, Co-op Green as a supporting accent, and Emergency Red reserved exclusively for genuine urgent-call actions — never used decoratively, so it keeps its meaning when it matters.

Heating Amber and Drain Teal identify their respective service categories throughout, and typography follows Manrope for headings with Inter for body and UI text, matching the client's own brand guide.

Copy consistently asks for a "Dublin area or Eircode" rather than a generic "postcode", and a real interactive coverage map (OpenStreetMap tiles with live Eircode/area search) replaced an earlier illustrative placeholder map, so the geography on the page is genuine rather than decorative.

Each page ships one H1, a deliberate heading hierarchy, unique metadata and canonical tags, and structured data that matches what is actually visible on the page — no invented review or rating schema.

WhatsApp is the primary low-friction contact route for planned work, with the message pre-filled per context (service, section) so the conversation starts with useful information already in place.

A structured enquiry form (validated with Zod, delivered through a single API route) remains available for anyone who prefers typing details over messaging, and the customer-proof section links to real Google reviews rather than displaying invented testimonials.