Bright Side PlumbingLocation Pages + Programmatic Figma Playbook

Audrey designs the 20% that carries the brand (hero, Why BSP). Bricks AI generates the 80% (trust bar, map, service grid, reviews grid, FAQ, CTA). Naming convention for Figma frames: NN_type_descriptor aligned with the § number in each section spec (e.g. 01_section_hero, 04_section_services_grid).

Header + Footer are off-limits for Audrey. Global Bricks components already ship on every page. She does not design them in Figma. Numbering starts at the first content section.

Prompt modes: Per-Section (one frame at a time) or Whole-Page Prompt Pack (all sections bundled, Figma-flagged frames marked “drop your Figma export, do not regenerate”).

→ Open the full 3-tool workflow diagram + 5 wiring steps

One line that drives every design decision

Location pages are not homepage clones with the city swapped. They are local-SEO weapons. Google rewards pages that prove the business serves a specific place: city in H1, neighborhoods in body, landmarks in copy, reviews filtered by city, schema with areaServed + GeoCircle, and differentiation that reads like a human who lives there wrote it. Phase 1 ships 4 T1 cities with 1 service each (4 pages). Phase 2 multiplies to 45 (15 cities × 3 services).

The Core Rule

Location-page traffic is 70%+ mobile (Emergency Eric searches on a phone, standing over a leak). Every section is designed at 375 px first. If it does not work one-handed in a dark basement at 11 PM, it does not ship.

Breakpoints (same as homepage)

Type scale, spacing, components

See Homepage Playbook § Figma Guide for full specs — H1 32/48 · H2 26/36 · H3 20/24 · Body 16/18 · 8-px spacing base · the same 8 Figma symbols (Primary CTA, Secondary CTA, Phone CTA, Service Card, Review Card, Trust Chip, FAQ Row, Wave Divider). Location pages add 2 new components:

• City Chip — clickable chip for neighborhood or nearby-city grid. Same base style as trust chip but pill-shaped, 32h, variant: default / hover / visited. Links to /plumber-in-{slug}/ on nearby-city grid, or to FAQ anchor on neighborhood grid.
• Availability Chip — "Techs available in [city] today · 45-min avg." Green dot + city name + response time + "Call now" CTA. Mobile: full-width card 80h. Desktop: pinned right in hero column 300×120.

Accessibility + Touch (inherited)

• ✅ Touch targets ≥ 48 × 48 px with ≥ 8 px spacing
• ✅ Body ≥ 16 px on mobile, no exceptions
• ✅ Contrast AA minimum: text on #1D1760 = #FFF or #30C5FF · text on #F8FAFC = #1D1760
• ✅ Focus ring 2 px #FFEA00 with 2 px offset on every interactive element
• ✅ Every image alt text includes city context ("Kalen Barker servicing sewer line in Olathe")
• ✅ One H1, sequential H2s, no skipping to H4

How to read this catalog

Fourteen reusable components that power every section of the Location Pages template. Each spec is self-contained: purpose, anatomy, variants, responsive sizes, tokens, motion, accessibility, exact Figma component name Audrey will publish, which sections consume it, the build-side HTML pattern Robert ships, and the CSS custom-property values. If a section needs something, it pulls from this catalog. No one-off styling. Phase 1 = must-ship on the first 4 T1 pages. Phase 2 = polish or data-driven layer.

Cross-reference matrix

Which component shows up in which location-page section. Audrey uses this to confirm every section has its components inventoried; Robert uses this to confirm every build task pulls from the library (not from scratch).

Component build order — Phase 1 ship priority

1. Phone CTA (CL-03) — single most tapped element, blocks everything
2. Primary + Secondary CTA (CL-01, CL-02) — fundamental button system
3. Trust Chip (CL-07) — used 6× in trust bar, simplest chip
4. City Chip (CL-08) — drives the entire internal-link moat, unique to location pages
5. Service Card (CL-04) — § 06 unit, reused from homepage
6. Review Card (CL-05) — § 07 moat unit
7. Reveal Card (CL-06) — powers availability + guarantees
8. Step Tile (CL-11) — § 08 process
9. FAQ Accordion (CL-09) — § 13 FAQPage schema driver
10. Wave Divider (CL-10) — section rhythm
11. Multi-Step Form Field (CL-14) — § 15 conversion
12. Sticky Mobile Call Bar (CL-12) — floating global
13. Daniel AI Chat Widget (CL-13) — Phase 2 polish, wire Vapi integration

Color palette — BSP Navy / Bright Blue / Yellow

Usage rules

• Navy #1D1760 — primary text, H1/H2, hero/CTA/footer backgrounds
• Blue #30C5FF — primary CTA, link color, trust-chip border, section dividers
• Yellow #FFEA00 — emergency accent ONLY: phone CTA, sticky emergency bar text, "Same-Day in [City]" chip, focus ring. Never body text.
• Ivory #F8FAFC — card bg, review card bg, neighborhoods grid bg
• Success #22C55E — live-availability dot, guarantee badges
• Danger #EF4444 — sticky emergency bar bg on mobile, FAQ warning callouts

Motion (inherited)

• Hover lift: translateY(-2px) 150ms ease-out on service / review / city chip
• FAQ expand: max-height 0 → auto 220ms ease-in-out
• Availability pulse: 1.2s ease-in-out on green dot, 50% opacity swing
• Scroll reveal: sections fade in 300ms when 15% visible (Phase 2 polish)
• Reduced motion: respect prefers-reduced-motion — disable transform, keep opacity only

Mobile scroll flow. Every section does ONE job and serves at least one of the 10 ranking signals. Visitor lands, sees emergency proof, scrolls sales conversation, closes. Each section is labeled with which persona it targets primarily.

Location pages inherit from two sources: the Homepage Playbook (design system) and the live Sewer-Camera Inspection page (component patterns). This playbook does NOT redefine shared tokens. It adds only location-specific additions.

Direct inheritance from Homepage Playbook

Direct inheritance from Sewer-Camera Inspection page (live)

Location-specific additions (NEW components Audrey designs)

• Emergency Bar — fixed top, red bg, yellow phone link. Mobile + desktop variants.
• Embedded Map wrapper — iframe + lazy placeholder + caption.
• Availability Chip — green dot pulse, city name, response time, call CTA.
• City Chip — neighborhood variant (non-clickable Phase 1) + nearby-city variant (always clickable).
• Landmark Copy Block — optional ivory-bg card for § 10 when landmarks get their own visual row.

Per-city photography (priority for Phase 1 T1)

Each T1 city gets a dedicated shoot slot. Fallbacks use generic KC-metro imagery with alt text specifying the city context until real shoots happen.

Reused assets (inherited)

• 🎨 Wave dividers, underline doodles, service icons — all reused from sewer-camera page
• 🏥 BSP vertical logo (footer, shipped Apr 17) + horizontal logo (header)
• 🥇 BBB A+ badge, Google review star, Angi / Yelp / Chamber badges (footer trust row)
• 🚨 Red emergency icon for sticky bar — new SVG (Audrey designs)
• 🟢 Green "live" dot for Availability Chip — new CSS pulse

Fallback plan

• If no city-specific hero shot exists on Phase 1 ship day, use a generic KC-metro shot with descriptive alt text: alt="Bright Side Plumbing branded truck serving Overland Park, Kansas".
• Landmark shot is optional. If we don't have it, fold the landmark reference into the opener paragraph copy only.
• Before/after gallery is Phase 2 gated — placeholder only on Phase 1.

Same 4 personas from the Homepage Playbook (derived from 301+ reviews across 6 platforms). Location pages skew even harder toward Emergency Eric because that traffic is keyword-triggered by panic ("emergency plumber Olathe," "sewer repair Overland Park now") and almost always mobile. Rachel and Bob land here too via research queries. Mike lands here when Google serves the "nearest plumber" answer for his neighborhood.

Current gap vs competitors

Same 5 competitors from the Homepage Playbook — here's how each handles LOCATION strategy

Analyzed April 17, 2026. Focus is the location-page layer specifically: do they have per-city pages, do they use Plumber schema with areaServed, do they filter reviews by city, do they use landmark-anchored copy. Anything I can't verify with source I mark as unknown rather than invent.

Location-signal gap matrix — Phase 1 closes every 🔴

These are the signals the template must hardcode. Every section the designer ships maps to at least one of these signals. If a section doesn't serve a signal, it doesn't exist.

Design hooks Audrey leaves in the template even for Phase 2 features

Why this exists

Every city page carries one small chip near the hero: green dot, city name, approximate ETA, crew count. That chip is the conversion hinge for Emergency Eric. This section shows the data sources, APIs, privacy rules, 3-rung ladder, component spec, cost ceiling, rollout phases, KPIs, and risk mitigation that make it real. Treat it as a standalone strategic brief inside the playbook.

UX precision required, by signal

Each signal a user sees on a city page needs the right grain. Too coarse and the badge feels fake. Too precise and we expose technician location, which breaks privacy and invites stalking risk.

The 3-rung ladder

Each rung unlocks more precision. Each one also costs more to operate. Ship Rung 1 immediately; earn the right to Rung 2 by proving conversion lift; earn Rung 3 only if dispatch desk demands a real-time operator view.

Badge-render privacy spec

System architecture

Three data sources feed one cron, which writes one JSON, which fans out to four consumers. Everything is cached aggressively so Google Maps API spend is bounded.

Cost table, Year 1

Phased rollout

KPI and measurement framework

Risk matrix

What this unlocks beyond the badge

• Daniel AI context: "Our tech will be at your house in 22 minutes" instead of generic "someone will be in touch soon."
• Outbound SMS on dispatch: "Juan is 15 min away, blue Ford F-150, ETA 2:47 PM." Drives 5-star reviews.
• Internal dispatch console for Ashton: real-time fleet map, auth-walled, zero public exposure.
• Google Business Profile special-hours auto-sync: if no crew is on-shift, GBP hours reflect "closed," protecting our LSA score.
• Google Ads dynamic ad copy: "Plumber 10 min from you in Overland Park, Call Now." RSAs update from the same feed.
• Emergency Eric conversion at 11 PM: the single moment this entire stack exists to own. Panic caller sees a green dot, calls BSP instead of Roto-Rooter.

Bonus free-API layers (stack on the same feed)

Each of these APIs is free or near-free and enriches the city page without any additional paid infrastructure. They plug into the same availability surface.

Ship Rung 1 this week · actual work order

1. Build /opt/nexus/titan/fleet_availability.py cron. Reads ServiceTitan jobs API (today's bookings, crew assignments, arrival windows). Buckets per city slug. Writes /opt/nexus/nexus/scripts/output/fleet_availability.json. 5-min cron. Stale-flag if >2h old.
2. Wire /api/fleet/availability/{city-slug} and /api/fleet/status endpoints on the existing port 8765 nexus API. Response includes: state (available/limited/booked-out/stale), eta_minutes, crew_count, updated_at, fallback_reason.
3. Add Live Availability Chip (CL-15) to the Figma component library. 5 variants (available, limited, booked-out, stale, after-hours). Audrey builds, Robert hydrates with the API in the Bricks template.

The blindspot framing

Prior Live Fleet analysis covered Distance Matrix and Geocoding only. That was the blindspot. The full Google stack breaks into 7 categories spanning 22 APIs. Grouped below by impact per dollar for BSP's Location Pages specifically, not by Google's own taxonomy. The rule: anything free or inside Google's $200/month Maps credit that touches conversion, data quality, or SEO measurement ships in Tier A. Anything strategic but deferrable waits for Phase 3 or Phase 4.

Three-tier ship order

Every API below is pre-ranked by when it earns a slot in the build. Tier A rides with the Rung 1 Fleet Badge. Tier B stacks on the Tech PWA in Phase 3. Tier C is the compounding strategic layer.

🗺️ Maps Platform · 9 APIs

🏢 Google Business Profile · 6 APIs, all FREE

🔍 Search Console · 3 APIs, FREE

📊 Analytics and Ads · 4 APIs, FREE with accounts

🤖 Cloud AI · 4 APIs, free tiers

📺 YouTube · 2 APIs, FREE

🛡️ Security and UX · 1 API, FREE tier

Integration architecture

How the 22 APIs stack with the Live Fleet system already specced in the previous section. Every arrow is an existing or planned feed.

5 strategic blindspot wins

Cost summary, Year 1

Conservative worst-case run cost across the 22-API stack at BSP's current scale. Assumes no special enterprise contracts, no volume commitments.

Decision tree

Use this flow any time a new Google API surfaces in a roadmap conversation.

What this unlocks beyond city chips

Every location page ships with all 8 layers. Robert wires the JSON-LD in the Bricks template. Audrey doesn't design this but must know it exists so Phase 2 animations and components don't break the structured data. Each layer below includes an example snippet Audrey (or anyone) can reference.

Layer 1 · Plumber (not generic LocalBusiness)

// Plumber is a more specific subtype than LocalBusiness. Google prefers specificity.
{
  "@context": "https://schema.org",
  "@type": "Plumber",
  "name": "Bright Side Plumbing",
  "telephone": "+19139631029",
  "url": "https://callbrightside.com/plumber-in-overland-park/",
  "priceRange": "$$"
}

Layer 2 · areaServed + GeoCircle

{
  "areaServed": {
    "@type": "GeoCircle",
    "geoMidpoint": {
      "@type": "GeoCoordinates",
      "latitude": 38.9822,   // from city data object
      "longitude": -94.6708
    },
    "geoRadius": "10000"   // meters — must match GBP service area
  }
}

Layer 3 · sameAs → Wikidata entity

{
  // This is the 10x MOAT: Google connects our page to the Wikidata city entity.
  "sameAs": [
    "https://www.wikidata.org/wiki/Q2030450",  // Overland Park
    "https://en.wikipedia.org/wiki/Overland_Park,_Kansas"
  ]
}

Layer 4 · hasOfferCatalog

{
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Plumbing Services in Overland Park",
    "itemListElement": [
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Sewer Repair" } },
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Drain Cleaning" } },
      { "@type": "Offer", "itemOffered": { "@type": "Service", "name": "Water Heater Service" } }
    ]
  }
}

Layer 5 · knowsAbout (AI-search signal)

{
  // Tells Gemini / Perplexity / ChatGPT what BSP is an expert at.
  "knowsAbout": [
    "Trenchless Sewer Repair",
    "Hydro-Jetting",
    "Backflow Prevention",
    "Sewer Camera Inspection",
    "Tankless Water Heater Installation"
  ]
}

Layer 6 · FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How much does sewer repair cost in Overland Park?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sewer repair in Overland Park typically ranges from $3,000 to $15,000..."
      }
    }
    // ... 5 more questions minimum
  ]
}

Layer 7 · AggregateRating + Review

{
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "384"
  },
  "review": [
    {
      "@type": "Review",
      "author": { "@type": "Person", "name": "Homeowner in Blue Valley" },
      "reviewRating": { "@type": "Rating", "ratingValue": "5" },
      "reviewBody": "Called at 10 PM, they were out to Overland Park by 11..."
    }
  ]
}

Layer 8 · BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://callbrightside.com/" },
    { "@type": "ListItem", "position": 2, "name": "Service Areas", "item": "https://callbrightside.com/service-areas/" },
    { "@type": "ListItem", "position": 3, "name": "Overland Park", "item": "https://callbrightside.com/plumber-in-overland-park/" }
  ]
}

Each city has one data object. The Bricks template consumes it and renders a full page. Audrey designs the template ONCE — this is how 1 template becomes 15 (Phase 1–2) or 45 pages (Phase 2 full multiplication).

{
  "slug": "overland-park",
  "name": "Overland Park",
  "state": "KS",
  "tier": 1,
  "wikidata_id": "Q2030450",
  "wikipedia_url": "https://en.wikipedia.org/wiki/Overland_Park,_Kansas",
  "lat": 38.9822,
  "lng": -94.6708,
  "geo_radius_m": 10000,
  "h1": "Sewer Repair in Overland Park — 5th-Generation Master Plumbers",
  "meta_title": "Plumber in Overland Park KS | Sewer Repair | Bright Side Plumbing",
  "meta_desc": "Sewer repair, drain cleaning, water heater service in Overland Park KS. 5th-gen family plumber. Same-day. Call (913) 963-1029.",
  "opener_paragraph": "Overland Park homes, especially along 151st and Metcalf, are often built on...",
  "neighborhoods": [
    "Blue Valley", "Corporate Woods", "Deer Creek", "Indian Hills",
    "Leabrooke", "Nottingham", "Oak Park", "Sycamore Hills",
    "The Village", "Wilshire Farms"
  ],
  "landmarks": [
    "Oak Park Mall", "Deanna Rose Farmstead",
    "Corporate Woods", "Overland Park Arboretum",
    "Scheels Overland Park Soccer Complex"
  ],
  "housing_stock_note": "Mix of 1970s-era tree-lined subdivisions north of I-435 and new construction south of 159th.",
  "soil_note": "Kansas clay; expansive soil that shifts with moisture, stressing older cast iron sewer lines.",
  "common_issue": "Tree-root intrusion into clay/cast iron sewer lines; water heater sediment from hard municipal water.",
  "response_time_minutes": 45,
  "nearby_cities": ["olathe", "lenexa", "leawood", "shawnee", "prairie-village", "mission"],
  "review_filter_terms": [
    "overland park", "op ", "blue valley", "oak park mall",
    "151st", "metcalf", "corporate woods"
  ],
  "faq": [
    {
      "q": "How much does sewer repair cost in Overland Park?",
      "a": "Sewer repair in Overland Park typically ranges from $3,000 to $15,000 depending on line length, depth, and method (traditional dig vs. trenchless). Most of the older neighborhoods north of College Blvd see higher costs because of mature trees and cast iron pipe age. We give free on-site estimates."
    },
    { // ... 5 more FAQ entries per Section 13 required types }
  ],
  "photo_set": {
    "hero": "/images/cities/overland-park/hero.jpg",
    "landmark": "/images/cities/overland-park/oak-park-mall.jpg",
    "neighborhood": "/images/cities/overland-park/blue-valley.jpg",
    "before_after": [
      { "before": "...", "after": "...", "street": "W 151st St", "date": "2026-03-15" }
    ]
  }
}

Phase 1 ships T1 (4 cities). Phase 2 adds T2 (5 cities). Phase 3 adds T3 (6 cities). Tier order follows search volume, revenue density, and proximity to BSP HQ.

Phase 1 Checklist (what Audrey designs to ship)

• 🟢 14-section template at 375 / 768 / 1440
• 🟢 5 new components designed (Emergency Bar, Embedded Map, Availability Chip, City Chip, Landmark Block)
• 🟢 All inherited components referenced, not redesigned
• 🟢 All tokens from homepage token library
• 🟢 Placeholder components (before/after gallery, live availability P2, crew ETA map) dashed-bordered, sized
• 🟢 City data object spec finalized — 4 T1 cities filled
• 🟢 Photography shot list flagged for Robert to commission
• 🟢 All schema layers referenced in a11y notes so build doesn't break structured data
• 🟢 Figma layer naming: § {section}. {element} · {city-variant} · {breakpoint}

Phase 2 Hook Points (leave Figma placeholders)

• 🟡 § 05 · Live ST Availability (API-driven)
• 🟡 § 08 · Live crew-ETA map widget (440×240 mobile / 480h desktop)
• 🟡 § 11 · Before/After Gallery (full section placeholder)
• 🟡 § 12 · Inline Wisetack rate quote (340×200 inside financing card)
• 🟡 § 09 · Neighborhood chips become clickable to /plumber-in-{city}/{neighborhood} hyper-local pages
• 🟡 All copy · Keyword weaponization pass per BSP_Keyword_Full_Arsenal.html

Design-side QA Audrey runs before handoff

1. ✅ All 14 sections designed at 375, 768, 1440 for 1 representative city (Overland Park)
2. ✅ 5 new components added to Figma library with variants
3. ✅ Every H1/H2/H3/Body uses a type-scale token (no stray font sizes)
4. ✅ Every padding/margin/gap uses an 8-px scale token
5. ✅ Every color is a brand token (no rogue hex codes)
6. ✅ Every button ≥ 48 × 48 px
7. ✅ Contrast AA for all text
8. ✅ Focus rings present on every interactive element
9. ✅ Every image alt text includes city context in Figma layer description
10. ✅ Sticky emergency bar designed at mobile + desktop
11. ✅ Availability Chip designed at mobile + desktop
12. ✅ City Chip designed at neighborhood variant + nearby-city variant
13. ✅ Phase 2 placeholders labeled + dashed-bordered
14. ✅ Per-city photography gaps listed on a shot-list card
15. ✅ Inheritance verified (Trust Bar, Service Card, Review Card, FAQ Row match homepage playbook)

Build-side QA Robert runs before ship

1. ✅ LCP < 2.5s on 4G mobile throttle (embedded map lazy-loaded)
2. ✅ CLS < 0.1
3. ✅ FID < 100ms
4. ✅ Sticky emergency bar phone tel: link fires
5. ✅ Multi-step form submits to ServiceTitan with city pre-filled + GCLID
6. ✅ All 8 schema layers validate in Google Rich Results Test
7. ✅ Plumber schema GeoCircle matches GBP service area polygon
8. ✅ FAQPage schema returns FAQ rich result in Rich Results Test
9. ✅ sameAs Wikidata URL resolves (no 404)
10. ✅ Review filter returns ≥ 2 matching reviews for each T1 city
11. ✅ City data object populated for all 4 T1 cities
12. ✅ Page passes a ≥ 40% uniqueness check against the homepage and against other city pages (tool: copyscape or local diff)
13. ✅ Embedded map loads without layout shift
14. ✅ Cloudflare purge + LiteSpeed purge fired after deploy
15. ✅ loading="lazy" on all below-fold images
16. ✅ One H1 per page, sequential H2s

What Audrey hands to Robert

1. 📐 Figma file — 14 sections × 3 breakpoints for Overland Park as reference city + all 5 new components with variants + all inherited components referenced
2. 📦 Asset package — new SVGs (Emergency icon, green live dot CSS, city chip) + reused doodles and waves (already in library)
3. 📷 Per-city photography shot list — 4 T1 cities, 5 shots each, priority ordered
4. 📋 Copy doc — final opener paragraphs (4 cities), neighborhoods lists (4 cities), landmarks lists (4 cities), FAQ sets (4 cities), meta titles/descs (4 cities)
5. 🎨 Design-tokens JSON — optional export from Figma Tokens plugin
6. 📝 Phase 2 hooks list — screenshot each placeholder with API/data spec
7. 🛡️ City data object — 4 filled examples (JSON) ready for Robert to wire into the Bricks template

Where this playbook lives