# Play Strategy SOP ## Purpose This SOP explains how the platform moves from modular copy experiments to an approved portfolio of active plays per tenant. The goal is to let strategy choose the right outbound play for each client, keep operations aligned on what is live, and still preserve experiments as the testing layer inside each play. ## Core Concepts - `play`: the strategic motion. This is the high-level outbound approach, such as pain-point-led, lookalike, free work, or no-brainer offer. - `play_instance`: the approved operational version of that strategy for a specific tenant or brand. This is what becomes active in the system. - `campaign_line`: the operational sending lane for a brand and region. It controls volume, region, ICP pool rules, and approved title buckets. A campaign line points to a `play_instance`. - `experiment`: the messaging variant used by that line. An experiment can be pinned directly on the line, or resolved dynamically from the active play. - `lego`: a reusable copy building block stored in `offer_components`. Legos are the ingredients the experiment uses to assemble copy. ## Hierarchy At A Glance The hierarchy should be understood like this: 1. `tenant` / `brand` 2. `play_instance` 3. `campaign_line` 4. `experiment` 5. `legos` In plain English: - the `play_instance` defines the strategy - the `campaign_line` is the sending lane that runs that strategy - the `experiment` defines the active copy variant for that lane - the `legos` are the modular parts used to build the final messaging Important clarification: - a `campaign_line` does **not** own a play portfolio on its own - instead, it is attached to one `play_instance` - from there, the runtime either uses the line's explicit `experiment_id` or resolves the correct experiment from the play So the runtime mental model is: - `Play` = strategy - `Campaign Line` = operational lane - `Experiment` = copy variant running in that lane - `Lego` = copy components used by the experiment ## The Five Approved Plays 1. `company_pain_points` Find companies that match the ICP and lead with the pains/challenges they are likely facing. 2. `lookalike` Build a list from company similarity and match each prospect to the best approved case study. 3. `great_offer_final_results` Lead with a strong result-focused offer backed by approved final outcomes. 4. `free_work_offer` Lead with a free slice of work that proves authority and creates momentum. 5. `no_brainer_offer` Lead with a highly compelling entry offer that lowers perceived risk. ## Roles - Onboarding team: captures the client brief, offer, ICP, proof, constraints, and positioning. - Strategy team: chooses which plays should be active and in what order. - Operations team: attaches active plays to campaign lines and monitors execution. - System: runs research, assembles prompts, generates snippets, and attributes performance by play and experiment. ## Operating Model ### 1. Capture tenant knowledge Required sources: - tenant documents - transcripts / sales calls - client brief - generated context - case studies - structured play inputs The better the structured inputs, the safer the play activation. ### 2. Ask the Play Strategist Use the `Play Strategist` chat in the dashboard when a new tenant is onboarded or when strategy needs to revisit the portfolio. The agent should answer: - which 2-3 plays fit best - why those plays fit - what inputs are still missing - what risks or blockers exist - what first experiments should be tested inside each play Important: - the agent recommends - humans approve - no play should become active automatically ### 3. Save recommendations Use the tenant detail page: - `Tenants -> [tenant] -> Plays` Generate recommendations per tenant or per brand. These are stored as `tenant_play_recommendations`. ### 4. Approve and activate plays When strategy approves a play, create a `play_instance`. Each `play_instance` should define: - `play_type` - `brand_id` or tenant-wide scope - `priority` - `status` - `approval_state` - `list_recipe` - `research_profile` - `message_framework` - `required_inputs` - optional `fallback_play_instance_id` ### 5. Load structured inputs Before a play is activated, make sure the structured inputs exist. Examples: - Play 1: ICP rules, fit criteria, industry patterns, approved pain framing. - Play 3: approved case studies, similarity rules, lookalike seeds. - Play 5: approved claims, quantified outcomes, process/result pairs, personalization guardrails. - Play 8: free deliverables, capacity, authority markers, scope limits. - Play 9: pricing, irresistible slice, speed advantage, risk removal language. If an input is missing, the play can remain recommended but should not be activated. ### 6. Create and bind campaign lines Use: - `Campaigns -> Campaign Lines` Each `campaign_line` should be created as a brand-aware, region-aware sending lane. At minimum, a new line should define: - `brand_id` - `line_code` - `label` - `region` - `daily_target` - `icp_for_rules` - optional `pool_split` - `allowed_buckets` - `play_instance_id` - optional `experiment_id` Each line can operate in one of two modes: - legacy mode: no `play_instance` is attached, and the line behaves like the old experiment-driven system. - play-managed mode: the line points to a `play_instance`. Recommended mental model: - first create the `play_instance` - then create the `campaign_line` that will run that play for a specific region / lane - then decide whether that line should pin one experiment or resolve the active experiment from the play Runtime rule: - when a line is assigned to a `play_instance`, the explicit experiment pin can be cleared - if no experiment is pinned, the runtime resolves the active experiment from inside the play - once the experiment is resolved, the system uses that experiment's approved legos to assemble copy This keeps the line aligned with the active play portfolio instead of a stale experiment. ### 7. Research pipeline The platform keeps general company research as the baseline, then adds play-specific research only when the play requires it. #### General research - company research remains the common base - no global expansion of pains is required unless a play needs it #### Play-specific research - Play 1: fit score, fit reason, challenge summary, challenge categories - Play 3: best case study match, similarity extraction, visual diagnosis for follow-up - Play 5: approved result mapping plus contact personalization signals with confidence and source URL - Play 8: validation that free work inputs are present - Play 9: validation that pricing and no-brainer inputs are present Blocking rules: - if required research artifacts are missing, the system blocks snippet generation for that contact or falls back according to the play policy - the system should never invent claims, case study similarities, or personalization ### 8. Snippet generation The writer receives: - tenant strategy context - play configuration - campaign line context - experiment definition - play-specific research artifacts The writer does not decide the play logic on its own. The writer renders: 1. the selected `play_instance` 2. for the active `campaign_line` 3. using the resolved `experiment` 4. assembled from the approved `legos` 5. constrained by the line's approved buckets and ICP rules This is why all four layers matter: - strategy lives in the play - routing lives in the campaign line - variation lives in the experiment - composition lives in the legos ### 9. Launch and measurement The scheduler and downstream reporting should attribute performance to both: - `play_instance_id` - `experiment_id` This lets strategy answer two different questions: - which play is working - which experiment is winning inside that play ## UI Surfaces - `Tenants -> [tenant] -> Plays` strategic setup, recommendations, active play instances, case studies, play inputs - `Play Strategist` chat surface for the strategy team - `Campaigns -> Campaign Lines` operational view showing which campaign lines exist, which play each line executes, which buckets are approved for that line, and whether the experiment is pinned or resolved from the play ## Definition of “Active Play” A play is considered active only when: - it has a `play_instance` - `approval_state = approved` - `status = active` - required inputs are present - any required play-specific research can run successfully If any of those conditions fail, the play is not operationally live even if it was recommended before. ## Default Safeguards - Recommendations never auto-activate plays. - Case studies must be structured and approved before Play 3 runs. - Personalization for Play 5 is optional, never fabricated. - Plays 8 and 9 should block if capacity, deliverables, pricing, or viability inputs are missing. - Campaign lines can stay legacy during migration. ## Team Checklist Before launch: 1. Confirm the tenant brief is complete. 2. Generate play recommendations. 3. Approve the correct plays. 4. Load missing case studies and play inputs. 5. Activate the right `play_instances`. 6. Assign the desired play to each campaign line. 7. Confirm research artifacts are being produced. 8. Review snippets and launch. After launch: 1. Review performance by play. 2. Review winners and losers by experiment inside the play. 3. Adjust priority, pause weak plays, or activate fallbacks. 4. Re-open the Play Strategist chat when the client offer or market changes.