This page documents the infrastructure that connects both public properties into one owner-controlled business. It covers the shared backend, the bot layer, the asset documentation framework, and the process of extracting Connie's expertise into transferable form. This is the business case for building it — and the blueprint for what gets built.
exceptionalsales.com and salesassessmenttesting.com are publicly separate — different domains, different audiences, different messaging. Behind both sits one system. Every lead, booking, form submission, and payment from either site routes to the same backend. Connie manages one set of tools. A buyer inherits one documented operating infrastructure. The brands stay distinct. The business data does not.
What runs underneath both brands
Worker / Router
Single intake endpoint for both sites. Tags source, identifies client, routes event to correct downstream tool. All logic lives here.
Cloudflare Workers · Owner account
CRM
One client record per email address across both sites. Tracks lifecycle stage, products purchased, source, LTV, booking history.
Supabase · Postgres
Booking
All booking types across both sites — EKG consult, results review, coaching intake, workshop discovery, speaking inquiry.
Cal.com · Webhook → CRM
Payments
Stripe payment links for every product. Webhook on success updates CRM, fires onboarding email, advances pipeline stage.
Stripe · Webhook → CRM
Documents
Coaching agreements, workshop proposals, and speaking contracts sent automatically when engagement is confirmed. Signed status logged in CRM.
DocuSeal · API → CRM
Email Sequences
Post-EKG nurture, post-report cross-sell, coaching graduation, stale pipeline alerts, repeat assessment prompts. All triggered by CRM events.
Event-triggered · Worker
Every client has an origin. Every origin is recorded.
Every form submission carries its source — a UTM parameter, a referral tag, or a "how did you find us?" field. The Worker writes it to the CRM on intake. Over time this produces a documented picture of what's actually generating clients: referrals, speaking audiences, search, LinkedIn. Without this, marketing decisions are guesses. With it, they're data.
■ REFERRAL
Highest close rate
Stage 04–06 clients are the most likely referral sources. Currently untracked — every referral that converts is invisible unless Connie remembers to note it.
■ SPEAKING
Highest volume potential
A keynote audience is the largest warm-lead pool in the system. Currently uncaptured. QR → EKG funnel fixes this in one setup step per event.
◆ GAP
No analytics today
Neither public site has traffic analytics or lead source tracking in place. The Worker-based form tagging is the minimum viable fix — no page analytics required to start.
Every visitor who has a question that doesn't get answered is a lead that doesn't convert. Connie cannot be available at 10pm when a hiring manager is reading the sample report and wants to know how SPQ*Gold differs from a personality test. The bot layer handles this. It is not a generic chatbot — it is a structured system with one shared framework, page-scoped instances tuned to their specific context, and a centralized log of every question the bots couldn't answer. That log is the content gap feed: the continuously updated list of what the site should be saying but isn't.
How the framework operates
Shared Base
One system prompt base covers Connie's credentials, SPQ*Gold methodology, call reluctance framework, and business overview. Shared across all instances.
Cloudflare AI Worker · Workers KV for context
Page Context Injection
At runtime, each page injects its specific context block: page purpose, intended audience, the one CTA to drive toward, and explicitly forbidden topics.
Runtime context · No separate bot per deployment
Grounded Knowledge
Answers come only from approved content: the page text, Connie's published writing, and pre-approved Q&A pairs. The bot does not answer from general internet knowledge.
Retrieval from approved content only
Gap Logging
When the bot cannot answer with confidence, it logs the question — source page, bot instance, timestamp — to a Supabase content_gaps table and offers the page CTA instead.
Worker → Supabase content_gaps · Admin portal
Bot instances — four scopes
Bots reduce support burden and continuously identify documentation gaps.
Every question the bots can't answer with confidence is logged to a single Supabase table. Source page, bot instance, question text, timestamp. The admin bot surfaces this as a ranked list — most frequent first. That ranked list is Connie's content roadmap: not guesswork about what to add to the site, but direct evidence of what buyers are asking that the site isn't addressing.
When a question appears 12 times in a month, it does not belong in a buried FAQ. It belongs on the page where the question is being asked — as a headline, a section, or a visible answer. The gap log makes this visible before leads leave.
■ THE COMPOUNDING EFFECT
Every answered gap makes the bot smarter and the site stronger.
When Connie adds a new FAQ answer — prompted by a gap log entry — the answer is added to the bot's grounding content. The bot can now answer that question. The gap log entry closes. The page content is stronger. Over time, both the bots and the sites continuously improve from real visitor behaviour, not assumptions.
This section is not about software features. It is about business formalization. Every component of the operating system described on this page serves a dual purpose: it makes the day-to-day business run better, and it produces the documented proof of business value that a future valuation depends on. These are the same thing, built at the same time.
"A service business doing consistent annual revenue can sell for a multiple — if it's systematized and transferable. This system makes that possible."
FRONTFRAME · BLUEPRINT PRINCIPLE
What the system documents — and why it matters to a buyer
■ CLIENT RELATIONSHIPS
Captured and transferable — not in Connie's head or inbox
Every client is a CRM record with full history: how they found the business, what they purchased, what lifecycle stage they're in, what they're likely to buy next. A buyer who acquires this business receives a documented client base — not a contact list that only makes sense to Connie.
■ REVENUE
Visible, trackable, and projectable
Revenue from both sites flows through Stripe and is recorded in Supabase against the client record that generated it. Monthly revenue, product mix, source attribution, and pipeline value are all computable from the same dataset. A buyer can see last year's revenue by source in under a minute — and project forward from pipeline data.
■ OPERATING SYSTEM
Can be handed to a buyer who runs it without Connie in the room
The pipelines, automations, booking flows, and follow-up sequences are documented logic — not Connie's personal judgment calls. A new owner reviews the admin portal, sees every active client and their stage, and knows what actions to take next without asking Connie. This is what "operational independence" means for a service business at this scale.
Without this system vs. with it
◆ WITHOUT THE OPERATING SYSTEM
When Connie stops, the revenue stops.
■ WITH THE OPERATING SYSTEM
The business runs. The asset is documented. An exit is possible.
What the reporting layer makes visible
| Metric | Without OS — current state | With OS — target state |
|---|---|---|
| Total revenue (MTD / YTD) | Assembled from Stripe dashboard + memory of informal payments. Takes 30 min to reconstruct. | Live Supabase query. Broken down by product type, site, and source. Seconds. |
| Active client count | Known to Connie approximately. Not documented. Cannot be verified by a third party. | Exact. Supabase record count filtered by coaching_active = true or pipeline stage. |
| Revenue by source | Unknown. No attribution tracking on either site. Cannot state what percentage comes from referrals vs. search vs. speaking. | Tagged on every intake record. Referral %, speaking conversion, and organic share all computable. |
| Pipeline forward value | Invisible. Pending proposals and likely renewals exist only in Connie's memory of recent conversations. | Open deals × avg deal value by type, visible in admin. Coaching retainer renewals projected automatically. |
| Client lifetime value | Unknown per client. Impressionistic ("Hal is a long-term client") without a dollar figure. | Computed per record from Stripe history. Top-10 clients by LTV visible in one query. |
| Cross-sell conversion rate | Unmeasured. The two-site synergy is a verbal assertion with no data behind it. | Tracked. A→B and B→A conversion rates are live metrics, demonstrable to any acquirer. |
Connie's expertise is the business. Thirty years of methodology, 16 call reluctance types understood at a practitioner level, thousands of coaching hours — none of it is documented in transferable form. It exists in her conversations, her session notes, and her responses to client questions. The operating system, over time, progressively moves that expertise out of her head and into documented, searchable, structured content. The goal is not to replace Connie. It is to ensure the business doesn't depend entirely on her memory.
"Your expertise becomes a business asset, not a personal dependency."
KNOWLEDGE EXTRACTION PRINCIPLE
How it progresses — four phases
PHASE 01 · IMMEDIATE
Capture what clients ask
Bot interactions are the first documented record of what clients actually want to know
The content gaps log captures what real visitors ask in real time — not what Connie guesses they ask, not what she thinks they need to know. Every unanswered question is a documented gap between what the business knows and what it communicates. This is the raw material of IP documentation: a continuously updated list of questions that Connie's expertise can answer but the current content doesn't.
Output: content_gaps table in Supabase · ranked by frequency · surfaced in admin bot
PHASE 02 · ONGOING
Gaps become documentation to-do list
The gap log tells Connie exactly what to write, in priority order
Each open gap log entry is an item on the IP documentation backlog. The admin bot can draft a proposed answer from Connie's existing published content. Connie reviews and refines it. Once approved, the answer is added to the site — closing the gap, strengthening the page, and feeding the corrected content back into the bot's knowledge base. The system learns from its own gaps.
Output: FAQ entries · page sections · methodology explainers · added to grounding content and published to both sites
PHASE 03 · MEDIUM TERM
Methodology becomes structured content
The 9-step coaching method, the 16 types, and 30 years of pattern recognition — made searchable
Over time, the gap log and client interaction patterns reveal which parts of Connie's methodology are being asked about most. Those become the priority documentation targets: structured explainers of each of the 9 coaching steps, type-specific profiles for the 16 call reluctance types, case study frameworks from real client outcomes. Each piece of documented methodology is simultaneously site content, bot grounding knowledge, and transferable IP.
Output: methodology library · type profiles · structured case study templates · bot knowledge base entries
PHASE 04 · LONG TERM
The business can answer its own questions
A documented operating system with codified methodology is a fundamentally different asset than a practitioner and her inbox
At phase four, the system has accumulated enough structured content that the bots handle the majority of pre-sale qualification questions without Connie's involvement. The methodology is documented well enough that a qualified associate could be onboarded from the IP library alone. Revenue attribution is clear enough that a buyer can model forward without a founder interview. This is the target state — not because Connie is stepping back, but because the business should be able to operate at that level of documentation whether or not she does.
Output: fully transferable business asset · documented methodology · measurable client base · owner-independent operating system
What gets extracted from Connie's expertise — and where it lives
◈ SOURCE
Client questions (bot interactions)
What buyers actually ask at each stage of the consideration process. Captured in content_gaps table. The most honest real-time view of what the business needs to communicate.
◈ SOURCE
Coaching session patterns
Which call reluctance types appear most frequently. Which coaching steps produce the most notable client breakthroughs. Which industries generate the most consistent results. Captured in CRM notes and structured into type profiles over time.
◈ SOURCE
Client outcomes (case studies)
Stage 06 clients — Hal Daugherty (8 years), Alan Bauer (9 new clients in 9 weeks), Matthew Hyde's client (top 2-percentile in industry) — are the strongest IP in the system. Structured case study templates turn them into transferable proof.
■ DESTINATION
Documented, searchable, bot-accessible content
FAQ pages, methodology explainers, type profiles, and case study pages — published on both sites, stored in the bot knowledge base, and available to any future owner, associate, or acquirer without Connie having to be in the room.
The business case — in plain terms
The operating system is not a technology project. It is a business formalization project that happens to require technology.
Every component — the CRM, the booking layer, the pipelines, the bots, the gap log, the knowledge extraction process — serves the same underlying goal: making the value that Connie has built over 30 years visible, measurable, and transferable. The business already has the raw material for a significant valuation. What it doesn't have yet is the documentation. This system produces that documentation as a byproduct of running the business better every day.
Hi, I'm here to answer your questions about how the FrontFrame operating system works. Use the icon below anytime.
Got it ×