Case study · A tenant on Intelligent Operations
Intelligent Operations
The platform every tenant here runs on.
Intelligent Operations, LLC builds and operates the software layer that runs a business's repetitive work: a store of Agent Libraries, templates and agents, and the tenant consoles that put them to work. This case study is the platform itself.
- 10screens
- 19prompt libraries
- 214column prompts
- 1,109variables filled
The business
- Agent Libraries: every area of the operating loop has at least five, each a questionnaire, six-part column prompts and a field map, sold once at $14 with a Notion template.
- The loop: Know, Research, Plan, Create, Distribute, Convert, Retain and Measure, with an Operate hub of agents, data and automation.
- One console per tenant, each with its own database, brand kit and Variables library.
- Mission: turn scattered operational knowledge into structured context that agents and people can both execute.
- Based in North Kansas City, Missouri.
/
/libraries
/areas/context-io
/areas/identity-io
/areas/brand-io
/areas/model-context-io
/areas/research-io
/areas/market-io
/areas/competitor-io
/io-consolePrompt libraryMission, Vision & Values
Codifies the platform's stated mission and its traceability and refuse-rather-than-pretend values.
- Purpose Discovery Questions
- Culture Evidence Review
- Mission Statement
- Vision Statement
- Core Values Set
- Value Behaviour Standards
- Values in Practice
- Public Mission Page Copy
- Alignment Check
- Rollout and Reinforcement Plan
Prompt libraryBrand Positioning
Positions IO between prompt/template marketplaces and agencies as the operating context layer.
- Market Category Definition
- Target Audience Positioning
- Competitive Positioning Matrix
- Value Proposition Statement
- Brand Benefits Hierarchy
- Points of Difference Framework
- Points of Parity Framework
- Brand Promise Statement
- Positioning Statement Structure
- Positioning Testing Framework
- Positioning Evolution Timeline
- Category Disruption Strategy
Prompt libraryCompetitor Offerings & Value Propositions
Maps the category alternatives, prices and claims buyers weigh against a $14 Agent Library, with sourced scans still to run.
- Competitor Set Definition
- Offering Portfolio Inventory
- Feature And Capability Comparison
- Pricing And Packaging Analysis
- Value Proposition Teardown
- Customer Pain Point Gap Map
- Differentiation Opportunity Shortlist
- Positioning Statement Drafts
- Sales Battlecard Set
- Message Claim Validation
- Competitor Watch Cadence
Prompt libraryTARGET MARKET
Defines the Notion-first operators and owner-led tenants the store and consoles serve.
- Target Market Overview
- Ideal Customer Profile
- Primary Target Segment
- Target Market Segments
- Customer Personas
- Target Market Industry, Companies, & Job Titles Overview
- Customer Insights & Behaviors Overview
- Customer Goals, Desires, & Motivations Overview
- Customer Communication & Engagement Overview
- Customer Problems & Pain Points Overview
- Customer Personalities & Archetypes Overview
- Customer Transformation Overview
- Storybrand Script
Prompt libraryValue Proposition
States the core promise of a ready-to-run method delivered instantly.
- Primary Value Proposition
- Audience-Specific Value Statements
- Problem Definition
- Solution Statement
- Unique Benefits Description
- Competitive Differentiation Points
- Evidence and Proof Points
- Value Quantification Framework
- Emotional Value Components
- Rational Value Components
- Value Delivery Timeline
- Value Proposition Testing Framework
Prompt libraryDigital Product Storefront
The Agent Libraries storefront is IO's primary self-serve revenue surface.
- Digital Offer Inventory
- Buyer Intent Questions
- Product Packaging Model
- Delivery And Access Method
- License Terms Summary
- Storefront Navigation Structure
- Product Listing Page
- Listing Copy
- Preview And Sample Assets
- Purchase To Access Test
- Refund And Support Policy
- Storefront Sales Measures
Prompt libraryPricing & Promotions
Sets rules around the flat $14 price, Stripe promotion codes and proposed bundles.
- Pricing Input Questions
- Competitive Price Scan
- Price Architecture
- Margin Floor Rules
- Promotion Type Menu
- Discount Guardrails
- Promotional Calendar
- Offer Copy Variants
- Price Change Communication
- Promotion Test Design
- Promotion Results Analysis
- Pricing Health Measures
Prompt libraryCheckout & Cart Optimization
Optimises the single-step Buy now to Stripe Checkout path.
- Checkout Flow Mapping
- Abandonment Point Diagnosis
- Buyer Hesitation Questions
- Cart Page Structure
- Checkout Field Minimization
- Payment Method Mix
- Trust And Reassurance Copy
- Shipping Cost Disclosure Rules
- Cart Recovery Sequence
- Checkout Test Plan
- Checkout Funnel Metrics
Prompt libraryOrder Fulfillment & Post-Purchase
Governs the automated fulfil(), entitlement and access-token delivery flow.
- Fulfillment Model Assessment
- Order Lifecycle Map
- Customer Expectation Questions
- Shipping And Delivery Promise
- Order Status Communication Plan
- Transactional Message Copy
- Returns And Exchange Policy
- Exception Handling Playbook
- Post-Purchase Onboarding Sequence
- Review And Referral Ask
- Fulfillment Service Levels
- Post-Purchase Performance Report
Prompt libraryNotion Template Productization
Every library ships as a Notion Duplicate-as-template product.
- Buyer Problem Definition
- Template Market Scan
- Template Scope And Promise
- Template Information Architecture
- Build Specification
- In-Template Guidance
- Duplication And Quality Test
- Listing Copy
- Listing Visual Plan
- Delivery And Support Process
- Template Sales Metrics
Prompt libraryPrompt Library Packaging
Each product is a packaged prompt library with questionnaire and field map.
- Library Buyer Profile
- Competitive Listing Scan
- Product Name And Promise
- Package Contents List
- Delivery Format Plan
- Listing Page Copy
- Sample Prompt Preview
- Setup Instructions
- Bundle And Price Points
- Pre-Launch Checklist
- Library Sales Measures
Prompt libraryProduct Launch
Plans the public launch of the 147-library store.
- Launch Announcement Framework
- Product Positioning Statement
- Key Messaging Points
- Launch Email Sequences
- Press Release Template
- Launch Timeline Communications
- Launch Event Content
- Launch Video Script Framework
- Early Adopter Messaging
- Sales Team Enablement Materials
- Launch FAQ Document
- Launch Success Metrics Framework
Prompt libraryGenerative Engine Optimization (GEO)
IO depends on answer engines describing it accurately; it already maintains an llms.txt brief.
- Prompt Set Discovery
- AI Visibility Baseline
- Citation Source Map
- Entity Clarity Framework
- Citable Content Standards
- Owned Content Plan
- Earned Presence Plan
- Crawler Access Review
- Misrepresentation Correction
- GEO Measurement Framework
- GEO Programme Report
Prompt libraryTenant Onboarding
Brings client businesses into their one console with brand, content and variables.
- Engagement Scope Summary
- Kickoff Discovery Questions
- Stakeholder and Role Map
- Access and Asset Intake
- Onboarding Sequence
- Welcome Communication
- Console Walkthrough Plan
- Onboarding Readiness Check
- Handoff to Ongoing Service
- Onboarding Success Measures
Prompt libraryTenant Health & Account Review
Reviews tenant accounts and risk, including platform incidents that touch tenant data.
- Account Context Summary
- Health Signal Inventory
- Health Score Model
- Value Delivered Assessment
- Relationship Risk Assessment
- Expansion Opportunities
- Review Meeting Agenda
- Account Review Report
- Next Period Success Plan
- Escalation Protocol
Prompt libraryAutomation Scripts & Runbooks
The platform runs on seed/sync scripts, a daily ops-audit and recovery runbooks.
- Automation Candidate Inventory
- Automation Priority Score
- Script Standards
- Safety and Idempotency Rules
- Script Specification
- Runbook Template
- Failure and Recovery Design
- Script Review Checklist
- Scheduling and Triggering Plan
- Automation Health Measures
Prompt libraryData Governance & Access
Governs multiple Postgres databases, tenant isolation and secrets after the 2026-09-28 incident.
- Data Landscape Questions
- Data Classification Scheme
- Data Ownership Register
- Role and Permission Model
- Access Request and Review Process
- Secrets and Credential Standards
- Retention and Deletion Schedule
- Audit Logging Requirements
- Governance Compliance Assessment
- Governance Health Metrics
- Governance Policy Statement
Prompt libraryRelease Notes & Changelog
Communicates PR-based releases such as the storefront and the admin-app retirement.
- Release Content Intake
- Change Classification
- Audience Impact Matrix
- Release Summary
- Changelog Entries
- Feature Announcement
- Deprecation Notice
- Changelog Style Rules
- Publishing Workflow
- Release Communication Metrics
- Release Retrospective
Prompt libraryA/B Testing Framework
Structures a disciplined test programme for product pages and the libraries index, starting with contents above the fold.
- Testing Readiness Questions
- Conversion Baseline Assessment
- Hypothesis Backlog
- Test Prioritisation Framework
- Experiment Design Brief
- Sample Size And Duration Plan
- Variant Copy And Layout Spec
- Test Launch Checklist
- Mid-Test Monitoring Rules
- Result Analysis Report
- Rollout And Learning Log
- Testing Programme Cadence
Variables · Mission, Vision & Values01 · Purpose Discovery Questions
{{01_Purpose_Discovery_Questions}}- Intelligent Operations exists because most businesses keep their operating knowledge in people's heads, scattered documents and tools that do not talk to each other, so neither staff nor AI agents can act on it reliably. The company serves operators, marketing and revenue teams, and owner-led businesses that have bought software but cannot turn it into repeatable outcomes. If it closed, its tenants would lose the one console that holds their brand, content, records and variables in one governed place, and buyers would lose a library of ready-to-run methods. It refuses to publish figures it cannot source or to sell tools it has not run itself. Its aspiration is for every IO area on the operating loop to be a method a business can duplicate and run the same day.
{{REASON_FOR_EXISTING}}- Operational knowledge is scattered across people, documents and disconnected tools, so it cannot be executed consistently by people or by agents. Intelligent Operations turns it into structured context that both can run.
{{PEOPLE_SERVED}}- Operators, marketing and RevOps teams, and owner-led businesses; tenant clients with their own console (for example a commercial brokerage and a construction company); and self-serve buyers of Agent Libraries.
{{LOSS_IF_CLOSED}}- Tenants would lose their single console with its own database, brand kit and variables library; buyers would lose a maintained catalogue of 147 Agent Libraries and the methods behind 65 IO areas.
{{REFUSALS}}- Refuses to present a figure without a source; refuses to invent testimonials, reviews or results; refuses to create a second workspace for a tenant; refuses to change production outside the one reviewed change path.
{{ASPIRATIONS}}- Every area on the eight-stage operating loop available as a method a buyer can duplicate into their own workspace, and every tenant console reading from one registry with no drift.
Variables · Mission, Vision & Values02 · Culture Evidence Review
{{02_Culture_Evidence_Review}}- The culture shows most clearly in how the platform documents itself: decisions are recorded as numbered ADRs, recovery steps as runbooks, and every change goes feature branch, staging, verify, then main. When a shared-variable mistake pointed tenant databases at the estate database, the response was a CRITICAL check in the daily ops-audit rather than a quiet fix. Placeholder copy is removed rather than dressed up, and pages state when no figures are on record. The stated value of traceability is practised in code comments that explain why each rule exists.
{{DEFINING_STORIES}}- Consolidating the whole estate into one repository and one backend (ADR 0001); folding per-tenant admin apps into a single tenant console; and rebuilding the platform's llms.txt so every count is read from the same module the index page renders from.
{{DEFINING_DECISIONS}}- Git is the source of truth and Notion only mirrors it (ADR 0004); one console per tenant (ADR 0002); media lives in buckets, never git (ADR 0005); no new Railway services (ADR 0009); console visibility is estate policy (ADR 0010).
{{OBSERVED_BEHAVIOURS}}- Dry run before every bulk write; backups before catalogue changes; incidents written up in a lessons file; empty states that say no data is on record instead of showing sample numbers.
{{STATED_VS_PRACTISED}}- Largely aligned on traceability and change control. Gap: PLAN.md records that point-in-time recovery was not yet on for the estate and tenant databases, so backup practice still trails the stated standard.
Variables · Mission, Vision & Values03 · Mission Statement
{{03_Mission_Statement}}- Intelligent Operations' mission is to turn scattered operational knowledge into structured context that agents and people can both execute. It does this through a store of Agent Libraries that any team can duplicate, and through dedicated tenant consoles that hold a business's brand, records and variables in one governed place. The outcome is work that runs the same way every time, whoever or whatever runs it. Every claim the platform makes resolves to a source.
{{MISSION_SENTENCE}}- To turn scattered operational knowledge into structured context that agents and people can both execute.
{{PEOPLE_SERVED_STATEMENT}}- For operators and marketing and revenue teams who bought the tools but still run their work by memory and spreadsheet.
{{OUTCOME_CREATED}}- Repeatable, sourced work: a library or console that produces the same quality of output whether a person or an agent runs it.
Variables · Mission, Vision & Values04 · Vision Statement
{{04_Vision_Statement}}- Intelligent Operations envisions a business's operating context as a governed asset rather than tribal memory. In that future, each area of the business sits on one operating loop, from knowing the company to measuring what worked, and every step can be called by an agent as easily as it is used by a person. Intelligent Operations aims to be the context layer beneath marketing and revenue operations. Proposed horizon: three years.
{{FUTURE_STATE}}- Operating context is a governed, versioned asset; every product is also an MCP tool; tenant consoles and the storefront read from one registry.
{{TIME_HORIZON}}- Proposed: three years (2026 to 2029), reviewed annually.
{{CHANGE_DESCRIBED}}- From tribal memory and one-off prompt runs to loops: a run produces data, a loop produces decisions.
Variables · Mission, Vision & Values05 · Core Values Set
{{05_Core_Values_Set}}- Intelligent Operations works to three core values: Traceability, Refuse Rather Than Pretend, and One Source of Truth. Traceability means every claim, number and field resolves to a source a reader can check. Refuse Rather Than Pretend means the platform shows an honest empty state instead of a plausible fabrication. One Source of Truth means each thing lives in exactly one place, and everything else mirrors it.
{{VALUE_NAMES}}- Traceability; Refuse Rather Than Pretend; One Source of Truth.
{{VALUE_MEANINGS}}- Traceability: every claim resolves to a source. Refuse Rather Than Pretend: say no data is on record rather than invent it. One Source of Truth: git holds intent, live systems hold reality, and a scheduled check compares them.
{{TRADEOFFS_RESOLVED}}- Accuracy over completeness when a page could be filled faster with sample data; one reviewed change path over speed when a direct production edit would be quicker.
{{VALUE_COUNT}}- Three.
Variables · Mission, Vision & Values06 · Value Behaviour Standards
{{06_Value_Behaviour_Standards}}- Each value is tied to observable behaviour. Traceability means every value in a tenant's library carries its source path, and every count on a public page is computed rather than typed. Refuse Rather Than Pretend means an unsourced field is written as a target or left empty, never as a result. One Source of Truth means changes are made in git and flow to Railway, Postgres and Notion, never edited in the mirror.
{{VALUE_BEHAVIOURS}}- Cite the source path for every fact; label plans as "Target:" or "Proposed:"; open a PR for every change; take a backup before bulk writes.
{{VALUE_ANTI_BEHAVIOURS}}- Sample numbers shown as results; editing docs directly in Notion; creating a second workspace or a new service to work around a busy one; pushing straight to main.
{{EXAMPLE_DECISIONS}}- Showing a library card without a product rather than inventing one for the 72 unmatched area labels; turning Notion search indexing off so paid templates are not listed publicly.
{{BEHAVIOUR_OWNERS}}- Founder and operator Tommy Saunders owns all three; the daily ops-audit and CI checks enforce them automatically.
Variables · Mission, Vision & Values07 · Values in Practice
{{07_Values_in_Practice}}- The values show up in every operating routine. Contractors and agents are briefed on the same rules the repo's CLAUDE.md sets, so hiring and onboarding start from the values. Reviews check sources and the change path, not only whether a page renders. With tenants, the platform reports what is on record and labels everything else as a plan.
{{HIRING_APPLICATION}}- Proposed: any contractor or agent brief includes the estate rules (one change path, secrets never in git, no bulk deletes without approval) and a sourcing test.
{{REVIEW_APPLICATION}}- Every PR is checked for sourced claims, canonical env reads and the staging-then-main flow before release.
{{CUSTOMER_APPLICATION}}- Tenant reports and case studies show only facts from the tenant's own sources; unsourced items are framed as targets.
{{DECISION_APPLICATION}}- Significant choices are written as ADRs with context, decision and consequences, so later decisions can cite them.
Variables · Mission, Vision & Values08 · Public Mission Page Copy
{{08_Public_Mission_Page_Copy}}- Intelligent Operations turns scattered operational knowledge into structured context that agents and people can both execute. It sells the methods as Agent Libraries you can duplicate into your own workspace today, and it runs dedicated consoles for the businesses it works with. Everything it publishes resolves to a source. When the data is not there, it says so.
{{MISSION_COPY}}- We turn scattered operational knowledge into structured context that agents and people can both execute.
{{VISION_COPY}}- Your operating context should be a governed asset, not tribal memory. We are building the context layer beneath marketing and revenue operations.
{{VALUES_COPY}}- Traceability: every claim resolves to a source. Refuse rather than pretend: no invented numbers. One source of truth: everything lives in one place.
{{VALUE_EXAMPLES}}- Our llms.txt reads every count from the same code that renders the page; our tenant pages say when no engagement figures are on record.
Variables · Mission, Vision & Values09 · Alignment Check
{{09_Alignment_Check}}- Alignment is checked against evidence rather than opinion. The proposed check asks whether operators can state the mission from memory, how many recent decisions cite a value or ADR, and whether tenant-facing output follows the sourcing rule. The daily ops-audit supplies much of the evidence automatically. Results are reviewed quarterly.
{{MISSION_RECALL}}- Target: the founder and every regular contractor can state the mission sentence unprompted.
{{VALUES_PRACTISED_SCORE}}- Proposed: a 1-5 score per value from a quarterly review of merged PRs and tenant outputs; target 4 or above for each.
{{DECISION_CITATIONS}}- Target: every significant change cites an ADR, runbook or PLAN phase in its PR description.
{{CUSTOMER_ALIGNMENT}}- Target: zero unsourced numbers found in tenant-facing pages at each quarterly review.
Variables · Mission, Vision & Values10 · Rollout and Reinforcement Plan
{{10_Rollout_and_Reinforcement_Plan}}- The mission and values roll out through the documents the platform already runs on. The founder signs off the statement, it is added to CLAUDE.md and the public site, and every agent and contractor brief inherits it. Process changes wire the values into CI and the ops-audit so they are enforced, not only stated. Recognition is lightweight: good sourcing and clean rollbacks are noted in the PLAN execution log.
{{LEADERSHIP_SIGNOFF}}- Founder Tommy Saunders approves the final mission, vision and values text.
{{STAFF_LAUNCH}}- Proposed: publish the statement in CLAUDE.md and the site's about copy in one PR, so every session and agent reads it.
{{ONBOARDING_UPDATE}}- Add the values and the sourcing rule to the tenant onboarding welcome and to every agent brief template.
{{PROCESS_CHANGES}}- Extend CI and the daily ops-audit to flag unsourced numeric claims on public pages and non-canonical secret reads.
{{RECOGNITION_ROUTINE}}- Proposed: a monthly note in the PLAN execution log naming changes that exemplified a value, such as a caught drift or a clean restore test.
Variables · Brand Positioning01 · Market Category Definition
{{01_Market_Category_Definition}}- Intelligent Operations competes in AI operations software for marketing and revenue teams, sitting between prompt and template marketplaces on one side and custom agency builds on the other. Its category statement is an operating system of ready-to-run methods, where each Agent Library is a Notion template and Markdown file built from structured column prompts. The same methods power dedicated tenant consoles for client businesses. Proposed category name: the operating context layer for marketing and revenue operations.
{{MARKET_CATEGORY}}- AI operations software and methods for marketing and revenue teams: an operating context layer delivered as Agent Libraries and tenant consoles.
Variables · Brand Positioning02 · Target Audience Positioning
{{02_Target_Audience_Positioning}}- The primary audience is operators and small marketing or RevOps teams who already work in Notion and use AI assistants but lack a repeatable method. A second audience is owner-led businesses that want the work done for them inside a dedicated console. Both share the same frustration: tools bought, outcomes not delivered. Positioning speaks to the operator who wants a method today for $14 and may later want the whole system run for them.
{{TARGET_AUDIENCE}}- Operators, marketing managers and RevOps leads at small and mid-sized businesses who work in Notion and AI tools; owner-led businesses seeking a done-for-you console.
Variables · Brand Positioning03 · Competitive Positioning Matrix
{{03_Competitive_Positioning_Matrix}}- On one axis sits depth of method, from single prompts to full operating systems; on the other sits delivery, from self-serve download to done-for-you service. Prompt marketplaces sit at shallow and self-serve; Notion template shops sit at moderate and self-serve; agencies sit at deep and done-for-you but at high cost. Intelligent Operations occupies deep and self-serve with the Agent Libraries, and deep and done-for-you with tenant consoles, on the same method. That span is the position no single category competitor covers.
{{COMPETITIVE_POSITIONING}}- Deeper than prompt marketplaces and Notion template shops, more affordable and self-serve than agencies, with one method spanning both $14 libraries and managed consoles.
Variables · Brand Positioning04 · Value Proposition Statement
{{04_Value_Proposition_Statement}}- Intelligent Operations gives teams a working method for every area of marketing and revenue operations, ready to duplicate into Notion today. Each Agent Library is a structured set of column prompts with a questionnaire and field mapping, so outputs chain into the next library instead of starting from a blank chat. For businesses that want it run for them, the same method lives in a dedicated console with its own database. The result is repeatable work that people and agents can both execute.
{{VALUE_PROPOSITION}}- A ready-to-run method for each area of marketing and revenue operations, in your own Notion workspace for $14, and the same system run for you in a dedicated console when you need it.
Variables · Brand Positioning05 · Brand Benefits Hierarchy
{{05_Brand_Benefits_Hierarchy}}- The functional benefit is a complete, structured method delivered instantly after purchase. The process benefit is that outputs chain: one library's fields feed the next on the eight-stage loop. The emotional benefit is confidence that the work is sourced and repeatable rather than improvised. The highest-order benefit is a business whose operating knowledge is an asset it owns.
{{BRAND_BENEFITS}}- Functional: complete method, instant delivery. Process: libraries chain across the loop. Emotional: confidence in sourced, repeatable work. Strategic: operating knowledge becomes an owned asset.
Variables · Brand Positioning06 · Points of Difference Framework
{{06_Points_of_Difference_Framework}}- Three points of difference separate Intelligent Operations. First, every library sits on a mapped operating loop with named reads and feeds, so it is part of a system rather than a standalone template. Second, the libraries are the same methods the platform runs in production for its own tenants. Third, every product is also designed as an MCP tool, so it can be called by an agent as well as used by a person.
{{POINTS_OF_DIFFERENCE}}- Libraries mapped onto one eight-stage operating loop with explicit reads and feeds; methods proven in the platform's own tenant consoles; every product also an MCP tool.
Variables · Brand Positioning07 · Points of Parity Framework
{{07_Points_of_Parity_Framework}}- To be considered at all, Intelligent Operations must match what buyers expect of any digital product store. That means a clear price, secure card checkout, instant delivery, a preview of what is inside, and a working duplicate into Notion. The storefront meets these with Stripe Checkout, a Notion Duplicate-as-template link and a signed Markdown download. Parity is maintained through a synthetic purchase test and a link crawl.
{{POINTS_OF_PARITY}}- Clear one-time price; Stripe card checkout; instant Notion and file delivery; product previews; mobile-friendly pages; no broken links.
Variables · Brand Positioning08 · Brand Promise Statement
{{08_Brand_Promise_Statement}}- Intelligent Operations promises that what it sells is a working method, delivered the moment you pay, and that every claim it makes is sourced. Buyers get the same library the platform runs for its own tenants. If data is not on record, the platform says so rather than filling the gap. That promise holds from a $14 library to a full console.
{{BRAND_PROMISE}}- A working method, delivered the moment you pay, with every claim sourced.
Variables · Brand Positioning09 · Positioning Statement Structure
{{09_Positioning_Statement_Structure}}- For operators and marketing and revenue teams who have the tools but not the method, Intelligent Operations is the operating context layer that turns scattered knowledge into structured work people and agents can both run. Unlike prompt marketplaces and template shops, its Agent Libraries are mapped onto one operating loop and proven in live tenant consoles. Unlike agencies, a buyer can start today for $14. And every product is also an MCP tool.
{{POSITIONING_STATEMENT}}- For operators and marketing and revenue teams who have the tools but not the method, Intelligent Operations is the operating context layer whose Agent Libraries turn scattered knowledge into structured work, because each is mapped onto one operating loop and proven in live tenant consoles.
Variables · Brand Positioning10 · Positioning Testing Framework
{{10_Positioning_Testing_Framework}}- Positioning is tested with the channels the platform already controls. Proposed tests compare two landing-page leads (method-first versus price-first) on the libraries index, measured by click-through to a product page and checkout starts. Buyer questions and support contacts are coded for which claim drew them in. Results are reviewed after each four-week window.
{{POSITIONING_TESTING}}- Proposed: A/B the /libraries lead line (method-first vs $14-first) for four weeks; measure product-page click-through and checkout starts; code buyer questions by claim.
Variables · Brand Positioning11 · Positioning Evolution Timeline
{{11_Positioning_Evolution_Timeline}}- The positioning evolves in stages that follow the PLAN. Today it leads with the Agent Libraries storefront and its 147 products. Next, once the registry contract lands, it adds libraries that chain directly into tenant consoles. Later it leads with the platform as the context layer beneath marketing operations, with the libraries as the entry point.
{{POSITIONING_EVOLUTION}}- Now: Agent Libraries storefront. Next (Proposed, after PLAN phase 4): libraries that chain into consoles via the registry contract. Later: the context layer beneath marketing and revenue operations.
Variables · Brand Positioning12 · Category Disruption Strategy
{{12_Category_Disruption_Strategy}}- Intelligent Operations disrupts the template category by selling methods that connect rather than files that stand alone. Where a template ends at download, an Agent Library names what it reads and what it feeds, and places itself on the operating loop. The strategy is to make that connected loop the buyer's expectation, so standalone prompt packs look incomplete by comparison. The storefront's loop and workflow diagrams on every product page are the first step.
{{CATEGORY_DISRUPTION}}- Reframe the category from standalone templates to connected methods: every product page shows its place on the operating loop and its reads and feeds, making isolated prompt packs look incomplete.
Variables · Competitor Offerings & Value Propositions01 · Competitor Set Definition
{{01_Competitor_Set_Definition}}- The competitor set for a $14 Agent Library has four groups: prompt marketplaces and prompt packs, Notion template shops, AI workspace and automation tools, and agencies or fractional operators. The alternative buyers weigh most often is doing it themselves in a blank chat or Notion page. No named competitors or lost-deal records are on record yet, so the set is defined by category and a named scan is proposed.
{{DIRECT_COMPETITORS}}- Prompt marketplaces and prompt packs; Notion template shops selling ready-made workspaces. Named sellers to be chosen in the scan.
{{ADJACENT_COMPETITORS}}- AI workspace and automation platforms with built-in templates; marketing playbook and course sellers.
{{SUBSTITUTE_SOLUTIONS}}- Writing prompts from scratch in a chat assistant; building the method in Notion alone; hiring an agency, consultant or fractional marketer.
{{SEGMENT_SPECIFIC_RIVALS}}- For operators: template shops. For consultants: playbook bundles. For owner-led tenants: agencies and fractional operators.
{{LOST_DEAL_EVIDENCE}}- None on record; storefront has no recorded lost orders. Proposed: log the reason for refund requests and abandoned checkouts.
Variables · Competitor Offerings & Value Propositions02 · Offering Portfolio Inventory
{{02_Offering_Portfolio_Inventory}}- Competitor portfolios fall into single prompts and packs, template workspaces and bespoke agency builds. Named product lines, tiers and dates are not on record, so this inventory records the category shapes and requires a dated source for every named item. Stated target customers range from individual creators to in-house teams.
{{COMPETITOR_PRODUCT_LINES}}- Prompt packs and single prompts; Notion templates for content, CRM and planning; custom automation builds and retainers.
{{SERVICE_TIERS}}- Category norm: free sample, single purchase, bundle; agencies use project and retainer tiers. Named tiers to be captured with sources.
{{BUNDLES_AND_ADD_ONS}}- Category norm: bundles of packs or templates, lifetime updates. Not verified for named sellers.
{{STATED_TARGET_CUSTOMER}}- Individual creators and freelancers for packs; small teams for templates; mid-market firms for agencies. To be confirmed from each seller's own page.
{{SOURCE_AND_DATE}}- Not yet captured. Proposed: each entry records its URL and capture date, refreshed per the watch cadence.
Variables · Competitor Offerings & Value Propositions03 · Feature And Capability Comparison
{{03_Feature_And_Capability_Comparison}}- IO's Agent Libraries differ from the category in being connected methods rather than standalone items: each has a questionnaire, six-part column prompts and a field map, and sits on an eight-stage loop. Named competitor capabilities are unverified, so differences are marked as confirmed only for IO's own side. The comparison is weighted by what buyers say they need, which is still to be gathered.
{{COMPARED_CAPABILITIES}}- Structured questionnaire; chained outputs across a loop; Notion template plus Markdown file; instant delivery; MCP tool access; upgrade path to a managed console.
{{CONFIRMED_DIFFERENCES}}- Confirmed for IO: 147 libraries across 65 areas on an eight-stage loop; instant delivery through an access link; $14 flat price. Competitor side not confirmed.
{{PARITY_AREAS}}- Likely parity: Notion template delivery and low one-time price. To be verified per competitor.
{{CUSTOMER_WEIGHTED_ROWS}}- Proposed rows: time to first use; depth of method; fit with Notion; price; path to done-for-you help. Weights to come from buyer feedback.
{{UNVERIFIED_CLAIMS}}- All named competitor capabilities, prices and review claims until sourced.
Variables · Competitor Offerings & Value Propositions04 · Pricing And Packaging Analysis
{{04_Pricing_And_Packaging_Analysis}}- IO's price is a flat $14 one-time per library, verified against Stripe on 2026-09-28. Competitor prices are not on record, so the analysis compares billing models and proposes a sourced scan of comparable prompt packs and Notion templates. The price position is a low entry for a deep method, with bundles proposed.
{{PRICE_POINTS}}- IO: $14 one-time per library. Competitors: not on record; proposed scan of 20 comparable packs and templates.
{{BILLING_MODELS}}- One-time purchase (IO, packs, templates); subscription or membership (some sellers); retainer and project fees (agencies).
{{CONTRACT_TERMS}}- IO: one-time licence; Proposed terms cover own-business and client use, no resale. Competitor terms to be captured.
{{HIDDEN_COSTS}}- IO: none beyond a Notion account; Notion AI optional since prompts can be pasted. Competitors: to be checked for add-ons and required tools.
{{IMPLIED_TARGET_CUSTOMER}}- Low one-time price implies individual operators and small teams; retainers imply mid-market firms.
Variables · Competitor Offerings & Value Propositions05 · Value Proposition Teardown
{{05_Value_Proposition_Teardown}}- Competitor headline claims tend to promise volume (many prompts), beauty (ready-made workspaces) or outcomes (done-for-you results). Named headlines are not yet captured, so this teardown sets the method and IO's own claims as the reference. IO's claim leans on a ready-to-run method and verifiable platform facts rather than outcome promises.
{{HEADLINE_CLAIMS}}- Category pattern: volume of prompts; polished templates; expert done-for-you work. Named headlines to be captured.
{{PROMISED_OUTCOMES}}- Category pattern: save time; ship faster; scale output. IO: a completed, structured deliverable in your own workspace.
{{PROOF_OFFERED}}- Category pattern: sales counts and testimonials. IO: verifiable platform facts, with no testimonials claimed.
{{CLAIM_STRENGTH}}- Rate each competitor claim as verified, plausible or unsupported once captured; none rated yet.
{{APPEAL_TYPE}}- Volume and price for packs; aesthetic and ease for templates; expertise and trust for agencies.
Variables · Competitor Offerings & Value Propositions06 · Customer Pain Point Gap Map
{{06_Customer_Pain_Point_Gap_Map}}- No customer complaints about competitors are on record, so the gap map uses working hypotheses from IO's positioning: disconnected templates, prompts that restart from zero and tools that never reach operational use. Frequencies are unknown and stated as such. The plan is to source complaints from public reviews and forums before using them in messaging.
{{COMPLAINT_THEMES}}- Hypotheses only: disconnected templates; prompts that restart from zero; no path from template to working process.
{{COMPLAINT_FREQUENCY}}- Not on record; to be counted from sourced reviews.
{{COMPETITOR_COVERAGE}}- Not assessed; to be rated per theme once reviews are collected.
{{UNSERVED_NEEDS}}- A connected method where each output feeds the next; instant delivery; an upgrade path to managed help.
{{REVIEW_SOURCES}}- Proposed: public marketplace reviews, Notion template forums, community threads; each cited with a date.
Variables · Competitor Offerings & Value Propositions07 · Differentiation Opportunity Shortlist
{{07_Differentiation_Opportunity_Shortlist}}- The shortlist of differentiation options centres on what IO can prove: connected methods on one operating loop, agency-grade depth at $14 and an upgrade path to a managed console. The exploited gap is the space between shallow self-serve and costly agencies. Each option lists the proof required before it is claimed.
{{DIFFERENTIATION_OPTIONS}}- Connected methods on an eight-stage loop; depth at $14; library-to-console upgrade path; every library callable as an MCP tool.
{{EXPLOITED_GAP}}- Deep and self-serve: a method with agency-grade structure at a flat low price.
{{TARGET_CUSTOMERS}}- Notion-first operators and marketing or RevOps teams; consultants duplicating methods per client; owner-led businesses needing a console.
{{PROOF_REQUIRED}}- Catalogue counts, field maps shown on product pages, a worked example from a tenant, and delivery timing data.
{{COPY_RESISTANCE}}- Connected chain of 147 libraries and the tenant consoles built on the same methods are harder to copy than one template.
Variables · Competitor Offerings & Value Propositions08 · Positioning Statement Drafts
{{08_Positioning_Statement_Drafts}}- The positioning statement is for operators and owner-led businesses who work in Notion and AI tools but lack a repeatable method. IO is framed as an operating context layer of ready-to-run methods, not a prompt pack. The benefit is a completed, structured deliverable today, and the reason to believe is the catalogue and the tenant consoles that run the same methods.
{{POSITIONING_AUDIENCE}}- Operators, marketing and RevOps teams and owner-led businesses who work in Notion and AI tools.
{{CATEGORY_FRAME}}- AI operations methods: an operating context layer delivered as Agent Libraries and tenant consoles.
{{COMPETITIVE_ALTERNATIVE}}- Prompt packs and template shops for self-serve; agencies and fractional operators for done-for-you.
{{KEY_BENEFIT}}- A complete, ready-to-run method in your own Notion workspace the moment you pay, for $14.
{{REASON_TO_BELIEVE}}- 147 active libraries with verified Stripe prices, 65 areas, and the same methods running inside the platform's tenant consoles.
Variables · Competitor Offerings & Value Propositions09 · Sales Battlecard Set
{{09_Sales_Battlecard_Set}}- The battlecards prepare the founder for the conversations where buyers compare IO with packs, templates or agencies. Competitor strengths are stated fairly, weaknesses are framed as hypotheses until verified, and walk-away criteria name when another option is the better fit. Nothing is claimed about a named competitor without a source.
{{COMPETITOR_STRENGTHS}}- Packs: variety and low cost. Templates: polish and familiarity. Agencies: bespoke work and accountability.
{{COMPETITOR_WEAKNESSES}}- Hypotheses: packs lack structure; templates stay disconnected; agencies cost more and take longer. To verify before use.
{{LIKELY_OBJECTIONS}}- It is only prompts; why not build it myself; I do not use Notion; will it fit my business.
{{DISCOVERY_QUESTIONS}}- Which deliverable do you need first? Where does the work live today? Who reviews AI output? Do you need it done for you or a method to run?
{{WALK_AWAY_CRITERIA}}- The buyer needs a fully bespoke build on short notice, or has no workspace to run a method in.
Variables · Competitor Offerings & Value Propositions10 · Message Claim Validation
{{10_Message_Claim_Validation}}- Every planned claim is tied to evidence with a source date before it appears in copy. Superlatives are avoided unless proven, and comparative claims about named competitors go to review. Claims about IO's own catalogue, price and delivery are backed by the estate database and the 2026-09-28 verification.
{{PLANNED_CLAIMS}}- 147 active libraries; $14 one-time; instant Notion and Markdown delivery; 65 IO areas; methods run inside tenant consoles.
{{CLAIM_EVIDENCE}}- Offerings and prices in the estate database; Stripe price check; orders and entitlements rows; site crawl.
{{SOURCE_DATES}}- Stripe prices verified 2026-09-28; site crawl of 226 pages with 0 broken links 2026-09-28.
{{SUPERLATIVE_RULES}}- No best, first or only without documented proof; no outcome guarantees.
{{LEGAL_REVIEW_FLAGS}}- Any named competitor comparison, pricing comparison, or claim about results.
Variables · Competitor Offerings & Value Propositions11 · Competitor Watch Cadence
{{11_Competitor_Watch_Cadence}}- The watch cadence tracks competitor offers, prices and claims at a rhythm one operator can keep. Signals come from public pages and marketplaces, each with an owner and refresh trigger. The founder owns the watch and reviews it monthly.
{{WATCHED_SIGNALS}}- New products; price changes; bundles; new claims; new Notion-based AI features from platforms.
{{SIGNAL_SOURCES}}- Competitor sites; marketplace listings; Notion template galleries; community threads.
{{CHECK_FREQUENCY}}- Monthly for listed competitors; quarterly for the full category scan.
{{SIGNAL_OWNERS}}- Founder, Tommy Saunders.
{{REFRESH_TRIGGERS}}- A competitor price change; a new entrant; a storefront price or bundle decision; a drop in conversion.
Variables · TARGET MARKET01 · Target Market Overview
{{01_Target_Market_Overview}}- Intelligent Operations targets small and mid-sized businesses and teams in the United States that run marketing and revenue work with Notion and AI assistants. Self-serve buyers purchase individual Agent Libraries; owner-led businesses become tenants with their own console. The platform is based in North Kansas City, Missouri, and delivers software and services remotely. The market is defined by need rather than industry: teams with tools but no repeatable method.
{{TARGET_MARKET_OVERVIEW}}- US small and mid-sized businesses and teams running marketing and revenue work in Notion and AI tools; self-serve library buyers and owner-led businesses seeking a managed console.
Variables · TARGET MARKET02 · Ideal Customer Profile
{{02_Ideal_Customer_Profile}}- The ideal self-serve customer is a marketing or operations lead at a team of roughly 2 to 50 people who already works in Notion daily and uses an AI assistant. They buy a library to solve one area now, then return for the next area on the loop. The ideal tenant is an owner-led business with a clear brand, an active website and several channels, which wants its content, records and campaigns run from one console.
{{IDEAL_CUSTOMER_PROFILE}}- Self-serve: a Notion-first marketing or ops lead at a 2-50 person team using AI daily. Tenant: an owner-led business with an active site and channels wanting one managed console.
Variables · TARGET MARKET03 · Primary Target Segment
{{03_Primary_Target_Segment}}- The primary segment for the storefront is the Notion-first operator. This person is comfortable duplicating a template, already pays for AI tools, and wants a method rather than another blank prompt. They are the fastest route to purchase because the $14 price is within a personal card limit.
{{PRIMARY_TARGET_SEGMENT}}- Notion-first operators and marketing leads who already pay for AI tools and want a method for one area of work.
Variables · TARGET MARKET04 · Target Market Segments
{{04_Target_Market_Segments}}- Four segments are proposed. Notion-first operators buy single libraries. Fractional marketers and consultants buy several libraries to use across clients. Owner-led small businesses buy services and consoles. Revenue and marketing teams inside larger firms buy stage sets for a specific initiative.
{{TARGET_MARKET_SEGMENTS}}- Notion-first operators; fractional marketers and consultants; owner-led small businesses (tenants); in-house marketing and RevOps teams.
Variables · TARGET MARKET05 · Customer Personas
{{05_Customer_Personas}}- The Operator runs a small team's marketing in Notion and wants to stop rebuilding the same brief every week. The Consultant serves several clients and wants a consistent method they can duplicate per client. The Owner runs a local business, such as a brokerage or contractor, and wants the work run for them in one console. The Team Lead needs a structured plan for one initiative this quarter.
{{CUSTOMER_PERSONAS}}- The Operator (Notion-first, self-serve); The Consultant (multi-client, repeat buyer); The Owner (tenant, done-for-you); The Team Lead (initiative-driven, buys stage sets).
Variables · TARGET MARKET06 · Target Market Industry, Companies, & Job Titles Overview
{{06_Target_Market_Industry_Companies_Job_Titles_Overview}}- Industry is secondary to function, but the platform's live tenants show where it is proven: commercial real estate, construction, hospitality and travel, and personal brands. Job titles include marketing manager, marketing operations manager, RevOps lead, founder or owner, and fractional CMO. Company size ranges from sole operators to small teams.
{{TARGET_MARKET_INDUSTRY_COMPANIES_JOB_TITLES_OVERVIEW}}- Functions: marketing, marketing ops, RevOps. Proven tenant industries: commercial real estate, construction, travel, personal brands. Titles: marketing manager, marketing ops manager, RevOps lead, founder, fractional CMO.
Variables · TARGET MARKET07 · Customer Insights & Behaviors Overview
{{07_Customer_Insights_Behaviors_Overview}}- Target buyers already live in Notion and AI chat tools and judge products by how quickly they can start. They preview before buying and expect delivery in minutes. They reuse what works, so a first library that performs is likely to lead to the next. Proposed: confirm these behaviours with purchase and access data once volume allows.
{{CUSTOMER_INSIGHTS_BEHAVIORS_OVERVIEW}}- Notion and AI-tool native; preview before buying; expect instant delivery; reuse what works and return for adjacent areas (to be confirmed with purchase data).
Variables · TARGET MARKET08 · Customer Goals, Desires, & Motivations Overview
{{08_Customer_Goals_Desires_Motivations_Overview}}- Buyers want to produce consistent, high-quality work without starting from scratch each time. They are motivated by saving setup time, looking prepared in front of clients or leadership, and making AI tools finally pay off. Owners want fewer tools and one place where the work lives.
{{CUSTOMER_GOALS_DESIRES_MOTIVATIONS_OVERVIEW}}- Consistent work without starting from zero; making AI tools pay off; looking prepared; for owners, one place where the work lives.
Variables · TARGET MARKET09 · Customer Communication & Engagement Overview
{{09_Customer_Communication_Engagement_Overview}}- Self-serve buyers find products through search, answer engines and the libraries index, then read the product page, preview and buy in one session. They prefer written, specific copy over sales calls. Tenants engage through their console and direct contact with the founder. Stripe receipts and the access page are the main post-purchase touchpoints today.
{{CUSTOMER_COMMUNICATION_ENGAGEMENT_OVERVIEW}}- Discovery via search, answer engines and the /libraries index; written product pages over calls; post-purchase through Stripe receipt and the access page; tenants through their console.
Variables · TARGET MARKET10 · Customer Problems & Pain Points Overview
{{10_Customer_Problems_Pain_Points_Overview}}- The central problem is execution: teams bought the tools but cannot operationalise them. Prompts start from a blank chat every time, templates do not connect, and knowledge sits with one person. For owners, work is spread across too many tools and vendors.
{{CUSTOMER_PROBLEMS_PAIN_POINTS_OVERVIEW}}- Tools bought but not operationalised; prompts that restart from zero; disconnected templates; knowledge held by one person; too many tools and vendors.
Variables · TARGET MARKET11 · Customer Personalities & Archetypes Overview
{{11_Customer_Personalities_Archetypes_Overview}}- The Builder likes to assemble their own system and values structure and control. The Pragmatist wants the fastest route to a finished output. The Delegator wants someone else to run it and cares about results and trust. The storefront serves the first two; tenant consoles serve the third.
{{CUSTOMER_PERSONALITIES_ARCHETYPES_OVERVIEW}}- The Builder (wants structure and control); The Pragmatist (wants the fastest finished output); The Delegator (wants it run for them, served by consoles).
Variables · TARGET MARKET12 · Customer Transformation Overview
{{12_Customer_Transformation_Overview}}- Before, the buyer improvises: a blank chat, a scattered doc and a deadline. After, they run a structured library whose outputs chain into the next area, so each piece of work builds on the last. At the tenant level, the transformation is from many tools to one console with its own database and variables library.
{{CUSTOMER_TRANSFORMATION_OVERVIEW}}- From improvised, blank-page work to structured libraries that chain across the loop; for tenants, from many tools to one console.
Variables · TARGET MARKET13 · Storybrand Script
{{13_Storybrand_Script}}- The hero is an operator who bought the tools but still starts every piece of work from a blank page. The problem is that their knowledge is scattered and nothing connects. Intelligent Operations is the guide: it built and runs its own operating system, and offers the plan as an Agent Library they can duplicate today for $14. Success is work that runs the same way every time; failure is another quarter of tools that never paid off.
{{STORYBRAND_SCRIPT}}- Hero: an operator with tools but no method. Guide: Intelligent Operations, which runs its own system. Plan: pick a library, duplicate it, answer the questionnaire, run the columns. Call to action: Buy now, $14. Success: repeatable work. Failure avoided: tools that never pay off.
Variables · Value Proposition01 · Primary Value Proposition
{{01_Primary_Value_Proposition}}- Intelligent Operations gives operators a ready-to-run method for any area of marketing and revenue operations, delivered into their own Notion workspace the moment they pay. Each Agent Library turns a questionnaire into structured fields through a set of column prompts, so the work is repeatable and feeds the next library on the loop. At $14 one-time, it removes the cost of trying a real method. The same methods power the platform's managed tenant consoles.
{{VALUE_STATEMENT}}- A ready-to-run method for any area of marketing and revenue operations, in your Notion workspace the moment you pay, for $14.
Variables · Value Proposition02 · Audience-Specific Value Statements
{{02_Audience_Specific_Value_Statements}}- For operators, the value is a method they can start today instead of a blank page. For consultants, it is a consistent system they can duplicate per client. For owners, it is a path from a single library to a console that runs the work for them. Each statement leads with the audience's own job.
{{AUDIENCE_TYPE}}- Operators; consultants and fractional marketers; owner-led businesses.
{{VALUE_DESCRIPTION}}- Operators: start today with a method. Consultants: one method duplicated per client. Owners: a path from a $14 library to a managed console.
Variables · Value Proposition03 · Problem Definition
{{03_Problem_Definition}}- Teams have invested in AI tools and workspaces, yet their operating knowledge remains scattered and every task starts from a blank prompt. Templates they buy do not connect, so outputs do not build on one another. The gap is execution, not software.
{{PROBLEM_STATEMENT}}- Operating knowledge is scattered and every AI task starts from a blank prompt, so tools never turn into repeatable outcomes.
Variables · Value Proposition04 · Solution Statement
{{04_Solution_Statement}}- Intelligent Operations packages each area of work as an Agent Library: a questionnaire, a set of column prompts in six parts, and a field map that feeds the next library. Buyers duplicate it into Notion, answer the questions and run the columns. The workflow includes a human review gate before the work is handed on.
{{SOLUTION_DESCRIPTION}}- Agent Libraries: questionnaire plus column prompts plus field map, duplicated into Notion, run in order, reviewed, then handed to the next library on the loop.
Variables · Value Proposition05 · Unique Benefits Description
{{05_Unique_Benefits_Description}}- Three benefits stand out. Buyers start immediately with a complete method. Their outputs chain across libraries rather than ending at download. And the method is the same one the platform runs for live tenants, so it is proven in use rather than written for sale.
{{BENEFIT_1}}- Start today: instant Notion and Markdown delivery after Stripe checkout.
{{BENEFIT_2}}- Outputs chain: each library names what it reads and what it feeds on the eight-stage loop.
{{BENEFIT_3}}- Proven in use: the same methods run inside the platform's own tenant consoles.
Variables · Value Proposition06 · Competitive Differentiation Points
{{06_Competitive_Differentiation_Points}}- Compared with prompt packs and template shops, Intelligent Operations sells connected methods with a mapped place in a whole operating system. Compared with agencies, it offers the same depth at a self-serve price, with an upgrade path to a managed console.
{{DIFFERENTIATION_POINT_1}}- Connected methods on one operating loop, not standalone templates or prompt lists.
{{DIFFERENTIATION_POINT_2}}- Agency-grade depth at $14 self-serve, with an upgrade path to a managed console.
Variables · Value Proposition07 · Evidence and Proof Points
{{07_Evidence_and_Proof_Points}}- Proof is drawn only from verifiable platform facts. The storefront lists 147 active products with live Stripe prices, all checked on 2026-09-28, and a production crawl that day found 226 pages and no broken links. The libraries cover 65 IO areas. Customer results are not yet on record and are not claimed.
{{EVIDENCE_TYPE}}- Verifiable platform facts: catalogue size, price checks, link crawl, area coverage.
{{PROOF_POINT}}- 147 active Agent Libraries with verified Stripe prices; 226 production pages with 0 broken links (2026-09-28); 65 IO areas.
Variables · Value Proposition08 · Value Quantification Framework
{{08_Value_Quantification_Framework}}- Value is quantified in terms buyers can check for themselves. The first metric is time from purchase to first run, which the platform can measure from order and access records. The second is time saved per task compared with starting from scratch, which requires buyer survey data. No results are claimed until measured.
{{VALUE_METRIC_1}}- Time from purchase to first access, measured from orders and downloads rows. Target: under 5 minutes.
{{VALUE_METRIC_2}}- Setup time saved versus building the method from scratch. Proposed: measure with a post-purchase survey; no figure claimed yet.
Variables · Value Proposition09 · Emotional Value Components
{{09_Emotional_Value_Components}}- Buyers feel prepared rather than improvising, and confident that what they produce is structured and defensible. The honest, sourced tone of the platform reduces the anxiety of buying yet another AI product.
{{EMOTIONAL_BENEFIT}}- Confidence and preparedness: the work has a method behind it and nothing is made up.
Variables · Value Proposition10 · Rational Value Components
{{10_Rational_Value_Components}}- The rational case is simple: a complete method for $14, delivered instantly, reusable indefinitely in the buyer's own workspace, and compatible with the next library they need.
{{RATIONAL_BENEFIT}}- $14 one-time for a complete, reusable, instantly delivered method that connects to the next library.
Variables · Value Proposition11 · Value Delivery Timeline
{{11_Value_Delivery_Timeline}}- Value arrives in three phases: access within minutes of payment, a first completed run the same day, and compounding value as further libraries chain onto the first. Owners who move to a console see value at onboarding, when their brand and records are loaded.
{{DELIVERY_PHASE}}- Minutes: access after checkout. Same day: first completed run. Weeks: compounding value as libraries chain. Tenants: value at console onboarding.
Variables · Value Proposition12 · Value Proposition Testing Framework
{{12_Value_Proposition_Testing_Framework}}- The value proposition is tested on the product pages and the libraries index. Proposed tests compare benefit-led against method-led headlines, measured by product-page click-through and checkout starts over four weeks. Buyer questions and refund reasons are coded to find which claims land.
{{TESTING_METHOD}}- Proposed: A/B headlines on /libraries and top product pages; four-week windows; primary metric checkout starts per view.
{{RESULTS_ANALYSIS}}- Compare conversion with a two-proportion test; adopt the winner only at a pre-set significance level; log the result and the next hypothesis.
Variables · Digital Product Storefront01 · Digital Offer Inventory
{{01_Digital_Offer_Inventory}}- The storefront at intelligentoperations.ai sells 147 Agent Libraries, each a one-time $14 product. Twelve are the original hand-built Notion libraries, delivered as a Notion duplicate; 135 were built from the prompt estate and are delivered as both a Notion template and a Markdown file. Products are grouped by the IO area they serve across 65 areas. All 147 were active with a live Stripe price on 2026-09-28.
{{DIGITAL_PRODUCTS}}- 147 Agent Libraries across 65 IO areas: 12 original hand-built Notion libraries and 135 built from the prompt estate.
{{PRODUCT_FORMATS}}- Notion template (Duplicate as template) for all 147; Markdown file from a private bucket for the 135 estate-built libraries.
{{PROBLEM_SOLVED}}- Each library gives a structured, repeatable method for one area of marketing and revenue operations, from brand positioning to reporting.
{{SOURCE_LOCATIONS}}- Offerings, prices and delivery rows in the estate database; Markdown in the private bucket intelligent-operations-assets under agent-libraries/; Notion pages under Agent Libraries — Store Delivery.
{{READINESS_STATUS}}- 147 of 147 active and buyable on 2026-09-28; 72 area labels still have no matching product and show without a card.
Variables · Digital Product Storefront02 · Buyer Intent Questions
{{02_Buyer_Intent_Questions}}- The buyer arrives wanting to get one area of work done with a method, not a blank chat. Their alternatives are building it themselves, a prompt pack, or hiring help. Before paying they need to see what is inside and know how delivery works. They expect access within minutes and a price low enough to try without approval.
{{BUYER_JOBS}}- Produce a specific deliverable (a positioning statement, a content brief, a campaign plan) with a proven method, inside their own workspace.
{{CURRENT_ALTERNATIVES}}- Building the method themselves in Notion or chat; buying a prompt pack or generic template; hiring an agency or consultant.
{{TRUST_REQUIREMENTS}}- A visible preview of the template, a clear list of columns and prompts, secure Stripe checkout, and a plain statement of where delivery happens.
{{DELIVERY_EXPECTATIONS}}- Instant access after payment, with a working Notion duplicate and a downloadable file, and a link they can return to.
{{EXPECTED_PRICE}}- A low one-time price that fits a personal card; the store charges $14.
Variables · Digital Product Storefront03 · Product Packaging Model
{{03_Product_Packaging_Model}}- Today every library is sold singly at one price, which keeps the choice simple. Proposed packaging adds bundles by stage of the operating loop, a full-area collection, and a later membership that includes new libraries as they ship. The upgrade path runs from libraries to services and a managed tenant console.
{{SINGLE_PRODUCTS}}- Each of the 147 Agent Libraries at $14 one-time.
{{BUNDLE_DEFINITIONS}}- Proposed: stage bundles (Know, Research, Plan, Create, Distribute, Convert, Retain, Measure), each the libraries on that stage of the loop.
{{COLLECTION_OFFER}}- Proposed: an area collection containing every library in one IO area, such as all five Brand IO libraries.
{{MEMBERSHIP_OFFER}}- Proposed, not live: an annual membership granting every current and future library; to be priced after purchase data exists.
{{UPGRADE_PATHS}}- Library to stage bundle (Proposed); library to a scoped service engagement; services to a dedicated tenant console.
Variables · Digital Product Storefront04 · Delivery And Access Method
{{04_Delivery_And_Access_Method}}- Delivery is automatic. When Stripe returns the buyer to the success page, the same idempotent fulfil() the webhook calls writes the order, order items and an entitlement. The buyer gets two links: one opens the Notion template, the other gives a short-lived signed download of the Markdown file. Every use of a token is recorded in the downloads table.
{{PAYMENT_CONFIRMATION}}- The success page asks Stripe about the session id and fulfils only a paid session; the checkout.session.completed webhook fulfils it too, idempotently.
{{ACCESS_EMAIL}}- Stripe sends the receipt to the buyer's email. Proposed: a separate access email repeating the buyer's /access links.
{{ACCESS_LINK_METHOD}}- /access/<token>?as=notion opens the Notion template; /access/<token> returns a signed bucket download, or the Notion page for the original 12.
{{LINK_VALIDITY}}- The access token remains the buyer's permanent link, checked by entitlement_state(); each download URL it issues is signed for 5 minutes.
{{REDOWNLOAD_PATH}}- Return to the same /access/<token> link, which issues a fresh 5-minute download each time.
Variables · Digital Product Storefront05 · License Terms Summary
{{05_License_Terms_Summary}}- Proposed licence terms, to be published on every product page: a single buyer may use the library for their own work and their clients' work, and may modify it freely. They may not resell or redistribute the template or its prompts. Team use is covered by one licence per user until a team licence is offered.
{{USE_SCOPE}}- Proposed: use for the buyer's own business and for client work they deliver.
{{USER_LIMITS}}- Proposed: one licence per individual user.
{{MODIFICATION_RIGHTS}}- Proposed: buyers may edit, extend and rename anything in their duplicate.
{{REDISTRIBUTION_RESTRICTIONS}}- Proposed: no resale, sharing of the duplicate link or public posting of the prompts; Notion search indexing is off to keep paid templates unlisted.
{{TEAM_LICENSE_TERMS}}- Proposed: a team licence for up to 10 users at a multiple of the single price, to be set after demand is measured.
Variables · Digital Product Storefront06 · Storefront Navigation Structure
{{06_Storefront_Navigation_Structure}}- The storefront is organised by the operating system itself. The landing page shows every IO area, with featured products beneath; each area page carries a products rail anchored at #agent-libraries; and /libraries lists every product with a filter. The top bar links Agent Libraries on every page, and product pages link back to their area.
{{STOREFRONT_HOME}}- The index of 65 IO areas, with the featured product block under the grid.
{{COLLECTION_PAGES}}- Each /areas/<slug> page, with a products rail listing that area's libraries.
{{SEARCH_AND_FILTERS}}- The /libraries index with a library filter; Proposed: filter by loop stage.
{{BUNDLE_SURFACING}}- Proposed: a stage-bundle card at the top of each area's products rail and on the loop diagram of each product page.
Variables · Digital Product Storefront07 · Product Listing Page
{{07_Product_Listing_Page}}- Each product page at /libraries/<slug> explains what the library produces, what is inside and who it is for. It shows generated previews of the Notion template (cover, desktop, mobile and prompts views), the library's place on the eight-stage operating loop, and its workflow with reads and feeds. The buy button renders only when the product is buyable, and the delivery method is stated beside it.
{{LISTING_PROMISE}}- A complete, ready-to-run method for one area of work, in your own Notion workspace today.
{{INCLUDED_CONTENTS}}- Column prompts in six parts, the questionnaire, the field map, a How to use this library section and, for estate libraries, the Markdown file.
{{INTENDED_BUYER}}- Operators, marketers and consultants who run this area of work and use Notion and AI tools.
{{PREVIEW_SECTION}}- Cover, desktop, mobile and prompts images drawn from the template; the operating-loop and workflow diagrams.
{{DELIVERY_EXPLANATION}}- Pay with Stripe, return to the success page, and open the Notion template or download the file immediately.
{{LISTING_FAQ}}- How is it delivered? Notion template plus file. Do I need Notion AI? No; each column's prompt can be pasted in. Can I re-download? Yes, from your access link.
Variables · Digital Product Storefront08 · Listing Copy
{{08_Listing_Copy}}- Listing copy follows one pattern across the catalogue so buyers can compare. The title is the library name followed by Agent Library. A one-line promise names the output, the short description names the method, and the included-contents line lists what arrives. The meta description repeats the promise and delivery in under 160 characters.
{{PRODUCT_TITLE}}- Brand Positioning - Agent Library
{{ONE_LINE_PROMISE}}- Define your category, audience and point of difference, and leave with a positioning statement you can use today.
{{SHORT_DESCRIPTION}}- Twelve column prompts take you from market category to category disruption strategy, each output feeding the next.
{{INCLUDED_CONTENTS_COPY}}- Notion template with 12 column prompts; questionnaire; field map; how-to guide; Markdown copy.
{{META_DESCRIPTION}}- Brand Positioning Agent Library: 12 column prompts from category to positioning statement. Notion template plus file, $14, instant delivery.
Variables · Digital Product Storefront09 · Preview And Sample Assets
{{09_Preview_And_Sample_Assets}}- Every product page draws its previews from the template itself, so what the buyer sees is what they get. The cover image doubles as the og:image, the Stripe product image and the Notion page cover. Proposed: one free sample column prompt per library and a short walkthrough video for the most viewed products. The full prompts and questionnaire stay behind purchase.
{{SCREENSHOT_SET}}- Cover, desktop, mobile and prompts views rendered at /libraries/<slug>/image/<view>.png.
{{FREE_SAMPLE}}- Proposed: the first column prompt of each library shown in full on the product page.
{{WALKTHROUGH_ASSET}}- Proposed: a 60-90 second screen recording of duplicating and running one library, for the top ten products.
{{CONTENTS_LIST}}- The list of column names for each library, shown on the page.
{{WITHHELD_CONTENT}}- Full prompt text, questionnaire and Markdown file, released only through the buyer's access link.
Variables · Digital Product Storefront10 · Purchase To Access Test
{{10_Purchase_To_Access_Test}}- The purchase path is tested end to end with a synthetic paid session run through fulfil() and access(), after which its orders, order items, entitlements and downloads rows are deleted. Proposed additions: a live low-value test purchase each release, checks that the Stripe receipt arrives, and a mobile run. The target is access within five minutes of payment.
{{TEST_PURCHASE_STEPS}}- Open a product page; Buy now; complete Stripe Checkout; land on /checkout/success; open both access links; confirm orders, entitlements and downloads rows.
{{EMAIL_DELIVERY_CHECK}}- Confirm the Stripe receipt reaches the test inbox and shows the product name.
{{ACCESS_CHECK}}- Confirm the Notion link duplicates cleanly and the file link downloads within its 5-minute window.
{{MOBILE_CHECK}}- Repeat the purchase and access on a phone browser, including opening Notion.
{{TIME_TO_ACCESS}}- Target: under 5 minutes from payment to first open.
Variables · Digital Product Storefront11 · Refund And Support Policy
{{11_Refund_And_Support_Policy}}- Proposed policy, to be published on product pages: a refund within 14 days if the library cannot be accessed or does not match its listing. Access problems are answered first by resending the buyer's access link. A short help section covers duplication and re-download. Repeated refund requests from one buyer are reviewed before approval.
{{REFUND_CONDITIONS}}- Proposed: full refund within 14 days where access failed or the contents do not match the listing.
{{ACCESS_ISSUE_RESPONSE}}- Proposed: reply within one business day with the buyer's /access link and duplication steps.
{{SELF_SERVICE_HELP}}- The How to use this library section in every template; Proposed: a help page covering duplication, pasting column prompts and re-download.
{{STANDARD_REPLIES}}- Proposed replies: resend access link; how to duplicate into your workspace; how to paste a column prompt; refund confirmation.
{{REPEAT_REQUEST_RULE}}- Proposed: a second refund request from the same buyer within 90 days is reviewed by the founder.
Variables · Digital Product Storefront12 · Storefront Sales Measures
{{12_Storefront_Sales_Measures}}- The storefront is measured on views, conversion, revenue by product, bundle attach and refunds. Orders and entitlements are recorded in the estate database, so revenue and product-level sales can be read directly. No sales figures are claimed here; the targets below are proposed starting points for the first review.
{{LISTING_VIEWS}}- Product-page views per library per week. Proposed: track through site analytics once enabled.
{{LISTING_CONVERSION_RATE}}- Orders divided by product-page views. Target: 2% as a first benchmark.
{{REVENUE_BY_PRODUCT}}- Sum of paid order items per offering, read from orders and order_items.
{{BUNDLE_ATTACH_RATE}}- Not yet applicable; Proposed once stage bundles launch.
{{REFUND_RATE}}- Refunded orders divided by paid orders. Target: under 3%.
Variables · Pricing & Promotions01 · Pricing Input Questions
{{01_Pricing_Input_Questions}}- Pricing starts from the fact that every library is a one-time $14 digital product with near-zero marginal cost. The main variable costs are Stripe processing fees and hosting. No past promotions have been run, and the checkout already allows promotion codes. There are no channel price commitments.
{{LANDED_COSTS}}- Near-zero marginal cost per sale; variable cost is Stripe's processing fee plus a share of hosting and bucket storage.
{{TARGET_MARGINS}}- Proposed: 90% or more gross margin after processing fees on every sale.
{{CURRENT_PRICES}}- $14 one-time for each of the 147 Agent Libraries.
{{PAST_PROMOTION_RESULTS}}- None on record; no promotion has been run.
{{CHANNEL_PRICE_COMMITMENTS}}- None; the storefront is the only sales channel.
Variables · Pricing & Promotions02 · Competitive Price Scan
{{02_Competitive_Price_Scan}}- No competitor prices are recorded in the platform's sources, so none are quoted. The proposed scan compares single prompt packs, single Notion templates and bundles in each category, on a delivered basis. The $14 price is intended to sit at the low end for a complete method, so the buyer compares depth rather than price.
{{COMPETITOR_PRICES}}- Not on record. Proposed: a sourced scan of 20 comparable prompt packs and Notion templates before any price change.
{{DELIVERED_PRICE_COMPARISON}}- Proposed: compare price per included prompt and per included database view, not headline price alone.
{{COMPETITOR_PROMOTION_PATTERNS}}- Not on record; to be captured in the same scan.
{{CATEGORY_POSITIONING}}- Low, flat entry price for a deep, connected method.
Variables · Pricing & Promotions03 · Price Architecture
{{03_Price_Architecture}}- The current architecture is one tier: every library at $14. The proposed architecture adds a stage bundle and an area collection above it, and later a membership. Prices end in whole dollars. Bundles are priced below the sum of their parts to reward buying along the loop.
{{PRICE_TIERS}}- Now: single library. Proposed: area collection; stage bundle; all-access membership.
{{TIER_PRICE_POINTS}}- Single: $14. Proposed: area collection at 4x single; stage bundle priced per library count at a discount; membership to be set after data.
{{TIER_DIFFERENCES}}- Single covers one area of work; collections cover a whole IO area; bundles cover one loop stage; membership covers every library and new releases.
{{PRICE_ENDING_RULES}}- Whole-dollar prices, no .99 endings, matching the plain tone of the store.
{{BUNDLE_PRICING}}- Proposed: bundles at roughly 70% of the sum of included singles.
Variables · Pricing & Promotions04 · Margin Floor Rules
{{04_Margin_Floor_Rules}}- Because marginal cost is near zero, the floor protects perceived value rather than cost. The proposed floor is no library below $7 net after any discount. Variable costs counted are processing fees and any delivery cost. Any price under the floor needs founder approval.
{{CATEGORY_MARGIN_MINIMUMS}}- Proposed: 85% minimum gross margin after processing fees on every order.
{{FLOOR_PRICE_CALCULATION}}- Floor = the greater of (processing fee plus delivery cost) divided by 0.15, or $7 per library.
{{VARIABLE_COST_INCLUSIONS}}- Stripe processing fees; bucket egress for downloads; a share of hosting.
{{BELOW_FLOOR_APPROVAL}}- Founder approval only, recorded in the PR or promotion log.
Variables · Pricing & Promotions05 · Promotion Type Menu
{{05_Promotion_Type_Menu}}- Promotions are limited to mechanics that suit a one-time digital product. Percentage codes suit launches; bundles suit buyers moving along the loop. Shipping offers do not apply. A free sample column prompt works as the gift offer.
{{DISCOUNT_MECHANICS}}- Stripe promotion codes for a fixed percentage off, already enabled at checkout.
{{SHIPPING_OFFERS}}- Not applicable; all products are digital with instant delivery.
{{GIFT_OFFERS}}- Proposed: a free sample column prompt from the next library on the loop, delivered on the success page.
{{BUNDLE_OFFERS}}- Proposed: stage bundles and area collections.
{{MECHANIC_GOALS}}- Codes: drive first purchases at launch. Bundles: raise order value. Samples: pull buyers to the next library.
Variables · Pricing & Promotions06 · Discount Guardrails
{{06_Discount_Guardrails}}- Guardrails keep the flat price credible. Codes do not stack and are never combined with bundle pricing. Codes are distributed through owned channels and expire. Sitewide events are rare and spaced apart.
{{STACKING_RULES}}- One code per order; no code on bundles.
{{CODE_DISTRIBUTION_RULES}}- Proposed: codes shared only through owned channels (email list, founder's LinkedIn), each with an expiry date and usage cap.
{{PROMOTION_EXCLUSIONS}}- Proposed: newly launched libraries excluded for their first 30 days.
{{FREQUENCY_LIMITS}}- Proposed: no more than one promotion per quarter.
{{SITEWIDE_EVENT_GAP}}- Proposed: at least 90 days between sitewide events.
Variables · Pricing & Promotions07 · Promotional Calendar
{{07_Promotional_Calendar}}- The proposed calendar is light and tied to real milestones. A launch code marks the storefront's public launch; a second window accompanies the first stage-bundle release; and a year-end planning window promotes the Plan and Measure libraries. Each needs about two weeks of preparation.
{{PROMOTION_DATES}}- Proposed: storefront launch week (Q4 2026); stage-bundle release (Q1 2027); year-end planning window (December 2026).
{{PROMOTION_MECHANICS}}- Launch: 25% code. Bundle release: bundle pricing only. Year-end: 20% code on Plan and Measure stage libraries.
{{INCLUDED_PRODUCTS}}- Launch: all 147. Year-end: libraries on the Plan and Measure stages, such as Strategic Planning and Reporting IO.
{{PROMOTION_AUDIENCE}}- Email subscribers, the founder's LinkedIn network and past buyers.
{{PREPARATION_LEAD_TIMES}}- Two weeks: create the code in Stripe, write copy, test checkout with the code.
Variables · Pricing & Promotions08 · Offer Copy Variants
{{08_Offer_Copy_Variants}}- Offer copy stays as plain as the rest of the store. The headline names the method, the supporting line names the saving, and the terms line states the limit. The call to action is always Buy now. Channel variants shorten for LinkedIn and email subject lines.
{{OFFER_HEADLINE}}- Every Agent Library, 25% off this week.
{{SUPPORTING_LINE}}- Ready-to-run methods for every area of marketing and revenue operations, delivered to your Notion workspace the moment you pay.
{{TERMS_LINE}}- One code per order. Not valid on bundles. Ends Sunday at midnight Central.
{{CALL_TO_ACTION}}- Buy now
{{CHANNEL_VARIANTS}}- Email subject: 25% off every Agent Library, this week only. LinkedIn: 147 methods, 25% off for a week, delivered straight into Notion.
Variables · Pricing & Promotions09 · Price Change Communication
{{09_Price_Change_Communication}}- Any future price change is announced before it takes effect. The message states the new price, the date, the reason and what stays the same. Past buyers keep their access unchanged. A short grace period honours the old price for carts already started.
{{CHANGE_DESCRIPTION}}- Proposed example: single library price moves from $14 to a new price as the catalogue deepens.
{{EFFECTIVE_DATE}}- Proposed: at least 14 days after announcement.
{{CHANGE_REASON}}- More prompts, previews and updates per library than at launch.
{{UNCHANGED_BENEFITS}}- Past purchases keep permanent access; delivery stays instant; Notion and file formats stay the same.
{{GRACE_PERIOD}}- Proposed: the old price honoured for 7 days after the effective date via a published code.
Variables · Pricing & Promotions10 · Promotion Test Design
{{10_Promotion_Test_Design}}- Promotions are tested before they are adopted. The proposed first test asks whether a launch code increases first purchases enough to offset the discount. A holdout sees no code; the variant sees a 25% code. The measurement window is four weeks, and incremental margin is compared, not revenue alone.
{{TEST_DECISION}}- Does a 25% launch code raise first-purchase margin compared with no code?
{{HOLDOUT_GROUP}}- Proposed: half of the email list receives no code.
{{OFFER_VARIANTS}}- No code versus 25% code.
{{MEASUREMENT_WINDOW}}- Four weeks from send.
{{INCREMENTAL_MARGIN_METHOD}}- (Variant margin per recipient minus holdout margin per recipient) times recipients in the variant.
Variables · Pricing & Promotions11 · Promotion Results Analysis
{{11_Promotion_Results_Analysis}}- No promotion has run yet, so no results are reported. When one does, the analysis will read revenue and margin directly from orders, identify new versus returning buyers from Stripe customers, and check for a post-promotion dip. The recommendation will state whether to repeat, change or stop the promotion.
{{PROMOTION_REVENUE}}- Not on record; no promotion has run.
{{MARGIN_AFTER_DISCOUNT}}- Not on record; to be read from orders after the first promotion.
{{NEW_BUYER_SHARE}}- Not on record; to be measured from Stripe customer creation.
{{INCREMENTAL_LIFT}}- Not on record; to be measured against the holdout.
{{POST_PROMOTION_DIP}}- Not on record; compare four weeks after with four weeks before.
{{PROMOTION_RECOMMENDATIONS}}- Proposed: run the launch-code test first, then decide on bundles based on multi-item buyer behaviour.
Variables · Pricing & Promotions12 · Pricing Health Measures
{{12_Pricing_Health_Measures}}- Pricing health is monitored on four measures. The share of orders at full price shows reliance on discounts, and average discount depth shows how much is given away. Gross margin confirms the floor holds. Competitive position is refreshed by the annual price scan.
{{FULL_PRICE_SHARE}}- Target: 80% or more of orders at full price.
{{AVERAGE_DISCOUNT_DEPTH}}- Target: under 10% across all orders.
{{CATEGORY_GROSS_MARGIN}}- Target: 90% or more after processing fees.
{{COMPETITIVE_PRICE_POSITION}}- Target: at or below the median delivered price of comparable templates, per the annual scan.
Variables · Checkout & Cart Optimization01 · Checkout Flow Mapping
{{01_Checkout_Flow_Mapping}}- The storefront has no cart: each product page's Buy now button posts only the slug to /api/checkout, which reads the price from the database and redirects to Stripe Checkout. Stripe collects email, card and billing address, then returns the buyer to /checkout/success. The flow works before any script loads because it is a plain form post. On mobile it is the same flow, with wallet options shown by Stripe where available.
{{CART_STEP}}- None; single-item purchase straight from the product page's Buy now form.
{{ACCOUNT_STEP}}- No account; Stripe creates a customer record on every purchase.
{{SHIPPING_STEP}}- None; digital delivery.
{{PAYMENT_STEP}}- Stripe Checkout in payment mode, one line item, promotion codes allowed, billing address collected automatically.
{{CONFIRMATION_STEP}}- /checkout/success verifies the session with Stripe, fulfils it and shows the Notion and download links.
{{MOBILE_DIFFERENCES}}- Same flow; Stripe's hosted page adapts to mobile and can offer wallets.
Variables · Checkout & Cart Optimization02 · Abandonment Point Diagnosis
{{02_Abandonment_Point_Diagnosis}}- Because there is only one step between product page and payment, the main drop-off points are the product page itself and the Stripe page. Likely causes are uncertainty about what is inside, doubts about Notion compatibility and hesitation at a hosted payment page. No drop-off data is on record yet. Proposed: count checkout sessions created versus completed from Stripe.
{{STEP_DROP_OFF}}- Not on record. Proposed: product views to Buy now clicks; Checkout sessions created to completed.
{{ABANDONMENT_CAUSES}}- Hypotheses: unclear contents; Notion plan or AI compatibility questions; unfamiliar brand at a payment step.
{{FORM_ERROR_HOTSPOTS}}- Minimal forms; Stripe handles card validation. Proposed: review Stripe's declined-payment reasons monthly.
{{PAYMENT_FAILURES}}- Not on record; read from Stripe's payment intent failures.
{{PRIORITY_LEAKS}}- Proposed priority: product-page clarity first, then trust copy beside the pay button.
Variables · Checkout & Cart Optimization03 · Buyer Hesitation Questions
{{03_Buyer_Hesitation_Questions}}- Hesitation is researched with short, specific questions. On exit, ask what stopped the purchase. After purchase, ask what nearly stopped it. A few buyer interviews go deeper into how they judged the product.
{{EXIT_SURVEY_QUESTIONS}}- Proposed: What stopped you buying today? Was anything unclear about what is inside or how it is delivered?
{{POST_PURCHASE_QUESTIONS}}- Proposed: What almost stopped you buying? What did you expect to receive, and did you get it?
{{INTERVIEW_QUESTIONS}}- Proposed: How did you find this library? What else did you consider? How did you decide it was worth $14?
{{HESITATION_THEMES}}- Expected themes to test: contents clarity; Notion compatibility; delivery confidence; unknown brand.
Variables · Checkout & Cart Optimization04 · Cart Page Structure
{{04_Cart_Page_Structure}}- There is no cart page by design, so the product page does the cart's job. It shows the single product, the $14 price, what arrives and how. Reassurance sits beside the button. Proposed add-on suggestions appear only after purchase, on the success page.
{{LINE_ITEM_DISPLAY}}- One product, named on the product page and on Stripe with its cover image.
{{COST_SUMMARY}}- $14, one-time, shown beside Buy now; tax handling per Stripe settings.
{{SHIPPING_ESTIMATE}}- Not applicable; delivery is instant.
{{CART_REASSURANCE}}- The delivery line beside Buy now and Stripe's custom text naming where delivery happens.
{{ADD_ON_SUGGESTIONS}}- Proposed: next library on the loop suggested on the success page, not before payment.
{{PRIMARY_ACTION}}- Buy now
Variables · Checkout & Cart Optimization05 · Checkout Field Minimization
{{05_Checkout_Field_Minimization}}- The checkout already asks for very little. Stripe needs email and card; billing address is collected automatically only when required. No account creation is needed. Validation is handled by Stripe, and the server rejects any slug that fails its pattern.
{{REQUIRED_FIELDS}}- Email; card details; billing address only when Stripe requires it.
{{REMOVED_FIELDS}}- Account creation, phone number, company name.
{{GUEST_CHECKOUT_RULE}}- All purchases are guest purchases; access is by token, not login.
{{AUTOFILL_SUPPORT}}- Stripe Checkout supports browser autofill and saved payment details.
{{VALIDATION_RULES}}- Slug must match ^[a-z0-9-]{1,120}$; price read from the database, never the form; unavailable products redirect back with a notice.
Variables · Checkout & Cart Optimization06 · Payment Method Mix
{{06_Payment_Method_Mix}}- Card payments through Stripe are the core. Digital wallets are shown by Stripe where enabled on the account. Instalments are unnecessary at $14. Local methods are a later consideration if non-US buyers appear.
{{CARD_PAYMENTS}}- All major cards via Stripe Checkout.
{{DIGITAL_WALLETS}}- Proposed: confirm Apple Pay and Google Pay are enabled in the Stripe dashboard.
{{INSTALMENT_OPTIONS}}- Not offered; not appropriate at $14.
{{LOCAL_METHODS}}- Proposed: review once international orders exceed 10% of volume.
{{EXPRESS_PLACEMENT}}- Wallet buttons at the top of Stripe's hosted page, as Stripe places them.
Variables · Checkout & Cart Optimization07 · Trust And Reassurance Copy
{{07_Trust_And_Reassurance_Copy}}- Reassurance copy answers the three questions a buyer asks at the pay button: is it secure, what if it goes wrong, and where does it arrive. The delivery line is already shown on Stripe's page. The rest is proposed for the product page. Each line sits next to the action it supports.
{{SECURITY_LINE}}- Payments are processed securely by Stripe. We never see your card details.
{{RETURNS_LINE}}- Proposed: If you can't access it or it isn't what the page describes, we'll refund you within 14 days.
{{DELIVERY_LINE}}- Your library opens as a Notion template and a download the moment payment completes.
{{SUPPORT_LINE}}- Questions? Email [email on file]
{{LINE_PLACEMENTS}}- Delivery line beside Buy now and in Stripe custom text; security and refund lines under the button; support line in the page footer.
Variables · Checkout & Cart Optimization08 · Shipping Cost Disclosure Rules
{{08_Shipping_Cost_Disclosure_Rules}}- There is no shipping, so the rules focus on price clarity. The product page shows the full price, the checkout shows the same, and nothing is added at the last step except any tax Stripe calculates.
{{PRODUCT_PAGE_DISCLOSURE}}- $14 one-time, digital delivery, shown beside Buy now.
{{CART_DISCLOSURE}}- Not applicable; Stripe shows the same price and product.
{{TAX_DISPLAY_RULE}}- Proposed: confirm Stripe Tax settings and state "plus applicable tax" on the product page if enabled.
{{FREE_SHIPPING_THRESHOLD}}- Not applicable; digital products.
{{FINAL_STEP_RULE}}- No new charges appear at the payment step beyond tax.
Variables · Checkout & Cart Optimization09 · Cart Recovery Sequence
{{09_Cart_Recovery_Sequence}}- Stripe can identify checkout sessions that expire unpaid when the buyer entered an email. The proposed recovery is one reminder after one hour and one after 24 hours, with no discount. Buyers who complete a purchase or unsubscribe are suppressed. Recovery requires consent handling to be confirmed first.
{{RECOVERY_TIMING}}- Proposed: first reminder 1 hour after an expired session; second at 24 hours; then stop.
{{SUBJECT_LINES}}- Proposed: "Your Agent Library is still waiting"; "Still want the Brand Positioning library?"
{{MESSAGE_BODIES}}- Proposed: a two-line note naming the library, what it produces and a single link back to its product page.
{{INCENTIVE_RULE}}- No discount in recovery messages, to protect full-price purchases.
{{SUPPRESSION_RULES}}- Suppress anyone who has since paid, unsubscribed or received a recovery email in the last 30 days.
Variables · Checkout & Cart Optimization10 · Checkout Test Plan
{{10_Checkout_Test_Plan}}- Tests focus on the product page, since the payment step is Stripe's. The first hypothesis is that a visible contents list lifts Buy now clicks; the second, that a refund line lifts completion. Each test has one change, one primary metric and guardrails on refunds.
{{TEST_HYPOTHESES}}- 1: showing the column list above the fold raises Buy now clicks. 2: a refund line under the button raises session completion.
{{TEST_CHANGES}}- 1: move the column list above the fold. 2: add the refund line.
{{PRIMARY_METRIC}}- Paid orders per product-page view.
{{GUARDRAIL_METRICS}}- Refund rate; support contacts per order.
{{TEST_PRIORITY}}- Test 1 first (larger expected effect, no policy dependency); test 2 after the refund policy is published.
Variables · Checkout & Cart Optimization11 · Checkout Funnel Metrics
{{11_Checkout_Funnel_Metrics}}- The funnel is short, so every step is measurable. Product views to Buy now clicks shows page effectiveness; sessions created to paid shows checkout completion. Payment failures and recovery rates come from Stripe. Alert thresholds flag a broken buy path quickly.
{{CART_TO_CHECKOUT_RATE}}- Buy now clicks per product-page view. Target: 5%.
{{STEP_COMPLETION_RATES}}- Checkout sessions created to paid. Target: 60%.
{{CHECKOUT_CONVERSION_RATE}}- Paid orders per product-page view. Target: 2%.
{{PAYMENT_FAILURE_RATE}}- Failed payment attempts per session. Target: under 5%.
{{RECOVERY_RATE}}- Recovered sessions per reminder sent. Target: 5% once recovery launches.
{{ALERT_THRESHOLDS}}- Alert if no paid order for 14 days after launch, if payment failures exceed 15% in a day, or if the synthetic purchase test fails.
Variables · Order Fulfillment & Post-Purchase01 · Fulfillment Model Assessment
{{01_Fulfillment_Model_Assessment}}- Fulfilment is fully automated and digital. A paid Stripe session triggers the same idempotent fulfil() from both the success page and the webhook, which writes orders, order items and entitlements. Delivery happens in seconds, and cost per order is essentially the processing fee. The main error sources are a webhook failure, a missing delivery row or a Notion page that is not yet public.
{{FULFILLMENT_MODEL}}- Automated digital fulfilment: Stripe webhook plus success page, both calling idempotent fulfil(); access by token.
{{COST_PER_ORDER}}- Stripe processing fee plus negligible storage and egress.
{{FULFILLMENT_SPEED}}- Seconds after payment, on the success page.
{{ERROR_SOURCES}}- Webhook delivery failure; a product without a delivery row; a Notion URL not yet recorded; an expired signed download.
{{SYSTEM_HANDOFFS}}- Stripe Checkout, then /checkout/success and the webhook, then fulfil() in the estate database, then /access/<token>, then Notion or the private bucket.
Variables · Order Fulfillment & Post-Purchase02 · Order Lifecycle Map
{{02_Order_Lifecycle_Map}}- An order moves from a Stripe session to paid, then fulfilled with an entitlement, then accessed each time the buyer uses a link. Stripe holds payment state, and the estate database holds orders, entitlements and downloads. Buyers see only the success page and their access links. Exceptions branch when the session is unpaid, the product is not buyable or an entitlement is revoked.
{{ORDER_STATUSES}}- Pending (session created); paid; fulfilled (order, items, entitlement written); accessed (downloads rows); refunded or revoked.
{{STATUS_SYSTEMS}}- Stripe for payment; estate database tables orders, order_items, entitlements and downloads; entitlement_state() for token validity.
{{CUSTOMER_VISIBILITY}}- The success page states paid, pending or unknown; the access links work or explain why not.
{{EXCEPTION_BRANCHES}}- Unpaid session shows pending; product not buyable redirects with ?unavailable=1; refunded order revokes the entitlement (Proposed).
Variables · Order Fulfillment & Post-Purchase03 · Customer Expectation Questions
{{03_Customer_Expectation_Questions}}- Buyers of digital products expect instant access, a receipt and a way back to their files. Proposed questions confirm how quickly they expected access, how they want updates, what went wrong in past digital purchases, and why they would contact support.
{{DELIVERY_TIME_EXPECTATIONS}}- Proposed question: How soon after paying did you expect to open the library? Expected answer: immediately.
{{UPDATE_PREFERENCES}}- Proposed question: Would you like an email when this library is updated?
{{PAST_ORDER_PROBLEMS}}- Proposed question: What has gone wrong with digital templates you bought before?
{{SUPPORT_CONTACT_REASONS}}- Expected reasons: lost access link, Notion duplication confusion, how to run column prompts.
Variables · Order Fulfillment & Post-Purchase04 · Shipping And Delivery Promise
{{04_Shipping_And_Delivery_Promise}}- The delivery promise is immediate access, stated on Stripe's page and on the product page. There are no cutoffs or windows. If access fails, the remedy is a resent link and, where the fault cannot be fixed, a refund.
{{DISPATCH_COMMITMENT}}- Access links shown on the success page as soon as payment completes.
{{DELIVERY_WINDOWS}}- Instant, 24 hours a day.
{{ORDER_CUTOFF_TIMES}}- None.
{{MISSED_PROMISE_REMEDY}}- Proposed: resend the access link within one business day; refund if access cannot be restored.
Variables · Order Fulfillment & Post-Purchase05 · Order Status Communication Plan
{{05_Order_Status_Communication_Plan}}- Communication is minimal because delivery is instant. Stripe's receipt is the one required message. Proposed additions are an access email repeating the links and a first-use tip a day later. Exception messages cover pending payments and unavailable products.
{{STATUS_TRIGGERED_MESSAGES}}- Payment: Stripe receipt. Proposed: access email on fulfilment; first-use tip at 24 hours.
{{EXCEPTION_MESSAGES}}- Pending payment notice on the success page; unavailable notice on the product page.
{{MESSAGE_CHANNELS}}- Email (Stripe receipt, Proposed access email); on-page messages.
{{REQUIRED_MESSAGES}}- Stripe receipt; success page with access links.
{{OPTIONAL_MESSAGES}}- Proposed: first-use tip; update notices; next-library suggestion.
Variables · Order Fulfillment & Post-Purchase06 · Transactional Message Copy
{{06_Transactional_Message_Copy}}- Transactional copy is short and practical. The confirmation mirrors the success page: thank you, it is yours, here are your links. Since nothing ships, the shipped and delivered messages become access and first-use messages. The delay message covers a pending payment.
{{CONFIRMATION_MESSAGE}}- Thank you, it's yours. Brand Positioning is ready. Open the Notion template or download the file from the links below, and keep this email: the links are yours to reuse.
{{SHIPPED_MESSAGE}}- Not applicable; replaced by the access message: "Your Agent Library is ready. Open it in Notion or download it here."
{{DELIVERED_MESSAGE}}- Proposed first-use tip: "Start with the questionnaire, then run the columns in order. Each one builds on the last."
{{DELAY_MESSAGE}}- Your payment is still being confirmed. This page will show your library as soon as Stripe confirms it.
{{MESSAGE_SUBJECT_LINES}}- Your Agent Library is ready; How to run your first column; Your payment is being confirmed.
Variables · Order Fulfillment & Post-Purchase07 · Returns And Exchange Policy
{{07_Returns_And_Exchange_Policy}}- Digital products cannot be returned in the physical sense, so the proposed policy is a refund window tied to access and accuracy. A buyer who cannot access the library or finds it does not match its page may request a refund within 14 days. Exchanges for a different library are offered as an alternative. Refunds are issued through Stripe.
{{RETURN_WINDOW}}- Proposed: 14 days from purchase.
{{ELIGIBLE_ITEMS}}- Any Agent Library purchase.
{{CONDITION_REQUIREMENTS}}- Proposed: access failed or contents do not match the listing.
{{RETURN_SHIPPING_TERMS}}- Not applicable; digital.
{{REFUND_TIMING}}- Proposed: issued in Stripe within two business days of approval; card timing per the issuer.
{{EXCHANGE_PROCESS}}- Proposed: swap for another library of the same price by refunding and sending a code for the replacement.
Variables · Order Fulfillment & Post-Purchase08 · Exception Handling Playbook
{{08_Exception_Handling_Playbook}}- Physical exceptions map to digital equivalents. A lost parcel is a lost access link; a damaged item is a broken template or file; a wrong item is a mismatched product; a late delivery is a pending payment or failed webhook. Each has a fixed procedure, and the founder holds refund authority.
{{LOST_PARCEL_PROCEDURE}}- Lost link: find the order by email in the estate database and resend the /access/<token> link.
{{DAMAGED_ITEM_PROCEDURE}}- Broken template or file: reproduce, fix the source, re-run the Notion or file step, and resend access.
{{WRONG_ITEM_PROCEDURE}}- Wrong product: refund or exchange, and check the offering-to-delivery mapping.
{{LATE_DELIVERY_PROCEDURE}}- Pending order: check the Stripe session and webhook logs, then run fulfil() for the paid session; it is idempotent.
{{COMPENSATION_AUTHORITY}}- Founder Tommy Saunders approves refunds and codes.
Variables · Order Fulfillment & Post-Purchase09 · Post-Purchase Onboarding Sequence
{{09_Post_Purchase_Onboarding_Sequence}}- The goal after purchase is a first completed run. Every template's How to use this library section already explains the steps. The proposed email sequence adds a first-use message, a value tip a few days later and the next library on the loop.
{{FIRST_USE_MESSAGE}}- Duplicate the template, answer the questionnaire, then run the columns top to bottom; paste each column's prompt from Column prompts if your workspace needs it.
{{VALUE_TIPS_MESSAGE}}- Proposed: "Your outputs are fields other libraries read. Keep them in the same workspace."
{{CARE_GUIDANCE}}- Keep your access link; re-download any time; do not share the duplicate link publicly.
{{HELP_ROUTES}}- In-template guide; Proposed help page; email [email on file]
{{SEQUENCE_TIMING}}- Proposed: access email at purchase; first-use tip at day 1; value tip at day 4; next-library suggestion at day 10.
Variables · Order Fulfillment & Post-Purchase10 · Review And Referral Ask
{{10_Review_And_Referral_Ask}}- Reviews and referrals are requested only after the buyer has had time to run the library. No reviews exist yet, and none will be shown until real ones are collected. Unhappy buyers are routed to support before any public review ask.
{{REVIEW_REQUEST_TIMING}}- Proposed: day 14 after purchase.
{{REVIEW_REQUEST_CONTENT}}- Proposed: "Did the library produce what you needed? Reply with one sentence we may quote with your permission."
{{REFERRAL_INVITATION}}- Proposed: a shareable product link with a code for a colleague, after a positive reply.
{{UNHAPPY_ROUTING_RULE}}- Any negative reply goes to the founder for a fix or refund; no review ask is repeated.
Variables · Order Fulfillment & Post-Purchase11 · Fulfillment Service Levels
{{11_Fulfillment_Service_Levels}}- Service levels translate physical fulfilment measures into digital ones. On-time dispatch becomes access issued on the success page; on-time delivery becomes a working first open; order accuracy is the right product delivered; damage is a broken template or file. The founder owns every level.
{{ON_TIME_DISPATCH_RATE}}- Paid sessions fulfilled within 1 minute. Target: 99%.
{{ON_TIME_DELIVERY_RATE}}- Entitlements with a first access within 24 hours. Target: 90%.
{{ORDER_ACCURACY_RATE}}- Orders delivering the purchased offering. Target: 100%.
{{DAMAGE_RATE}}- Orders with a broken template or file reported. Target: under 1%.
{{SERVICE_LEVEL_OWNERS}}- Founder Tommy Saunders; checked by the synthetic purchase test and the daily ops-audit.
Variables · Order Fulfillment & Post-Purchase12 · Post-Purchase Performance Report
{{12_Post_Purchase_Performance_Report}}- No post-purchase performance data is claimed yet. The proposed monthly report reads refunds and reasons, support contacts per order, review volume once collected, and repeat purchase rate from Stripe customers. Each report ends with next actions.
{{RETURN_RATE_AND_REASONS}}- Not on record; to be read monthly from Stripe refunds with coded reasons.
{{ORDER_STATUS_CONTACT_RATE}}- Not on record; support contacts about access per 100 orders.
{{REVIEW_VOLUME_AND_RATING}}- None collected yet; none displayed.
{{REPEAT_PURCHASE_RATE}}- Not on record; share of Stripe customers with two or more orders. Target: 20%.
{{NEXT_ACTIONS}}- Proposed: publish refund policy; launch access email; add next-library suggestion on the success page.
Variables · Notion Template Productization01 · Buyer Problem Definition
{{01_Buyer_Problem_Definition}}- The buyer is an operator or marketer who already works in Notion and wants a method for one area of work. Today they improvise in a blank page or an AI chat, and the result is different every time. Building a structured database with prompts, relations and a questionnaire themselves takes hours they do not have. They describe the need in plain terms: a template that does the thinking in order.
{{BUYER_ROLE}}- Marketing lead, operator, consultant or founder working in Notion daily.
{{BUYER_JOB}}- Produce one area's deliverable, such as a positioning statement or content brief, with a repeatable method.
{{CURRENT_WORKAROUND}}- A blank Notion page or AI chat, copied from last time.
{{BUILD_IT_YOURSELF_BLOCKERS}}- Time to design databases and relations; writing prompts that chain; no questionnaire to capture inputs.
{{BUYER_LANGUAGE}}- "A template that does the thinking in order"; "stop starting from scratch"; "something I can just duplicate".
Variables · Notion Template Productization02 · Template Market Scan
{{02_Template_Market_Scan}}- No comparable templates are named or priced in the platform's sources, so the scan is framed as a plan. Proposed: review 20 templates in Notion's template gallery and independent shops covering marketing strategy and content. Compare scope, price and complaints. The expected unserved angle is templates that connect into a larger operating loop.
{{COMPARABLE_TEMPLATES}}- Not on record. Proposed: 20 marketing, content and CRM templates from Notion's gallery and independent shops.
{{PRICE_RANGE}}- Not on record; to be captured in the scan. IO's price is $14.
{{SCOPE_COMPARISON}}- Proposed: compare number of databases, prompts and whether outputs feed another template.
{{REVIEW_COMPLAINTS}}- Not on record; to be collected from public reviews in the scan.
{{UNSERVED_ANGLE}}- Templates that are one step in a mapped operating loop, with named reads and feeds.
Variables · Notion Template Productization03 · Template Scope And Promise
{{03_Template_Scope_And_Promise}}- Each Agent Library template promises one completed area of work. It delivers a set of filled fields that later libraries read. It includes the questionnaire, the column prompts and a guide. It deliberately excludes integrations and automations, which belong to services and consoles.
{{TEMPLATE_PROMISE}}- Duplicate, answer the questionnaire, run the columns, and leave with a finished method output.
{{DELIVERED_OUTCOMES}}- A completed row of structured outputs for one area, ready to feed the next library on the loop.
{{INCLUDED_COMPONENTS}}- The library database with one column per prompt; the questionnaire; the Column prompts section; How to use this library; a cover.
{{DELIBERATE_EXCLUSIONS}}- No third-party integrations, no automations, no hosted data; those are part of services and tenant consoles.
Variables · Notion Template Productization04 · Template Information Architecture
{{04_Template_Information_Architecture}}- The template is kept deliberately flat. A front page explains the library and how to use it, and the back end is one database whose columns are the prompts in run order. Relations are not required, so the template works on any plan. The first-run path goes guide, questionnaire, columns.
{{DASHBOARD_LAYOUT}}- Cover image; library title and promise; How to use this library; link to the database.
{{FRONT_END_PAGES}}- How to use this library; Column prompts; questionnaire.
{{BACK_END_DATABASES}}- One library database; each column is one prompt output in phase order (Discover, Define, Build, Validate, Activate).
{{TEMPLATE_RELATIONS}}- None required; outputs chain across libraries by shared field names rather than Notion relations.
{{FIRST_RUN_PATH}}- Read the guide, answer the questionnaire, add a row, then fill each column in order.
Variables · Notion Template Productization05 · Build Specification
{{05_Build_Specification}}- Templates are generated, not hand-built, by notion-agent-libraries.mjs from the offerings in the estate database. Each database column carries its prompt name; the prompt text is in the Column prompts section because the Notion API cannot set AI autofill prompts. Formulas and buttons are not used. One sample row may be included.
{{DATABASE_SPECS}}- One database per library; a Name column plus one text column per column prompt, named as in the library.
{{FORMULA_SPECS}}- None; kept formula-free for compatibility.
{{VIEW_SPECS}}- Default table view in run order; Proposed: a gallery view of completed rows.
{{BUTTON_SPECS}}- None.
{{SAMPLE_DATA}}- Proposed: one example row per library, drawn from a real tenant's sourced values.
{{PLAN_COMPATIBILITY}}- Works on any Notion plan; AI autofill needs Notion AI, otherwise paste the prompt into any assistant.
Variables · Notion Template Productization06 · In-Template Guidance
{{06_In_Template_Guidance}}- Guidance lives inside the template so the buyer never needs to leave. A start-here checklist opens the page, short callouts explain each section, and a toggle explains pasting column prompts. The advanced guide links back to the library's product page, with its loop and workflow.
{{START_HERE_CHECKLIST}}- Duplicate the template; answer the questionnaire; add your first row; paste or enable each column's prompt; run columns in order.
{{SECTION_CALLOUTS}}- Questionnaire: "Your answers are the inputs every column reads." Column prompts: "One prompt per column, in run order."
{{HOW_TO_TOGGLES}}- How to paste a column prompt into Notion AI autofill; how to run without Notion AI.
{{ADVANCED_GUIDE_LINK}}- The library's product page on intelligentoperations.ai, with its operating loop and workflow.
Variables · Notion Template Productization07 · Duplication And Quality Test
{{07_Duplication_And_Quality_Test}}- Every template is checked by duplicating it into a clean workspace before release. Because the template has no relations, formulas or buttons, the checks focus on columns, views and links. The parent page is published with Duplicate as template on and search indexing off, which child pages inherit. Target setup time is under five minutes.
{{RELATION_CHECKS}}- Not applicable; confirm no relation columns exist.
{{FORMULA_CHECKS}}- Not applicable; confirm no formula columns exist.
{{VIEW_FILTER_CHECKS}}- Default view shows all rows and all prompt columns in order.
{{BUTTON_CHECKS}}- Not applicable.
{{PRIVATE_LINK_CHECKS}}- Confirm the page is public via --check-public, Duplicate as template is on, and search indexing is off.
{{SETUP_TIME}}- Target: under 5 minutes from opening the link to the first row added.
Variables · Notion Template Productization08 · Listing Copy
{{08_Listing_Copy}}- Template listing copy follows the product page pattern. The title names the library, the promise names the output, and the for-whom line names the role. What's inside lists the parts; compatibility notes cover Notion AI; delivery names the Notion duplicate and file.
{{LISTING_TITLE}}- Content Brief - Agent Library
{{LISTING_PROMISE}}- Turn a topic into a complete content brief your writers and agents can follow.
{{FOR_WHOM}}- Content leads, marketers and consultants who brief writers or AI tools.
{{WHATS_INSIDE}}- Column prompts, questionnaire, field map, how-to guide and a Markdown copy.
{{COMPATIBILITY_NOTES}}- Any Notion plan. Notion AI autofill optional; prompts can be pasted into any AI assistant.
{{DELIVERY_METHOD}}- Duplicate the Notion template from your access link and download the Markdown file, instantly after payment.
Variables · Notion Template Productization09 · Listing Visual Plan
{{09_Listing_Visual_Plan}}- Visuals are generated from the template by the site's mockup renderer, so every listing is consistent. The cover is shared with Stripe and Notion. Desktop, mobile and prompts views show the template in use. A walkthrough video is proposed for the top products.
{{COVER_IMAGE}}- The cover view at /libraries/<slug>/image/cover.png, also the og:image and Stripe product image.
{{DASHBOARD_SCREENSHOT}}- The desktop view render.
{{VIEW_SCREENSHOTS}}- Mobile and prompts view renders.
{{WALKTHROUGH_VIDEO}}- Proposed: a 60-90 second duplicate-and-run recording for the ten most viewed libraries.
{{VISUAL_CAPTIONS}}- "The template in your workspace"; "On your phone"; "The column prompts, in run order".
Variables · Notion Template Productization10 · Delivery And Support Process
{{10_Delivery_And_Support_Process}}- Delivery links are set up in the delivery table and resolved through the buyer's access token. The success page is the welcome today; a welcome email is proposed. Support runs by email with canned replies. Updates are re-run by the build script and reach buyers through the same links.
{{DELIVERY_LINK_SETUP}}- delivery.notion_url recorded by notion-agent-libraries.mjs --check-public; served at /access/<token>?as=notion.
{{WELCOME_EMAIL}}- Proposed: "Your Agent Library is ready" with both access links and the first-run steps.
{{SUPPORT_CHANNEL}}- Email [email on file]
{{CANNED_REPLIES}}- Resend access; how to duplicate; how to paste column prompts; refund confirmation.
{{UPDATE_PROCESS}}- Rebuild with area-agent-libraries.mjs and notion-agent-libraries.mjs; the access link always serves the current version.
{{REFUND_POLICY}}- Proposed: refund within 14 days if access fails or contents do not match the listing.
Variables · Notion Template Productization11 · Template Sales Metrics
{{11_Template_Sales_Metrics}}- Template sales are measured on the same data as the storefront. Views and conversion show listing strength; revenue comes from orders; refunds and support requests show quality. No figures are claimed here, and no review score exists yet.
{{LISTING_VIEWS}}- Proposed: weekly product-page views per library.
{{CONVERSION_RATE}}- Target: 2% of product-page views to paid orders.
{{REVENUE}}- Read from orders and order_items per offering; no figure claimed.
{{REFUND_RATE}}- Target: under 3%.
{{SUPPORT_REQUEST_RATE}}- Target: under 5 support emails per 100 orders.
{{REVIEW_SCORE}}- None collected yet; Target: 4.5 of 5 once reviews are gathered.
Variables · Prompt Library Packaging01 · Library Buyer Profile
{{01_Library_Buyer_Profile}}- The library buyer is a working marketer or operator who uses AI tools daily but finds single prompts inconsistent. They want an outcome, not a list: a completed deliverable they can defend. They already have Notion and at least one AI assistant. Their barriers are uncertainty about what is inside and whether it will work in their setup.
{{BUYER_ROLE}}- Marketer, operator or consultant using AI assistants daily.
{{DESIRED_OUTCOME}}- A finished, consistent deliverable for one area of work, produced the same way every time.
{{EXISTING_TOOLS}}- Notion, ChatGPT or Claude, and often Notion AI.
{{PROMPT_EXPERIENCE}}- Intermediate: comfortable pasting prompts, less so designing chained systems.
{{PURCHASE_BARRIERS}}- Unclear contents; doubt that prompts will fit their business; unfamiliar seller.
Variables · Prompt Library Packaging02 · Competitive Listing Scan
{{02_Competitive_Listing_Scan}}- No specific competing listings are named in the platform's sources. Prompt marketplaces typically promise quantity; template shops promise design and time saved. Formats are usually PDFs, docs or single Notion pages. Intelligent Operations leads with structure: a questionnaire, a field map and prompts that chain.
{{COMPARABLE_LISTINGS}}- Not on record. Proposed: scan prompt marketplaces and Notion template shops for marketing prompt packs.
{{COMPETITOR_PROMISES}}- Category pattern: "hundreds of prompts"; "save hours"; "copy and paste".
{{COMPETITOR_PRICES}}- Not on record; to be sourced in the scan.
{{COMPETITOR_FORMATS}}- PDFs, Google Docs, spreadsheets and single Notion pages.
{{LEAD_DIFFERENCE}}- Structured method with questionnaire and field map, delivered as a working Notion template plus Markdown, and placed on an operating loop.
Variables · Prompt Library Packaging03 · Product Name And Promise
{{03_Product_Name_And_Promise}}- Every product is named for the area of work followed by Agent Library, so the name says what it does. The promise names the finished output. The audience is named in the promise so buyers recognise themselves.
{{PRODUCT_NAME}}- <Library name> - Agent Library, for example "Mission, Vision & Values - Agent Library".
{{PRODUCT_PROMISE}}- Leave with a finished mission, vision and values set your team can use, built from ten chained column prompts.
{{PROMISE_AUDIENCE}}- Founders and operators who need their purpose written down in a form people and agents can follow.
Variables · Prompt Library Packaging04 · Package Contents List
{{04_Package_Contents_List}}- Each library contains its column prompts in the estate's six-part shape, a questionnaire and a field map using {{FIELDS}}. Supporting materials are the How to use this library guide and the Markdown file. Sample outputs are proposed from real tenant examples.
{{PROMPT_COUNT}}- Varies by library; most estate libraries carry 10 to 14 column prompts.
{{QUESTIONNAIRE_CONTENTS}}- The intake questions whose answers fill the {{FIELDS}} every prompt reads.
{{INSTRUCTION_PARTS}}- Six parts per prompt, as in the prompt estate's standard shape.
{{SUPPORTING_MATERIALS}}- How to use this library; Column prompts section; Markdown copy of the library.
{{SAMPLE_OUTPUTS}}- Proposed: sourced example values from a tenant console, shown on the product page.
Variables · Prompt Library Packaging05 · Delivery Format Plan
{{05_Delivery_Format_Plan}}- Delivery combines Notion and Markdown so the buyer can use either. The Notion template is duplicated from a published parent; the Markdown file comes from the private bucket through a signed link. Updates are delivered by rebuilding the source, so the buyer's link always serves the current version.
{{DELIVERY_FORMAT}}- Notion template (Duplicate as template) plus Markdown file.
{{TEMPLATE_STRUCTURE}}- Front page with guide; one database with a column per prompt; Column prompts section.
{{DUPLICATION_METHOD}}- Notion Duplicate as template from the published parent Agent Libraries — Store Delivery.
{{UPDATE_DELIVERY}}- Rebuilt by the seed scripts; buyers re-open their /access link for the current version. Proposed: notify buyers by email.
Variables · Prompt Library Packaging06 · Listing Page Copy
{{06_Listing_Page_Copy}}- The listing leads with the output, then shows who it is for, what columns it contains and how it works in three steps. The call to action is Buy now, with the delivery line beside it. Column names are listed exactly as they appear in the template.
{{LISTING_HEADLINE}}- Mission, Vision & Values, ready to run in your workspace.
{{LISTING_PROMISE}}- Ten column prompts take you from why you exist to a rollout plan your team will follow.
{{BUYER_FIT_COPY}}- For founders and operators who need purpose, direction and values written in a form people and agents can use.
{{COLUMN_LIST_COPY}}- Purpose Discovery Questions; Culture Evidence Review; Mission Statement; Vision Statement; Core Values Set; Value Behaviour Standards; Values in Practice; Public Mission Page Copy; Alignment Check; Rollout and Reinforcement Plan.
{{HOW_IT_WORKS_COPY}}- Duplicate the template. Answer the questionnaire. Run each column in order; each builds on the last.
{{PURCHASE_CTA}}- Buy now, $14
Variables · Prompt Library Packaging07 · Sample Prompt Preview
{{07_Sample_Prompt_Preview}}- A preview shows one full column so buyers can judge quality. The proposed preview column is the first in each library, with its six parts and the questionnaire items it reads. A note explains that later columns read this column's output.
{{PREVIEW_COLUMN}}- Proposed: column 01 of each library, for example Purpose Discovery Questions.
{{PREVIEW_PARTS}}- All six parts of that prompt shown in full.
{{PREVIEW_QUESTIONNAIRE}}- The questionnaire items that column reads, with their {{FIELDS}}.
{{CHAIN_CONTEXT_NOTE}}- "Every later column reads this one's output, so the library builds a single, consistent answer."
Variables · Prompt Library Packaging08 · Setup Instructions
{{08_Setup_Instructions}}- Setup takes five steps, all inside the buyer's own workspace. They open their access link, duplicate the template, set up the page, answer the questionnaire and run the columns in order.
{{ACCESS_STEP}}- Open your /access link from the success page or receipt email.
{{DUPLICATE_STEP}}- Choose Duplicate in Notion and pick your workspace.
{{PAGE_PREPARATION}}- Rename the page for your business; add your first row.
{{QUESTIONNAIRE_STEP}}- Answer every questionnaire item; these fill the fields each prompt reads.
{{RUN_ORDER_STEP}}- Fill columns from left to right, pasting each prompt from Column prompts if Notion AI autofill is not set.
Variables · Prompt Library Packaging09 · Bundle And Price Points
{{09_Bundle_And_Price_Points}}- Single libraries are $14 each. Proposed bundles group libraries by IO area or loop stage at a discount. The upgrade offer points to services and a managed console.
{{SINGLE_PRICE}}- $14 one-time.
{{BUNDLE_DEFINITIONS}}- Proposed: area collections (all libraries in one IO area) and stage bundles (all libraries on one loop stage).
{{BUNDLE_PRICES}}- Proposed: about 70% of the sum of included singles.
{{UPGRADE_OFFER}}- A scoped service engagement or a dedicated tenant console running the same methods for you.
Variables · Prompt Library Packaging10 · Pre-Launch Checklist
{{10_Pre_Launch_Checklist}}- Before a library goes on sale, the runbook's checks must pass. The product must be buyable, the Notion page duplicated and public, the receipt verified, the listing accurate, and a synthetic buyer run completed. Each item is ticked in the PR.
{{REVIEW_PASSED_CHECK}}- Authored specs lint cleanly with authored-libraries.mjs; estate prompts have the six-part shape.
{{DUPLICATION_CHECK}}- Template duplicates into a clean workspace with all columns present.
{{DELIVERY_EMAIL_CHECK}}- Stripe receipt arrives; Proposed access email arrives with both links.
{{LISTING_ACCURACY_CHECK}}- Column list, prompt count and previews match the template.
{{TEST_BUYER_CHECK}}- Synthetic paid session through fulfil() and access(), then its rows deleted.
Variables · Prompt Library Packaging11 · Library Sales Measures
{{11_Library_Sales_Measures}}- Library sales are read from the estate database and Stripe. No sales figures are claimed. Buyer questions are logged to improve listings and guides.
{{LISTING_VIEWS}}- Proposed: product-page views per library per week.
{{CONVERSION_RATE}}- Target: 2% of views to orders.
{{LIBRARY_REVENUE}}- Read from order_items per offering; no figure claimed.
{{BUNDLE_SHARE}}- Not applicable until bundles launch.
{{REFUND_RATE}}- Target: under 3%.
{{BUYER_QUESTIONS}}- Proposed: log every question by theme (access, Notion AI, fit) and fix the listing or guide for any theme raised three times.
Variables · Product Launch01 · Launch Announcement Framework
{{01_Launch_Announcement_Framework}}- The launch announcement introduces the Agent Libraries storefront as a store of ready-to-run methods for every area of marketing and revenue operations. It leads with the size and structure of the catalogue, then explains delivery and price. The body stays factual: 147 libraries, 65 areas, $14 each, delivered instantly to Notion. The call to action sends readers to /libraries.
{{HEADER}}- 147 Agent Libraries. Every area of marketing and revenue operations, ready to run.
{{SUBHEADER}}- Duplicate a working method into your Notion workspace for $14, the moment you pay.
{{BODY_CONTENT}}- Intelligent Operations has opened its Agent Libraries store: 147 structured libraries across 65 IO areas, each a questionnaire, column prompts and a field map that chains into the next area of the operating loop. The same methods run inside the platform's own tenant consoles.
{{CALL_TO_ACTION}}- Buy your first library and reply with what you ran it on.
Variables · Product Launch02 · Product Positioning Statement
{{02_Product_Positioning_Statement}}- For operators and marketing and revenue teams who have AI tools but not a method, the Agent Libraries are ready-to-run methods for every area of the work. Unlike prompt packs and standalone templates, each library sits on one operating loop and feeds the next. It is delivered instantly into Notion and as a file.
{{POSITIONING}}- The ready-to-run method library for marketing and revenue operations, mapped onto one operating loop.
{{TARGET_AUDIENCE}}- Notion-first operators, marketers, consultants and RevOps leads.
{{VALUE_PROPOSITION}}- Be first to run the method library, and shape which bundles come next.
{{COMPETITIVE_ADVANTAGE}}- Libraries connect across an eight-stage loop and are proven in live tenant consoles; every product is also an MCP tool.
Variables · Product Launch03 · Key Messaging Points
{{03_Key_Messaging_Points}}- Four messages carry the launch. The catalogue is complete across the operating loop. Each library is a method, not a list. Delivery is instant and lives in the buyer's own workspace. And the methods are the ones the platform runs itself.
{{MESSAGE_1}}- Every area on the loop: 147 libraries across 65 IO areas, from Know to Measure.
{{MESSAGE_2}}- A method, not a list: questionnaire, column prompts and a field map that chain.
{{MESSAGE_3}}- Yours in minutes: a Notion template and a file, straight after Stripe checkout.
{{MESSAGE_4}}- Run in production: the same methods power Intelligent Operations' tenant consoles.
Variables · Product Launch04 · Launch Email Sequences
{{04_Launch_Email_Sequences}}- The proposed launch sequence has three emails to the existing list and network. The first announces the store; the second shows one library end to end; the third points to libraries by loop stage. The follow-up targets people who clicked but did not buy.
{{EMAIL_SUBJECT}}- The Agent Libraries store is open
{{EMAIL_BODY}}- 147 ready-to-run methods for marketing and revenue operations, each one a Notion template you can duplicate today for $14. Start with the area you are working on this week.
{{CALL_TO_ACTION}}- Buy your first library and reply with what you ran it on.
{{FOLLOW_UP}}- Proposed: day 3, "What's inside one library" walkthrough; day 7, "Pick your stage on the loop".
Variables · Product Launch05 · Press Release Template
{{05_Press_Release_Template}}- A short release suits trade and local business press. The headline states the launch, the subheadline the scope, and the body the what, how and why, with no invented quotes. Contact details are the company's published ones.
{{HEADLINE}}- Intelligent Operations Opens Agent Libraries Store With 147 Ready-to-Run Methods for Marketing and Revenue Teams
{{SUBHEADLINE}}- North Kansas City company delivers structured AI methods for 65 areas of operations as Notion templates, each priced at $14.
{{BODY}}- Intelligent Operations, LLC has launched its Agent Libraries store at intelligentoperations.ai. Each of the 147 libraries packages one area of marketing or revenue operations as a questionnaire, column prompts and a field map, delivered instantly as a Notion template and file after Stripe checkout. The libraries are the same methods the company runs for its tenant businesses.
{{CONTACT_INFORMATION}}- [email on file]
Variables · Product Launch06 · Launch Timeline Communications
{{06_Launch_Timeline_Communications}}- Launch communications follow four milestones. Readiness is confirmed first by the runbook checks, then the store is announced, then a walkthrough follows, and a review closes the first month.
{{MILESTONE_1}}- Readiness: 147 of 147 Stripe prices verified and 0 broken links across 226 pages (met 2026-09-28).
{{MILESTONE_2}}- Proposed: public announcement on the founder's LinkedIn, the email list and the site.
{{MILESTONE_3}}- Proposed: week 2, a one-library walkthrough video and post.
{{MILESTONE_4}}- Proposed: week 4, launch review of views, conversion and buyer questions.
Variables · Product Launch07 · Launch Event Content
{{07_Launch_Event_Content}}- A short live walkthrough is proposed rather than a large event. The founder duplicates a library live, runs it for a real business and answers questions. It is online, so no venue is needed.
{{EVENT_NAME}}- Proposed: "Run a Library Live".
{{AGENDA}}- 10 minutes: the operating loop. 20 minutes: duplicate and run one library. 15 minutes: questions.
{{SPEAKERS}}- Tommy Saunders, founder and operator of Intelligent Operations.
{{LOCATION}}- Online (LinkedIn Live or YouTube Live, on the Intelligent Operations channel).
Variables · Product Launch08 · Launch Video Script Framework
{{08_Launch_Video_Script_Framework}}- The launch video runs about 60 to 90 seconds. It opens with the problem, shows one library being duplicated and run, and closes with the catalogue and price. The call to action is a single link.
{{INTRODUCTION}}- You bought the AI tools. You still start every task from a blank page.
{{KEY_POINTS}}- One library per area of work; answer the questionnaire; run the columns; outputs feed the next library; delivered straight to Notion.
{{CONCLUSION}}- 147 libraries across 65 areas, each ready to run today.
{{CALL_TO_ACTION}}- Buy your first library and reply with what you ran it on.
Variables · Product Launch09 · Early Adopter Messaging
{{09_Early_Adopter_Messaging}}- Early adopters are Notion-first operators in the founder's network. The message invites them to buy one library and reply with what worked. No testimonials exist yet, so none are shown; the ask is to collect the first real ones with permission.
{{TARGET_GROUP}}- Notion-first operators and consultants in the founder's LinkedIn network and email list.
{{VALUE_PROPOSITION}}- Be first to run the method library, and shape which bundles come next.
{{TESTIMONIALS}}- None on record; Proposed: request one-sentence feedback at day 14 and quote only with permission.
{{CALL_TO_ACTION}}- Buy your first library and reply with what you ran it on.
Variables · Product Launch10 · Sales Team Enablement Materials
{{10_Sales_Team_Enablement_Materials}}- There is no sales team; the founder sells directly and tenant work is scoped personally. Enablement is therefore a one-page brief the founder and any contractor can use: what the store is, who it suits, and the common questions.
{{TRAINING_CONTENT}}- The operating loop; how a library is built; delivery flow; when to suggest a console instead.
{{SALES_TIPS}}- Start from the buyer's area of work this week; show the product page loop; suggest the next library, not a bundle, first.
{{FAQ}}- Notion AI needed? No. Refunds? Proposed 14-day policy. Can I use it for clients? Proposed licence allows client work.
{{CONTACT_INFORMATION}}- [email on file]
Variables · Product Launch11 · Launch FAQ Document
{{11_Launch_FAQ_Document}}- The launch FAQ answers the three questions buyers ask most: what they receive, whether Notion AI is required and whether they can come back later. Answers match the runbook exactly.
{{QUESTION_1}}- What do I receive?
{{ANSWER_1}}- A Notion template you duplicate into your workspace and, for most libraries, a Markdown file, both available the moment payment completes.
{{QUESTION_2}}- Do I need Notion AI?
{{ANSWER_2}}- No. Each column's prompt is listed under Column prompts; paste it into Notion AI autofill or any AI assistant.
{{QUESTION_3}}- Can I download it again later?
{{ANSWER_3}}- Yes. Your access link is permanent; each download it issues is valid for five minutes.
Variables · Product Launch12 · Launch Success Metrics Framework
{{12_Launch_Success_Metrics_Framework}}- Launch success is judged on four measures over the first four weeks. Targets are proposed, not results. Data comes from the estate database, Stripe and site analytics.
{{METRIC_1}}- Product-page views. Target: 2,000 in the first four weeks.
{{METRIC_2}}- Conversion to paid orders. Target: 2% of product-page views.
{{METRIC_3}}- Refund rate. Target: under 3%.
{{METRIC_4}}- Buyers who purchase a second library within 30 days. Target: 15%.
Variables · Generative Engine Optimization (GEO)01 · Prompt Set Discovery
{{01_Prompt_Set_Discovery}}- The GEO programme starts from the questions buyers ask AI assistants when they need a method. The tracking set covers recommendation prompts (best Notion templates for marketing strategy), comparison prompts (prompt packs versus templates), problem prompts (how to operationalise AI in marketing) and cost prompts (cheap brand positioning template). Proposed: a fixed set of 40 prompts, run monthly across the major assistants.
{{RECOMMENDATION_PROMPTS}}- "Best Notion template for brand positioning"; "AI prompt library for marketing operations"; "template for a content brief with AI".
{{COMPARISON_PROMPTS}}- "Notion templates vs prompt packs for marketing"; "agency vs template for marketing strategy".
{{PROBLEM_PROMPTS}}- "How do I make my team's AI prompts consistent"; "how to operationalise AI in a small marketing team".
{{COST_PROMPTS}}- "Affordable marketing strategy template"; "cheap prompt library for RevOps".
{{TRACKING_PROMPT_SET}}- Proposed: 40 prompts (10 per type) run monthly in ChatGPT, Claude, Gemini, Perplexity and Google AI Overviews.
Variables · Generative Engine Optimization (GEO)02 · AI Visibility Baseline
{{02_AI_Visibility_Baseline}}- No AI visibility baseline has been recorded yet, so none is claimed. The first monthly run will measure how often Intelligent Operations is mentioned and cited, where it ranks when recommended, and whether assistants describe it accurately. The platform's llms.txt, which reads its counts from code, is the reference for accuracy.
{{MENTION_RATE}}- Not on record; to be measured in the first monthly run.
{{CITATION_RATE}}- Not on record; share of answers linking intelligentoperations.ai.
{{RECOMMENDATION_POSITION}}- Not on record; average position when listed.
{{DESCRIPTION_ACCURACY}}- Not on record; scored against llms.txt facts.
{{CITED_SOURCES}}- Not on record; domains cited in answers to be logged.
Variables · Generative Engine Optimization (GEO)03 · Citation Source Map
{{03_Citation_Source_Map}}- The source map records which domains assistants cite for the tracked prompts, by type. Until the first run, only the platform's own presence is known: the site, the product pages and the llms.txt brief. Gaps are expected in third-party listings, reviews and community discussions.
{{CITED_DOMAINS}}- Not on record; to be logged per prompt in the first run.
{{SOURCE_TYPES}}- Expected: template galleries, review sites, community forums, publisher roundups, vendor sites.
{{CITATION_FREQUENCY}}- Not on record.
{{COMPANY_PRESENCE}}- Owned: intelligentoperations.ai, 147 product pages, 65 area pages, /llms.txt; the Intelligent Operations YouTube channel.
{{PRESENCE_GAPS}}- Expected: no third-party template-gallery listings, reviews or community mentions on record.
Variables · Generative Engine Optimization (GEO)04 · Entity Clarity Framework
{{04_Entity_Clarity_Framework}}- Assistants need one consistent description of the company. The canonical facts are the legal name, location, what it sells and how it delivers. They must match on the site, llms.txt, Stripe, Notion and every profile. A known conflict is that Tommy Saunders's personal site and the platform are separate entities that must not be merged.
{{CANONICAL_FACTS}}- Intelligent Operations, LLC; North Kansas City, MO; [email on file]; store of tools, templates, agents and prompt libraries plus services; every product also an MCP tool.
{{CATEGORY_STATEMENT}}- Intelligent Operations builds and operates the software layer that runs a business's repetitive work.
{{OFFERING_DESCRIPTIONS}}- Agent Libraries: 147 structured methods at $14, delivered as Notion templates and files. Tenant consoles: a dedicated console and database per client business.
{{CONSISTENCY_LOCATIONS}}- Site pages and JSON-LD; /llms.txt; Stripe product names and images; Notion page covers; the founder's LinkedIn and YouTube.
{{CONFLICTING_FACTS}}- Earlier llms.txt described a brokerage (fixed); the founder's personal brand and the platform must remain distinct entities.
Variables · Generative Engine Optimization (GEO)05 · Citable Content Standards
{{05_Citable_Content_Standards}}- Pages are written so an assistant can quote a single passage accurately. Every claim is plain and sourced, numbers are computed rather than typed, and each page states who wrote it and when it was checked. Freshness is maintained by dated state lines, as in the runbooks.
{{CLAIM_CLARITY_STANDARD}}- One claim per sentence, with the number and its unit, for example "147 libraries at $14 each".
{{ORIGINAL_DATA_STANDARD}}- Only first-party figures from the platform's own records; no borrowed industry statistics.
{{EXPERTISE_SIGNALS}}- Name the founder and operator; link methods to the live tenant consoles that use them.
{{PASSAGE_STANDARD}}- Each section answers one question in 40-80 words that stand alone.
{{FRESHNESS_STANDARD}}- A "checked on" date on every factual page; counts rendered from live data.
Variables · Generative Engine Optimization (GEO)06 · Owned Content Plan
{{06_Owned_Content_Plan}}- The owned plan fills the gaps the prompt set reveals. Proposed pieces explain the operating loop, compare templates with methods, and show one library run end to end. Each targets specific tracked prompts. All must render server-side so crawlers see the full text.
{{CONTENT_PIECES}}- Proposed: "The eight-stage operating loop" explainer; "Templates vs methods" comparison; one worked example per loop stage.
{{TARGET_PROMPTS}}- Problem prompts on operationalising AI; comparison prompts on templates vs prompt packs.
{{GAPS_FILLED}}- No explainer of how libraries connect; no worked examples on record.
{{CRAWLABILITY_REQUIREMENTS}}- Server-rendered HTML, listed in the sitemap, linked from /libraries and the area pages.
Variables · Generative Engine Optimization (GEO)07 · Earned Presence Plan
{{07_Earned_Presence_Plan}}- Earned presence is built slowly and honestly. Proposed actions list selected libraries in Notion's template gallery, collect real reviews after purchase, contribute expert commentary on AI operations, and answer questions in communities where operators ask them. No paid or fake reviews.
{{TARGET_SOURCES}}- Notion template gallery; relevant marketing and operations newsletters; operator communities.
{{REVIEW_ACTIONS}}- Proposed: request reviews at day 14 from satisfied buyers; publish only real ones with permission.
{{LISTING_ACTIONS}}- Proposed: list five representative libraries in the Notion template gallery.
{{EXPERT_COMMENTARY_ACTIONS}}- Proposed: founder essays on the operating loop and on running a platform as one operator.
{{COMMUNITY_ACTIONS}}- Proposed: answer questions on Notion and marketing-ops forums, disclosing affiliation.
Variables · Generative Engine Optimization (GEO)08 · Crawler Access Review
{{08_Crawler_Access_Review}}- Crawler access is reviewed so assistants can read the store. Product and area pages render server-side, and the checkout success page is marked noindex. Paid Notion templates keep search indexing off deliberately. The sitemap should list every product and area page.
{{AI_CRAWLER_RULES}}- Proposed: allow major AI crawlers on product, area and /llms.txt paths; disallow /access and /checkout.
{{RENDERING_CHECK}}- Product and area pages are server-rendered Next.js routes; confirm with a no-JavaScript fetch.
{{SITEMAP_COVERAGE}}- Proposed: confirm all 147 product pages and 65 area pages appear in the sitemap.
{{HIDDEN_CONTENT}}- Paid prompt text and Notion templates are intentionally unindexed; the success page is noindex.
{{ACCESS_FIXES}}- Proposed: add /llms.txt to the www deploy with store counts; add robots rules for /access.
Variables · Generative Engine Optimization (GEO)09 · Misrepresentation Correction
{{09_Misrepresentation_Correction}}- When an assistant describes the company wrongly, the error is logged, traced to its source and corrected there. The platform has already corrected one source: its llms.txt previously described a brokerage. Rechecks follow each monthly run.
{{INACCURACY_LOG}}- Proposed: a table of prompt, assistant, wrong statement, date and source.
{{SOURCE_TRACING}}- Find the cited or likely source for each error, starting with owned pages and llms.txt.
{{SOURCE_CORRECTIONS}}- Fix owned sources first; the llms.txt was rewritten so every count reads from code.
{{FEEDBACK_SUBMISSIONS}}- Use each assistant's feedback tool to flag inaccurate answers.
{{RECHECK_SCHEDULE}}- Monthly, with the tracking prompt set.
Variables · Generative Engine Optimization (GEO)10 · GEO Measurement Framework
{{10_GEO_Measurement_Framework}}- GEO is measured monthly on the tracked prompt set. Share of answers, citation, position and accuracy are logged per assistant, and referral traffic is read from site analytics. Targets are proposed for the first two quarters.
{{SHARE_OF_AI_ANSWERS}}- Target: mentioned in 10% of tracked answers by the end of Q2 2027.
{{CITATION_TREND}}- Target: month-on-month growth in answers citing intelligentoperations.ai.
{{POSITION_TREND}}- Target: average position in the top five when listed.
{{ACCURACY_TREND}}- Target: 90% of descriptions match canonical facts.
{{AI_REFERRAL_TRAFFIC}}- Proposed: track sessions referred by AI assistants in site analytics.
Variables · Generative Engine Optimization (GEO)11 · GEO Programme Report
{{11_GEO_Programme_Report}}- The monthly report will show visibility change, winning and losing prompts, new sources and next priorities. No results exist yet; the first report follows the baseline run. Priorities start with entity consistency and crawler access.
{{VISIBILITY_CHANGE}}- Not on record; baseline pending.
{{WINNING_PROMPTS}}- Not on record.
{{LOSING_PROMPTS}}- Not on record.
{{SOURCE_GAINS}}- Not on record.
{{NEXT_PRIORITIES}}- Run the baseline; publish store counts in www's llms.txt; list five libraries in the Notion gallery.
Variables · Tenant Onboarding01 · Engagement Scope Summary
{{01_Engagement_Scope_Summary}}- Tenant onboarding brings a client business into its one console on the platform. Scope typically covers the tenant site, brand kit, content areas such as Properties, Articles and Products, and the Variables library. Every tenant gets its own Postgres database and a single console; other work streams become content types in that console, not a separate workspace. The first expected outcome is the tenant's site content and brand loaded and editable.
{{CONTRACTED_SERVICES}}- Tenant console, tenant site, brand assets section, Variables library and content areas agreed per tenant.
{{CONTENT_AREAS_IN_SCOPE}}- Foundation (brand assets), Website IO pages, Properties, Articles and Products, as applicable.
{{START_DATE}}- Set per tenant at kickoff; Proposed: within five business days of signed scope.
{{FIRST_EXPECTED_OUTCOME}}- Brand kit, site content and first records live in the tenant console.
{{SCOPE_MISMATCHES}}- A request for a second workspace or admin app is re-scoped as a content type inside the one console (ADR 0002).
Variables · Tenant Onboarding02 · Kickoff Discovery Questions
{{02_Kickoff_Discovery_Questions}}- Kickoff gathers the facts the console and libraries need. It covers the business, its offers and audience, the channels it runs, assets already in hand, who decides and how they want to be contacted. Answers go into the tenant's knowledge base, so every later value has a source.
{{BUSINESS_FACTS}}- Legal and trading name, location, service area, years operating, stakeholder.
{{AUDIENCE_AND_OFFERS}}- Who buys, what they buy, and the top three offers.
{{CURRENT_CHANNELS}}- Website, Google Business Profile, LinkedIn, Instagram, Facebook, YouTube, email.
{{EXISTING_ASSETS}}- Logo, fonts, colours, photography, documents, existing site content.
{{DECISION_MAKERS}}- Who approves brand, content and spend.
{{COMMUNICATION_PREFERENCES}}- Channel, frequency and response expectations.
Variables · Tenant Onboarding03 · Stakeholder and Role Map
{{03_Stakeholder_and_Role_Map}}- Each tenant has a named stakeholder who is the primary contact, recorded in the tenant registry. Operators run the console; the tenant approves. Console permissions follow estate UI policy, which the master operator sets on Tenant IO. Approval responsibilities are written down at kickoff.
{{PRIMARY_CONTACT}}- The tenant's named stakeholder in the registry, for example Martin Rucker for Rucker Construction.
{{STAKEHOLDER_ROLES}}- Stakeholder (approves); operator (builds and runs); contributors (supply content).
{{CONSOLE_PERMISSIONS}}- Set by estate UI policy on Tenant IO (ADR 0010): visibility, labels and order per console, with estate locks.
{{APPROVAL_RESPONSIBILITIES}}- Stakeholder approves brand, public copy and anything sent externally; operator approves technical changes through the PR flow.
Variables · Tenant Onboarding04 · Access and Asset Intake
{{04_Access_and_Asset_Intake}}- Intake collects account connections, brand files and source documents, and records where each lands. Media goes to the tenant's bucket under /cloud/<tenant>/, never into git. Source documents feed the knowledge base. Intake status is tracked per item.
{{ACCOUNT_CONNECTIONS}}- Domain and DNS, Google Business Profile, social accounts, analytics, as scoped.
{{BRAND_FILES}}- Logo, fonts, colour values and imagery, loaded to the tenant bucket and the brand kit.
{{SOURCE_DOCUMENTS}}- Existing site content, brochures, bios and case material for the knowledge base.
{{DELIVERY_METHOD}}- Upload to the tenant bucket via the console; URLs served as /cloud/<tenant>/brand or /sources.
{{INTAKE_STATUS}}- Per item: requested, received, loaded, verified.
Variables · Tenant Onboarding05 · Onboarding Sequence
{{05_Onboarding_Sequence}}- Onboarding follows a fixed order. Kickoff comes first, then intake, then the console and brand kit, then site content and records, then a walkthrough and readiness check. Each step has an owner and a target date, and later steps wait on earlier ones.
{{ONBOARDING_STEPS}}- Kickoff; asset intake; console and database set up; brand kit; site content and records; walkthrough; readiness check; handoff.
{{STEP_OWNERS}}- Operator owns every step except asset supply and approvals, which the stakeholder owns.
{{TARGET_DATES}}- Proposed: kickoff day 1; intake by day 5; console and brand by day 10; content by day 15; walkthrough day 20.
{{TENANT_GATING_ACTIONS}}- Supply brand files and source documents; approve site copy; confirm stakeholder login.
{{STEP_DEPENDENCIES}}- Brand kit needs brand files; site content needs source documents and brand; walkthrough needs content loaded.
Variables · Tenant Onboarding06 · Welcome Communication
{{06_Welcome_Communication}}- The welcome message tells the tenant what happens, what is needed from them and how to reach the operator. It sets expectations in plain language and names the console as the one place their work lives.
{{WELCOME_OPENING}}- Welcome to Intelligent Operations. Your business now has one console where your brand, site content and records live together.
{{TIMELINE_OVERVIEW}}- Over the next three weeks we load your brand, build your pages and walk you through the console.
{{REQUESTED_ITEMS}}- Your logo files, brand colours and fonts, current website content, and the name of whoever approves public copy.
{{CONSOLE_ACCESS_NOTE}}- You will receive a sign-in for your console once your brand kit is loaded.
{{SUPPORT_CONTACT}}- Tommy Saunders, [email on file]
Variables · Tenant Onboarding07 · Console Walkthrough Plan
{{07_Console_Walkthrough_Plan}}- The walkthrough shows the tenant the sections they will use most, and has them complete a real task in each. Practice records are real content, not samples. Help resources point back to the console.
{{WALKTHROUGH_SECTIONS}}- Home; Foundation and Brand assets; Website IO pages; Properties, Articles or Products; Variables library.
{{TENANT_TASKS}}- Edit one page section; add or update one record; review one set of variables.
{{PRACTICE_RECORDS}}- The tenant's own first records, loaded during onboarding.
{{HELP_RESOURCES}}- Proposed: a short guide in the console and direct email to the operator.
Variables · Tenant Onboarding08 · Onboarding Readiness Check
{{08_Onboarding_Readiness_Check}}- Readiness is checked against the scope before handoff. Every deliverable must be live, no blocking items may remain, and the stakeholder must be able to sign in. The operator records the decision.
{{DELIVERABLE_STATUS}}- Per scoped item: live, pending tenant, pending operator.
{{BLOCKING_ITEMS}}- Missing brand files, unapproved copy or DNS not yet pointed.
{{STAKEHOLDER_LOGIN_CHECK}}- Stakeholder signs in and lands on their console.
{{READINESS_DECISION}}- Ready, ready with open items, or not ready, with reasons.
Variables · Tenant Onboarding09 · Handoff to Ongoing Service
{{09_Handoff_to_Ongoing_Service}}- Handoff records everything the ongoing service needs: the account context, commitments made, open issues, preferences and a first-month plan. It lives in the tenant's console and knowledge base, not in email.
{{ACCOUNT_CONTEXT}}- Business facts, stakeholder, scope and sources, in the tenant knowledge base.
{{COMMITMENTS_MADE}}- Deliverables and dates agreed at kickoff.
{{OPEN_ISSUES}}- Items still pending from the readiness check.
{{TENANT_PREFERENCES}}- Communication channel and approval style recorded at kickoff.
{{FIRST_MONTH_PLAN}}- Proposed: fill the Variables library for the tenant's chosen libraries; publish the first content cards.
Variables · Tenant Onboarding10 · Onboarding Success Measures
{{10_Onboarding_Success_Measures}}- Onboarding is measured on speed, completeness and early satisfaction. Targets are proposed. Delay causes are logged so the sequence improves.
{{TIME_TO_FIRST_CONTENT}}- Target: tenant content live within 15 business days of kickoff.
{{INTAKE_COMPLETION_RATE}}- Target: 100% of requested items received by day 10.
{{EARLY_SATISFACTION_SCORE}}- Proposed: a 1-5 rating at the walkthrough; Target: 4 or above.
{{DELAY_CAUSES}}- Proposed categories: tenant assets late, approvals late, DNS, operator capacity.
Variables · Tenant Health & Account Review01 · Account Context Summary
{{01_Account_Context_Summary}}- Account reviews start from the tenant's context held in its console and knowledge base. The summary states current scope, how long the tenant has been on the platform, its goals, its stakeholder and what has changed since the last review. For example, tenant admin pages moved into the platform tenant console in September 2026, replacing separate admin apps.
{{CURRENT_SCOPE}}- The tenant's console areas, site and libraries currently in use.
{{TENURE}}- Months since the tenant's console went live.
{{TENANT_GOALS}}- The goals recorded at kickoff and in the tenant knowledge base.
{{KEY_CONTACTS}}- The stakeholder named in the tenant registry.
{{CHANGES_SINCE_LAST_REVIEW}}- Platform changes affecting the tenant, such as the September 2026 move of admin pages into the one tenant console.
Variables · Tenant Health & Account Review02 · Health Signal Inventory
{{02_Health_Signal_Inventory}}- Health is read from signals the platform already records. Usage signals come from console activity; delivery signals from shipped work; results signals from the tenant's own metrics where on record; sentiment from direct feedback; billing from Stripe invoices.
{{USAGE_SIGNALS}}- Console sign-ins, record edits and variables reviewed per month.
{{DELIVERY_SIGNALS}}- Scoped deliverables shipped on time; open items.
{{RESULTS_SIGNALS}}- Tenant-reported outcomes only where on record; none are assumed.
{{SENTIMENT_SIGNALS}}- Stakeholder feedback at reviews and in correspondence.
{{BILLING_SIGNALS}}- Stripe invoice status: paid, open, overdue.
Variables · Tenant Health & Account Review03 · Health Score Model
{{03_Health_Score_Model}}- The proposed score combines five components on a 0-100 scale. Delivery and usage carry the most weight because they are measured directly. A missing signal is scored neutral and flagged rather than guessed.
{{SCORE_COMPONENTS}}- Usage; delivery; results; sentiment; billing.
{{COMPONENT_WEIGHTS}}- Proposed: usage 25%, delivery 30%, results 15%, sentiment 15%, billing 15%.
{{SCORING_RULES}}- Each component 0-100 against its target; weighted sum rounded to the nearest whole number.
{{HEALTH_BANDS}}- Healthy 75-100; watch 50-74; at risk below 50.
{{MISSING_SIGNAL_RULE}}- Score 50 and flag "no data on record"; never infer.
Variables · Tenant Health & Account Review04 · Value Delivered Assessment
{{04_Value_Delivered_Assessment}}- The value assessment compares what was delivered with what was scoped, and outcomes with goals. Shortfalls are named with their causes, so the success plan can fix them. Only recorded outcomes are counted.
{{DELIVERABLES_VS_SCOPE}}- List of scoped items with status live, partial or not started.
{{OUTCOMES_VS_GOALS}}- Recorded outcomes against each goal; "not on record" where no data exists.
{{SHORTFALLS}}- Scoped items not delivered or goals without progress.
{{SHORTFALL_CAUSES}}- Tenant assets pending, operator capacity, platform changes, or scope unclear.
Variables · Tenant Health & Account Review05 · Relationship Risk Assessment
{{05_Relationship_Risk_Assessment}}- Risks are named with evidence, rated and assigned a mitigation. Typical risks are low usage, delayed approvals, unpaid invoices and platform incidents that affected the tenant, such as the September 2026 shared-variable incident that pointed tenant databases at the estate database.
{{IDENTIFIED_RISKS}}- Low console usage; approval delays; overdue invoices; incident impact on tenant data.
{{RISK_EVIDENCE}}- Usage logs, open-item lists, Stripe status and incident notes in the lessons file.
{{RISK_RATINGS}}- High, medium or low by likelihood and impact.
{{MITIGATION_ACTIONS}}- Walkthrough refresh; approval deadlines; payment reminder; incident explanation and the check that prevents recurrence.
Variables · Tenant Health & Account Review06 · Expansion Opportunities
{{06_Expansion_Opportunities}}- Expansion is proposed only where a need is observed. A tenant who edits content often may benefit from a content operations cadence; one with active campaigns may need campaign libraries run for them. Readiness depends on current scope being delivered first.
{{OBSERVED_NEEDS}}- Needs noted in reviews and console usage.
{{PROPOSED_SERVICES}}- Additional content areas, campaign support or library runs within the tenant console.
{{EXPECTED_BENEFITS}}- Stated per proposal as a target, not a promise.
{{READINESS_CONDITION}}- Current scope delivered and health score in the healthy band.
Variables · Tenant Health & Account Review07 · Review Meeting Agenda
{{07_Review_Meeting_Agenda}}- Reviews run 45 minutes with a fixed agenda. The operator presents status and findings, the tenant gives feedback, and both agree actions.
{{AGENDA_ITEMS}}- Status against scope; health score; value and risks; tenant feedback; next-period plan.
{{TIME_ALLOCATIONS}}- 10, 5, 10, 10 and 10 minutes respectively.
{{TENANT_FEEDBACK_PROMPTS}}- What has been most useful? What is harder than it should be? What should we stop or start?
{{AGREED_ACTIONS}}- Recorded in the tenant's console with owner and date.
Variables · Tenant Health & Account Review08 · Account Review Report
{{08_Account_Review_Report}}- The written report records the health score, a short summary, value and risk findings, and the agreed plan. It is stored with the tenant's account context and uses only sourced facts.
{{HEALTH_SCORE_RESULT}}- Score and band, with any missing signals flagged.
{{REVIEW_SUMMARY}}- Three sentences: where the account stands, what changed, what happens next.
{{VALUE_FINDINGS}}- Delivered items and recorded outcomes.
{{RISK_FINDINGS}}- Rated risks with mitigations.
{{AGREED_PLAN}}- Next-period goals and actions from the meeting.
Variables · Tenant Health & Account Review09 · Next Period Success Plan
{{09_Next_Period_Success_Plan}}- The success plan sets two or three goals for the next period, with actions on both sides and a measure for each. The next review date is fixed before the meeting ends.
{{NEXT_PERIOD_GOALS}}- Proposed: close open scope items; raise console usage; complete the tenant's chosen library variables.
{{OPERATOR_ACTIONS}}- Deliver open items; run the walkthrough refresh; fill variables.
{{TENANT_ACTIONS}}- Supply pending assets; approve copy within the agreed window.
{{GOAL_MEASURES}}- Open items to zero; monthly sign-ins; variables filled.
{{NEXT_REVIEW_DATE}}- Proposed: quarterly, set at the meeting.
Variables · Tenant Health & Account Review10 · Escalation Protocol
{{10_Escalation_Protocol}}- Escalation is triggered by a low score, a missed commitment or an incident. Levels run from operator fix to founder involvement. Response times are set, and any recovery plan must name its cause and fix.
{{ESCALATION_TRIGGERS}}- Health below 50; a missed delivery date; an incident affecting tenant data; an overdue invoice past 30 days.
{{ESCALATION_LEVELS}}- Level 1: operator resolves. Level 2: founder reviews with the stakeholder.
{{RESPONSE_TIME}}- Proposed: acknowledgement within one business day; plan within three.
{{RECOVERY_PLAN_REQUIREMENTS}}- Cause, fix, the check that prevents recurrence, owner and date; logged in the lessons file where platform-related.
Variables · Automation Scripts & Runbooks01 · Automation Candidate Inventory
{{01_Automation_Candidate_Inventory}}- The platform already automates much of its catalogue work through seed and sync scripts, and the inventory lists what remains manual or fragile. Candidates include the Agent Libraries refresh chain, Stripe price checks, Notion public-URL checks, the synthetic purchase test and the daily ops-audit. Each touches production systems, so failure impact ranges from a missing buy button to a wrong price. Error history is drawn from the lessons file and PLAN execution log.
{{CANDIDATE_TASKS}}- Agent Libraries refresh (offerings, Stripe, icons, Notion); Stripe price verification; Notion --check-public; synthetic purchase test; production link crawl; ops-audit.
{{RUN_FREQUENCY}}- Refresh: per catalogue change. Price check and crawl: Proposed weekly. Ops-audit: daily.
{{MANUAL_EFFORT}}- Notion build takes about 40 seconds per library due to rate limits; the full chain is run by hand step by step.
{{ERROR_HISTORY}}- Notion syncs failing for weeks (PLAN); shared-variable spill pointing tenant databases at the estate database (2026-09-28).
{{SYSTEMS_TOUCHED}}- Estate Postgres, Stripe, Notion, the private tenant bucket, Railway.
{{FAILURE_IMPACT}}- A product without a delivery row shows no buy button; a wrong price or inactive Stripe price blocks purchase; a missing Notion URL hides the Notion button.
Variables · Automation Scripts & Runbooks02 · Automation Priority Score
{{02_Automation_Priority_Score}}- Candidates are scored on frequency, manual effort, error history and blast radius. Read-only checks with high value score first because they are safe to schedule. Write scripts with wide blast radius stay manual with dry runs until they are proven.
{{SCORING_CRITERIA}}- Frequency (1-5); manual effort (1-5); error history (1-5); blast radius (1-5, inverted for scheduling).
{{CANDIDATE_SCORES}}- Proposed: Stripe price check 17; link crawl 16; synthetic purchase test 15; Notion --check-public 14; full refresh chain 9.
{{BLAST_RADIUS_RATING}}- Read-only checks: low. Stripe product creation: high. Offerings commit: high.
{{PRIORITY_RANKING}}- 1 Stripe price check; 2 link crawl; 3 synthetic purchase test; 4 Notion public check; 5 refresh chain (manual).
Variables · Automation Scripts & Runbooks03 · Script Standards
{{03_Script_Standards}}- Scripts follow the estate's existing conventions. They are Node ES modules, dry run by default and write only with --commit. Secrets are read by canonical name, never printed. Exit codes signal success or failure for CI and the ops-audit.
{{LANGUAGE_CHOICE}}- Node.js ES modules (.mjs), as in packages/db/seed and packages/db/sync.
{{STRICT_MODE}}- ES modules run in strict mode; unhandled rejections fail the process.
{{ARGUMENT_PARSING}}- Flags such as --commit, --refresh-media, --fix-icons and --check-public; nothing destructive without a flag.
{{LOGGING_RULES}}- Log counts and slugs, never secret values; summarise planned changes on dry run.
{{EXIT_CODE_RULES}}- 0 on success; non-zero on any failed check or write.
{{LINT_REQUIREMENTS}}- CI runs the console typecheck, secret scan and env canonical-read check on every PR.
Variables · Automation Scripts & Runbooks04 · Safety and Idempotency Rules
{{04_Safety_and_Idempotency_Rules}}- Every write script is safe to run twice. Dry run is the default, preconditions are checked before any write, and targets are confirmed by environment. Fulfilment is idempotent by design, and the Notion build stores progress so it can resume.
{{PRECONDITION_CHECKS}}- Confirm DATABASE_URL target, required bucket and Stripe keys, and that the site is deployed before Stripe media refresh.
{{DRY_RUN_MODE}}- Default for seed and sync scripts; --commit required to write.
{{TARGET_CONFIRMATION}}- Print the target environment and counts before committing; production is read from Railway variables for www.
{{IDEMPOTENCY_APPROACH}}- Upserts keyed on slug; fulfil() idempotent per session; the estate seed never touches titles, prices, Stripe ids or the original 12.
{{CONCURRENCY_LOCKING}}- Proposed: a Postgres advisory lock per script name to prevent overlapping runs.
{{PARTIAL_FAILURE_HANDLING}}- Notion build resumes from offerings.metadata.notion; other scripts report the failed slug and exit non-zero.
Variables · Automation Scripts & Runbooks05 · Script Specification
{{05_Script_Specification}}- The example specification is the Stripe price check. Its purpose is to confirm every price is active, one-off, matches its amount and is its product's default. It takes read-only credentials, reads prices, queries Stripe and reports mismatches. It has no side effects, so rollback is not needed.
{{SCRIPT_PURPOSE}}- Verify every prices.stripe_price_id is active, one-time, equal to unit_amount and the product's default_price.
{{INPUTS_AND_FLAGS}}- DATABASE_URL and STRIPE_API_SECRET_KEY by canonical name; optional --json for machine output.
{{COMMAND_SEQUENCE}}- Read prices joined to offerings; fetch each Stripe price and product; compare; print mismatches; exit non-zero if any.
{{OUTPUTS_AND_SIDE_EFFECTS}}- A report of checked and mismatched prices; no writes.
{{REQUIRED_PERMISSIONS}}- Read-only database role; Stripe restricted key with read access to products and prices (Proposed).
{{ROLLBACK_APPROACH}}- Not applicable; read-only.
Variables · Automation Scripts & Runbooks06 · Runbook Template
{{06_Runbook_Template}}- Runbooks follow the estate format: when to use it, triage, fix, communicate and after. The template begins read-only until the cause is found. Escalation is always to the user for anything irreversible.
{{RUNBOOK_TRIGGER}}- A named symptom, for example "a product page shows no Buy now button".
{{IMPACT_ASSESSMENT}}- Which products, tenants or hosts are affected, and whether purchases are blocked.
{{ACCESS_PREREQUISITES}}- Railway CLI access, database URL by canonical name, Stripe and Notion keys as needed.
{{DIAGNOSTIC_STEPS}}- Check /api/health; check buyable() conditions (active status, active Stripe price, delivery row); check recent merges and deploy logs.
{{REMEDIATION_STEPS}}- Fix the missing row or price with the relevant seed script in dry run, then --commit; roll back a bad deploy per rollback.md.
{{ESCALATION_PATH}}- Anything irreversible, or a restore over production, goes to the user for explicit approval.
Variables · Automation Scripts & Runbooks07 · Failure and Recovery Design
{{07_Failure_and_Recovery_Design}}- Scripts are designed to fail safely and leave a known state. Transient API errors are retried with backoff; persistent ones stop the run with a report. Cleanup removes only what the run created, and alerts go to the ops-audit.
{{FAILURE_MODES}}- Notion rate limits; Stripe API errors; database connection loss; missing environment variable.
{{RETRY_POLICY}}- Proposed: up to 3 retries with exponential backoff for 429 and 5xx; none for 4xx.
{{CLEANUP_ACTIONS}}- Synthetic purchase test deletes its orders, order_items, entitlements and downloads rows.
{{FAILURE_ALERTS}}- Non-zero exit surfaces in the ops-audit report; Proposed: a notification to the founder.
{{KNOWN_STATE_GUARANTEE}}- Each write is keyed and resumable, so a rerun completes the remaining work without duplication.
Variables · Automation Scripts & Runbooks08 · Script Review Checklist
{{08_Script_Review_Checklist}}- Every new or changed script passes a review before it runs against production. The checklist covers standards, dry-run evidence, a staging run, secrets handling and an owner.
{{STANDARDS_CHECK}}- Dry-run default, flags documented, canonical env reads, exit codes set.
{{DRY_RUN_EVIDENCE}}- Dry-run output attached to the PR.
{{STAGING_TEST}}- Run against staging first where the target exists.
{{SECRETS_HANDLING_CHECK}}- No values printed or committed; secret scan passes.
{{OWNER_ASSIGNED}}- Founder Tommy Saunders unless delegated in the PR.
Variables · Automation Scripts & Runbooks09 · Scheduling and Triggering Plan
{{09_Scheduling_and_Triggering_Plan}}- Read-only checks run on a schedule; write scripts run on demand. The existing daily ops-audit runs as a LaunchAgent. Credentials come from Railway variables or the single local env file. Each run has a timeout and reports its result.
{{RUN_MODES}}- Scheduled (read-only checks); on demand (seed and sync writes); on PR (CI checks).
{{RUNNER_ENVIRONMENT}}- The operator's Mac via LaunchAgent for the ops-audit; GitHub Actions for CI; Proposed: move scheduled checks to CI cron.
{{CREDENTIAL_SOURCE}}- Railway variables and the 0600 .env.local, read by canonical name through @/lib/env.
{{TIMEOUTS}}- Proposed: 10 minutes for checks; the Notion build is resumable and may run longer.
{{RUN_NOTIFICATIONS}}- Ops-audit report on completion; Proposed: alert only on failure.
Variables · Automation Scripts & Runbooks10 · Automation Health Measures
{{10_Automation_Health_Measures}}- Automation health is tracked on success rate, duration, manual interventions, time saved and stale scripts. Targets are proposed and read from run logs.
{{SUCCESS_RATE}}- Target: 98% of scheduled runs succeed.
{{RUN_DURATION}}- Track per script; flag any run 50% longer than its median.
{{MANUAL_INTERVENTIONS}}- Target: under 2 per month.
{{TIME_SAVED}}- Proposed: estimate from manual effort times run frequency; no figure claimed yet.
{{STALE_SCRIPTS}}- Target: zero scripts referenced in docs that do not exist (PLAN found some).
Variables · Data Governance & Access01 · Data Landscape Questions
{{01_Data_Landscape_Questions}}- The platform runs several Postgres databases: the estate database, the PIO database in the io-gtm project, a Playbooks database, and one database per tenant. Data categories include catalogue and orders, tenant content and brand, and prospect and profile records. Buyers' emails and Stripe customer ids are personal data. The 2026-09-28 incident, where a shared variable pointed tenant database URLs at the estate database, shows why credentials must never be shared across services.
{{DATABASE_INVENTORY}}- Estate DB (Postgres-vacation-branson); PIO DB in the io-gtm project; Postgres-Playbooks; one Postgres per tenant.
{{DATA_CATEGORIES}}- Catalogue (offerings, prices, delivery); commerce (orders, entitlements, downloads); tenant content and brand; profiles and prospects; operational logs.
{{APPLICABLE_REGULATIONS}}- Proposed review: US state privacy laws for buyer data; PCI handled by Stripe, since card data never reaches the platform.
{{CURRENT_ACCESS}}- Founder and operator sessions via Railway; the console service; the www site service.
{{SHARED_CREDENTIALS}}- Shared Railway variables must never reference service or database variables; ops-audit fails CRITICAL on a spill.
Variables · Data Governance & Access02 · Data Classification Scheme
{{02_Data_Classification_Scheme}}- Four levels are proposed. Public data appears on the site; internal data is operational; confidential data includes tenant content and buyer details; restricted data is secrets and credentials. Each level has handling rules, and anything unlabelled is treated as confidential.
{{CLASSIFICATION_LEVELS}}- Public; Internal; Confidential; Restricted.
{{LEVEL_CRITERIA}}- Public: published by design. Internal: operational, no personal data. Confidential: tenant or buyer data. Restricted: secrets and credentials.
{{LEVEL_EXAMPLES}}- Public: product pages. Internal: seed progress metadata. Confidential: orders, tenant records. Restricted: Stripe and database keys.
{{HANDLING_REQUIREMENTS}}- Confidential: tenant-isolated databases, no copies in git. Restricted: Railway variables and .env.local only, never printed.
{{DEFAULT_LEVEL}}- Confidential.
Variables · Data Governance & Access03 · Data Ownership Register
{{03_Data_Ownership_Register}}- Each dataset has a business owner and a technical steward. At present both roles sit with the founder, which the register records honestly. Purposes are stated so retention can be set against them.
{{DATASETS}}- offerings, prices, delivery; orders, order_items, entitlements, downloads; tenant databases; profiles and prospects; registry tables.
{{BUSINESS_OWNERS}}- Founder Tommy Saunders for all datasets; each tenant's stakeholder for their own content.
{{TECHNICAL_STEWARDS}}- Founder Tommy Saunders.
{{DATASET_CLASSIFICATION}}- Catalogue: Public/Internal. Commerce: Confidential. Tenant DBs: Confidential. Secrets: Restricted.
{{PROCESSING_PURPOSE}}- Catalogue: sell and deliver. Commerce: fulfil and grant access. Tenant: run the tenant's console and site.
Variables · Data Governance & Access04 · Role and Permission Model
{{04_Role_and_Permission_Model}}- Roles are kept few and explicit. The master operator controls estate UI policy on Tenant IO; tenant users see only their console. Service accounts are scoped per service, and tenant databases are isolated from each other and from the estate.
{{ROLE_DEFINITIONS}}- Master operator; tenant stakeholder; tenant contributor; service account (console, www); buyer (token holder).
{{ROLE_PRIVILEGES}}- Master operator: all consoles and policy. Stakeholder: own console. Buyer: own entitlements via token only.
{{SERVICE_ACCOUNT_RULES}}- One database URL per service, set as a service variable; never on shared variables.
{{ISOLATION_RULES}}- Each tenant's TENANT_DB points only at its own database; ops-audit checks this daily.
{{LEAST_PRIVILEGE_POLICY}}- Proposed: read-only roles for checks and reports; write roles only for services that need them.
Variables · Data Governance & Access05 · Access Request and Review Process
{{05_Access_Request_and_Review_Process}}- Access is requested, approved by the founder, provisioned through Railway or the console, and reviewed quarterly. Revocation is prompt when a contractor finishes or a tenant leaves.
{{REQUEST_STEPS}}- Request states person, system, level and reason.
{{APPROVAL_RULES}}- Founder approves all Confidential and Restricted access.
{{PROVISIONING_STEPS}}- Create the console user or Railway member with the minimum role; record it.
{{REVIEW_CADENCE}}- Proposed: quarterly review of every account and key.
{{REVOCATION_TIMELINE}}- Proposed: within one business day of end of need.
Variables · Data Governance & Access06 · Secrets and Credential Standards
{{06_Secrets_and_Credential_Standards}}- Secrets follow the estate rules. They live in Railway variables and one local 0600 env file, and code reads them by canonical name. They are never committed, never placed behind NEXT_PUBLIC_ and never printed. Staging shares production keys, so every rotation touches both.
{{STORAGE_RULES}}- Railway variables (sealed) and ~/.env.local at 0600; key names only in .env.example.
{{ROTATION_POLICY}}- Per rotate-secret.md: find consumers, issue new, set staging, set production, revoke old. Proposed: annual scheduled rotation.
{{ENVIRONMENT_SEPARATION}}- Staging shares production keys (ADR 0008), so staging actions can have real effects and are treated as production.
{{EXPOSURE_RESPONSE}}- Rotate immediately with no overlap; check git history by prefix; record per incident.md.
{{DISTRIBUTION_RULES}}- Never paste values in chat, docs or PRs; report key names only.
Variables · Data Governance & Access07 · Retention and Deletion Schedule
{{07_Retention_and_Deletion_Schedule}}- Retention is set per dataset against its purpose. Orders and entitlements are kept for as long as the buyer's access lasts and for tax records. Download logs are kept shorter. Backups follow the restore runbook, and nothing is bulk-deleted without explicit approval.
{{RETENTION_PERIODS}}- Proposed: orders 7 years; entitlements while active; downloads logs 2 years; tenant data for the life of the engagement plus 90 days.
{{RETENTION_BASIS}}- Tax records; buyer access rights; tenant contract.
{{DELETION_METHOD}}- Row-level deletes by script with dry run and backup first.
{{BACKUP_HANDLING}}- pg_dump -Fc before bulk catalogue writes; off-machine copies in the bucket archive prefix with sha256 manifest.
{{LEGAL_HOLD_RULES}}- Proposed: suspend deletion for any dataset under a dispute or request.
Variables · Data Governance & Access08 · Audit Logging Requirements
{{08_Audit_Logging_Requirements}}- Logging covers access, data changes and policy changes. Every UI policy change is logged and undoable (ADR 0010), and every access token use writes a downloads row. Logs are stored in Postgres and Railway, and alerts cover isolation breaches.
{{LOGGED_EVENTS}}- Token uses (downloads); UI policy changes; migrations; deploys; ops-audit results.
{{LOG_STORAGE}}- Postgres tables and Railway deploy logs.
{{LOG_RETENTION}}- Proposed: 2 years for access logs; Railway defaults for deploy logs.
{{REVIEW_OWNERS}}- Founder Tommy Saunders.
{{ALERT_CONDITIONS}}- Tenant DB pointing at another database; unusual download volume on one token (Proposed); failed migrations.
Variables · Data Governance & Access09 · Governance Compliance Assessment
{{09_Governance_Compliance_Assessment}}- The first assessment rates each database against the standards above. PLAN.md already records known gaps, including backups not yet enabled, non-idempotent migrations and duplicate registry definitions. Each gap has a severity and an owner.
{{DATABASES_ASSESSED}}- Estate DB; PIO DB; Playbooks DB; tenant DBs.
{{COMPLIANCE_RATINGS}}- Proposed per database: meets, partial, gap, against isolation, backup, access and logging.
{{IDENTIFIED_GAPS}}- PITR and scheduled backups not on (PLAN phase 3); estate migrations 001-009 not idempotent; no migration ledger at time of PLAN.
{{GAP_SEVERITY}}- Backups: high. Idempotent migrations: medium. Registry duplication: medium.
{{REMEDIATION_OWNERS}}- Founder Tommy Saunders, tracked in PLAN phases.
Variables · Data Governance & Access10 · Governance Health Metrics
{{10_Governance_Health_Metrics}}- Governance health is tracked on access reviews, revocation speed, rotations and classification coverage. Targets are proposed.
{{ACCESS_REVIEW_RATE}}- Target: 100% of accounts reviewed each quarter.
{{REVOCATION_TIME}}- Target: within one business day.
{{OVERDUE_ROTATIONS}}- Target: zero.
{{UNCLASSIFIED_COLUMNS}}- Target: zero columns in commerce and tenant tables without a classification.
{{METRIC_TARGETS}}- Reported monthly in the ops-audit summary.
Variables · Data Governance & Access11 · Governance Policy Statement
{{11_Governance_Policy_Statement}}- Intelligent Operations classifies the data it holds, grants the least access needed, keeps data only as long as its purpose requires and logs who touched what. Tenant data stays in the tenant's own database. Card data never reaches the platform.
{{CLASSIFICATION_COMMITMENT}}- Every dataset carries a classification; unlabelled means Confidential.
{{ACCESS_COMMITMENT}}- Least privilege, founder-approved, reviewed quarterly; tenant databases isolated.
{{RETENTION_COMMITMENT}}- Kept only as long as its purpose requires, and deleted with a backup and approval.
{{AUDIT_COMMITMENT}}- Access, policy changes and token use are logged and reviewed.
Variables · Release Notes & Changelog01 · Release Content Intake
{{01_Release_Content_Intake}}- Release notes are drawn from merged PRs, which already describe each change. For the Agent Libraries, the shipped changes are recorded in PRs 147, 157, 160 and 170. Affected users are buyers, tenants or operators. Rollout runs through staging then main.
{{CHANGES_SHIPPED}}- Example: Agent Libraries storefront with Stripe checkout and Notion delivery (PRs 147, 157, 160, 170).
{{TICKET_LINKS}}- GitHub PR numbers in the monorepo, for example #147 and #170.
{{AFFECTED_USERS}}- Buyers on intelligentoperations.ai; tenants on their consoles; the operator.
{{ROLLOUT_AND_FLAGS}}- Feature branch, PR to staging, verify, release PR to main; visibility changes via estate UI policy.
Variables · Release Notes & Changelog02 · Change Classification
{{02_Change_Classification}}- Every entry is classified into one of six categories so readers can scan. Breaking and security changes are always called out first.
{{NEW_CATEGORY}}- New: a capability that did not exist, such as the Agent Libraries store.
{{IMPROVED_CATEGORY}}- Improved: an existing capability made better, such as product-page previews.
{{FIXED_CATEGORY}}- Fixed: a defect corrected, such as broken links rewritten by links.ts.
{{DEPRECATED_CATEGORY}}- Deprecated: a capability scheduled for removal, such as per-tenant admin apps.
{{BREAKING_CATEGORY}}- Breaking: a change that requires action from users, such as a moved URL without a redirect.
{{SECURITY_CATEGORY}}- Security: a change to access, secrets or data handling.
Variables · Release Notes & Changelog03 · Audience Impact Matrix
{{03_Audience_Impact_Matrix}}- Each change is mapped to its audiences. End users are buyers and tenant stakeholders; admins are operators; developers are anyone calling the platform's MCP tools or APIs. Action required is stated plainly.
{{END_USER_IMPACT}}- Buyers: can now buy and receive libraries instantly. Tenants: admin pages now in their one console.
{{ADMIN_IMPACT}}- Operators: UI visibility set once on Tenant IO for all consoles (ADR 0010).
{{DEVELOPER_IMPACT}}- Old .html paths redirect to routes; no API contract change.
{{ACTION_REQUIRED}}- None for buyers; tenants sign in to the console instead of the retired admin app.
Variables · Release Notes & Changelog04 · Release Summary
{{04_Release_Summary}}- The summary gives the headline change, who it helps and any action needed, in three sentences. It is the first thing a reader sees.
{{HEADLINE_CHANGE}}- The Agent Libraries store is live: 147 libraries you can buy and duplicate into Notion instantly.
{{WHO_IT_HELPS}}- Operators and marketers who want a method for one area of work today.
{{ACTION_REQUIRED_SUMMARY}}- No action needed; browse /libraries.
Variables · Release Notes & Changelog05 · Changelog Entries
{{05_Changelog_Entries}}- Entries are one line each, in past tense, with a benefit and a docs link, dated. The docs link points to the runbook or ADR that explains the change.
{{ENTRY_TEXT}}- Added the Agent Libraries store with Stripe checkout and Notion delivery.
{{BENEFIT_STATEMENT}}- Buy a library and open it in your workspace in minutes.
{{DOCS_LINK}}- docs/runbooks/agent-libraries.md
{{VERSION_OR_DATE}}- 2026-09-28
Variables · Release Notes & Changelog06 · Feature Announcement
{{06_Feature_Announcement}}- Feature announcements expand one entry into a short post. They name the problem, show how to start and include one visual.
{{ANNOUNCEMENT_HEADLINE}}- Every Agent Library now shows where it sits on the operating loop.
{{PROBLEM_SOLVED}}- Buyers could not see how one library connected to the rest of their work.
{{HOW_TO_START}}- Open any product page and scroll to the loop and workflow diagrams.
{{ANNOUNCEMENT_VISUAL}}- The eight-stage operating loop with the library's stage highlighted.
Variables · Release Notes & Changelog07 · Deprecation Notice
{{07_Deprecation_Notice}}- Deprecation notices give what is changing, when, how to move and who to contact. The model is the retirement of per-tenant admin apps in favour of the tenant console.
{{WHAT_IS_CHANGING}}- Per-tenant admin apps are replaced by admin pages inside each tenant's one console.
{{REMOVAL_TIMELINE}}- Admin apps removed 2026-09-23; their services deleted 2026-09-24.
{{MIGRATION_STEPS}}- Sign in to your tenant console; your admin pages are under the same names.
{{SUPPORT_CONTACT}}- [email on file]
Variables · Release Notes & Changelog08 · Changelog Style Rules
{{08_Changelog_Style_Rules}}- Style follows the estate's writing: plain, past tense, active voice, short. Features use their product names. Internal jargon is removed.
{{TENSE_AND_VOICE}}- Past tense, active voice: "Added", "Fixed", "Removed".
{{ENTRY_LENGTH}}- One sentence, under 25 words.
{{FEATURE_NAMING}}- Use public names: Agent Libraries, tenant console, Variables library.
{{JARGON_EXCLUSIONS}}- No internal table names, env variable names or service ids in public notes.
Variables · Release Notes & Changelog09 · Publishing Workflow
{{09_Publishing_Workflow}}- Notes are drafted with the release PR and published after production is verified. The founder drafts and approves; publication goes to the site and, for major changes, email and LinkedIn.
{{DRAFT_OWNER}}- Founder Tommy Saunders, drafted from the release PR description.
{{REVIEWERS}}- Founder; Proposed: an agent check against the PR diff for accuracy.
{{PUBLISH_CHANNELS}}- Proposed: a changelog page on the site; email for major releases; LinkedIn for features.
{{PUBLISH_TIMING}}- After production verification of the release PR.
Variables · Release Notes & Changelog10 · Release Communication Metrics
{{10_Release_Communication_Metrics}}- Release communication is measured on reach, engagement, adoption and support load. Targets are proposed.
{{NOTE_VIEWS}}- Proposed: changelog page views per release.
{{ANNOUNCEMENT_ENGAGEMENT}}- Proposed: clicks from announcement to the feature.
{{FEATURE_ADOPTION}}- Proposed: share of active users using the feature within 30 days.
{{SUPPORT_CONTACTS_AFTER_RELEASE}}- Target: no increase in support contacts in the week after release.
Variables · Release Notes & Changelog11 · Release Retrospective
{{11_Release_Retrospective}}- Each significant release closes with a short retrospective recorded in the lessons file. It notes what worked, what was missed, where users were confused and what process changes follow.
{{WHAT_WORKED}}- Example: a production crawl before release confirmed 226 pages with 0 broken links.
{{WHAT_MISSED}}- Example: 72 area labels had no matching product and appeared without a card.
{{CUSTOMER_CONFUSION}}- Proposed: log buyer questions in the first two weeks after release.
{{PROCESS_CHANGES}}- Proposed: add the crawl and synthetic purchase to the release checklist.
Variables · A/B Testing Framework01 · Testing Readiness Questions
{{01_Testing_Readiness_Questions}}- The storefront has 147 products at $14 and Stripe Checkout, but traffic and conversion counts are not yet recorded in a testing-ready form. Orders and checkout sessions exist in the estate database; page views need analytics. The founder has sole authority to change the site, and no test has been run. Readiness depends on confirming page-view tracking first.
{{WEEKLY_VISITORS}}- Not on record. Proposed: enable site analytics and read 8 weeks before planning.
{{WEEKLY_CONVERSIONS}}- Orders are countable from the orders table; checkout starts need an event. Weekly counts to be recorded.
{{TRACKING_SETUP}}- Orders, order_items and entitlements rows exist; page-view and Buy now click tracking are not confirmed.
{{CHANGE_AUTHORITY}}- The founder, through a pull request and the staging-to-main release path.
{{PAST_TEST_HISTORY}}- None; the storefront launched 2026-09-28 with no experiments run.
{{TRAFFIC_DISTORTIONS}}- Launch-week spikes; founder and test purchases; promotion codes; bot crawls.
Variables · A/B Testing Framework02 · Conversion Baseline Assessment
{{02_Conversion_Baseline_Assessment}}- The path runs from the /libraries index or an area page to a product page, Buy now, Stripe Checkout and the success page. Baseline rates are not recorded and the store is days old, so the baseline period begins once tracking is on. Device and source splits are unknown and must be measured.
{{KEY_CONVERSION_STEPS}}- Index or area view; product page view; Buy now click; checkout session created; payment; access opened.
{{BASELINE_RATES}}- Not on record. Target benchmark for product-page conversion: 2 percent, to be checked against data.
{{DEVICE_SPLIT}}- Not on record; measure mobile versus desktop from analytics.
{{SOURCE_SPLIT}}- Not on record; expected: founder LinkedIn, email, search, direct.
{{BASELINE_PERIOD}}- Proposed: four weeks after launch-week traffic settles.
{{WEEKLY_VARIATION}}- Expected to follow email sends and LinkedIn posts; measure across the baseline.
Variables · A/B Testing Framework03 · Hypothesis Backlog
{{03_Hypothesis_Backlog}}- The hypothesis backlog comes from decisions in the storefront and checkout work: lead with the method or the price, show contents before the button, and place a refund line near Buy now. Each is stated with a change and a metric. Evidence is reasoning and product design so far, not data.
{{HYPOTHESIS_STATEMENTS}}- A method-first lead on /libraries beats a price-first lead; showing the column list above the fold raises Buy now clicks; a refund line under the button raises checkout starts; a stage bundle beats singles on order value.
{{OBSERVED_PROBLEMS}}- None measured yet. Possible: buyers cannot see contents before paying; price is prominent but method is not.
{{SUPPORTING_EVIDENCE}}- Product page design and buyer-job analysis; no conversion evidence yet.
{{PAGE_OR_EMAIL_TARGET}}- /libraries index lead; product page above the fold; area pages' products rail.
Variables · A/B Testing Framework04 · Test Prioritisation Framework
{{04_Test_Prioritisation_Framework}}- Tests are scored on impact, confidence and effort from 1 to 5. The product page above the fold ranks first because every purchase passes through it. Bundle tests are deferred until stage bundles exist and traffic supports them.
{{IMPACT_SCORES}}- Contents above the fold 4; method-first lead 3; refund line 3; stage bundle 4.
{{CONFIDENCE_SCORES}}- Contents above the fold 3; method-first lead 3; refund line 2; stage bundle 2.
{{EFFORT_SCORES}}- Contents above the fold 2; method-first lead 1; refund line 1; stage bundle 4.
{{PRIORITY_RANKING}}- 1 Contents above the fold; 2 Method-first lead; 3 Refund line; 4 Stage bundle.
{{DEFERRED_TESTS}}- Stage bundle versus singles; promotion code placement.
{{DEFERRAL_REASONS}}- Bundles are not built yet; promotion tests need a live promotion and enough traffic.
Variables · A/B Testing Framework05 · Experiment Design Brief
{{05_Experiment_Design_Brief}}- The first experiment moves the column list above the fold on product pages. Control keeps the current layout; the variant shows the list of column prompts next to Buy now. The primary metric is Buy now clicks per product-page view, and the decision rule is set before launch.
{{TEST_HYPOTHESIS}}- If the column list appears above the fold next to Buy now, then Buy now clicks per page view will rise, because buyers can see what they receive.
{{CONTROL_DESCRIPTION}}- Current product page with the contents list below the fold.
{{VARIANT_DESCRIPTION}}- Product page with the column list in the first screen beside the price and Buy now button.
{{AUDIENCE_SPLIT}}- 50/50 of product-page visitors, assigned per visitor and stable across visits.
{{PRIMARY_METRIC}}- Buy now clicks divided by unique product-page views.
{{GUARDRAIL_METRICS}}- Completed orders per checkout start; refund requests; page speed.
{{DECISION_RULE}}- Adopt the variant only if the primary metric improves at the pre-set significance level and completed orders per checkout start do not fall.
Variables · A/B Testing Framework06 · Sample Size And Duration Plan
{{06_Sample_Size_And_Duration_Plan}}- Sample size depends on the baseline product-page conversion rate, which is not yet known. The plan uses a two-proportion calculation with a 95 percent confidence level and a minimum detectable effect set from the baseline. With 147 products, tests run on the pooled set of product pages, which raises traffic per test.
{{BASELINE_RATE}}- Not on record; benchmark target 2 percent until measured.
{{MINIMUM_DETECTABLE_EFFECT}}- Proposed: set from the baseline, expecting a relative lift in the range of 20 to 30 percent to be detectable.
{{CONFIDENCE_LEVEL}}- 95 percent, two-sided.
{{REQUIRED_SAMPLE}}- To be calculated once the baseline is known; pooled across all product pages.
{{RUN_DURATION_WEEKS}}- Proposed: 4 weeks minimum, matching the four-week window used across the estate.
{{FEASIBILITY_NOTE}}- If pooled traffic cannot reach the sample in 8 weeks, test on the /libraries index instead or wait for more traffic.
Variables · A/B Testing Framework07 · Variant Copy And Layout Spec
{{07_Variant_Copy_And_Layout_Spec}}- The variant changes the product page layout only: the column list moves into the first screen next to the price. The headline and copy stay the same, and the variant uses the library's own column names. The button reads Buy now in both versions.
{{VARIANT_HEADLINE}}- Brand Positioning - Agent Library (unchanged product title).
{{VARIANT_BODY_COPY}}- Twelve column prompts take you from market category to category disruption strategy, each output feeding the next. (Unchanged; the column list is added beside it.)
{{VARIANT_CTA}}- Buy now
{{LAYOUT_CHANGE}}- Column list moved from below the preview to the right of the price block on desktop and directly above the button on mobile.
{{UNCHANGED_ELEMENTS}}- Price of $14, title, images, FAQ, Stripe Checkout flow and footer.
Variables · A/B Testing Framework08 · Test Launch Checklist
{{08_Test_Launch_Checklist}}- Before launch, assignment, events, device rendering, speed parity and exclusion of founder and test purchases are each verified. A test purchase is made in each version to confirm the path through Stripe and fulfilment. The test does not start until every check passes.
{{ASSIGNMENT_CHECK}}- Confirm 50/50 assignment and that a returning visitor sees the same version.
{{EVENT_TRACKING_CHECK}}- Confirm product-page view and Buy now click events fire in both versions.
{{DEVICE_RENDER_CHECK}}- Check both versions on phone, tablet and desktop widths.
{{SPEED_PARITY_CHECK}}- Confirm both versions load within the same time range.
{{INTERNAL_TRAFFIC_EXCLUSION}}- Exclude founder devices and test Stripe sessions from analytics and results.
Variables · A/B Testing Framework09 · Mid-Test Monitoring Rules
{{09_Mid_Test_Monitoring_Rules}}- Monitoring is a weekly check of events, sample ratio and the checkout path, with no decisions before the planned end date. Emergency stops cover a broken checkout, failed fulfilment or a large guardrail drop. The peeking policy allows fault checks only.
{{MONITORING_SCHEDULE}}- Weekly: events firing, sample ratio, completed orders and fulfilment.
{{EMERGENCY_STOP_TRIGGERS}}- Checkout errors; fulfilment failures; completed orders per checkout start dropping beyond a set margin; tracking outage.
{{PEEKING_POLICY}}- No decisions on results before the end date; fault checks are allowed.
{{SAMPLE_RATIO_CHECK}}- Flag any departure from 50/50 beyond a chi-square threshold and investigate before continuing.
Variables · A/B Testing Framework10 · Result Analysis Report
{{10_Result_Analysis_Report}}- No test has run yet, so this is the report template. When a test ends, the report states the primary result with a confidence interval, guardrail outcomes, segment differences and threats to validity before recording a decision. It is written in plain language and stored in the testing log.
{{PRIMARY_METRIC_RESULT}}- No test has run yet; report control and variant rates and the relative difference.
{{CONFIDENCE_INTERVAL}}- Report the interval for the difference, not only the point estimate.
{{GUARDRAIL_RESULTS}}- Report completed orders per checkout start, refunds and page speed for both versions.
{{SEGMENT_DIFFERENCES}}- Compare mobile with desktop and new with returning visitors, marked as exploratory.
{{VALIDITY_THREATS}}- Launch-week traffic; promotion codes; founder purchases; product mix differences between versions.
{{TEST_DECISION}}- Adopt, keep control or rerun, with the reason stated.
Variables · A/B Testing Framework11 · Rollout And Learning Log
{{11_Rollout_And_Learning_Log}}- A winning variant rolls out to all product pages through a pull request and the normal release path, followed by a two-week check. Each test ends with a learning statement and follow-up hypotheses kept in the testing log. The log feeds the monthly storefront report.
{{ROLLOUT_STEPS}}- Open a PR with the winning layout; merge to staging; verify; release to main; confirm on production.
{{POST_ROLLOUT_CHECK}}- Compare Buy now clicks and orders in the two weeks after rollout with the test result.
{{LEARNING_STATEMENT}}- One sentence on what buyers responded to, recorded after each test.
{{FOLLOW_UP_HYPOTHESES}}- Drawn from the result, such as testing the preview images or the refund line next.
{{LOG_LOCATION}}- The testing library's records in the IO workspace, summarised in the storefront report.
Variables · A/B Testing Framework12 · Testing Programme Cadence
{{12_Testing_Programme_Cadence}}- The programme is sized to a small team: a few tests per quarter and one live test per page type. The founder owns it and reviews monthly. Overlap rules keep promotion tests and layout tests from running on the same pages at once.
{{TESTS_PER_QUARTER}}- Proposed: three storefront tests.
{{CONCURRENT_TEST_LIMIT}}- One live test per page type.
{{PROGRAMME_OWNER}}- Founder, Tommy Saunders.
{{REVIEW_MEETING}}- Monthly, with the storefront report.
{{AUDIENCE_OVERLAP_RULES}}- No layout test and promotion test on the same pages at the same time.
Screens were captured from Intelligent Operations’s own site and tenant console on 2026-09-30, with personal data blurred. Variable values are the structured outputs of its prompt libraries, marked Provisional in its console until the client confirms them.