BOR Multi-Location System Blueprint

Type: INTERNAL / STRATEGIC. The architecture for turning one good location website into a system that serves all ~70 Best Option Restoration locations. Date: 2026-10-12 Basis: The project research files (franchise audit, social audit, competitor analysis, TRP reverse-engineering, estimate spec, agent training pattern). Facts about BOR are cited to those files; everything else is design. Where BOR data does not exist yet, this blueprint says so — the data problem is treated as a first-class design constraint, not a footnote. Core idea in one sentence: TRP (BHL, LLC) proved that one template plus a variable table can dress a national network in local clothing; this blueprint builds that same machine owned by the locations, with the layers TRP does not have — real local data, a CRM under every location, an AI agent on every site, and reviews compounding per location.

1. Architecture overview

Five layers, one data spine:

┌─────────────────────────────────────────────────────────┐
│  LAYER 5 — Lead generation (owned TRP-style funnel)     │
│  Service landing pages · geo in the ad account · ZIP    │
│  router · call tracking                                 │
├─────────────────────────────────────────────────────────┤
│  LAYER 4 — Social engine                                │
│  Central calendar → localized variants → per-location   │
│  posting by territory/ZIP                               │
├─────────────────────────────────────────────────────────┤
│  LAYER 3 — AI agents                                    │
│  One core BOR brain + per-location overlay · orb per    │
│  location · identical guardrails everywhere             │
├─────────────────────────────────────────────────────────┤
│  LAYER 2 — Location websites                            │
│  One master template · per-location pages, meta,        │
│  schema, blog · generated from the data spine           │
├─────────────────────────────────────────────────────────┤
│  LAYER 1 — THE DATA SPINE                               │
│  One verified record per location (the variable table). │
│  Nothing renders, posts, or answers without it.         │
└─────────────────────────────────────────────────────────┘
        Every lead lands in: Layer 0 — one CRM per location
        (Zuops subaccounts, piloted with Craig — Step 8)

Design principles: 1. Data before pages. TRP can fake locality because it never promises anything real. We cannot: every phone number, review, service area, and hour we publish must be true for that location. The spine is the product; the templates are rendering. 2. One template, many truths. A single master template + per-location variable table (exactly TRP's model, research/trp-site-reverse-engineering.md §8) — but each location's variables are verified facts, not dressing. 3. Central production, local proof. Content, design, and systems are produced once, centrally. Proof (reviews, job photos, local stories) is generated locally, because only local proof is real. 4. The franchisor is a stakeholder, not an obstacle to route around. At network scale this needs BOR Franchising, LLC alignment (§8). The pilot is deliberately one location, operating within what one franchisee can do for his own business.

2. Layer 1 — The data spine (per-location record)

One record per location. This is the single variable table every layer reads. Fields (grouped by who must supply them):

Identity (franchisor directory + owner confirmation) - Location slug (e.g. st-paul), official location name ("Best Option Restoration of ___") - Legal entity / DBA name - Owner first name (public), owner full name (internal) - Year opened (if the owner wants it public)

Contact & coverage (owner-confirmed ONLY — never scraped-and-assumed) - Public phone (and whether it is call-tracked), after-hours/emergency number - Public email, lead-notification destination - Public address, or "service-area business, no public address" - Territory definition: ZIP list (primary), plus human-readable town list for display - Hours: office hours + genuine 24/7 emergency status (owner's word, not the system's assumption)

Services & operations (owner-confirmed) - Services subset actually offered (from the BOR core list + stated extras in audit/franchise-audit.md §5), and services referred out - Testing/sampling offered? Post-remediation verification method - Direct-bills insurance? Free estimates? (Both are location-page claims system-wide; each location confirms its own practice — training/bor-agent-training.md §5) - Estimating system in use (for the Phase-3 estimate tool) - Licences/certifications with documents on file (never copied from another location — the St. Paul licence QC807138 belongs to St. Paul)

Presence links (verified URLs only — the social audit's rule) - Google Business Profile URL, Google review short link - Facebook, Instagram, LinkedIn, YouTube, TikTok, X (only those that exist and are verified) - Existing website/domain, if any (to be migrated or redirected deliberately)

Proof assets (locally generated, centrally stored) - Approved job photos (with customer consent records), before/after sets - Drying/performance documentation where the location uses the thermal system (timed outcomes — the unclaimed differentiator in competitor-analysis.md Gap §5) - Owner/team photos, van photos

System fields (generated by us) - Page URLs, orb agent ID, CRM subaccount ID, call-tracking number assignment - Data status: unverified → owner-confirmed → published (nothing renders publicly below owner-confirmed for contact/coverage/services fields) - Last-verified date + verifier

Why the spine comes first: the project needed 20 questions to describe ONE location (Craig) with confidence (training/bor-agent-training.md YOUR TURN list), and a research team could only document 33 of ~72 units at all (audit/franchise-audit.md §4). Scaling pages before scaling verified data is how you get the current mess: two addresses for one location, a location under another company's name, profiles nobody can find. The spine is unglamorous and it is the whole game.

Population plan: the YOUR TURN questionnaire (already written for Craig) becomes the standard intake. Franchisor directory data seeds identity fields as unverified; owners confirm the rest. A location does not launch until its record is owner-confirmed.

3. Layer 2 — Location websites

3.1 Site architecture (two shapes, one system)

• Shape A — location section on one master domain: bestoptionrestoration.com/locations/<slug>/ pattern already exists on the corporate site for 15 units. Extending it is the franchisor-friendly path (single domain authority) but requires franchisor partnership and their WordPress/Beaver Builder stack.
• Shape B — generated location microsites on a system domain: each location gets a full site (home, services, blog, contact) generated from the template + spine, on a consistent domain pattern (one system domain with location subpaths or subdomains — NOT the current chaos of one-off domains like borlakewood.com / boraustin.com).
• Recommendation: pilot on Shape B under our control (Craig's site is already the prototype), design the template to be portable to Shape A if the franchisor adopts it. The template and spine are the assets; the host domain is a deployment detail. Existing location domains get redirected deliberately at migration, never abandoned (they carry whatever local equity exists).

3.2 The master template (page set per location)

Generated per location from the spine; section order follows the proven landing structure (landing-page/website-plan.md) expanded to a full site: 1. Home — hero (service + town from spine), call CTA (location's real number), trust checks (only claims true for this location), services grid, process, owner feature (name/photo from spine), real reviews module (§3.4), estimate/contact section. 2. Service pages — one per core service the location actually offers (/water-damage/, /mold-remediation/, /fire-damage/, /storm-damage/, /contents-cleaning/, /commercial/ — the Phase-2 map already drafted in website-plan.md), each with the location's own process notes where the owner supplied them. 3. Service-area page — the town/ZIP list from the spine, published only when owner-confirmed. This page is the anti-TRP statement: a real territory, stated by the operator who serves it. 4. About — owner story, team, entity name, licences (document-verified only). 5. Blog — §4. 6. Contact — form into the location's CRM (§7), phone, hours, GBP link. 7. Privacy / terms — system-standard pages.

3.3 Geo/meta system

• Title/meta templates (variables from spine): "<Service> in <Town>, <ST> | Best Option Restoration of <Location>"; descriptions generated from the location's confirmed services + phone; no location may publish a town it does not serve (spine ZIP list is the source of truth, enforced at generation time).
• Canonical strategy: one canonical URL per location per page type on the system domain. Legacy one-off domains 301 to the canonical location site at migration. Within the blog engine, the corporate master post is canonical for the article body; localized versions carry local intro/outro blocks and location schema (see §4.3 for the duplicate-content design).
• JSON-LD per location — LocalBusiness/HomeAndConstructionBusiness + Service nodes generated ONLY from owner-confirmed spine fields: name, phone, address (or areaServed ZIP list for service-area businesses), hours, geo, sameAs (verified socials), and review aggregate only where a real, current aggregate exists for that location (the audit's samples prove ratings vary wildly by unit, 5.0 down to 1.9 — schema must reflect the location's actual profile or omit ratings entirely; never borrow another location's numbers).
• Geo sitemap: one system sitemap index → per-location sitemaps, regenerated on every publish; location landing pages for paid traffic kept separate from organic location pages (canonical/noindex discipline on ad variants — the improvement on TRP's all-indexable duplicates, per trp-site-reverse-engineering.md §8).
• GBP alignment: each location's website URL, name, phone, and address in the spine must match its Google Business Profile exactly (NAP consistency), with UTM-tagged GBP website links so GBP-driven leads are attributable in the CRM.

3.4 Avoiding duplicate-content penalties (genuinely local content)

Templated pages across 70 locations will be near-duplicates unless local substance is engineered in. The system requires each location page to carry at least three genuinely local blocks: - Local reviews module — the location's own current Google reviews (pulled from its profile), never the system's best location's reviews. - Local jobs block — recent documented jobs from the spine's proof assets (photos with consent, service, town, dated outcomes where documented — e.g. timed drying results). - Local owner block — the owner's own words/photo; owners are different people in different towns, and the template treats that as content, not decoration. - Local blog localization (§4.3) and local service notes (e.g. a Minnesota location's basement-moisture realities vs a Florida location's storm season — written once per region/climate cluster, reviewed by the owners in that cluster). - Locations that cannot yet supply local blocks launch with fewer pages (home + services + contact) rather than thin duplicates of everything.

4. Blog engine

Model: produce once, centrally; localize mechanically and honestly; publish per location.

• Topic clusters (from the services + competitor gaps): mold (signs, inspection vs testing, basement/bathroom/attic mold, cost factors without invented prices, prevention), water (first 24 hours after a leak, drying process, insurance documentation), fire/smoke (aftermath steps, contents), seasonal/regional (spring thaw and basement moisture in the upper Midwest; storm/hurricane season in the Southeast; freeze events in the South; monsoon in the Southwest), insurance literacy (how documentation works, what adjusters need — general education, never coverage promises), proof content (documented local jobs, drying outcomes).
• The MN Mold Company lesson: St. Paul's split-off mold brand already publishes the right Minnesota mold content (competitor-analysis.md Gap §2). The blog engine absorbs that pattern into the master brand: specialty content lives on the location's BOR site under BOR branding, so authority compounds in one place.
• Localization method per post: corporate body (written once, expert-reviewed) + generated local frame: intro paragraph naming the location and its real service towns, region/climate block where relevant, local proof block if available, local CTA (real phone, real booking path), location author attribution (owner name from spine). Localized frames are written per region cluster by humans, not spun per city by string replacement.
• Cadence: one master post per week at system level (sustainable centrally); each location publishes the localized version on its own site and the post feeds its social queue (§6). Seasonal clusters are scheduled ahead of regional risk seasons (storm content lands before storm season, freeze content before winter).
• Guardrails: no invented prices, statistics, or local claims; no medical/health-risk advice beyond "consult a professional" generalities; review content passes the same hard rules as the agent training file (training/bor-agent-training.md Hard Rules). Every post is an asset for the AI agents too — approved posts join the core brain's knowledge (§5).

5. Layer 3 — AI agent duplication

Pattern (already established in training/agent-plan.md + bor-agent-training.md): one core brain + per-location overlay.

• Core BOR brain (central, versioned): the franchise-system facts (company, services definitions, general process, insurance-documentation education, guardrails, approved hard-question scripts), sourced from the verified sections of the training file. Maintained centrally; a core update is drafted, approved, and pushed to every location's agent at once — no location runs a stale or divergent copy.
• Per-location overlay (from the spine): location name, owner first name, phone, territory/ZIPs (the agent checks coverage honestly against the ZIP list instead of guessing), hours, services subset, direct-billing/free-estimate status, booking rules, escalation routing, review links, socials. If a field is not owner-confirmed in the spine, the overlay omits it and the agent uses the honest "not confirmed, let me take your details" path — the guardrail behaviour already specified in the training file.
• Identical guardrails everywhere (non-negotiable, inherited from the training file's Hard Rules): never invent prices/reviews/service areas/credentials; never diagnose health risk or identify mold species; never promise timelines or coverage; emergencies escalate to a human by phone immediately; never attribute another location's facts. Guardrails live in the core so no location can weaken them.
• Orb per location: provisioned per location on the Business Hub OS orb platform with the location's BOR branding (palette/fonts verified in landing-page/asset-pass.md — blue #0179fb, orange #f7a01f, deep blue #0255a0; both widget colours always set from the real palette), embedded on that location's site only, labelled for that location. Phone/SMS receptionist per location is a later phase, wired through that location's CRM subaccount (§7) with its own approval.
• Pre-launch test set per location: the 10-question guardrail test set in training/agent-plan.md §9 runs against every location's agent before it goes live (price question, health question, town-coverage question, emergency, reviews question, competitor question…). One failing answer blocks that location's launch, not the system's.
• Feedback loop: unanswered/failed questions across all locations aggregate centrally — they are the content roadmap for the blog engine and the core brain's next revision.

6. Layer 4 — Social posting across ~70 locations, by territory

The problem (from the social audit): today there is no system — 3 of 7 corporate platforms verified, 13 of 21 sampled locations with nothing, no handle standard, one location under a different name, two locations pointing at the corporate Instagram. Any plan that starts with "post more" without fixing identity first will scale the splinter. (audit/social-profiles.md)

6.1 Account strategy — recommendation

Per-location accounts on a strict naming system, fed centrally; corporate accounts as the brand flagship. Reasoning: - Local restoration is bought locally: a homeowner follows/trusts the crew in their town, and Google/social proof must attach to the location that will do the work (and to its GBP/reviews). Corporate-only posting (the Paul Davis programme documented in competitor-analysis.md is the sophisticated version) still requires location pages to post to — Paul Davis posts ON franchisees' behalf, which presupposes governed location accounts. - Per-location accounts only work with governance: handle standard (bestoptionrestoration<location> pattern, claimed uniformly, with a registry in the spine), corporate accounts keep the national story (Franchise 500, system news), location accounts carry local proof. - Locations that truly will not engage keep a claimed, correctly-named, minimally-active profile (so customers land somewhere true) rather than a splintered or wrong-named one. The Mesa situation (operating as "Built Different Restoration" on LinkedIn) is the failure mode the registry exists to prevent. - Platform priority per location: Facebook + Instagram + Google posts first (where local home-services attention and reviews live), YouTube/TikTok short video second (the category's open lane — no BOR presence verified there at all today), LinkedIn corporate-led, X optional. Do not launch all platforms for all locations at once.

6.2 Content system — central calendar, localized variants

• Central calendar (monthly): built from the blog engine (§4) + system campaigns (seasonal risk, awareness moments, brand stories). Every item is produced once as a master asset (copy, image/video, link) with localization slots: town name, owner/team photo swap, local job photo swap, local link (location blog post / GBP), local phone.
• Territory/ZIP logic: variants are generated per region cluster and per location, not per ZIP (ZIPs are the routing unit for leads and ads; the posting unit is the location/territory). Weather-triggered posting is the exception that uses ZIP-level data: when a storm/freeze/flood event hits a territory's ZIP list, that location's queue gets the pre-approved event sequence (preparedness → during-event safety → post-event documentation/assessment posts) within hours, while unaffected locations stay silent. This is the social expression of the same spine data that routes leads.
• Local proof pipeline (the content that cannot be faked centrally): crews capture job photos/video on a simple protocol (before/during/after + one 30-second walkthrough); uploads land in the location's proof assets in the spine (with consent record); central team edits into posts. BOR's unproven thermal-drying claim becomes proven one timed local job at a time (competitor-analysis.md Gap §5).
• Approval flow: system content (brand, seasonal, educational) is pre-approved at system level and flows automatically; anything location-specific that a location owner or the central editor drafts enters a one-tap approval queue (owner or designated approver); weather-event sequences are pre-approved templates with a human confirmation at trigger time. Nothing posts to a location's accounts that names prices, another location, or a customer without explicit consent on file.
• Tooling: scheduling, queues, approvals, and reporting run inside Business Hub OS (the locations' CRM/social home), so social activity, leads, and reviews are visible in one place per location and in aggregate centrally. Reporting: per location (posts out, reach, profile actions, review movement) and system roll-up; the metric that matters is profile-to-call/lead actions per territory, not follower counts.

7. Layer 0/5 — CRM architecture & lead routing

7.1 One subaccount per location vs master-with-pipelines

Recommendation: one subaccount per location, duplicated from a single governed BOR template subaccount (pipelines, workflows, forms, review engine, AI settings prebuilt), with a central roll-up report built on top. Craig's subaccount is the pilot and the template's first real-world test (Project Step 8: duplicate the Benefit Connect template for Craig; no purchases, no AI/outbound activation, no invites without Anton's approval — those gates stay).

7.2 Lead routing by ZIP — the TRP router, owned

• Every lead source (location site forms, system landing pages, call tracking, marketplace purchases during transition) enters through one router: ZIP → spine territory table → owning location's CRM subaccount as a contact + opportunity with full source attribution (campaign, keyword, query, landing page, call recording link).
• Uncovered ZIP (no participating location): captured to a house list — it is simultaneously a homeowner we can refer deliberately and a recruitment asset (proof of demand in an unsold/unparticipating territory).
• Speed-to-lead automation (per location, from the template): instant internal alert + customer-facing response within minutes (AI-assisted), missed-call text-back, assessment booking flow, estimate follow-up sequence, insurance-stage check-ins, and at close-out the review request — all identical in structure, localized in details (location name, phone, review link) from the spine.
• Marketplace leads during transition: TRP-type leads keep flowing to locations that buy them, but now land in the CRM with attribution, so for the first time the system can compute cost per booked job by source — the number that justifies (or kills) continued renting and prices the owned funnel (§8 of the TRP teardown: their handoff ends at the call; ours tracks to the booked job).

7.3 Layer 5 — owned lead generation (the funnel on top)

Once Layers 1–3 stand, the owned funnel is mostly assembly of proven parts (research/trp-site-reverse-engineering.md §8): - Service landing pages from the same generator (one canonical organic page per service per location; ad-variant pages noindexed), geo in the ad account (location-targeted groups on the spine's ZIP lists), call-tracking number pools per service cluster, ZIP gate → router → location CRM + AI follow-up. - Ads on Google + Microsoft from the start of scale (TRP's Microsoft presence with loose thematic matching suggests cheap incremental volume — matched with tighter local relevance on our side). - The photo-estimate tool (research/estimate-software-spec.md) slots in as the premium qualification step on these pages — after, and only after, a location's rate-card data exists in the spine and the human gates are in place.

8. Rollout phases

Phase 0 — Pilot (Craig, 1 location). Proves: the spine, the template, and the numbers on one real business. - Craig's location record completed through the YOUR TURN intake (the 20 questions), his site live off the master template (the current review site is its prototype), GBP claimed/built, his CRM subaccount duplicated from the template with lead routing + speed-to-lead + review engine, his AI agent live on verified facts only, social accounts claimed under the naming standard with the central calendar's first month running. - Measured: leads by source, response times, assessments booked, review count/velocity, cost per booked job on any paid test — the baseline every later phase is sold on. - Gate to Phase 1: Craig's operation runs on the system for a full season cycle of real jobs, and the template's rough edges are fixed in the template, not in his copy of it.

Phase 1 — Regional (5–10 locations). Proves: duplication — that the system is a system, not a bespoke build. - Target the documented, engaged locations first (the ones with existing presence — e.g. locations with official pages and named owners in franchise-audit.md §4 Tier A), plus any owners the franchisor or Craig connects us to. Each goes through the same spine intake; gaps (no GBP, splinter domains, wrong-named profiles) are fixed as onboarding steps, domains redirected deliberately. - Central calendar + blog localization run for the cohort; first weather-triggered sequence fires in one region; roll-up reporting v1 ships. - Gate to Phase 2: onboarding time per location is measured and falling; per-location data quality passes audit (every published field owner-confirmed); the franchisor conversation (below) is open.

Phase 2 — National (~70 locations) + franchisor alignment. Proves: the system as BOR's official location-marketing infrastructure. - Franchisor gate (hard): network-wide use of BOR branding, templates on or linked from the corporate domain, system-wide AI/social representation, and anything touching franchise sales requires BOR Franchising, LLC buy-in — brand standards, approved claims, template approval, and clarity on franchise-agreement marketing rules (including the ad-fund relationship: locations already pay 2% of gross sales into advertising per FDD-based listings, franchise-audit.md §7 — expect the franchisor to see this system through that lens). This is a partnership negotiation, not a deployment step; Anton leads it, armed with Phase 0/1 numbers. - Remaining locations onboard in waves by region; legacy domains/profiles consolidated; the owned lead funnel (§7.3) expands metro by proven metro; holdout locations stay on claimed-minimal profiles until they join.

Sequencing rule at every phase: a location launches when its data is ready, not when its pages are generated. Pages take minutes; verified local truth is the schedule.

9. Risks & constraints (stated plainly)

1. Franchise agreement constraints. Franchisees' rights to run their own sites/agents/ads under the brand, and the franchisor's approval rights over brand use, are governed by documents we have not seen (the actual FDD/franchise agreement was not publicly fetched — franchise-audit.md §7 caveat). What one owner (Craig) may do for his own location marketing is a narrower question than a 70-location system; Phase 2 assumes franchisor counsel reviews the system before network launch. The corporate footer also shows BOR is not registered to offer/sell franchises in some states (incl. Minnesota) — a franchise-sales matter, but another reason recruitment-adjacent claims stay franchisor-approved. (asset-pass.md)
2. Per-location data quality is the binding constraint. Most locations' data is currently unverified (33 of ~72 even documentable). The YOUR TURN problem scales linearly: ~70 owners must each confirm territory, services, hours, licences. Mitigations: franchisor directory seeding (identity only), a ruthless intake form, launch gating on confirmation, and accepting a long tail of minimal-profile locations. Any vendor who promises to skip this step is proposing to publish guesses about 70 businesses.
3. Duplicate content / thin-page risk. 70 templated sites without the local-proof requirements in §3.4 would replicate TRP's duplicate-slug problem at location scale and invite the same search penalties TRP avoids by not caring about organic. The local-blocks rule and fewer-pages-for-new-locations rule are the controls.
4. Review integrity & platform policy. Review generation must stay within Google/platform rules and FTC guidance: ask every customer, never gate by sentiment, never incentivize, never import another location's reviews into a location's schema or pages. The 1.9-star Baldwin County tail (franchise-audit.md §8) also means some locations need service-recovery work before amplification — marketing a broken location louder is harm, not help; onboarding includes a reputation check with a remediation path.
5. Brand-claim discipline at scale. System claims (thermal drying speed, response times, "24/7") vary in truth by location. The spine's per-location confirmation exists precisely so the system never publishes a claim for a location that cannot back it — one location's unbacked claim, screenshotted, becomes the system's problem.
6. Template drift & governance. 70 subaccounts and sites will drift without a governed template (versioned releases, change log, push process for the core brain and site template). Budget the governance as a permanent function, not a launch task.
7. Owner adoption risk. Some owners will not capture job photos, answer the intake, or approve posts. The system is designed to degrade gracefully (central content still flows; local proof simply accrues slower), but Phase 1 must measure real owner effort honestly — if the pilot's effort only worked because Craig is motivated, the rollout model changes.

Appendix — how the pieces already built map in

Sources (project files)

• PROJECT.md; audit/franchise-audit.md (§3 counts, §4 locations/territories, §5 services, §7 FDD/ad fund); audit/social-profiles.md (§1–§3 platforms, handles, splinter); research/competitor-analysis.md (Paul Davis social system, PuroClean blogs, review samples, Gaps §1–§8); research/trp-site-reverse-engineering.md (§3 number pools, §4 geo-in-ads, §8 replication blueprint); research/trp-model-and-kraken-application.md; research/estimate-software-spec.md (§7 rate-card dependency, §9 CRM integration); training/agent-plan.md + training/bor-agent-training.md (core/overlay pattern, guardrails, intake); landing-page/website-plan.md (page map, metadata plan) + landing-page/asset-pass.md (verified palette, franchisor legal/footer facts)