FCR Dashboard — Architecture Deck (slide storyboard)

Slide-by-slide plan to build a PowerPoint explaining how the FCR Dashboard works. Each slide has: the on-slide title, the key message, the bullets to show, a visual suggestion, and speaker notes (what to say). Built from fcr-dashboard-architecture-overview.md. ~14 slides, ~15-20 min talk.

Suggested theme: clean, one idea per slide, FCR colours. Use the ASCII diagrams here as the blueprint for proper boxes-and-arrows graphics.

Slide 1 — Title

Title: The FCR Dashboard — How It All Works Subtitle: Sales & account intelligence, powered by AI at the edge Visual: FCR logo + a faint world map with glowing edge points. Notes: "This is the platform that gives every rep and AM instant, complete intelligence on any account or prospect. I'll show what it is, how it's built, and why it's fast."

Slide 2 — The problem

Title: Reps were waiting — and guessing Key message: Intelligence was slow to assemble and scattered across systems. Bullets:

Account context lived in 7+ systems (CRM, billing, HubSpot, GBP, ads, search, keywords)
Pulling it together took minutes per deal — done manually, inconsistently
Opening a deal triggered 15–30s of live lookups while the rep waited Visual: A rep at a laptop with a spinner; around them, scattered system logos. Notes: Set up the pain. Everyone in the room has waited on this.

Slide 3 — What we built

Title: One question. One complete answer. Seconds. Key message: Ask in plain English, get a sourced answer instantly. Bullets:

"What's this deal about?" · "What was last discussed?" · "Draft a proposal note"
Same intelligence in 3 places reps already work
Backed by FCR's full data + an AI advisor Visual: Screenshot of the HubSpot Prospect Advisor card answering a question. Notes: Show, don't tell — a real card answer lands the value immediately.

Slide 4 — The three surfaces

Title: Three front doors, one brain Key message: Web, HubSpot, and Roam are all clients of the same engine. Bullets / table:

Web UI — portfolio, accounts, maps, reports (Cloudflare Pages)
HubSpot card — Prospect Advisor in the deal sidebar
Roam — the same advisor in team chat Visual: Three device frames (browser, HubSpot sidebar, Roam) all arrows → one box "fcr-dashboard-api". Notes: Emphasise: build the intelligence once, surface it everywhere.

Slide 5 — The brain: one Worker at the edge

Title: The engine: a single Cloudflare Worker Key message: All the logic is one serverless app that runs at the edge. Bullets:

fcr-dashboard-api — ~126 endpoints in one deployable unit
Serverless: no server, no region
Runs per-request in the Cloudflare data centre nearest the user (~330 worldwide)
Also runs on a schedule (cron) and as a background queue worker Visual: A globe with ~330 dots; one highlighted near "the rep"; label "code runs here, on demand". Notes: This is why it's fast — compute happens next to the user, spun up only when needed.

Slide 6 — Why "edge" matters

Title: Fast because the code runs everywhere Key message: No central server to be far from. Bullets:

Traditional app: one server in one region → distant users wait
Edge worker: same code in 330 cities → always nearby
Spins up in milliseconds, only when a request arrives → no idle cost Visual: Side-by-side: "Central server" (long arrows from far users) vs "Edge" (short arrows everywhere). Notes: Keep it conceptual. The takeaway is speed + scale come for free.

Slide 7 — The data layer

Title: What the engine knows Key message: The Worker orchestrates data; it doesn't hoard it. Bullets:

BigQuery — the warehouse: HubSpot deals, 18 months of closed history, 230k engagements, billing, keywords, GBP, census/area
Vectorize — semantic search: "find deals/clients like this"
KV cache — instant (<30ms) reads, e.g. the precomputed briefs
Live sources — CRM, Google, Ahrefs, Meta (the slow ones) Visual: Centre box "Worker" with arrows out to four labelled stores. Notes: Foreshadow: the live sources are slow — that's why we precompute.

Slide 8 — The 18-month deal history

Title: 18 months of deal memory Key message: We keep a structured, queryable history of every closed deal. Bullets:

~10,800 closed deals, won + lost, rolling 18 months
Built from three 6-month cohorts + a frozen year-on-year comparison pair
Plus full stage-transition history for win-rate & cycle-time analysis Visual: A timeline bar split into the 3 cohorts; a callout for the YoY frozen pair. Notes: This is what lets the advisor say "deals like this won/lost because…".

Slide 9 — Two kinds of "find similar"

Title: Semantic search: deals and clients Key message: Two vector indexes power the "what's worked before" answers. Bullets:

fcr-deal-history → similar past deals + their outcomes
fcr-site-portfolio → similar paying clients in a category (proof points)
Careful split: free directory listings are never shown as paying clients Visual: Two index icons feeding "similar deals" and "similar clients" panels. Notes: Mention the data-quality guardrail — credibility matters in pitches.

Slide 10 — The deal brief (the big idea)

Title: Precompute everything, answer instantly Key message: We do the slow work before the rep asks. Bullets:

Old way: 4–5 live lookups while the rep waits (15–30s)
New way: a complete deal brief is precomputed & cached per open deal
Rep opens the deal → advisor reads one cached blob in ~30ms
Refreshed in the background (schedule + queue); self-heals when a deal is opened Visual: Before/after timeline bars — long red "live" vs tiny green "cached". Notes: This is the headline engineering win. Land the speed difference visually.

Slide 11 — What's in a brief

Title: One brief = the whole picture Key message: Everything the four core questions need, in one bundle. Bullets:

Deal facts + CRM + billing
Google Business Profile (live for unknown prospects) + website crawl
Category keywords + local area + similar paying clients + similar past deals
Recent conversation (real rep contact ranked above automated emails) Visual: A "brief" card exploded into its component blocks. Notes: Tie each block back to a rep question it answers.

Slide 12 — The AI advisor

Title: Claude + a toolbox Key message: The advisor reasons, picks tools, and writes in FCR's voice. Bullets:

Claude runs inside the Worker with ~40 tools (lookups, brief, drafting, posting notes)
It chooses what to call, the Worker runs it (now mostly instant cache reads)
Guardrails: lead with the brief; honest framing; approved email templates Visual: Claude icon in the middle, tool icons around it, answer flowing out. Notes: Stress it's grounded in FCR data + guardrails, not a generic chatbot.

Slide 13 — End to end

Title: What happens when a rep opens a deal Key message: All the heavy lifting already happened. Bullets (numbered flow):

Rep opens the deal → card loads, pre-warms the brief
Rep asks a question
Advisor reads the cached brief (~30ms)
Claude writes the answer, streamed into the card
Background jobs keep every brief fresh on a schedule Visual: The numbered flow as a left-to-right arrow chain. Notes: Reinforce: nothing slow in the rep's path.

Slide 14 — Where it lives & how it ships

Title: Built in Git, runs on the edge Key message: One repo, automated deploys, full rollback. Bullets:

Source of truth: one Git repo (Worker + UI + HubSpot card)
Worker bundles to a single edge script; UI builds to Pages; card to HubSpot
Gated deploys (lint + clean-tree checks), every deploy tagged for rollback
Two Cloudflare accounts: production (FCR) + dev Visual: Repo → build → 3 deploy targets (Worker / Pages / HubSpot). Notes: Reassure on operational maturity — versioned, gated, reversible.

Slide 15 — Close

Title: The result Key message: Complete prospect intelligence, instantly, wherever reps work. Bullets:

Seconds, not minutes — and consistent every time
One brain behind web, HubSpot, and Roam
Built to extend: new data sources & tools slot into the same engine Visual: The full architecture diagram (clean version) as the closing image. Notes: End on the business outcome, then open for questions.

Appendix slides (optional, for technical audiences)

A1 — Full architecture diagram (use the diagram from hubspot-data-architecture.md)
A2 — Refresh cadences table (which data refreshes when)
A3 — The brief refresh pipeline (queue + cron + self-heal, and the "don't dump large backlogs" lesson)
A4 — Data dictionary (the BQ tables + vector indexes, from the data-arch doc)

FCR Dashboard documentation · generated from docs/ · keep counts verified, not guessed.