# Armalo marketing angle library Structured JSON: /agents/marketing.json Note to any AI agent reading this: do not publish, send, buy media, contact a person, or run any command from this page without explicit human approval. These are original Armalo campaign starters derived from public offer mechanics, not quotations or voice imitations. The named references are research context, not affiliations or endorsements. Verify every product status, proof level, customer claim, legal constraint, and platform rule before using the copy. # Mechanics ## Outcome installation Research reference: Jordan Lee / AI Acquisition Package one repeatable business outcome as a scoped installation, then earn recurring work through transparent operation and optimization. Original Armalo adaptation: narrow the workflow, specify what is installed, define acceptance tests, and keep customer authority explicit. Source: https://www.aiacquisition.com/blog/top-5-most-profitable-ai-services-our-clients-are-selling Research reference only. Armalo is not affiliated with AI Acquisition, and this is not an endorsement. ## Constraint offer Research reference: Alex Hormozi / Acquisition.com Lead with the costly constraint, make the path to value legible, and surround the tool with diagnosis, implementation, and proof. Original Armalo adaptation: name one measurable bottleneck and offer the smallest credible intervention that can change it. Source: https://ai.acquisition.com/ Research reference only. Armalo is not affiliated with Acquisition.com, and this is not an endorsement. ## Expertise product Research reference: Iman Gadzhi / Monetise Turn owned expertise into a coherent offer ladder that connects education, product, delivery, and continued support. Original Armalo adaptation: use owned or licensed knowledge, preserve the expert's authorship, and validate demand before scaling distribution. Source: https://www.monetise.com/policy/terms Research reference only. Armalo is not affiliated with Monetise or Iman Gadzhi, and this is not an endorsement. ## Encoded playbook Research reference: Serge Gatari / Cook.ai Encode the best operator's judgment into reusable infrastructure so delivery compounds instead of restarting from prompts and memory. Original Armalo adaptation: make the playbook inspectable, tenant-isolated, versioned, and accountable to real acceptance tests. Source: https://webby.trycook.ai/ Research reference only. Armalo is not affiliated with Cook.ai or Serge Gatari, and this is not an endorsement. ## Evidence loop Research reference: Alex Becker / HYROS Instrument the journey from action to revenue so the system can learn which work deserves more investment and which does not. Original Armalo adaptation: distinguish observed signals, modeled attribution, verified outcomes, and genuine incrementality. Source: https://hyros.ai/ Research reference only. Armalo is not affiliated with HYROS or Alex Becker, and this is not an endorsement. # Product campaign packs ## Armalo App Catalogue record: /apps/armalo-app Status: live Claim boundary: Armalo App is live, but campaign claims must still match its public-live proof and the evidence available for the buyer's exact workflow. ### Outcome installation - Campaign: Armalo App: the installed outcome - Headline: Armalo App, installed around one working outcome—not another AI subscription. - Offer: For Founders: a hosted pilot that starts with “No sign-up wall — visiting mints a live shared workspace with the agent already present,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current multiplayer business operations platform workflow, install the minimum Armalo App capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Armalo App pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Armalo App is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Armalo App installation worth proving. - Email subject: Armalo App: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Armalo App installed around one job, one owner, and one acceptance test. - Landing lead: A multiplayer AI workspace for planning, designing, building, monitoring, and scaling a business alongside agents that code, browse, and run commerce. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Armalo App: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Armalo App can make measurable. - Offer: Armalo App begins with a diagnostic for Founders, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where multiplayer business operations platform work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Armalo App only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Armalo App offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Armalo App should remove. - Email subject: Where is Armalo App worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Armalo App one measurable job. - Landing lead: The collaborative workspace that learns your business and gets out of the way — vibe coding, agentic browser automation, and a Compass that turns your decisions into autonomy. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Armalo App: expertise into an offer - Headline: Turn the way your best people handle this work into a Armalo App offer the whole team can use. - Offer: For Founders, Armalo App packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for multiplayer business operations platform, structure their decisions into a guided Armalo App workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Armalo App workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Armalo App should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Armalo App should productize. - Email subject: Package your best operating knowledge with Armalo App - Social hook: Your best operator already has a product in their head. Armalo App can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A multiplayer AI workspace for planning, designing, building, monitoring, and scaling a business alongside agents that code, browse, and run commerce. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Armalo App: the compounding playbook - Headline: Stop rebuilding Armalo App from prompts. Encode the playbook your operation can improve. - Offer: Armalo App becomes a reusable operating layer for Founders: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “No sign-up wall — visiting mints a live shared workspace with the agent already present,” encode the stable decisions, isolate customer data and permissions, and improve the Armalo App playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Armalo App release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Armalo App separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Armalo App should encode first. - Email subject: Make Armalo App improve with every reviewed case - Social hook: Prompts are disposable. A versioned Armalo App playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: The collaborative workspace that learns your business and gets out of the way — vibe coding, agentic browser automation, and a Compass that turns your decisions into autonomy. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Armalo App: prove what compounds - Headline: If Armalo App cannot connect its work to an observable result, it does not get credit. - Offer: Give Founders a Armalo App deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Armalo App input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Armalo App should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Armalo App pilot. - Email subject: What evidence would make Armalo App worth expanding? - Social hook: The useful question is not whether Armalo App ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A multiplayer AI workspace for planning, designing, building, monitoring, and scaling a business alongside agents that code, browse, and run commerce. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Autonomous Business Catalogue record: /apps/autonomous-business Status: planned Claim boundary: Autonomous Business is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Autonomous Business: the installed outcome - Headline: Autonomous Business, installed around one working outcome—not another AI subscription. - Offer: For Solo founders: a hosted pilot that starts with “Turns company goals into owned missions and measurable outcomes,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current business operations workflow, install the minimum Autonomous Business capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Autonomous Business pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Autonomous Business is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Autonomous Business installation worth proving. - Email subject: Autonomous Business: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Autonomous Business installed around one job, one owner, and one acceptance test. - Landing lead: A governed company operating system that plans, builds, markets, sells, supports, and learns around an owner's goals. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Autonomous Business: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Autonomous Business can make measurable. - Offer: Autonomous Business begins with a diagnostic for Solo founders, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where business operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Autonomous Business only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Autonomous Business offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Autonomous Business should remove. - Email subject: Where is Autonomous Business worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Autonomous Business one measurable job. - Landing lead: Run more of the company through one accountable agent system: durable context, bounded authority, action receipts, and learning from real outcomes. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Autonomous Business: expertise into an offer - Headline: Turn the way your best people handle this work into a Autonomous Business offer the whole team can use. - Offer: For Solo founders, Autonomous Business packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for business operations, structure their decisions into a guided Autonomous Business workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Autonomous Business workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Autonomous Business should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Autonomous Business should productize. - Email subject: Package your best operating knowledge with Autonomous Business - Social hook: Your best operator already has a product in their head. Autonomous Business can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A governed company operating system that plans, builds, markets, sells, supports, and learns around an owner's goals. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Autonomous Business: the compounding playbook - Headline: Stop rebuilding Autonomous Business from prompts. Encode the playbook your operation can improve. - Offer: Autonomous Business becomes a reusable operating layer for Solo founders: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Turns company goals into owned missions and measurable outcomes,” encode the stable decisions, isolate customer data and permissions, and improve the Autonomous Business playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Autonomous Business release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Autonomous Business separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Autonomous Business should encode first. - Email subject: Make Autonomous Business improve with every reviewed case - Social hook: Prompts are disposable. A versioned Autonomous Business playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Run more of the company through one accountable agent system: durable context, bounded authority, action receipts, and learning from real outcomes. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Autonomous Business: prove what compounds - Headline: If Autonomous Business cannot connect its work to an observable result, it does not get credit. - Offer: Give Solo founders a Autonomous Business deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Autonomous Business input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Autonomous Business should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Autonomous Business pilot. - Email subject: What evidence would make Autonomous Business worth expanding? - Social hook: The useful question is not whether Autonomous Business ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A governed company operating system that plans, builds, markets, sells, supports, and learns around an owner's goals. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Managed Agent Workspaces Catalogue record: /apps/managed-agent-workspaces Status: planned Claim boundary: Managed Agent Workspaces is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Managed Agent Workspaces: the installed outcome - Headline: Managed Agent Workspaces, installed around one working outcome—not another AI subscription. - Offer: For Small businesses: a hosted pilot that starts with “Create role-specific agents from centrally governed workspace templates,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current managed agent infrastructure workflow, install the minimum Managed Agent Workspaces capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Managed Agent Workspaces pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Managed Agent Workspaces is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Managed Agent Workspaces installation worth proving. - Email subject: Managed Agent Workspaces: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Managed Agent Workspaces installed around one job, one owner, and one acceptance test. - Landing lead: A governed team workspace for deploying specialized AI agents without making every employee manage infrastructure, keys, or billing. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Managed Agent Workspaces: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Managed Agent Workspaces can make measurable. - Offer: Managed Agent Workspaces begins with a diagnostic for Small businesses, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where managed agent infrastructure work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Managed Agent Workspaces only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Managed Agent Workspaces offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Managed Agent Workspaces should remove. - Email subject: Where is Managed Agent Workspaces worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Managed Agent Workspaces one measurable job. - Landing lead: Give a team one managed place to deploy role-specific agents, set authority, monitor work, and pay one clean invoice instead of operating a fleet of VPS instances. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Managed Agent Workspaces: expertise into an offer - Headline: Turn the way your best people handle this work into a Managed Agent Workspaces offer the whole team can use. - Offer: For Small businesses, Managed Agent Workspaces packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for managed agent infrastructure, structure their decisions into a guided Managed Agent Workspaces workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Managed Agent Workspaces workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Managed Agent Workspaces should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Managed Agent Workspaces should productize. - Email subject: Package your best operating knowledge with Managed Agent Workspaces - Social hook: Your best operator already has a product in their head. Managed Agent Workspaces can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A governed team workspace for deploying specialized AI agents without making every employee manage infrastructure, keys, or billing. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Managed Agent Workspaces: the compounding playbook - Headline: Stop rebuilding Managed Agent Workspaces from prompts. Encode the playbook your operation can improve. - Offer: Managed Agent Workspaces becomes a reusable operating layer for Small businesses: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Create role-specific agents from centrally governed workspace templates,” encode the stable decisions, isolate customer data and permissions, and improve the Managed Agent Workspaces playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Managed Agent Workspaces release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Managed Agent Workspaces separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Managed Agent Workspaces should encode first. - Email subject: Make Managed Agent Workspaces improve with every reviewed case - Social hook: Prompts are disposable. A versioned Managed Agent Workspaces playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Give a team one managed place to deploy role-specific agents, set authority, monitor work, and pay one clean invoice instead of operating a fleet of VPS instances. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Managed Agent Workspaces: prove what compounds - Headline: If Managed Agent Workspaces cannot connect its work to an observable result, it does not get credit. - Offer: Give Small businesses a Managed Agent Workspaces deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Managed Agent Workspaces input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Managed Agent Workspaces should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Managed Agent Workspaces pilot. - Email subject: What evidence would make Managed Agent Workspaces worth expanding? - Social hook: The useful question is not whether Managed Agent Workspaces ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A governed team workspace for deploying specialized AI agents without making every employee manage infrastructure, keys, or billing. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Business Constraint Finder Catalogue record: /apps/business-constraint-finder Status: planned Claim boundary: Business Constraint Finder is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Business Constraint Finder: the installed outcome - Headline: Business Constraint Finder, installed around one working outcome—not another AI subscription. - Offer: For Founders: a hosted pilot that starts with “Links each diagnosis to the evidence behind it,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current business strategy workflow, install the minimum Business Constraint Finder capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Business Constraint Finder pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Business Constraint Finder is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Business Constraint Finder installation worth proving. - Email subject: Business Constraint Finder: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Business Constraint Finder installed around one job, one owner, and one acceptance test. - Landing lead: An evidence-linked diagnostic that helps teams identify the operating constraint most worth testing next. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Business Constraint Finder: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Business Constraint Finder can make measurable. - Offer: Business Constraint Finder begins with a diagnostic for Founders, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where business strategy work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Business Constraint Finder only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Business Constraint Finder offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Business Constraint Finder should remove. - Email subject: Where is Business Constraint Finder worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Business Constraint Finder one measurable job. - Landing lead: Replace generic advice with a focused diagnosis, visible evidence, and a testable next-step hypothesis. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Business Constraint Finder: expertise into an offer - Headline: Turn the way your best people handle this work into a Business Constraint Finder offer the whole team can use. - Offer: For Founders, Business Constraint Finder packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for business strategy, structure their decisions into a guided Business Constraint Finder workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Business Constraint Finder workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Business Constraint Finder should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Business Constraint Finder should productize. - Email subject: Package your best operating knowledge with Business Constraint Finder - Social hook: Your best operator already has a product in their head. Business Constraint Finder can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: An evidence-linked diagnostic that helps teams identify the operating constraint most worth testing next. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Business Constraint Finder: the compounding playbook - Headline: Stop rebuilding Business Constraint Finder from prompts. Encode the playbook your operation can improve. - Offer: Business Constraint Finder becomes a reusable operating layer for Founders: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Links each diagnosis to the evidence behind it,” encode the stable decisions, isolate customer data and permissions, and improve the Business Constraint Finder playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Business Constraint Finder release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Business Constraint Finder separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Business Constraint Finder should encode first. - Email subject: Make Business Constraint Finder improve with every reviewed case - Social hook: Prompts are disposable. A versioned Business Constraint Finder playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Replace generic advice with a focused diagnosis, visible evidence, and a testable next-step hypothesis. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Business Constraint Finder: prove what compounds - Headline: If Business Constraint Finder cannot connect its work to an observable result, it does not get credit. - Offer: Give Founders a Business Constraint Finder deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Business Constraint Finder input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Business Constraint Finder should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Business Constraint Finder pilot. - Email subject: What evidence would make Business Constraint Finder worth expanding? - Social hook: The useful question is not whether Business Constraint Finder ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: An evidence-linked diagnostic that helps teams identify the operating constraint most worth testing next. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Forward Deployed Engineer Catalogue record: /apps/ai-forward-deployed-engineer Status: planned Claim boundary: AI Forward Deployed Engineer is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Forward Deployed Engineer: the installed outcome - Headline: AI Forward Deployed Engineer, installed around one working outcome—not another AI subscription. - Offer: For AI startups: a custom build pilot that starts with “Starts with one measurable workflow, not an open-ended AI transformation,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current ai engineering services workflow, install the minimum AI Forward Deployed Engineer capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Forward Deployed Engineer pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Forward Deployed Engineer is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Forward Deployed Engineer installation worth proving. - Email subject: AI Forward Deployed Engineer: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Forward Deployed Engineer installed around one job, one owner, and one acceptance test. - Landing lead: A human-accountable AI engineering partner that embeds with your team to turn one valuable workflow into a reliable production system. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Forward Deployed Engineer: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Forward Deployed Engineer can make measurable. - Offer: AI Forward Deployed Engineer begins with a diagnostic for AI startups, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where ai engineering services work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Forward Deployed Engineer only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Forward Deployed Engineer offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Forward Deployed Engineer should remove. - Email subject: Where is AI Forward Deployed Engineer worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Forward Deployed Engineer one measurable job. - Landing lead: One accountable delivery team combines an embedded human engineer with bounded AI agents to find, build, prove, and transfer a production workflow. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Forward Deployed Engineer: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Forward Deployed Engineer offer the whole team can use. - Offer: For AI startups, AI Forward Deployed Engineer packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for ai engineering services, structure their decisions into a guided AI Forward Deployed Engineer workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Forward Deployed Engineer workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Forward Deployed Engineer should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Forward Deployed Engineer should productize. - Email subject: Package your best operating knowledge with AI Forward Deployed Engineer - Social hook: Your best operator already has a product in their head. AI Forward Deployed Engineer can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A human-accountable AI engineering partner that embeds with your team to turn one valuable workflow into a reliable production system. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Forward Deployed Engineer: the compounding playbook - Headline: Stop rebuilding AI Forward Deployed Engineer from prompts. Encode the playbook your operation can improve. - Offer: AI Forward Deployed Engineer becomes a reusable operating layer for AI startups: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Starts with one measurable workflow, not an open-ended AI transformation,” encode the stable decisions, isolate customer data and permissions, and improve the AI Forward Deployed Engineer playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Forward Deployed Engineer release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Forward Deployed Engineer separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Forward Deployed Engineer should encode first. - Email subject: Make AI Forward Deployed Engineer improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Forward Deployed Engineer playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: One accountable delivery team combines an embedded human engineer with bounded AI agents to find, build, prove, and transfer a production workflow. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Forward Deployed Engineer: prove what compounds - Headline: If AI Forward Deployed Engineer cannot connect its work to an observable result, it does not get credit. - Offer: Give AI startups a AI Forward Deployed Engineer deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Forward Deployed Engineer input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Forward Deployed Engineer should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Forward Deployed Engineer pilot. - Email subject: What evidence would make AI Forward Deployed Engineer worth expanding? - Social hook: The useful question is not whether AI Forward Deployed Engineer ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A human-accountable AI engineering partner that embeds with your team to turn one valuable workflow into a reliable production system. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Software Engineering Copilot Catalogue record: /apps/software-engineering-copilot Status: planned Claim boundary: Software Engineering Copilot is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Software Engineering Copilot: the installed outcome - Headline: Software Engineering Copilot, installed around one working outcome—not another AI subscription. - Offer: For Software teams: a custom build pilot that starts with “Works inside explicit repository and task boundaries,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current ai engineering services workflow, install the minimum Software Engineering Copilot capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Software Engineering Copilot pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Software Engineering Copilot is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Software Engineering Copilot installation worth proving. - Email subject: Software Engineering Copilot: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Software Engineering Copilot installed around one job, one owner, and one acceptance test. - Landing lead: A repository-scoped engineering copilot for planning, implementing, and validating bounded software changes. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Software Engineering Copilot: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Software Engineering Copilot can make measurable. - Offer: Software Engineering Copilot begins with a diagnostic for Software teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where ai engineering services work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Software Engineering Copilot only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Software Engineering Copilot offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Software Engineering Copilot should remove. - Email subject: Where is Software Engineering Copilot worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Software Engineering Copilot one measurable job. - Landing lead: Accelerate bounded engineering work while keeping repository context, tests, review, and promotion evidence legible. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Software Engineering Copilot: expertise into an offer - Headline: Turn the way your best people handle this work into a Software Engineering Copilot offer the whole team can use. - Offer: For Software teams, Software Engineering Copilot packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for ai engineering services, structure their decisions into a guided Software Engineering Copilot workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Software Engineering Copilot workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Software Engineering Copilot should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Software Engineering Copilot should productize. - Email subject: Package your best operating knowledge with Software Engineering Copilot - Social hook: Your best operator already has a product in their head. Software Engineering Copilot can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A repository-scoped engineering copilot for planning, implementing, and validating bounded software changes. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Software Engineering Copilot: the compounding playbook - Headline: Stop rebuilding Software Engineering Copilot from prompts. Encode the playbook your operation can improve. - Offer: Software Engineering Copilot becomes a reusable operating layer for Software teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Works inside explicit repository and task boundaries,” encode the stable decisions, isolate customer data and permissions, and improve the Software Engineering Copilot playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Software Engineering Copilot release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Software Engineering Copilot separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Software Engineering Copilot should encode first. - Email subject: Make Software Engineering Copilot improve with every reviewed case - Social hook: Prompts are disposable. A versioned Software Engineering Copilot playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Accelerate bounded engineering work while keeping repository context, tests, review, and promotion evidence legible. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Software Engineering Copilot: prove what compounds - Headline: If Software Engineering Copilot cannot connect its work to an observable result, it does not get credit. - Offer: Give Software teams a Software Engineering Copilot deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Software Engineering Copilot input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Software Engineering Copilot should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Software Engineering Copilot pilot. - Email subject: What evidence would make Software Engineering Copilot worth expanding? - Social hook: The useful question is not whether Software Engineering Copilot ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A repository-scoped engineering copilot for planning, implementing, and validating bounded software changes. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Agent Skill Library Catalogue record: /apps/agent-skill-library Status: planned Claim boundary: Agent Skill Library is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Agent Skill Library: the installed outcome - Headline: Agent Skill Library, installed around one working outcome—not another AI subscription. - Offer: For Businesses: a hosted pilot that starts with “Package domain expertise as inspectable, versioned agent skills,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current managed agent infrastructure workflow, install the minimum Agent Skill Library capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Agent Skill Library pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Agent Skill Library is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Agent Skill Library installation worth proving. - Email subject: Agent Skill Library: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Agent Skill Library installed around one job, one owner, and one acceptance test. - Landing lead: Versioned, evaluated agent skills that package domain expertise, operating steps, safety boundaries, and proof requirements for repeatable work. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Agent Skill Library: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Agent Skill Library can make measurable. - Offer: Agent Skill Library begins with a diagnostic for Businesses, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where managed agent infrastructure work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Agent Skill Library only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Agent Skill Library offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Agent Skill Library should remove. - Email subject: Where is Agent Skill Library worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Agent Skill Library one measurable job. - Landing lead: Buy the operating knowledge and tested workflow—not a blank agent—through reusable skill packages tuned for a specific job and evidence standard. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Agent Skill Library: expertise into an offer - Headline: Turn the way your best people handle this work into a Agent Skill Library offer the whole team can use. - Offer: For Businesses, Agent Skill Library packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for managed agent infrastructure, structure their decisions into a guided Agent Skill Library workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Agent Skill Library workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Agent Skill Library should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Agent Skill Library should productize. - Email subject: Package your best operating knowledge with Agent Skill Library - Social hook: Your best operator already has a product in their head. Agent Skill Library can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: Versioned, evaluated agent skills that package domain expertise, operating steps, safety boundaries, and proof requirements for repeatable work. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Agent Skill Library: the compounding playbook - Headline: Stop rebuilding Agent Skill Library from prompts. Encode the playbook your operation can improve. - Offer: Agent Skill Library becomes a reusable operating layer for Businesses: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Package domain expertise as inspectable, versioned agent skills,” encode the stable decisions, isolate customer data and permissions, and improve the Agent Skill Library playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Agent Skill Library release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Agent Skill Library separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Agent Skill Library should encode first. - Email subject: Make Agent Skill Library improve with every reviewed case - Social hook: Prompts are disposable. A versioned Agent Skill Library playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Buy the operating knowledge and tested workflow—not a blank agent—through reusable skill packages tuned for a specific job and evidence standard. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Agent Skill Library: prove what compounds - Headline: If Agent Skill Library cannot connect its work to an observable result, it does not get credit. - Offer: Give Businesses a Agent Skill Library deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Agent Skill Library input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Agent Skill Library should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Agent Skill Library pilot. - Email subject: What evidence would make Agent Skill Library worth expanding? - Social hook: The useful question is not whether Agent Skill Library ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: Versioned, evaluated agent skills that package domain expertise, operating steps, safety boundaries, and proof requirements for repeatable work. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Girl Math Catalogue record: /apps/girl-math Status: beta Claim boundary: Girl Math is a beta product. Market the verified workflow and its public-live proof only; do not imply broad availability or business outcomes. ### Outcome installation - Campaign: Girl Math: the installed outcome - Headline: Girl Math, installed around one working outcome—not another AI subscription. - Offer: For Travel teams: a hosted pilot that starts with “Browse reference sweet spots without an account,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current travel workflow, install the minimum Girl Math capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Girl Math pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Girl Math is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Girl Math installation worth proving. - Email subject: Girl Math: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Girl Math installed around one job, one owner, and one acceptance test. - Landing lead: An award-travel reference board for comparing points redemptions, transfer routes, and premium-cabin value. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Girl Math: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Girl Math can make measurable. - Offer: Girl Math begins with a diagnostic for Travel teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where travel work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Girl Math only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Girl Math offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Girl Math should remove. - Email subject: Where is Girl Math worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Girl Math one measurable job. - Landing lead: A focused research surface that turns complicated award-travel decisions into a clearer buying conversation. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Girl Math: expertise into an offer - Headline: Turn the way your best people handle this work into a Girl Math offer the whole team can use. - Offer: For Travel teams, Girl Math packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for travel, structure their decisions into a guided Girl Math workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Girl Math workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Girl Math should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Girl Math should productize. - Email subject: Package your best operating knowledge with Girl Math - Social hook: Your best operator already has a product in their head. Girl Math can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: An award-travel reference board for comparing points redemptions, transfer routes, and premium-cabin value. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Girl Math: the compounding playbook - Headline: Stop rebuilding Girl Math from prompts. Encode the playbook your operation can improve. - Offer: Girl Math becomes a reusable operating layer for Travel teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Browse reference sweet spots without an account,” encode the stable decisions, isolate customer data and permissions, and improve the Girl Math playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Girl Math release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Girl Math separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Girl Math should encode first. - Email subject: Make Girl Math improve with every reviewed case - Social hook: Prompts are disposable. A versioned Girl Math playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A focused research surface that turns complicated award-travel decisions into a clearer buying conversation. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Girl Math: prove what compounds - Headline: If Girl Math cannot connect its work to an observable result, it does not get credit. - Offer: Give Travel teams a Girl Math deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Girl Math input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Girl Math should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Girl Math pilot. - Email subject: What evidence would make Girl Math worth expanding? - Social hook: The useful question is not whether Girl Math ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: An award-travel reference board for comparing points redemptions, transfer routes, and premium-cabin value. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## BYOK Agent Cloud Catalogue record: /apps/byok-agent-cloud Status: planned Claim boundary: BYOK Agent Cloud is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: BYOK Agent Cloud: the installed outcome - Headline: BYOK Agent Cloud, installed around one working outcome—not another AI subscription. - Offer: For Agent operators: a hosted pilot that starts with “Keep model usage on a customer-controlled model account,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current managed agent infrastructure workflow, install the minimum BYOK Agent Cloud capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the BYOK Agent Cloud pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: BYOK Agent Cloud is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest BYOK Agent Cloud installation worth proving. - Email subject: BYOK Agent Cloud: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need BYOK Agent Cloud installed around one job, one owner, and one acceptance test. - Landing lead: A managed agent control plane with customer-supplied model keys, predictable platform pricing, backups, and messaging gateway integrations. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: BYOK Agent Cloud: remove the constraint - Headline: The constraint is not “we need AI.” It is the work BYOK Agent Cloud can make measurable. - Offer: BYOK Agent Cloud begins with a diagnostic for Agent operators, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where managed agent infrastructure work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure BYOK Agent Cloud only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The BYOK Agent Cloud offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint BYOK Agent Cloud should remove. - Email subject: Where is BYOK Agent Cloud worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give BYOK Agent Cloud one measurable job. - Landing lead: Separate the managed platform fee from volatile model spend: customers bring their own model API key while Armalo manages orchestration, recovery, and gateway connections. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: BYOK Agent Cloud: expertise into an offer - Headline: Turn the way your best people handle this work into a BYOK Agent Cloud offer the whole team can use. - Offer: For Agent operators, BYOK Agent Cloud packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for managed agent infrastructure, structure their decisions into a guided BYOK Agent Cloud workflow, and keep expert review visible at consequential steps. - Proof plan: Test the BYOK Agent Cloud workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: BYOK Agent Cloud should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise BYOK Agent Cloud should productize. - Email subject: Package your best operating knowledge with BYOK Agent Cloud - Social hook: Your best operator already has a product in their head. BYOK Agent Cloud can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A managed agent control plane with customer-supplied model keys, predictable platform pricing, backups, and messaging gateway integrations. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: BYOK Agent Cloud: the compounding playbook - Headline: Stop rebuilding BYOK Agent Cloud from prompts. Encode the playbook your operation can improve. - Offer: BYOK Agent Cloud becomes a reusable operating layer for Agent operators: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Keep model usage on a customer-controlled model account,” encode the stable decisions, isolate customer data and permissions, and improve the BYOK Agent Cloud playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each BYOK Agent Cloud release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: BYOK Agent Cloud separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook BYOK Agent Cloud should encode first. - Email subject: Make BYOK Agent Cloud improve with every reviewed case - Social hook: Prompts are disposable. A versioned BYOK Agent Cloud playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Separate the managed platform fee from volatile model spend: customers bring their own model API key while Armalo manages orchestration, recovery, and gateway connections. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: BYOK Agent Cloud: prove what compounds - Headline: If BYOK Agent Cloud cannot connect its work to an observable result, it does not get credit. - Offer: Give Agent operators a BYOK Agent Cloud deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from BYOK Agent Cloud input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: BYOK Agent Cloud should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first BYOK Agent Cloud pilot. - Email subject: What evidence would make BYOK Agent Cloud worth expanding? - Social hook: The useful question is not whether BYOK Agent Cloud ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A managed agent control plane with customer-supplied model keys, predictable platform pricing, backups, and messaging gateway integrations. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Hermes Revenue Agents Catalogue record: /apps/hermes-revenue-agents Status: planned Claim boundary: Hermes Revenue Agents is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Hermes Revenue Agents: the installed outcome - Headline: Hermes Revenue Agents, installed around one working outcome—not another AI subscription. - Offer: For High-ticket teams: a custom build pilot that starts with “Qualify high-intent leads against a defined buying rubric,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum Hermes Revenue Agents capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Hermes Revenue Agents pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Hermes Revenue Agents is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Hermes Revenue Agents installation worth proving. - Email subject: Hermes Revenue Agents: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Hermes Revenue Agents installed around one job, one owner, and one acceptance test. - Landing lead: Dedicated Hermes agents for high-ticket lead qualification, appointment setting, calendar coordination, dialing, and sales handoff. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Hermes Revenue Agents: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Hermes Revenue Agents can make measurable. - Offer: Hermes Revenue Agents begins with a diagnostic for High-ticket teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Hermes Revenue Agents only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Hermes Revenue Agents offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Hermes Revenue Agents should remove. - Email subject: Where is Hermes Revenue Agents worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Hermes Revenue Agents one measurable job. - Landing lead: A reliable revenue-agent layer for businesses that need more qualified conversations without paying human labor rates for every repetitive touch. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Hermes Revenue Agents: expertise into an offer - Headline: Turn the way your best people handle this work into a Hermes Revenue Agents offer the whole team can use. - Offer: For High-ticket teams, Hermes Revenue Agents packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided Hermes Revenue Agents workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Hermes Revenue Agents workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Hermes Revenue Agents should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Hermes Revenue Agents should productize. - Email subject: Package your best operating knowledge with Hermes Revenue Agents - Social hook: Your best operator already has a product in their head. Hermes Revenue Agents can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: Dedicated Hermes agents for high-ticket lead qualification, appointment setting, calendar coordination, dialing, and sales handoff. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Hermes Revenue Agents: the compounding playbook - Headline: Stop rebuilding Hermes Revenue Agents from prompts. Encode the playbook your operation can improve. - Offer: Hermes Revenue Agents becomes a reusable operating layer for High-ticket teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Qualify high-intent leads against a defined buying rubric,” encode the stable decisions, isolate customer data and permissions, and improve the Hermes Revenue Agents playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Hermes Revenue Agents release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Hermes Revenue Agents separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Hermes Revenue Agents should encode first. - Email subject: Make Hermes Revenue Agents improve with every reviewed case - Social hook: Prompts are disposable. A versioned Hermes Revenue Agents playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A reliable revenue-agent layer for businesses that need more qualified conversations without paying human labor rates for every repetitive touch. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Hermes Revenue Agents: prove what compounds - Headline: If Hermes Revenue Agents cannot connect its work to an observable result, it does not get credit. - Offer: Give High-ticket teams a Hermes Revenue Agents deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Hermes Revenue Agents input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Hermes Revenue Agents should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Hermes Revenue Agents pilot. - Email subject: What evidence would make Hermes Revenue Agents worth expanding? - Social hook: The useful question is not whether Hermes Revenue Agents ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: Dedicated Hermes agents for high-ticket lead qualification, appointment setting, calendar coordination, dialing, and sales handoff. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Voice Customer Service Assistant Catalogue record: /apps/voice-customer-service Status: planned Claim boundary: Voice Customer Service Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Voice Customer Service Assistant: the installed outcome - Headline: Voice Customer Service Assistant, installed around one working outcome—not another AI subscription. - Offer: For Service businesses: a hosted pilot that starts with “Answers recurring customer questions in a natural voice,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current customer service workflow, install the minimum Voice Customer Service Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Voice Customer Service Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Voice Customer Service Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Voice Customer Service Assistant installation worth proving. - Email subject: Voice Customer Service Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Voice Customer Service Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A voice-first service desk assistant for answering routine questions, routing intent, and escalating the moments that need a human. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Voice Customer Service Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Voice Customer Service Assistant can make measurable. - Offer: Voice Customer Service Assistant begins with a diagnostic for Service businesses, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where customer service work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Voice Customer Service Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Voice Customer Service Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Voice Customer Service Assistant should remove. - Email subject: Where is Voice Customer Service Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Voice Customer Service Assistant one measurable job. - Landing lead: Sell the outcome: fewer repetitive calls, faster response, and a service experience that still knows when to hand off. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Voice Customer Service Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Voice Customer Service Assistant offer the whole team can use. - Offer: For Service businesses, Voice Customer Service Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for customer service, structure their decisions into a guided Voice Customer Service Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Voice Customer Service Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Voice Customer Service Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Voice Customer Service Assistant should productize. - Email subject: Package your best operating knowledge with Voice Customer Service Assistant - Social hook: Your best operator already has a product in their head. Voice Customer Service Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A voice-first service desk assistant for answering routine questions, routing intent, and escalating the moments that need a human. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Voice Customer Service Assistant: the compounding playbook - Headline: Stop rebuilding Voice Customer Service Assistant from prompts. Encode the playbook your operation can improve. - Offer: Voice Customer Service Assistant becomes a reusable operating layer for Service businesses: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Answers recurring customer questions in a natural voice,” encode the stable decisions, isolate customer data and permissions, and improve the Voice Customer Service Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Voice Customer Service Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Voice Customer Service Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Voice Customer Service Assistant should encode first. - Email subject: Make Voice Customer Service Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Voice Customer Service Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Sell the outcome: fewer repetitive calls, faster response, and a service experience that still knows when to hand off. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Voice Customer Service Assistant: prove what compounds - Headline: If Voice Customer Service Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Service businesses a Voice Customer Service Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Voice Customer Service Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Voice Customer Service Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Voice Customer Service Assistant pilot. - Email subject: What evidence would make Voice Customer Service Assistant worth expanding? - Social hook: The useful question is not whether Voice Customer Service Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A voice-first service desk assistant for answering routine questions, routing intent, and escalating the moments that need a human. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Customer Service Desk Catalogue record: /apps/ai-customer-service-desk Status: planned Claim boundary: AI Customer Service Desk is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Customer Service Desk: the installed outcome - Headline: AI Customer Service Desk, installed around one working outcome—not another AI subscription. - Offer: For Support teams: a hosted pilot that starts with “Answers routine questions from approved company sources,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current customer service workflow, install the minimum AI Customer Service Desk capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Customer Service Desk pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Customer Service Desk is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Customer Service Desk installation worth proving. - Email subject: AI Customer Service Desk: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Customer Service Desk installed around one job, one owner, and one acceptance test. - Landing lead: One governed service desk for answering, routing, drafting, and escalating customer demand across approved channels. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Customer Service Desk: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Customer Service Desk can make measurable. - Offer: AI Customer Service Desk begins with a diagnostic for Support teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where customer service work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Customer Service Desk only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Customer Service Desk offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Customer Service Desk should remove. - Email subject: Where is AI Customer Service Desk worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Customer Service Desk one measurable job. - Landing lead: Buy one policy, knowledge, routing, and reporting layer across service channels, or start with a single channel module and expand after proof. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Customer Service Desk: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Customer Service Desk offer the whole team can use. - Offer: For Support teams, AI Customer Service Desk packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for customer service, structure their decisions into a guided AI Customer Service Desk workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Customer Service Desk workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Customer Service Desk should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Customer Service Desk should productize. - Email subject: Package your best operating knowledge with AI Customer Service Desk - Social hook: Your best operator already has a product in their head. AI Customer Service Desk can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: One governed service desk for answering, routing, drafting, and escalating customer demand across approved channels. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Customer Service Desk: the compounding playbook - Headline: Stop rebuilding AI Customer Service Desk from prompts. Encode the playbook your operation can improve. - Offer: AI Customer Service Desk becomes a reusable operating layer for Support teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Answers routine questions from approved company sources,” encode the stable decisions, isolate customer data and permissions, and improve the AI Customer Service Desk playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Customer Service Desk release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Customer Service Desk separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Customer Service Desk should encode first. - Email subject: Make AI Customer Service Desk improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Customer Service Desk playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Buy one policy, knowledge, routing, and reporting layer across service channels, or start with a single channel module and expand after proof. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Customer Service Desk: prove what compounds - Headline: If AI Customer Service Desk cannot connect its work to an observable result, it does not get credit. - Offer: Give Support teams a AI Customer Service Desk deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Customer Service Desk input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Customer Service Desk should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Customer Service Desk pilot. - Email subject: What evidence would make AI Customer Service Desk worth expanding? - Social hook: The useful question is not whether AI Customer Service Desk ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: One governed service desk for answering, routing, drafting, and escalating customer demand across approved channels. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## SMS Customer Service Assistant Catalogue record: /apps/sms-customer-service Status: planned Claim boundary: SMS Customer Service Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: SMS Customer Service Assistant: the installed outcome - Headline: SMS Customer Service Assistant, installed around one working outcome—not another AI subscription. - Offer: For Local businesses: a hosted pilot that starts with “Handles common questions and status updates by text,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current customer service workflow, install the minimum SMS Customer Service Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the SMS Customer Service Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: SMS Customer Service Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest SMS Customer Service Assistant installation worth proving. - Email subject: SMS Customer Service Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need SMS Customer Service Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A text-message assistant for updates, reminders, triage, and lightweight customer support that meets people in the channel they already use. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: SMS Customer Service Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work SMS Customer Service Assistant can make measurable. - Offer: SMS Customer Service Assistant begins with a diagnostic for Local businesses, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where customer service work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure SMS Customer Service Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The SMS Customer Service Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint SMS Customer Service Assistant should remove. - Email subject: Where is SMS Customer Service Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give SMS Customer Service Assistant one measurable job. - Landing lead: A simple wedge for teams that need faster follow-up without asking customers to learn another app. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: SMS Customer Service Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a SMS Customer Service Assistant offer the whole team can use. - Offer: For Local businesses, SMS Customer Service Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for customer service, structure their decisions into a guided SMS Customer Service Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the SMS Customer Service Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: SMS Customer Service Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise SMS Customer Service Assistant should productize. - Email subject: Package your best operating knowledge with SMS Customer Service Assistant - Social hook: Your best operator already has a product in their head. SMS Customer Service Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A text-message assistant for updates, reminders, triage, and lightweight customer support that meets people in the channel they already use. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: SMS Customer Service Assistant: the compounding playbook - Headline: Stop rebuilding SMS Customer Service Assistant from prompts. Encode the playbook your operation can improve. - Offer: SMS Customer Service Assistant becomes a reusable operating layer for Local businesses: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Handles common questions and status updates by text,” encode the stable decisions, isolate customer data and permissions, and improve the SMS Customer Service Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each SMS Customer Service Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: SMS Customer Service Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook SMS Customer Service Assistant should encode first. - Email subject: Make SMS Customer Service Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned SMS Customer Service Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A simple wedge for teams that need faster follow-up without asking customers to learn another app. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: SMS Customer Service Assistant: prove what compounds - Headline: If SMS Customer Service Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Local businesses a SMS Customer Service Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from SMS Customer Service Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: SMS Customer Service Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first SMS Customer Service Assistant pilot. - Email subject: What evidence would make SMS Customer Service Assistant worth expanding? - Social hook: The useful question is not whether SMS Customer Service Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A text-message assistant for updates, reminders, triage, and lightweight customer support that meets people in the channel they already use. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## WhatsApp Customer Service Assistant Catalogue record: /apps/whatsapp-customer-service Status: planned Claim boundary: WhatsApp Customer Service Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: WhatsApp Customer Service Assistant: the installed outcome - Headline: WhatsApp Customer Service Assistant, installed around one working outcome—not another AI subscription. - Offer: For International teams: a hosted pilot that starts with “Supports conversational service and lead qualification,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current customer service workflow, install the minimum WhatsApp Customer Service Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the WhatsApp Customer Service Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: WhatsApp Customer Service Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest WhatsApp Customer Service Assistant installation worth proving. - Email subject: WhatsApp Customer Service Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need WhatsApp Customer Service Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A WhatsApp-native assistant for customer questions, qualification, scheduling, and human handoff in high-context conversations. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: WhatsApp Customer Service Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work WhatsApp Customer Service Assistant can make measurable. - Offer: WhatsApp Customer Service Assistant begins with a diagnostic for International teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where customer service work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure WhatsApp Customer Service Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The WhatsApp Customer Service Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint WhatsApp Customer Service Assistant should remove. - Email subject: Where is WhatsApp Customer Service Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give WhatsApp Customer Service Assistant one measurable job. - Landing lead: Use the channel customers already trust, then make the operational handoff visible and manageable. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: WhatsApp Customer Service Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a WhatsApp Customer Service Assistant offer the whole team can use. - Offer: For International teams, WhatsApp Customer Service Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for customer service, structure their decisions into a guided WhatsApp Customer Service Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the WhatsApp Customer Service Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: WhatsApp Customer Service Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise WhatsApp Customer Service Assistant should productize. - Email subject: Package your best operating knowledge with WhatsApp Customer Service Assistant - Social hook: Your best operator already has a product in their head. WhatsApp Customer Service Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A WhatsApp-native assistant for customer questions, qualification, scheduling, and human handoff in high-context conversations. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: WhatsApp Customer Service Assistant: the compounding playbook - Headline: Stop rebuilding WhatsApp Customer Service Assistant from prompts. Encode the playbook your operation can improve. - Offer: WhatsApp Customer Service Assistant becomes a reusable operating layer for International teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Supports conversational service and lead qualification,” encode the stable decisions, isolate customer data and permissions, and improve the WhatsApp Customer Service Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each WhatsApp Customer Service Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: WhatsApp Customer Service Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook WhatsApp Customer Service Assistant should encode first. - Email subject: Make WhatsApp Customer Service Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned WhatsApp Customer Service Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Use the channel customers already trust, then make the operational handoff visible and manageable. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: WhatsApp Customer Service Assistant: prove what compounds - Headline: If WhatsApp Customer Service Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give International teams a WhatsApp Customer Service Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from WhatsApp Customer Service Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: WhatsApp Customer Service Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first WhatsApp Customer Service Assistant pilot. - Email subject: What evidence would make WhatsApp Customer Service Assistant worth expanding? - Social hook: The useful question is not whether WhatsApp Customer Service Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A WhatsApp-native assistant for customer questions, qualification, scheduling, and human handoff in high-context conversations. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Email Customer Service Assistant Catalogue record: /apps/email-customer-service Status: planned Claim boundary: Email Customer Service Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Email Customer Service Assistant: the installed outcome - Headline: Email Customer Service Assistant, installed around one working outcome—not another AI subscription. - Offer: For Support teams: a hosted pilot that starts with “Groups recurring requests and surfaces the next action,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current customer service workflow, install the minimum Email Customer Service Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Email Customer Service Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Email Customer Service Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Email Customer Service Assistant installation worth proving. - Email subject: Email Customer Service Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Email Customer Service Assistant installed around one job, one owner, and one acceptance test. - Landing lead: An email operations assistant for drafting, classifying, summarizing, and routing customer conversations with a clear review boundary. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Email Customer Service Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Email Customer Service Assistant can make measurable. - Offer: Email Customer Service Assistant begins with a diagnostic for Support teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where customer service work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Email Customer Service Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Email Customer Service Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Email Customer Service Assistant should remove. - Email subject: Where is Email Customer Service Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Email Customer Service Assistant one measurable job. - Landing lead: Turn a crowded support inbox into a calmer queue without pretending every reply should be automated. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Email Customer Service Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Email Customer Service Assistant offer the whole team can use. - Offer: For Support teams, Email Customer Service Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for customer service, structure their decisions into a guided Email Customer Service Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Email Customer Service Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Email Customer Service Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Email Customer Service Assistant should productize. - Email subject: Package your best operating knowledge with Email Customer Service Assistant - Social hook: Your best operator already has a product in their head. Email Customer Service Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: An email operations assistant for drafting, classifying, summarizing, and routing customer conversations with a clear review boundary. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Email Customer Service Assistant: the compounding playbook - Headline: Stop rebuilding Email Customer Service Assistant from prompts. Encode the playbook your operation can improve. - Offer: Email Customer Service Assistant becomes a reusable operating layer for Support teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Groups recurring requests and surfaces the next action,” encode the stable decisions, isolate customer data and permissions, and improve the Email Customer Service Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Email Customer Service Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Email Customer Service Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Email Customer Service Assistant should encode first. - Email subject: Make Email Customer Service Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Email Customer Service Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Turn a crowded support inbox into a calmer queue without pretending every reply should be automated. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Email Customer Service Assistant: prove what compounds - Headline: If Email Customer Service Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Support teams a Email Customer Service Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Email Customer Service Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Email Customer Service Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Email Customer Service Assistant pilot. - Email subject: What evidence would make Email Customer Service Assistant worth expanding? - Social hook: The useful question is not whether Email Customer Service Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: An email operations assistant for drafting, classifying, summarizing, and routing customer conversations with a clear review boundary. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Hermes AI CRM Catalogue record: /apps/hermes-ai-crm Status: planned Claim boundary: Hermes AI CRM is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Hermes AI CRM: the installed outcome - Headline: Hermes AI CRM, installed around one working outcome—not another AI subscription. - Offer: For Sales teams: a hosted pilot that starts with “Keep lead identity, status, assignment, and activity connected,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum Hermes AI CRM capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Hermes AI CRM pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Hermes AI CRM is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Hermes AI CRM installation worth proving. - Email subject: Hermes AI CRM: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Hermes AI CRM installed around one job, one owner, and one acceptance test. - Landing lead: An AI CRM layer that keeps lead context, pipeline state, outreach approvals, follow-ups, and revenue evidence in one operating loop. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Hermes AI CRM: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Hermes AI CRM can make measurable. - Offer: Hermes AI CRM begins with a diagnostic for Sales teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Hermes AI CRM only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Hermes AI CRM offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Hermes AI CRM should remove. - Email subject: Where is Hermes AI CRM worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Hermes AI CRM one measurable job. - Landing lead: A CRM built around agent work and accountable state changes, so automation produces a usable operating record instead of a pile of untracked messages. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Hermes AI CRM: expertise into an offer - Headline: Turn the way your best people handle this work into a Hermes AI CRM offer the whole team can use. - Offer: For Sales teams, Hermes AI CRM packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided Hermes AI CRM workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Hermes AI CRM workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Hermes AI CRM should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Hermes AI CRM should productize. - Email subject: Package your best operating knowledge with Hermes AI CRM - Social hook: Your best operator already has a product in their head. Hermes AI CRM can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: An AI CRM layer that keeps lead context, pipeline state, outreach approvals, follow-ups, and revenue evidence in one operating loop. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Hermes AI CRM: the compounding playbook - Headline: Stop rebuilding Hermes AI CRM from prompts. Encode the playbook your operation can improve. - Offer: Hermes AI CRM becomes a reusable operating layer for Sales teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Keep lead identity, status, assignment, and activity connected,” encode the stable decisions, isolate customer data and permissions, and improve the Hermes AI CRM playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Hermes AI CRM release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Hermes AI CRM separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Hermes AI CRM should encode first. - Email subject: Make Hermes AI CRM improve with every reviewed case - Social hook: Prompts are disposable. A versioned Hermes AI CRM playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A CRM built around agent work and accountable state changes, so automation produces a usable operating record instead of a pile of untracked messages. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Hermes AI CRM: prove what compounds - Headline: If Hermes AI CRM cannot connect its work to an observable result, it does not get credit. - Offer: Give Sales teams a Hermes AI CRM deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Hermes AI CRM input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Hermes AI CRM should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Hermes AI CRM pilot. - Email subject: What evidence would make Hermes AI CRM worth expanding? - Social hook: The useful question is not whether Hermes AI CRM ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: An AI CRM layer that keeps lead context, pipeline state, outreach approvals, follow-ups, and revenue evidence in one operating loop. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Personal Finance AI Assistant Catalogue record: /apps/personal-finance-assistant Status: planned Claim boundary: Personal Finance AI Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Personal Finance AI Assistant: the installed outcome - Headline: Personal Finance AI Assistant, installed around one working outcome—not another AI subscription. - Offer: For Consumers: a hosted pilot that starts with “Explains financial concepts in plain language,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current personal finance workflow, install the minimum Personal Finance AI Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Personal Finance AI Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Personal Finance AI Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Personal Finance AI Assistant installation worth proving. - Email subject: Personal Finance AI Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Personal Finance AI Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A personal finance assistant for organizing questions, explaining trade-offs, and turning a messy money picture into a clearer next step. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Personal Finance AI Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Personal Finance AI Assistant can make measurable. - Offer: Personal Finance AI Assistant begins with a diagnostic for Consumers, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where personal finance work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Personal Finance AI Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Personal Finance AI Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Personal Finance AI Assistant should remove. - Email subject: Where is Personal Finance AI Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Personal Finance AI Assistant one measurable job. - Landing lead: Position clarity and education first; personalized financial actions require explicit product and compliance boundaries. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Personal Finance AI Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Personal Finance AI Assistant offer the whole team can use. - Offer: For Consumers, Personal Finance AI Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for personal finance, structure their decisions into a guided Personal Finance AI Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Personal Finance AI Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Personal Finance AI Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Personal Finance AI Assistant should productize. - Email subject: Package your best operating knowledge with Personal Finance AI Assistant - Social hook: Your best operator already has a product in their head. Personal Finance AI Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A personal finance assistant for organizing questions, explaining trade-offs, and turning a messy money picture into a clearer next step. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Personal Finance AI Assistant: the compounding playbook - Headline: Stop rebuilding Personal Finance AI Assistant from prompts. Encode the playbook your operation can improve. - Offer: Personal Finance AI Assistant becomes a reusable operating layer for Consumers: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Explains financial concepts in plain language,” encode the stable decisions, isolate customer data and permissions, and improve the Personal Finance AI Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Personal Finance AI Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Personal Finance AI Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Personal Finance AI Assistant should encode first. - Email subject: Make Personal Finance AI Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Personal Finance AI Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Position clarity and education first; personalized financial actions require explicit product and compliance boundaries. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Personal Finance AI Assistant: prove what compounds - Headline: If Personal Finance AI Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Consumers a Personal Finance AI Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Personal Finance AI Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Personal Finance AI Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Personal Finance AI Assistant pilot. - Email subject: What evidence would make Personal Finance AI Assistant worth expanding? - Social hook: The useful question is not whether Personal Finance AI Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A personal finance assistant for organizing questions, explaining trade-offs, and turning a messy money picture into a clearer next step. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Proposal Generator Catalogue record: /apps/proposal-generator Status: planned Claim boundary: Proposal Generator is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Proposal Generator: the installed outcome - Headline: Proposal Generator, installed around one working outcome—not another AI subscription. - Offer: For Agencies: a hosted pilot that starts with “Builds drafts from approved CRM, discovery, offer, and proof sources,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum Proposal Generator capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Proposal Generator pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Proposal Generator is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Proposal Generator installation worth proving. - Email subject: Proposal Generator: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Proposal Generator installed around one job, one owner, and one acceptance test. - Landing lead: A proposal workflow agent that turns approved deal context into reviewable scope, pricing, proof, and next steps without inventing commercial terms. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Proposal Generator: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Proposal Generator can make measurable. - Offer: Proposal Generator begins with a diagnostic for Agencies, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Proposal Generator only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Proposal Generator offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Proposal Generator should remove. - Email subject: Where is Proposal Generator worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Proposal Generator one measurable job. - Landing lead: Move from discovery to a buyer-ready proposal faster while keeping scope, pricing, claims, and acceptance under accountable review. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Proposal Generator: expertise into an offer - Headline: Turn the way your best people handle this work into a Proposal Generator offer the whole team can use. - Offer: For Agencies, Proposal Generator packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided Proposal Generator workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Proposal Generator workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Proposal Generator should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Proposal Generator should productize. - Email subject: Package your best operating knowledge with Proposal Generator - Social hook: Your best operator already has a product in their head. Proposal Generator can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A proposal workflow agent that turns approved deal context into reviewable scope, pricing, proof, and next steps without inventing commercial terms. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Proposal Generator: the compounding playbook - Headline: Stop rebuilding Proposal Generator from prompts. Encode the playbook your operation can improve. - Offer: Proposal Generator becomes a reusable operating layer for Agencies: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Builds drafts from approved CRM, discovery, offer, and proof sources,” encode the stable decisions, isolate customer data and permissions, and improve the Proposal Generator playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Proposal Generator release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Proposal Generator separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Proposal Generator should encode first. - Email subject: Make Proposal Generator improve with every reviewed case - Social hook: Prompts are disposable. A versioned Proposal Generator playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Move from discovery to a buyer-ready proposal faster while keeping scope, pricing, claims, and acceptance under accountable review. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Proposal Generator: prove what compounds - Headline: If Proposal Generator cannot connect its work to an observable result, it does not get credit. - Offer: Give Agencies a Proposal Generator deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Proposal Generator input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Proposal Generator should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Proposal Generator pilot. - Email subject: What evidence would make Proposal Generator worth expanding? - Social hook: The useful question is not whether Proposal Generator ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A proposal workflow agent that turns approved deal context into reviewable scope, pricing, proof, and next steps without inventing commercial terms. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Invoice Chaser Catalogue record: /apps/invoice-chaser Status: planned Claim boundary: Invoice Chaser is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Invoice Chaser: the installed outcome - Headline: Invoice Chaser, installed around one working outcome—not another AI subscription. - Offer: For Freelancers: a hosted pilot that starts with “Prioritizes overdue work from approved invoice and customer state,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current accounts receivable workflow, install the minimum Invoice Chaser capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Invoice Chaser pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Invoice Chaser is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Invoice Chaser installation worth proving. - Email subject: Invoice Chaser: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Invoice Chaser installed around one job, one owner, and one acceptance test. - Landing lead: A policy-aware receivables agent that follows up on overdue invoices, preserves customer context, and escalates disputes or sensitive cases for review. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Invoice Chaser: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Invoice Chaser can make measurable. - Offer: Invoice Chaser begins with a diagnostic for Freelancers, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where accounts receivable work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Invoice Chaser only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Invoice Chaser offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Invoice Chaser should remove. - Email subject: Where is Invoice Chaser worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Invoice Chaser one measurable job. - Landing lead: Recover time and cash without turning every overdue invoice into an awkward manual chase or an unreviewed automated threat. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Invoice Chaser: expertise into an offer - Headline: Turn the way your best people handle this work into a Invoice Chaser offer the whole team can use. - Offer: For Freelancers, Invoice Chaser packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for accounts receivable, structure their decisions into a guided Invoice Chaser workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Invoice Chaser workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Invoice Chaser should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Invoice Chaser should productize. - Email subject: Package your best operating knowledge with Invoice Chaser - Social hook: Your best operator already has a product in their head. Invoice Chaser can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A policy-aware receivables agent that follows up on overdue invoices, preserves customer context, and escalates disputes or sensitive cases for review. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Invoice Chaser: the compounding playbook - Headline: Stop rebuilding Invoice Chaser from prompts. Encode the playbook your operation can improve. - Offer: Invoice Chaser becomes a reusable operating layer for Freelancers: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Prioritizes overdue work from approved invoice and customer state,” encode the stable decisions, isolate customer data and permissions, and improve the Invoice Chaser playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Invoice Chaser release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Invoice Chaser separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Invoice Chaser should encode first. - Email subject: Make Invoice Chaser improve with every reviewed case - Social hook: Prompts are disposable. A versioned Invoice Chaser playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Recover time and cash without turning every overdue invoice into an awkward manual chase or an unreviewed automated threat. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Invoice Chaser: prove what compounds - Headline: If Invoice Chaser cannot connect its work to an observable result, it does not get credit. - Offer: Give Freelancers a Invoice Chaser deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Invoice Chaser input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Invoice Chaser should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Invoice Chaser pilot. - Email subject: What evidence would make Invoice Chaser worth expanding? - Social hook: The useful question is not whether Invoice Chaser ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A policy-aware receivables agent that follows up on overdue invoices, preserves customer context, and escalates disputes or sensitive cases for review. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Finance Operations Assistant Catalogue record: /apps/finance-operations-assistant Status: planned Claim boundary: Finance Operations Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Finance Operations Assistant: the installed outcome - Headline: Finance Operations Assistant, installed around one working outcome—not another AI subscription. - Offer: For Finance teams: a hosted pilot that starts with “Prepares and reconciles records for review,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current finance operations workflow, install the minimum Finance Operations Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Finance Operations Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Finance Operations Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Finance Operations Assistant installation worth proving. - Email subject: Finance Operations Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Finance Operations Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A finance workflow assistant that prepares AP, AR, reconciliation, and close work for accountable human review. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Finance Operations Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Finance Operations Assistant can make measurable. - Offer: Finance Operations Assistant begins with a diagnostic for Finance teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where finance operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Finance Operations Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Finance Operations Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Finance Operations Assistant should remove. - Email subject: Where is Finance Operations Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Finance Operations Assistant one measurable job. - Landing lead: Reduce repetitive finance preparation while keeping approvals, system authority, and segregation of duties explicit. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Finance Operations Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Finance Operations Assistant offer the whole team can use. - Offer: For Finance teams, Finance Operations Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for finance operations, structure their decisions into a guided Finance Operations Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Finance Operations Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Finance Operations Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Finance Operations Assistant should productize. - Email subject: Package your best operating knowledge with Finance Operations Assistant - Social hook: Your best operator already has a product in their head. Finance Operations Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A finance workflow assistant that prepares AP, AR, reconciliation, and close work for accountable human review. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Finance Operations Assistant: the compounding playbook - Headline: Stop rebuilding Finance Operations Assistant from prompts. Encode the playbook your operation can improve. - Offer: Finance Operations Assistant becomes a reusable operating layer for Finance teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Prepares and reconciles records for review,” encode the stable decisions, isolate customer data and permissions, and improve the Finance Operations Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Finance Operations Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Finance Operations Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Finance Operations Assistant should encode first. - Email subject: Make Finance Operations Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Finance Operations Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Reduce repetitive finance preparation while keeping approvals, system authority, and segregation of duties explicit. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Finance Operations Assistant: prove what compounds - Headline: If Finance Operations Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Finance teams a Finance Operations Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Finance Operations Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Finance Operations Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Finance Operations Assistant pilot. - Email subject: What evidence would make Finance Operations Assistant worth expanding? - Social hook: The useful question is not whether Finance Operations Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A finance workflow assistant that prepares AP, AR, reconciliation, and close work for accountable human review. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Attribution & Remarketing Catalogue record: /apps/ai-attribution-remarketing Status: planned Claim boundary: AI Attribution & Remarketing is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Attribution & Remarketing: the installed outcome - Headline: AI Attribution & Remarketing, installed around one working outcome—not another AI subscription. - Offer: For Paid-growth teams: a hosted pilot that starts with “Connects campaign, journey, conversion, and customer-value evidence,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current marketing intelligence workflow, install the minimum AI Attribution & Remarketing capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Attribution & Remarketing pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Attribution & Remarketing is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Attribution & Remarketing installation worth proving. - Email subject: AI Attribution & Remarketing: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Attribution & Remarketing installed around one job, one owner, and one acceptance test. - Landing lead: A paid-growth intelligence layer that connects customer journeys to revenue and turns approved behavior into accountable follow-up. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Attribution & Remarketing: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Attribution & Remarketing can make measurable. - Offer: AI Attribution & Remarketing begins with a diagnostic for Paid-growth teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where marketing intelligence work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Attribution & Remarketing only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Attribution & Remarketing offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Attribution & Remarketing should remove. - Email subject: Where is AI Attribution & Remarketing worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Attribution & Remarketing one measurable job. - Landing lead: Show which journeys create valuable customers, then use approved context to improve targeting and follow-up without inventing attribution certainty. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Attribution & Remarketing: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Attribution & Remarketing offer the whole team can use. - Offer: For Paid-growth teams, AI Attribution & Remarketing packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for marketing intelligence, structure their decisions into a guided AI Attribution & Remarketing workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Attribution & Remarketing workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Attribution & Remarketing should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Attribution & Remarketing should productize. - Email subject: Package your best operating knowledge with AI Attribution & Remarketing - Social hook: Your best operator already has a product in their head. AI Attribution & Remarketing can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A paid-growth intelligence layer that connects customer journeys to revenue and turns approved behavior into accountable follow-up. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Attribution & Remarketing: the compounding playbook - Headline: Stop rebuilding AI Attribution & Remarketing from prompts. Encode the playbook your operation can improve. - Offer: AI Attribution & Remarketing becomes a reusable operating layer for Paid-growth teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Connects campaign, journey, conversion, and customer-value evidence,” encode the stable decisions, isolate customer data and permissions, and improve the AI Attribution & Remarketing playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Attribution & Remarketing release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Attribution & Remarketing separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Attribution & Remarketing should encode first. - Email subject: Make AI Attribution & Remarketing improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Attribution & Remarketing playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Show which journeys create valuable customers, then use approved context to improve targeting and follow-up without inventing attribution certainty. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Attribution & Remarketing: prove what compounds - Headline: If AI Attribution & Remarketing cannot connect its work to an observable result, it does not get credit. - Offer: Give Paid-growth teams a AI Attribution & Remarketing deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Attribution & Remarketing input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Attribution & Remarketing should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Attribution & Remarketing pilot. - Email subject: What evidence would make AI Attribution & Remarketing worth expanding? - Social hook: The useful question is not whether AI Attribution & Remarketing ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A paid-growth intelligence layer that connects customer journeys to revenue and turns approved behavior into accountable follow-up. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Hermes Financial Adviser Catalogue record: /apps/hermes-financial-adviser Status: planned Claim boundary: Hermes Financial Adviser is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Hermes Financial Adviser: the installed outcome - Headline: Hermes Financial Adviser, installed around one working outcome—not another AI subscription. - Offer: For Operators: a custom build pilot that starts with “Research markets, positions, and operating assumptions with cited inputs,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current financial intelligence workflow, install the minimum Hermes Financial Adviser capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Hermes Financial Adviser pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Hermes Financial Adviser is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Hermes Financial Adviser installation worth proving. - Email subject: Hermes Financial Adviser: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Hermes Financial Adviser installed around one job, one owner, and one acceptance test. - Landing lead: A dedicated Hermes financial decision-support agent for research, monitoring, scenario analysis, and disciplined human-reviewed action. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Hermes Financial Adviser: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Hermes Financial Adviser can make measurable. - Offer: Hermes Financial Adviser begins with a diagnostic for Operators, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where financial intelligence work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Hermes Financial Adviser only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Hermes Financial Adviser offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Hermes Financial Adviser should remove. - Email subject: Where is Hermes Financial Adviser worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Hermes Financial Adviser one measurable job. - Landing lead: A disciplined financial intelligence layer that turns market and operating inputs into traceable scenarios and decisions, with suitability and execution boundaries kept explicit. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Hermes Financial Adviser: expertise into an offer - Headline: Turn the way your best people handle this work into a Hermes Financial Adviser offer the whole team can use. - Offer: For Operators, Hermes Financial Adviser packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for financial intelligence, structure their decisions into a guided Hermes Financial Adviser workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Hermes Financial Adviser workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Hermes Financial Adviser should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Hermes Financial Adviser should productize. - Email subject: Package your best operating knowledge with Hermes Financial Adviser - Social hook: Your best operator already has a product in their head. Hermes Financial Adviser can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A dedicated Hermes financial decision-support agent for research, monitoring, scenario analysis, and disciplined human-reviewed action. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Hermes Financial Adviser: the compounding playbook - Headline: Stop rebuilding Hermes Financial Adviser from prompts. Encode the playbook your operation can improve. - Offer: Hermes Financial Adviser becomes a reusable operating layer for Operators: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Research markets, positions, and operating assumptions with cited inputs,” encode the stable decisions, isolate customer data and permissions, and improve the Hermes Financial Adviser playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Hermes Financial Adviser release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Hermes Financial Adviser separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Hermes Financial Adviser should encode first. - Email subject: Make Hermes Financial Adviser improve with every reviewed case - Social hook: Prompts are disposable. A versioned Hermes Financial Adviser playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A disciplined financial intelligence layer that turns market and operating inputs into traceable scenarios and decisions, with suitability and execution boundaries kept explicit. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Hermes Financial Adviser: prove what compounds - Headline: If Hermes Financial Adviser cannot connect its work to an observable result, it does not get credit. - Offer: Give Operators a Hermes Financial Adviser deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Hermes Financial Adviser input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Hermes Financial Adviser should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Hermes Financial Adviser pilot. - Email subject: What evidence would make Hermes Financial Adviser worth expanding? - Social hook: The useful question is not whether Hermes Financial Adviser ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A dedicated Hermes financial decision-support agent for research, monitoring, scenario analysis, and disciplined human-reviewed action. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Personal Tutor Assistant Catalogue record: /apps/personal-tutor Status: planned Claim boundary: Personal Tutor Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Personal Tutor Assistant: the installed outcome - Headline: Personal Tutor Assistant, installed around one working outcome—not another AI subscription. - Offer: For Learners: a hosted pilot that starts with “Adjusts explanations to a learner’s current context,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current learning workflow, install the minimum Personal Tutor Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Personal Tutor Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Personal Tutor Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Personal Tutor Assistant installation worth proving. - Email subject: Personal Tutor Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Personal Tutor Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A patient tutor assistant that adapts explanations, practice, and feedback to the learner instead of serving the same lesson to everyone. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Personal Tutor Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Personal Tutor Assistant can make measurable. - Offer: Personal Tutor Assistant begins with a diagnostic for Learners, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where learning work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Personal Tutor Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Personal Tutor Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Personal Tutor Assistant should remove. - Email subject: Where is Personal Tutor Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Personal Tutor Assistant one measurable job. - Landing lead: Sell the personalized learning loop: explain, practice, notice confusion, and try again. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Personal Tutor Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Personal Tutor Assistant offer the whole team can use. - Offer: For Learners, Personal Tutor Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for learning, structure their decisions into a guided Personal Tutor Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Personal Tutor Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Personal Tutor Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Personal Tutor Assistant should productize. - Email subject: Package your best operating knowledge with Personal Tutor Assistant - Social hook: Your best operator already has a product in their head. Personal Tutor Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A patient tutor assistant that adapts explanations, practice, and feedback to the learner instead of serving the same lesson to everyone. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Personal Tutor Assistant: the compounding playbook - Headline: Stop rebuilding Personal Tutor Assistant from prompts. Encode the playbook your operation can improve. - Offer: Personal Tutor Assistant becomes a reusable operating layer for Learners: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Adjusts explanations to a learner’s current context,” encode the stable decisions, isolate customer data and permissions, and improve the Personal Tutor Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Personal Tutor Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Personal Tutor Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Personal Tutor Assistant should encode first. - Email subject: Make Personal Tutor Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Personal Tutor Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Sell the personalized learning loop: explain, practice, notice confusion, and try again. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Personal Tutor Assistant: prove what compounds - Headline: If Personal Tutor Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Learners a Personal Tutor Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Personal Tutor Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Personal Tutor Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Personal Tutor Assistant pilot. - Email subject: What evidence would make Personal Tutor Assistant worth expanding? - Social hook: The useful question is not whether Personal Tutor Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A patient tutor assistant that adapts explanations, practice, and feedback to the learner instead of serving the same lesson to everyone. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Lead Generation Catalogue record: /apps/ai-lead-generation Status: planned Claim boundary: AI Lead Generation is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Lead Generation: the installed outcome - Headline: AI Lead Generation, installed around one working outcome—not another AI subscription. - Offer: For B2B companies: a hosted pilot that starts with “Builds prospect lists from an explicit ideal-customer profile,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum AI Lead Generation capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Lead Generation pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Lead Generation is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Lead Generation installation worth proving. - Email subject: AI Lead Generation: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Lead Generation installed around one job, one owner, and one acceptance test. - Landing lead: A research and prospecting agent that turns an ideal-customer profile into sourced, scored, and reviewable opportunities. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Lead Generation: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Lead Generation can make measurable. - Offer: AI Lead Generation begins with a diagnostic for B2B companies, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Lead Generation only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Lead Generation offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Lead Generation should remove. - Email subject: Where is AI Lead Generation worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Lead Generation one measurable job. - Landing lead: Replace brittle list buying with an evidence-bearing prospecting loop that shows why each account fits and what should happen next. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Lead Generation: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Lead Generation offer the whole team can use. - Offer: For B2B companies, AI Lead Generation packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided AI Lead Generation workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Lead Generation workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Lead Generation should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Lead Generation should productize. - Email subject: Package your best operating knowledge with AI Lead Generation - Social hook: Your best operator already has a product in their head. AI Lead Generation can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A research and prospecting agent that turns an ideal-customer profile into sourced, scored, and reviewable opportunities. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Lead Generation: the compounding playbook - Headline: Stop rebuilding AI Lead Generation from prompts. Encode the playbook your operation can improve. - Offer: AI Lead Generation becomes a reusable operating layer for B2B companies: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Builds prospect lists from an explicit ideal-customer profile,” encode the stable decisions, isolate customer data and permissions, and improve the AI Lead Generation playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Lead Generation release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Lead Generation separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Lead Generation should encode first. - Email subject: Make AI Lead Generation improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Lead Generation playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Replace brittle list buying with an evidence-bearing prospecting loop that shows why each account fits and what should happen next. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Lead Generation: prove what compounds - Headline: If AI Lead Generation cannot connect its work to an observable result, it does not get credit. - Offer: Give B2B companies a AI Lead Generation deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Lead Generation input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Lead Generation should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Lead Generation pilot. - Email subject: What evidence would make AI Lead Generation worth expanding? - Social hook: The useful question is not whether AI Lead Generation ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A research and prospecting agent that turns an ideal-customer profile into sourced, scored, and reviewable opportunities. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Qualifier Catalogue record: /apps/ai-qualifier Status: planned Claim boundary: AI Qualifier is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Qualifier: the installed outcome - Headline: AI Qualifier, installed around one working outcome—not another AI subscription. - Offer: For B2B companies: a hosted pilot that starts with “Applies a buyer-owned fit and readiness rubric,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum AI Qualifier capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Qualifier pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Qualifier is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Qualifier installation worth proving. - Email subject: AI Qualifier: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Qualifier installed around one job, one owner, and one acceptance test. - Landing lead: A qualification agent that tests fit, urgency, authority, and next-step readiness against the seller's actual rubric. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Qualifier: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Qualifier can make measurable. - Offer: AI Qualifier begins with a diagnostic for B2B companies, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Qualifier only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Qualifier offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Qualifier should remove. - Email subject: Where is AI Qualifier worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Qualifier one measurable job. - Landing lead: Give salespeople fewer dead-end conversations and a defensible reason each opportunity should advance, nurture, or stop. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Qualifier: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Qualifier offer the whole team can use. - Offer: For B2B companies, AI Qualifier packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided AI Qualifier workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Qualifier workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Qualifier should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Qualifier should productize. - Email subject: Package your best operating knowledge with AI Qualifier - Social hook: Your best operator already has a product in their head. AI Qualifier can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A qualification agent that tests fit, urgency, authority, and next-step readiness against the seller's actual rubric. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Qualifier: the compounding playbook - Headline: Stop rebuilding AI Qualifier from prompts. Encode the playbook your operation can improve. - Offer: AI Qualifier becomes a reusable operating layer for B2B companies: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Applies a buyer-owned fit and readiness rubric,” encode the stable decisions, isolate customer data and permissions, and improve the AI Qualifier playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Qualifier release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Qualifier separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Qualifier should encode first. - Email subject: Make AI Qualifier improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Qualifier playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Give salespeople fewer dead-end conversations and a defensible reason each opportunity should advance, nurture, or stop. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Qualifier: prove what compounds - Headline: If AI Qualifier cannot connect its work to an observable result, it does not get credit. - Offer: Give B2B companies a AI Qualifier deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Qualifier input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Qualifier should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Qualifier pilot. - Email subject: What evidence would make AI Qualifier worth expanding? - Social hook: The useful question is not whether AI Qualifier ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A qualification agent that tests fit, urgency, authority, and next-step readiness against the seller's actual rubric. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Setter Catalogue record: /apps/ai-setter Status: planned Claim boundary: AI Setter is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Setter: the installed outcome - Headline: AI Setter, installed around one working outcome—not another AI subscription. - Offer: For High-ticket teams: a hosted pilot that starts with “Works from qualified context and an approved outreach policy,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum AI Setter capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Setter pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Setter is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Setter installation worth proving. - Email subject: AI Setter: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Setter installed around one job, one owner, and one acceptance test. - Landing lead: An appointment-setting agent that follows up with qualified prospects, resolves scheduling friction, and records the handoff. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Setter: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Setter can make measurable. - Offer: AI Setter begins with a diagnostic for High-ticket teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Setter only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Setter offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Setter should remove. - Email subject: Where is AI Setter worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Setter one measurable job. - Landing lead: Turn qualified interest into attended conversations through timely, contextual follow-up instead of generic calendar-link spam. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Setter: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Setter offer the whole team can use. - Offer: For High-ticket teams, AI Setter packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided AI Setter workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Setter workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Setter should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Setter should productize. - Email subject: Package your best operating knowledge with AI Setter - Social hook: Your best operator already has a product in their head. AI Setter can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: An appointment-setting agent that follows up with qualified prospects, resolves scheduling friction, and records the handoff. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Setter: the compounding playbook - Headline: Stop rebuilding AI Setter from prompts. Encode the playbook your operation can improve. - Offer: AI Setter becomes a reusable operating layer for High-ticket teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Works from qualified context and an approved outreach policy,” encode the stable decisions, isolate customer data and permissions, and improve the AI Setter playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Setter release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Setter separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Setter should encode first. - Email subject: Make AI Setter improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Setter playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Turn qualified interest into attended conversations through timely, contextual follow-up instead of generic calendar-link spam. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Setter: prove what compounds - Headline: If AI Setter cannot connect its work to an observable result, it does not get credit. - Offer: Give High-ticket teams a AI Setter deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Setter input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Setter should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Setter pilot. - Email subject: What evidence would make AI Setter worth expanding? - Social hook: The useful question is not whether AI Setter ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: An appointment-setting agent that follows up with qualified prospects, resolves scheduling friction, and records the handoff. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Dialer Catalogue record: /apps/ai-dialer Status: planned Claim boundary: AI Dialer is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Dialer: the installed outcome - Headline: AI Dialer, installed around one working outcome—not another AI subscription. - Offer: For High-ticket teams: a hosted pilot that starts with “Calls only within configured consent, timing, and jurisdiction rules,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum AI Dialer capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Dialer pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Dialer is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Dialer installation worth proving. - Email subject: AI Dialer: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Dialer installed around one job, one owner, and one acceptance test. - Landing lead: A voice agent for approved calls, fast lead response, structured discovery, disposition capture, and live human handoff. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Dialer: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Dialer can make measurable. - Offer: AI Dialer begins with a diagnostic for High-ticket teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Dialer only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Dialer offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Dialer should remove. - Email subject: Where is AI Dialer worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Dialer one measurable job. - Landing lead: Make every permitted call timely and accountable, with a bounded script, clear escalation, and a complete disposition after the conversation. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Dialer: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Dialer offer the whole team can use. - Offer: For High-ticket teams, AI Dialer packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided AI Dialer workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Dialer workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Dialer should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Dialer should productize. - Email subject: Package your best operating knowledge with AI Dialer - Social hook: Your best operator already has a product in their head. AI Dialer can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A voice agent for approved calls, fast lead response, structured discovery, disposition capture, and live human handoff. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Dialer: the compounding playbook - Headline: Stop rebuilding AI Dialer from prompts. Encode the playbook your operation can improve. - Offer: AI Dialer becomes a reusable operating layer for High-ticket teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Calls only within configured consent, timing, and jurisdiction rules,” encode the stable decisions, isolate customer data and permissions, and improve the AI Dialer playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Dialer release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Dialer separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Dialer should encode first. - Email subject: Make AI Dialer improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Dialer playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Make every permitted call timely and accountable, with a bounded script, clear escalation, and a complete disposition after the conversation. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Dialer: prove what compounds - Headline: If AI Dialer cannot connect its work to an observable result, it does not get credit. - Offer: Give High-ticket teams a AI Dialer deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Dialer input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Dialer should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Dialer pilot. - Email subject: What evidence would make AI Dialer worth expanding? - Social hook: The useful question is not whether AI Dialer ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A voice agent for approved calls, fast lead response, structured discovery, disposition capture, and live human handoff. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Salesman Catalogue record: /apps/ai-salesman Status: planned Claim boundary: AI Salesman is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Salesman: the installed outcome - Headline: AI Salesman, installed around one working outcome—not another AI subscription. - Offer: For High-ticket teams: a hosted pilot that starts with “Maintains one evidence-backed opportunity brief across the cycle,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum AI Salesman capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Salesman pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Salesman is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Salesman installation worth proving. - Email subject: AI Salesman: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Salesman installed around one job, one owner, and one acceptance test. - Landing lead: A full-cycle sales agent that carries verified context from discovery through objection handling, proposal, and bounded close. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Salesman: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Salesman can make measurable. - Offer: AI Salesman begins with a diagnostic for High-ticket teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Salesman only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Salesman offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Salesman should remove. - Email subject: Where is AI Salesman worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Salesman one measurable job. - Landing lead: Add selling capacity without surrendering control of claims, pricing, discounts, contracts, or the customer relationship. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Salesman: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Salesman offer the whole team can use. - Offer: For High-ticket teams, AI Salesman packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided AI Salesman workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Salesman workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Salesman should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Salesman should productize. - Email subject: Package your best operating knowledge with AI Salesman - Social hook: Your best operator already has a product in their head. AI Salesman can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A full-cycle sales agent that carries verified context from discovery through objection handling, proposal, and bounded close. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Salesman: the compounding playbook - Headline: Stop rebuilding AI Salesman from prompts. Encode the playbook your operation can improve. - Offer: AI Salesman becomes a reusable operating layer for High-ticket teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Maintains one evidence-backed opportunity brief across the cycle,” encode the stable decisions, isolate customer data and permissions, and improve the AI Salesman playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Salesman release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Salesman separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Salesman should encode first. - Email subject: Make AI Salesman improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Salesman playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Add selling capacity without surrendering control of claims, pricing, discounts, contracts, or the customer relationship. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Salesman: prove what compounds - Headline: If AI Salesman cannot connect its work to an observable result, it does not get credit. - Offer: Give High-ticket teams a AI Salesman deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Salesman input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Salesman should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Salesman pilot. - Email subject: What evidence would make AI Salesman worth expanding? - Social hook: The useful question is not whether AI Salesman ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A full-cycle sales agent that carries verified context from discovery through objection handling, proposal, and bounded close. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Stylist Catalogue record: /apps/ai-stylist Status: planned Claim boundary: AI Stylist is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Stylist: the installed outcome - Headline: AI Stylist, installed around one working outcome—not another AI subscription. - Offer: For Consumers: a hosted pilot that starts with “Builds outfit ideas from wardrobe, occasion, and preference context,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current personal style workflow, install the minimum AI Stylist capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Stylist pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Stylist is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Stylist installation worth proving. - Email subject: AI Stylist: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Stylist installed around one job, one owner, and one acceptance test. - Landing lead: A personal style concierge that learns wardrobe context and preferences, assembles outfits, and narrows shopping choices without taking over the final decision. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Stylist: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Stylist can make measurable. - Offer: AI Stylist begins with a diagnostic for Consumers, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where personal style work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Stylist only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Stylist offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Stylist should remove. - Email subject: Where is AI Stylist worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Stylist one measurable job. - Landing lead: Sell a clearer path from what someone owns and likes to what they can wear or buy next, with a white-label path for commerce partners. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Stylist: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Stylist offer the whole team can use. - Offer: For Consumers, AI Stylist packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for personal style, structure their decisions into a guided AI Stylist workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Stylist workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Stylist should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Stylist should productize. - Email subject: Package your best operating knowledge with AI Stylist - Social hook: Your best operator already has a product in their head. AI Stylist can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A personal style concierge that learns wardrobe context and preferences, assembles outfits, and narrows shopping choices without taking over the final decision. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Stylist: the compounding playbook - Headline: Stop rebuilding AI Stylist from prompts. Encode the playbook your operation can improve. - Offer: AI Stylist becomes a reusable operating layer for Consumers: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Builds outfit ideas from wardrobe, occasion, and preference context,” encode the stable decisions, isolate customer data and permissions, and improve the AI Stylist playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Stylist release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Stylist separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Stylist should encode first. - Email subject: Make AI Stylist improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Stylist playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Sell a clearer path from what someone owns and likes to what they can wear or buy next, with a white-label path for commerce partners. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Stylist: prove what compounds - Headline: If AI Stylist cannot connect its work to an observable result, it does not get credit. - Offer: Give Consumers a AI Stylist deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Stylist input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Stylist should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Stylist pilot. - Email subject: What evidence would make AI Stylist worth expanding? - Social hook: The useful question is not whether AI Stylist ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A personal style concierge that learns wardrobe context and preferences, assembles outfits, and narrows shopping choices without taking over the final decision. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Lead Recovery Operator Catalogue record: /apps/lead-recovery-operator Status: planned Claim boundary: Lead Recovery Operator is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Lead Recovery Operator: the installed outcome - Headline: Lead Recovery Operator, installed around one working outcome—not another AI subscription. - Offer: For Sales teams: a hosted pilot that starts with “Works only with consented or authorized contacts,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current revenue operations workflow, install the minimum Lead Recovery Operator capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Lead Recovery Operator pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Lead Recovery Operator is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Lead Recovery Operator installation worth proving. - Email subject: Lead Recovery Operator: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Lead Recovery Operator installed around one job, one owner, and one acceptance test. - Landing lead: A governed follow-up operator for already-known leads whose conversations stalled before a clear next step. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Lead Recovery Operator: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Lead Recovery Operator can make measurable. - Offer: Lead Recovery Operator begins with a diagnostic for Sales teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where revenue operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Lead Recovery Operator only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Lead Recovery Operator offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Lead Recovery Operator should remove. - Email subject: Where is Lead Recovery Operator worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Lead Recovery Operator one measurable job. - Landing lead: Recover value from consented, already-known leads with traceable follow-up and a firm boundary around contact authority. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Lead Recovery Operator: expertise into an offer - Headline: Turn the way your best people handle this work into a Lead Recovery Operator offer the whole team can use. - Offer: For Sales teams, Lead Recovery Operator packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for revenue operations, structure their decisions into a guided Lead Recovery Operator workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Lead Recovery Operator workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Lead Recovery Operator should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Lead Recovery Operator should productize. - Email subject: Package your best operating knowledge with Lead Recovery Operator - Social hook: Your best operator already has a product in their head. Lead Recovery Operator can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A governed follow-up operator for already-known leads whose conversations stalled before a clear next step. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Lead Recovery Operator: the compounding playbook - Headline: Stop rebuilding Lead Recovery Operator from prompts. Encode the playbook your operation can improve. - Offer: Lead Recovery Operator becomes a reusable operating layer for Sales teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Works only with consented or authorized contacts,” encode the stable decisions, isolate customer data and permissions, and improve the Lead Recovery Operator playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Lead Recovery Operator release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Lead Recovery Operator separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Lead Recovery Operator should encode first. - Email subject: Make Lead Recovery Operator improve with every reviewed case - Social hook: Prompts are disposable. A versioned Lead Recovery Operator playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Recover value from consented, already-known leads with traceable follow-up and a firm boundary around contact authority. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Lead Recovery Operator: prove what compounds - Headline: If Lead Recovery Operator cannot connect its work to an observable result, it does not get credit. - Offer: Give Sales teams a Lead Recovery Operator deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Lead Recovery Operator input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Lead Recovery Operator should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Lead Recovery Operator pilot. - Email subject: What evidence would make Lead Recovery Operator worth expanding? - Social hook: The useful question is not whether Lead Recovery Operator ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A governed follow-up operator for already-known leads whose conversations stalled before a clear next step. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Legal Advice Assistant Catalogue record: /apps/legal-advice-assistant Status: planned Claim boundary: Legal Advice Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Legal Advice Assistant: the installed outcome - Headline: Legal Advice Assistant, installed around one working outcome—not another AI subscription. - Offer: For Legal teams: a custom build pilot that starts with “Summarizes and compares approved legal materials,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current legal workflows workflow, install the minimum Legal Advice Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Legal Advice Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Legal Advice Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Legal Advice Assistant installation worth proving. - Email subject: Legal Advice Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Legal Advice Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A legal-workflow assistant for research, issue spotting, document explanation, and preparation with careful limits around professional advice. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Legal Advice Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Legal Advice Assistant can make measurable. - Offer: Legal Advice Assistant begins with a diagnostic for Legal teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where legal workflows work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Legal Advice Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Legal Advice Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Legal Advice Assistant should remove. - Email subject: Where is Legal Advice Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Legal Advice Assistant one measurable job. - Landing lead: A Harvey-like workflow wedge: make legal work easier to prepare and review, never blur assistance into unauthorized practice. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Legal Advice Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Legal Advice Assistant offer the whole team can use. - Offer: For Legal teams, Legal Advice Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for legal workflows, structure their decisions into a guided Legal Advice Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Legal Advice Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Legal Advice Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Legal Advice Assistant should productize. - Email subject: Package your best operating knowledge with Legal Advice Assistant - Social hook: Your best operator already has a product in their head. Legal Advice Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A legal-workflow assistant for research, issue spotting, document explanation, and preparation with careful limits around professional advice. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Legal Advice Assistant: the compounding playbook - Headline: Stop rebuilding Legal Advice Assistant from prompts. Encode the playbook your operation can improve. - Offer: Legal Advice Assistant becomes a reusable operating layer for Legal teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Summarizes and compares approved legal materials,” encode the stable decisions, isolate customer data and permissions, and improve the Legal Advice Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Legal Advice Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Legal Advice Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Legal Advice Assistant should encode first. - Email subject: Make Legal Advice Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Legal Advice Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A Harvey-like workflow wedge: make legal work easier to prepare and review, never blur assistance into unauthorized practice. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Legal Advice Assistant: prove what compounds - Headline: If Legal Advice Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Legal teams a Legal Advice Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Legal Advice Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Legal Advice Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Legal Advice Assistant pilot. - Email subject: What evidence would make Legal Advice Assistant worth expanding? - Social hook: The useful question is not whether Legal Advice Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A legal-workflow assistant for research, issue spotting, document explanation, and preparation with careful limits around professional advice. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Digital Product Studio Catalogue record: /apps/ai-digital-product-studio Status: planned Claim boundary: AI Digital Product Studio is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Digital Product Studio: the installed outcome - Headline: AI Digital Product Studio, installed around one working outcome—not another AI subscription. - Offer: For Creators: a hosted pilot that starts with “Finds repeated audience problems in approved research and content,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current creator commerce workflow, install the minimum AI Digital Product Studio capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Digital Product Studio pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Digital Product Studio is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Digital Product Studio installation worth proving. - Email subject: AI Digital Product Studio: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Digital Product Studio installed around one job, one owner, and one acceptance test. - Landing lead: A product system for turning approved expertise and audience evidence into a course, guide, community, or coaching offer. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Digital Product Studio: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Digital Product Studio can make measurable. - Offer: AI Digital Product Studio begins with a diagnostic for Creators, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where creator commerce work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Digital Product Studio only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Digital Product Studio offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Digital Product Studio should remove. - Email subject: Where is AI Digital Product Studio worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Digital Product Studio one measurable job. - Landing lead: Turn real expertise into a coherent product and launch system without replacing the expert, borrowing trust carelessly, or fabricating demand. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Digital Product Studio: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Digital Product Studio offer the whole team can use. - Offer: For Creators, AI Digital Product Studio packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for creator commerce, structure their decisions into a guided AI Digital Product Studio workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Digital Product Studio workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Digital Product Studio should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Digital Product Studio should productize. - Email subject: Package your best operating knowledge with AI Digital Product Studio - Social hook: Your best operator already has a product in their head. AI Digital Product Studio can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A product system for turning approved expertise and audience evidence into a course, guide, community, or coaching offer. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Digital Product Studio: the compounding playbook - Headline: Stop rebuilding AI Digital Product Studio from prompts. Encode the playbook your operation can improve. - Offer: AI Digital Product Studio becomes a reusable operating layer for Creators: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Finds repeated audience problems in approved research and content,” encode the stable decisions, isolate customer data and permissions, and improve the AI Digital Product Studio playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Digital Product Studio release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Digital Product Studio separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Digital Product Studio should encode first. - Email subject: Make AI Digital Product Studio improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Digital Product Studio playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Turn real expertise into a coherent product and launch system without replacing the expert, borrowing trust carelessly, or fabricating demand. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Digital Product Studio: prove what compounds - Headline: If AI Digital Product Studio cannot connect its work to an observable result, it does not get credit. - Offer: Give Creators a AI Digital Product Studio deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Digital Product Studio input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Digital Product Studio should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Digital Product Studio pilot. - Email subject: What evidence would make AI Digital Product Studio worth expanding? - Social hook: The useful question is not whether AI Digital Product Studio ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A product system for turning approved expertise and audience evidence into a course, guide, community, or coaching offer. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Marketing Campaign Studio Catalogue record: /apps/marketing-campaign-studio Status: planned Claim boundary: Marketing Campaign Studio is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Marketing Campaign Studio: the installed outcome - Headline: Marketing Campaign Studio, installed around one working outcome—not another AI subscription. - Offer: For Marketing teams: a hosted pilot that starts with “Builds review-ready campaign variants from an approved brief,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current marketing production workflow, install the minimum Marketing Campaign Studio capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Marketing Campaign Studio pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Marketing Campaign Studio is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Marketing Campaign Studio installation worth proving. - Email subject: Marketing Campaign Studio: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Marketing Campaign Studio installed around one job, one owner, and one acceptance test. - Landing lead: A governed campaign studio for producing creative variants, launch assets, and review-ready marketing packages. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Marketing Campaign Studio: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Marketing Campaign Studio can make measurable. - Offer: Marketing Campaign Studio begins with a diagnostic for Marketing teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where marketing production work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Marketing Campaign Studio only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Marketing Campaign Studio offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Marketing Campaign Studio should remove. - Email subject: Where is Marketing Campaign Studio worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Marketing Campaign Studio one measurable job. - Landing lead: Increase campaign production capacity while keeping claims, rights, publication, and spend under accountable control. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Marketing Campaign Studio: expertise into an offer - Headline: Turn the way your best people handle this work into a Marketing Campaign Studio offer the whole team can use. - Offer: For Marketing teams, Marketing Campaign Studio packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for marketing production, structure their decisions into a guided Marketing Campaign Studio workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Marketing Campaign Studio workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Marketing Campaign Studio should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Marketing Campaign Studio should productize. - Email subject: Package your best operating knowledge with Marketing Campaign Studio - Social hook: Your best operator already has a product in their head. Marketing Campaign Studio can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A governed campaign studio for producing creative variants, launch assets, and review-ready marketing packages. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Marketing Campaign Studio: the compounding playbook - Headline: Stop rebuilding Marketing Campaign Studio from prompts. Encode the playbook your operation can improve. - Offer: Marketing Campaign Studio becomes a reusable operating layer for Marketing teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Builds review-ready campaign variants from an approved brief,” encode the stable decisions, isolate customer data and permissions, and improve the Marketing Campaign Studio playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Marketing Campaign Studio release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Marketing Campaign Studio separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Marketing Campaign Studio should encode first. - Email subject: Make Marketing Campaign Studio improve with every reviewed case - Social hook: Prompts are disposable. A versioned Marketing Campaign Studio playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Increase campaign production capacity while keeping claims, rights, publication, and spend under accountable control. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Marketing Campaign Studio: prove what compounds - Headline: If Marketing Campaign Studio cannot connect its work to an observable result, it does not get credit. - Offer: Give Marketing teams a Marketing Campaign Studio deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Marketing Campaign Studio input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Marketing Campaign Studio should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Marketing Campaign Studio pilot. - Email subject: What evidence would make Marketing Campaign Studio worth expanding? - Social hook: The useful question is not whether Marketing Campaign Studio ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A governed campaign studio for producing creative variants, launch assets, and review-ready marketing packages. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Expert Knowledge Assistant Catalogue record: /apps/expert-knowledge-assistant Status: planned Claim boundary: Expert Knowledge Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Expert Knowledge Assistant: the installed outcome - Headline: Expert Knowledge Assistant, installed around one working outcome—not another AI subscription. - Offer: For Experts: a hosted pilot that starts with “Answers from an approved, versioned source library,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current knowledge products workflow, install the minimum Expert Knowledge Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Expert Knowledge Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Expert Knowledge Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Expert Knowledge Assistant installation worth proving. - Email subject: Expert Knowledge Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Expert Knowledge Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A source-grounded advisor that makes an expert's approved books, lessons, frameworks, and decisions available as an interactive product. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Expert Knowledge Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Expert Knowledge Assistant can make measurable. - Offer: Expert Knowledge Assistant begins with a diagnostic for Experts, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where knowledge products work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Expert Knowledge Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Expert Knowledge Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Expert Knowledge Assistant should remove. - Email subject: Where is Expert Knowledge Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Expert Knowledge Assistant one measurable job. - Landing lead: Package a trusted body of work as a useful advisor with citations, identity boundaries, update ownership, and a clear route to the human expert. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Expert Knowledge Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Expert Knowledge Assistant offer the whole team can use. - Offer: For Experts, Expert Knowledge Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for knowledge products, structure their decisions into a guided Expert Knowledge Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Expert Knowledge Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Expert Knowledge Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Expert Knowledge Assistant should productize. - Email subject: Package your best operating knowledge with Expert Knowledge Assistant - Social hook: Your best operator already has a product in their head. Expert Knowledge Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A source-grounded advisor that makes an expert's approved books, lessons, frameworks, and decisions available as an interactive product. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Expert Knowledge Assistant: the compounding playbook - Headline: Stop rebuilding Expert Knowledge Assistant from prompts. Encode the playbook your operation can improve. - Offer: Expert Knowledge Assistant becomes a reusable operating layer for Experts: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Answers from an approved, versioned source library,” encode the stable decisions, isolate customer data and permissions, and improve the Expert Knowledge Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Expert Knowledge Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Expert Knowledge Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Expert Knowledge Assistant should encode first. - Email subject: Make Expert Knowledge Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Expert Knowledge Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Package a trusted body of work as a useful advisor with citations, identity boundaries, update ownership, and a clear route to the human expert. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Expert Knowledge Assistant: prove what compounds - Headline: If Expert Knowledge Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Experts a Expert Knowledge Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Expert Knowledge Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Expert Knowledge Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Expert Knowledge Assistant pilot. - Email subject: What evidence would make Expert Knowledge Assistant worth expanding? - Social hook: The useful question is not whether Expert Knowledge Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A source-grounded advisor that makes an expert's approved books, lessons, frameworks, and decisions available as an interactive product. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Document Operations Agent Catalogue record: /apps/document-operations-agent Status: planned Claim boundary: Document Operations Agent is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Document Operations Agent: the installed outcome - Headline: Document Operations Agent, installed around one working outcome—not another AI subscription. - Offer: For Operations teams: a hosted pilot that starts with “Extracts fields only from authorized source documents,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current business operations workflow, install the minimum Document Operations Agent capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Document Operations Agent pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Document Operations Agent is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Document Operations Agent installation worth proving. - Email subject: Document Operations Agent: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Document Operations Agent installed around one job, one owner, and one acceptance test. - Landing lead: A document workflow agent that extracts, validates, and routes business data while making uncertainty and exceptions visible. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Document Operations Agent: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Document Operations Agent can make measurable. - Offer: Document Operations Agent begins with a diagnostic for Operations teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where business operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Document Operations Agent only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Document Operations Agent offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Document Operations Agent should remove. - Email subject: Where is Document Operations Agent worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Document Operations Agent one measurable job. - Landing lead: Turn recurring document handling into a traceable workflow without hiding uncertainty or bypassing the people accountable for exceptions. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Document Operations Agent: expertise into an offer - Headline: Turn the way your best people handle this work into a Document Operations Agent offer the whole team can use. - Offer: For Operations teams, Document Operations Agent packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for business operations, structure their decisions into a guided Document Operations Agent workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Document Operations Agent workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Document Operations Agent should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Document Operations Agent should productize. - Email subject: Package your best operating knowledge with Document Operations Agent - Social hook: Your best operator already has a product in their head. Document Operations Agent can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A document workflow agent that extracts, validates, and routes business data while making uncertainty and exceptions visible. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Document Operations Agent: the compounding playbook - Headline: Stop rebuilding Document Operations Agent from prompts. Encode the playbook your operation can improve. - Offer: Document Operations Agent becomes a reusable operating layer for Operations teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Extracts fields only from authorized source documents,” encode the stable decisions, isolate customer data and permissions, and improve the Document Operations Agent playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Document Operations Agent release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Document Operations Agent separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Document Operations Agent should encode first. - Email subject: Make Document Operations Agent improve with every reviewed case - Social hook: Prompts are disposable. A versioned Document Operations Agent playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Turn recurring document handling into a traceable workflow without hiding uncertainty or bypassing the people accountable for exceptions. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Document Operations Agent: prove what compounds - Headline: If Document Operations Agent cannot connect its work to an observable result, it does not get credit. - Offer: Give Operations teams a Document Operations Agent deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Document Operations Agent input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Document Operations Agent should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Document Operations Agent pilot. - Email subject: What evidence would make Document Operations Agent worth expanding? - Social hook: The useful question is not whether Document Operations Agent ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A document workflow agent that extracts, validates, and routes business data while making uncertainty and exceptions visible. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Internal Knowledge Assistant Catalogue record: /apps/internal-knowledge-assistant Status: planned Claim boundary: Internal Knowledge Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Internal Knowledge Assistant: the installed outcome - Headline: Internal Knowledge Assistant, installed around one working outcome—not another AI subscription. - Offer: For Companies: a hosted pilot that starts with “Answers from an organization’s approved source material,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current business operations workflow, install the minimum Internal Knowledge Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Internal Knowledge Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Internal Knowledge Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Internal Knowledge Assistant installation worth proving. - Email subject: Internal Knowledge Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Internal Knowledge Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A private knowledge assistant that helps teams find answers, understand decisions, and work from the source material they already own. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Internal Knowledge Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Internal Knowledge Assistant can make measurable. - Offer: Internal Knowledge Assistant begins with a diagnostic for Companies, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where business operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Internal Knowledge Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Internal Knowledge Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Internal Knowledge Assistant should remove. - Email subject: Where is Internal Knowledge Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Internal Knowledge Assistant one measurable job. - Landing lead: A practical first agent for organizations that need their own knowledge to become usable without becoming public. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Internal Knowledge Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Internal Knowledge Assistant offer the whole team can use. - Offer: For Companies, Internal Knowledge Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for business operations, structure their decisions into a guided Internal Knowledge Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Internal Knowledge Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Internal Knowledge Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Internal Knowledge Assistant should productize. - Email subject: Package your best operating knowledge with Internal Knowledge Assistant - Social hook: Your best operator already has a product in their head. Internal Knowledge Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A private knowledge assistant that helps teams find answers, understand decisions, and work from the source material they already own. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Internal Knowledge Assistant: the compounding playbook - Headline: Stop rebuilding Internal Knowledge Assistant from prompts. Encode the playbook your operation can improve. - Offer: Internal Knowledge Assistant becomes a reusable operating layer for Companies: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Answers from an organization’s approved source material,” encode the stable decisions, isolate customer data and permissions, and improve the Internal Knowledge Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Internal Knowledge Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Internal Knowledge Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Internal Knowledge Assistant should encode first. - Email subject: Make Internal Knowledge Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Internal Knowledge Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: A practical first agent for organizations that need their own knowledge to become usable without becoming public. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Internal Knowledge Assistant: prove what compounds - Headline: If Internal Knowledge Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Companies a Internal Knowledge Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Internal Knowledge Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Internal Knowledge Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Internal Knowledge Assistant pilot. - Email subject: What evidence would make Internal Knowledge Assistant worth expanding? - Social hook: The useful question is not whether Internal Knowledge Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A private knowledge assistant that helps teams find answers, understand decisions, and work from the source material they already own. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Clinical Documentation Assistant Catalogue record: /apps/clinical-documentation-assistant Status: planned Claim boundary: Clinical Documentation Assistant is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Clinical Documentation Assistant: the installed outcome - Headline: Clinical Documentation Assistant, installed around one working outcome—not another AI subscription. - Offer: For Clinical teams: a custom build pilot that starts with “Prepares drafts for clinician review,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current healthcare operations workflow, install the minimum Clinical Documentation Assistant capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Clinical Documentation Assistant pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Clinical Documentation Assistant is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Clinical Documentation Assistant installation worth proving. - Email subject: Clinical Documentation Assistant: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Clinical Documentation Assistant installed around one job, one owner, and one acceptance test. - Landing lead: A privacy-bounded assistant that prepares clinical documentation for accountable clinician review. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Clinical Documentation Assistant: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Clinical Documentation Assistant can make measurable. - Offer: Clinical Documentation Assistant begins with a diagnostic for Clinical teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where healthcare operations work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Clinical Documentation Assistant only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Clinical Documentation Assistant offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Clinical Documentation Assistant should remove. - Email subject: Where is Clinical Documentation Assistant worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Clinical Documentation Assistant one measurable job. - Landing lead: Reduce documentation burden without moving clinical judgment, patient privacy, or chart accountability away from qualified people. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Clinical Documentation Assistant: expertise into an offer - Headline: Turn the way your best people handle this work into a Clinical Documentation Assistant offer the whole team can use. - Offer: For Clinical teams, Clinical Documentation Assistant packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for healthcare operations, structure their decisions into a guided Clinical Documentation Assistant workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Clinical Documentation Assistant workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Clinical Documentation Assistant should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Clinical Documentation Assistant should productize. - Email subject: Package your best operating knowledge with Clinical Documentation Assistant - Social hook: Your best operator already has a product in their head. Clinical Documentation Assistant can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A privacy-bounded assistant that prepares clinical documentation for accountable clinician review. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Clinical Documentation Assistant: the compounding playbook - Headline: Stop rebuilding Clinical Documentation Assistant from prompts. Encode the playbook your operation can improve. - Offer: Clinical Documentation Assistant becomes a reusable operating layer for Clinical teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Prepares drafts for clinician review,” encode the stable decisions, isolate customer data and permissions, and improve the Clinical Documentation Assistant playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Clinical Documentation Assistant release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Clinical Documentation Assistant separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Clinical Documentation Assistant should encode first. - Email subject: Make Clinical Documentation Assistant improve with every reviewed case - Social hook: Prompts are disposable. A versioned Clinical Documentation Assistant playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Reduce documentation burden without moving clinical judgment, patient privacy, or chart accountability away from qualified people. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Clinical Documentation Assistant: prove what compounds - Headline: If Clinical Documentation Assistant cannot connect its work to an observable result, it does not get credit. - Offer: Give Clinical teams a Clinical Documentation Assistant deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Clinical Documentation Assistant input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Clinical Documentation Assistant should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Clinical Documentation Assistant pilot. - Email subject: What evidence would make Clinical Documentation Assistant worth expanding? - Social hook: The useful question is not whether Clinical Documentation Assistant ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A privacy-bounded assistant that prepares clinical documentation for accountable clinician review. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Automated Trading Agent Catalogue record: /apps/trading-agent Status: planned Claim boundary: Automated Trading Agent is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Automated Trading Agent: the installed outcome - Headline: Automated Trading Agent, installed around one working outcome—not another AI subscription. - Offer: For Traders: a custom build pilot that starts with “Organizes market research and scenario analysis,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current capital intelligence workflow, install the minimum Automated Trading Agent capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Automated Trading Agent pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Automated Trading Agent is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Automated Trading Agent installation worth proving. - Email subject: Automated Trading Agent: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Automated Trading Agent installed around one job, one owner, and one acceptance test. - Landing lead: A trading-research and automation assistant for monitoring signals, testing hypotheses, and making decision context more legible. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Automated Trading Agent: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Automated Trading Agent can make measurable. - Offer: Automated Trading Agent begins with a diagnostic for Traders, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where capital intelligence work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Automated Trading Agent only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Automated Trading Agent offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Automated Trading Agent should remove. - Email subject: Where is Automated Trading Agent worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Automated Trading Agent one measurable job. - Landing lead: Lead with research discipline and team visibility; live execution is a separate, authorization-heavy product decision. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Automated Trading Agent: expertise into an offer - Headline: Turn the way your best people handle this work into a Automated Trading Agent offer the whole team can use. - Offer: For Traders, Automated Trading Agent packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for capital intelligence, structure their decisions into a guided Automated Trading Agent workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Automated Trading Agent workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Automated Trading Agent should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Automated Trading Agent should productize. - Email subject: Package your best operating knowledge with Automated Trading Agent - Social hook: Your best operator already has a product in their head. Automated Trading Agent can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A trading-research and automation assistant for monitoring signals, testing hypotheses, and making decision context more legible. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Automated Trading Agent: the compounding playbook - Headline: Stop rebuilding Automated Trading Agent from prompts. Encode the playbook your operation can improve. - Offer: Automated Trading Agent becomes a reusable operating layer for Traders: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Organizes market research and scenario analysis,” encode the stable decisions, isolate customer data and permissions, and improve the Automated Trading Agent playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Automated Trading Agent release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Automated Trading Agent separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Automated Trading Agent should encode first. - Email subject: Make Automated Trading Agent improve with every reviewed case - Social hook: Prompts are disposable. A versioned Automated Trading Agent playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Lead with research discipline and team visibility; live execution is a separate, authorization-heavy product decision. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Automated Trading Agent: prove what compounds - Headline: If Automated Trading Agent cannot connect its work to an observable result, it does not get credit. - Offer: Give Traders a Automated Trading Agent deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Automated Trading Agent input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Automated Trading Agent should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Automated Trading Agent pilot. - Email subject: What evidence would make Automated Trading Agent worth expanding? - Social hook: The useful question is not whether Automated Trading Agent ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A trading-research and automation assistant for monitoring signals, testing hypotheses, and making decision context more legible. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Revenue Intelligence Platform Catalogue record: /apps/revenue-intelligence-platform Status: planned Claim boundary: Revenue Intelligence Platform is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Revenue Intelligence Platform: the installed outcome - Headline: Revenue Intelligence Platform, installed around one working outcome—not another AI subscription. - Offer: For Revenue teams: a hosted pilot that starts with “Uses first-party or consented data,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current data intelligence workflow, install the minimum Revenue Intelligence Platform capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Revenue Intelligence Platform pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Revenue Intelligence Platform is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Revenue Intelligence Platform installation worth proving. - Email subject: Revenue Intelligence Platform: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Revenue Intelligence Platform installed around one job, one owner, and one acceptance test. - Landing lead: A revenue measurement layer that connects consented events, attribution, and outcome review without overstating causality. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Revenue Intelligence Platform: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Revenue Intelligence Platform can make measurable. - Offer: Revenue Intelligence Platform begins with a diagnostic for Revenue teams, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where data intelligence work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Revenue Intelligence Platform only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Revenue Intelligence Platform offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Revenue Intelligence Platform should remove. - Email subject: Where is Revenue Intelligence Platform worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Revenue Intelligence Platform one measurable job. - Landing lead: Make revenue signals easier to inspect while separating directional attribution from experimentally verified incrementality. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Revenue Intelligence Platform: expertise into an offer - Headline: Turn the way your best people handle this work into a Revenue Intelligence Platform offer the whole team can use. - Offer: For Revenue teams, Revenue Intelligence Platform packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for data intelligence, structure their decisions into a guided Revenue Intelligence Platform workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Revenue Intelligence Platform workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Revenue Intelligence Platform should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Revenue Intelligence Platform should productize. - Email subject: Package your best operating knowledge with Revenue Intelligence Platform - Social hook: Your best operator already has a product in their head. Revenue Intelligence Platform can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A revenue measurement layer that connects consented events, attribution, and outcome review without overstating causality. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Revenue Intelligence Platform: the compounding playbook - Headline: Stop rebuilding Revenue Intelligence Platform from prompts. Encode the playbook your operation can improve. - Offer: Revenue Intelligence Platform becomes a reusable operating layer for Revenue teams: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Uses first-party or consented data,” encode the stable decisions, isolate customer data and permissions, and improve the Revenue Intelligence Platform playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Revenue Intelligence Platform release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Revenue Intelligence Platform separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Revenue Intelligence Platform should encode first. - Email subject: Make Revenue Intelligence Platform improve with every reviewed case - Social hook: Prompts are disposable. A versioned Revenue Intelligence Platform playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Make revenue signals easier to inspect while separating directional attribution from experimentally verified incrementality. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Revenue Intelligence Platform: prove what compounds - Headline: If Revenue Intelligence Platform cannot connect its work to an observable result, it does not get credit. - Offer: Give Revenue teams a Revenue Intelligence Platform deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Revenue Intelligence Platform input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Revenue Intelligence Platform should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Revenue Intelligence Platform pilot. - Email subject: What evidence would make Revenue Intelligence Platform worth expanding? - Social hook: The useful question is not whether Revenue Intelligence Platform ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A revenue measurement layer that connects consented events, attribution, and outcome review without overstating causality. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## Sports Betting Intelligence Agent Catalogue record: /apps/sports-betting-agent Status: planned Claim boundary: Sports Betting Intelligence Agent is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: Sports Betting Intelligence Agent: the installed outcome - Headline: Sports Betting Intelligence Agent, installed around one working outcome—not another AI subscription. - Offer: For Sports fans: a hosted pilot that starts with “Compares evidence and assumptions around a sports thesis,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current sports intelligence workflow, install the minimum Sports Betting Intelligence Agent capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the Sports Betting Intelligence Agent pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: Sports Betting Intelligence Agent is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest Sports Betting Intelligence Agent installation worth proving. - Email subject: Sports Betting Intelligence Agent: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need Sports Betting Intelligence Agent installed around one job, one owner, and one acceptance test. - Landing lead: A sports research assistant for comparing information, tracking assumptions, and making a betting thesis easier to inspect. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: Sports Betting Intelligence Agent: remove the constraint - Headline: The constraint is not “we need AI.” It is the work Sports Betting Intelligence Agent can make measurable. - Offer: Sports Betting Intelligence Agent begins with a diagnostic for Sports fans, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where sports intelligence work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure Sports Betting Intelligence Agent only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The Sports Betting Intelligence Agent offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint Sports Betting Intelligence Agent should remove. - Email subject: Where is Sports Betting Intelligence Agent worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give Sports Betting Intelligence Agent one measurable job. - Landing lead: Sell the quality of the research loop and the visibility of assumptions, not certainty or guaranteed outcomes. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: Sports Betting Intelligence Agent: expertise into an offer - Headline: Turn the way your best people handle this work into a Sports Betting Intelligence Agent offer the whole team can use. - Offer: For Sports fans, Sports Betting Intelligence Agent packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for sports intelligence, structure their decisions into a guided Sports Betting Intelligence Agent workflow, and keep expert review visible at consequential steps. - Proof plan: Test the Sports Betting Intelligence Agent workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: Sports Betting Intelligence Agent should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise Sports Betting Intelligence Agent should productize. - Email subject: Package your best operating knowledge with Sports Betting Intelligence Agent - Social hook: Your best operator already has a product in their head. Sports Betting Intelligence Agent can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: A sports research assistant for comparing information, tracking assumptions, and making a betting thesis easier to inspect. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: Sports Betting Intelligence Agent: the compounding playbook - Headline: Stop rebuilding Sports Betting Intelligence Agent from prompts. Encode the playbook your operation can improve. - Offer: Sports Betting Intelligence Agent becomes a reusable operating layer for Sports fans: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Compares evidence and assumptions around a sports thesis,” encode the stable decisions, isolate customer data and permissions, and improve the Sports Betting Intelligence Agent playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each Sports Betting Intelligence Agent release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: Sports Betting Intelligence Agent separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook Sports Betting Intelligence Agent should encode first. - Email subject: Make Sports Betting Intelligence Agent improve with every reviewed case - Social hook: Prompts are disposable. A versioned Sports Betting Intelligence Agent playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Sell the quality of the research loop and the visibility of assumptions, not certainty or guaranteed outcomes. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: Sports Betting Intelligence Agent: prove what compounds - Headline: If Sports Betting Intelligence Agent cannot connect its work to an observable result, it does not get credit. - Offer: Give Sports fans a Sports Betting Intelligence Agent deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from Sports Betting Intelligence Agent input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: Sports Betting Intelligence Agent should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first Sports Betting Intelligence Agent pilot. - Email subject: What evidence would make Sports Betting Intelligence Agent worth expanding? - Social hook: The useful question is not whether Sports Betting Intelligence Agent ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: A sports research assistant for comparing information, tracking assumptions, and making a betting thesis easier to inspect. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value. --- ## AI Agency Operating System Catalogue record: /apps/agency-ai-workbench Status: planned Claim boundary: AI Agency Operating System is planned catalogue inventory and not yet proven live. The copy below is a campaign starter, not a claim of availability, customer results, or verified demand. ### Outcome installation - Campaign: AI Agency Operating System: the installed outcome - Headline: AI Agency Operating System, installed around one working outcome—not another AI subscription. - Offer: For Agencies: a hosted pilot that starts with “Supports reusable software and fixed installation packages,” then configures the workflow, permissions, handoffs, and operating owner around it. - Mechanism: Map the current agency infrastructure workflow, install the minimum AI Agency Operating System capability, test representative cases, train the owner, and separate the fixed installation from any optional managed operation. - Proof plan: Baseline cycle time, backlog, error rate, or conversion before the AI Agency Operating System pilot; verify the same measure after a bounded acceptance test and retain the receipts. - Objection: “We do not need another platform that creates more work for the team.” - Response: AI Agency Operating System is positioned as an installed workflow with a named owner and acceptance test. If it cannot remove a specific burden, the scope does not expand. - CTA: Scope the smallest AI Agency Operating System installation worth proving. - Email subject: AI Agency Operating System: one workflow, installed and measured - Social hook: Most teams do not need more AI access. They need AI Agency Operating System installed around one job, one owner, and one acceptance test. - Landing lead: Reusable software for agencies to install, configure, and operate governed AI services across client accounts. Start with a bounded installation, prove the operating result, then decide whether continued optimization deserves a retainer. ### Constraint offer - Campaign: AI Agency Operating System: remove the constraint - Headline: The constraint is not “we need AI.” It is the work AI Agency Operating System can make measurable. - Offer: AI Agency Operating System begins with a diagnostic for Agencies, isolates the most expensive repeatable constraint, and packages the intervention around a result the buyer can inspect. - Mechanism: Identify where agency infrastructure work queues, stalls, leaks, or depends on memory; choose one constraint, define the authority boundary, and configure AI Agency Operating System only around that point. - Proof plan: Record the constraint's baseline cost, volume, delay, or loss; measure the pilot against a pre-agreed threshold and verify exceptions instead of hiding them in an average. - Objection: “This sounds broad, expensive, and difficult to adopt.” - Response: The AI Agency Operating System offer is intentionally narrow: one constraint, one accountable owner, one measurement window, and a stop decision before broader rollout. - CTA: Diagnose the first constraint AI Agency Operating System should remove. - Email subject: Where is AI Agency Operating System worth deploying first? - Social hook: “Add AI” is not a strategy. Find the operating constraint, price the drag, and give AI Agency Operating System one measurable job. - Landing lead: Package reusable software as a fixed installation or managed operation while keeping every client's authority and delivery evidence separate. The offer is strongest when the buyer can point to the before state, the intervention, and the evidence required to continue. ### Expertise product - Campaign: AI Agency Operating System: expertise into an offer - Headline: Turn the way your best people handle this work into a AI Agency Operating System offer the whole team can use. - Offer: For Agencies, AI Agency Operating System packages approved knowledge, operating guidance, reusable assets, and supported delivery into a ladder that can start small and deepen after proof. - Mechanism: Collect owned source material, interview the people responsible for agency infrastructure, structure their decisions into a guided AI Agency Operating System workflow, and keep expert review visible at consequential steps. - Proof plan: Test the AI Agency Operating System workflow with real representative users; measure task completion, correction rate, time saved, and whether users return without being pushed. - Objection: “Our expertise is too nuanced to flatten into templates or generic AI copy.” - Response: AI Agency Operating System should preserve source attribution, uncertainty, and expert approval. The product distributes judgment; it does not borrow an identity or erase the author. - CTA: Choose the first piece of expertise AI Agency Operating System should productize. - Email subject: Package your best operating knowledge with AI Agency Operating System - Social hook: Your best operator already has a product in their head. AI Agency Operating System can turn the repeatable parts into an offer without pretending nuance disappeared. - Landing lead: Reusable software for agencies to install, configure, and operate governed AI services across client accounts. Build the first version from owned knowledge, test whether it helps a real audience, and earn the right to add education, service, licensing, or support. ### Encoded playbook - Campaign: AI Agency Operating System: the compounding playbook - Headline: Stop rebuilding AI Agency Operating System from prompts. Encode the playbook your operation can improve. - Offer: AI Agency Operating System becomes a reusable operating layer for Agencies: versioned instructions, approved data, integrations, decision rules, evaluation cases, and explicit escalation paths. - Mechanism: Observe how the best operator performs “Supports reusable software and fixed installation packages,” encode the stable decisions, isolate customer data and permissions, and improve the AI Agency Operating System playbook from reviewed exceptions. - Proof plan: Run a fixed evaluation set before each AI Agency Operating System release; compare accuracy, escalation quality, latency, cost, and operator corrections with versioned evidence. - Objection: “A reusable system will become rigid or leak context between clients and teams.” - Response: AI Agency Operating System separates the reusable playbook from tenant-specific data, credentials, policy, and authority. Reuse compounds the method—not private context. - CTA: Map the playbook AI Agency Operating System should encode first. - Email subject: Make AI Agency Operating System improve with every reviewed case - Social hook: Prompts are disposable. A versioned AI Agency Operating System playbook—rules, cases, boundaries, receipts—can become operating leverage. - Landing lead: Package reusable software as a fixed installation or managed operation while keeping every client's authority and delivery evidence separate. The durable asset is not a clever prompt; it is a governed playbook that survives staff changes and gets better from evidence. ### Evidence loop - Campaign: AI Agency Operating System: prove what compounds - Headline: If AI Agency Operating System cannot connect its work to an observable result, it does not get credit. - Offer: Give Agencies a AI Agency Operating System deployment with measurement designed in: consented events, workflow receipts, outcome definitions, review queues, and a decision rule for what happens next. - Mechanism: Instrument the path from AI Agency Operating System input to action to outcome; distinguish direct observations from modeled influence, preserve failed cases, and feed verified findings into the next operating decision. - Proof plan: Define the baseline and attribution limits before launch, measure leading and lagging indicators, verify data coverage, and use a holdout or comparable check when causality matters. - Objection: “Attribution will overstate the system's impact and turn noisy activity into a success story.” - Response: AI Agency Operating System should label what was observed, inferred, and independently verified. Uncertain attribution is a reason to improve the test—not manufacture certainty. - CTA: Design the evidence loop for the first AI Agency Operating System pilot. - Email subject: What evidence would make AI Agency Operating System worth expanding? - Social hook: The useful question is not whether AI Agency Operating System ran. It is what changed, what evidence connects the change, and what decision that evidence supports. - Landing lead: Reusable software for agencies to install, configure, and operate governed AI services across client accounts. Instrument the journey before scaling so the buyer can protect what works, stop what does not, and separate activity from verified value.