Activation email audience flow

# Agentic activation email system

## Status

Implementation-ready specification for engineering and agent execution.

Before production launch, replace every bracketed placeholder, connect the selected ESP, confirm consent and suppression rules with the responsible owner, and verify every CTA destination.

## 1. Project objective

Build a 14-day activation email system that helps every new signup discover useful parts of Ploy.

The system does not wait for users to complete product actions before sending the next email. Every eligible signup receives the fixed cadence. Available signals change which email module is selected and how its subject, message, deliverable, CTA, integration, and Ploybook are personalized.

The system should:

- help users understand what Ploy can do without asking them to design their own journey;
- recommend one specific next action in every email;
- let the CTA approve work that Ploy can perform;
- use specific deliverables rather than generic references to pages, assets, or workflows;
- expose more of Ploy than website publishing, including research, visitor de-anonymization, integrations, monitoring, reporting, CLI, automation, PloyDB, and recurring Ploybooks;
- move users from initial discovery to a useful one-time result and then to a repeatable workflow.

## 2. Fixed sending cadence

Every eligible signup receives five emails:

| Email | Send day | Purpose |
| --- | --- | --- |
| 1 | Day 0 | Welcome and orientation |
| 2 | Day 3 | Best discovery or continuation module for the current segment |
| 3 | Day 6 | Specific opportunity, deliverable, or feature discovery |
| 4 | Day 10 | Integration, monitoring, education, or workflow recommendation |
| 5 | Day 14 | Ploybook creation, broader education, or power-user expansion |

Actions do not determine whether the next scheduled email is sent. Actions and new signals can change the module or personalization used in the remaining scheduled slots.

## 3. Entry, exit, and suppression

### Entry

Enter the sequence after a valid new signup event:

`user.signed_up`

Required fields:

- `user_id`
- `email`
- `signup_at`
- `source`
- `consent_status`
- `workspace_id`, when available

### Exit

Exit the sequence when any of the following occurs:

- the user unsubscribes;
- the address hard-bounces;
- the account is deleted;
- the user is manually suppressed;
- a workspace-level rule marks the user ineligible;
- the user enters a higher-priority lifecycle campaign that should suppress activation messaging.

Product activity alone does not exit the sequence. It changes future content.

### Frequency and conflict rules

- Send no more than one activation email on the same calendar day.
- Apply the production workspace’s global frequency cap: `[GLOBAL_FREQUENCY_CAP]`.
- Define priority against sales, transactional, product, and other lifecycle emails in `[MESSAGE_PRIORITY_POLICY]`.
- Transactional emails must not be blocked by activation suppression.

## 4. Segmentation inputs

Evaluate the latest available state before rendering each scheduled email.

### Primary split

1. Completed FTU
2. Incomplete FTU or dropped off

### Persona

- Marketer / content
- Growth / lifecycle / demand generation
- Sales / GTM / ABM
- Founder / operator
- Technical / AI-native builder
- Website / web team
- Unknown / insufficient signal

### Goal

Use the stated FTU goal when FTU is complete. Use an inferred goal only when FTU is incomplete, and label it as inferred internally.

### Available signals

- email and company domain;
- company website;
- signup source or referral;
- stated goal;
- first FTU reply;
- persona or team type;
- selected channels;
- generated page, post, workflow, report, research, or other result;
- publishing status of the selected deliverable;
- connected integrations;
- product activity after signup;
- return visits;
- Ploybook creation;
- repeated or high product usage;
- identified companies visiting the website;
- relevant account, campaign, SEO/AEO, conversion, or market signals.

### Signal confidence

- **High:** completed FTU plus a clear persona and stated goal.
- **Medium:** partial FTU, inferred persona, unfinished work, or one useful behavioral signal.
- **Low:** unknown persona, unknown goal, and little or no product activity.

## 5. State constraints

The data model and UI must prevent impossible combinations.

- Incomplete FTU cannot have published selected work.
- Incomplete FTU cannot have high product usage.
- Incomplete FTU should not have a connected post-signup integration unless the integration predates the signup and the implementation explicitly supports that case.
- Published requires a generated deliverable that is publishable.
- Research, reports, visitor lists, community maps, automation workflows, and other non-page deliverables must not trigger publish-confidence messaging.
- Power-user expansion requires repeated sessions, multiple outputs, published work, connected tools, or another verified strong-usage signal.
- Unknown or low-signal users should not receive advanced CLI, automation, or generic integration recommendations.

## 6. Audience and feature map

### Marketer / content

Goals and specific outputs:

- Improve SEO/AEO → blog post targeting a verified content gap.
- Launch blog posts → a specific new blog post.
- Build a content engine → a workflow that finds opportunities and drafts posts.

Features to highlight:

- SEO/AEO research;
- Google Search Console;
- content-gap monitoring;
- content publishing;
- PloyDB content workflows;
- weekly opportunity reports.

### Growth / lifecycle / demand generation

Goals and specific outputs:

- Generate leads → a prioritized list of companies visiting the website.
- Launch campaigns → a campaign landing page.
- Improve conversion → a conversion opportunity report or named landing-page test.

Features to highlight:

- visitor de-anonymization;
- campaign creation;
- Google Analytics;
- HubSpot or CRM routing;
- Slack alerts;
- conversion monitoring and recurring reports.

### Sales / GTM / ABM

Goals and specific outputs:

- Build ABM pages → one ABM page for a named target account.
- Support outbound → an account research brief and outbound email draft.
- Identify engaged accounts → a prioritized list of engaged companies visiting the website.

Features to highlight:

- visitor de-anonymization;
- account research;
- outbound drafting;
- ABM page creation;
- Salesforce, HubSpot, Clay, and Slack;
- visitor-to-ABM Ploybooks.

### Founder / operator

Goals and specific outputs:

- Plan a product launch → a competitor-informed launch brief.
- Find new growth channels → a shortlist of relevant Reddit communities and discussion themes.
- Identify website visitors → a prioritized list of companies visiting the website.

Features to highlight:

- competitor and launch research;
- community and channel research;
- visitor de-anonymization;
- founder-level opportunity monitoring;
- recurring research and opportunity Ploybooks.

Do not make founder recommendations primarily about landing pages.

### Technical / AI-native builder

Goals and specific outputs:

- Automate workflows → a named automated growth workflow.
- Use CLI → a specific page, campaign, or workflow generated through CLI.
- Connect existing tools → a workflow that runs across the selected tools.

Features to highlight:

- CLI / faster execution;
- integrations / automation;
- data sources;
- advanced flows;
- Ploybooks and monitoring.

CLI is an execution method, not a data integration.

### Website / web team

Goals and specific outputs:

- Publish pages → one specific landing page.
- Work with an existing site → one campaign page added through the safest publishing path.
- Build a content workflow → one blog post backed by a CMS or PloyDB workflow.

Features to highlight:

- one-deliverable-first publishing;
- existing-site compatibility;
- reverse proxy, domain, or CMS paths;
- PloyDB / CMS workflows;
- structured publishing automation.

### Unknown / insufficient signal

The sequence should create a stronger signal without asking the user to configure Ploy.

Use:

- the consistent welcome email;
- a small set of concrete outputs;
- Teams like yours examples;
- a low-risk starter Ploybook;
- Continue where you left off when partial activity exists.

Avoid advanced features until the user expresses a clear goal.

## 7. Complete email module inventory

### Core categories

1. Welcome / orientation
2. Signal-led recommendation
3. Publish confidence
4. Teams like yours
5. Ploybook creation
6. Power-user expansion

### Conditional modules

- Continue where you left off
- Use-case-led integration
- Monitoring / recurring report
- Integrations / automation
- CLI / faster execution
- PloyDB / CMS workflow
- Starter Ploybook

Each five-email path selects from this larger inventory.

## 8. Module selection logic

Evaluate before each scheduled slot.

```text
IF slot = Day 0:
  send Welcome / orientation
  keep subject and body consistent
  personalize CTA only when a clear signal or unfinished project exists

ELSE IF FTU is incomplete:
  prioritize Continue where you left off when partial work exists
  otherwise prioritize Teams like yours
  use low-confidence Signal-led recommendation only after a useful click or return visit
  recommend a persona-specific or starter Ploybook by Day 14
  do not recommend advanced CLI, power-user expansion, or generic integrations

ELSE IF FTU is complete:
  IF generated deliverable is publishable and unpublished:
    include Publish confidence using the exact deliverable
  ELSE:
    prioritize Signal-led recommendation

  IF a relevant tool is missing and the goal is clear:
    include the matching integration, monitoring, or CLI module

  IF the user has reached first value or expressed clear intent:
    include Ploybook creation

  IF verified high usage exists:
    Day 14 may use Power-user expansion
  ELSE:
    Day 14 uses Ploybook creation or persona-relevant education
```

The fixed schedule remains unchanged when branches change.

## 9. Welcome email invariant

The welcome subject and body stay the same across all personas.

Only the CTA may change based on known context or unfinished work.

Default subject:

`Meet Ploy, your AI growth team`

Default preview text:

`Turn a goal, idea, or opportunity into live marketing work.`

Default body:

`Ploy is an agentic growth engine that helps teams turn goals, ideas, signals, and opportunities into live pages, campaigns, workflows, and repeatable systems. Tell Ploy what you want to accomplish, then review and approve the work it recommends.`

CTA examples:

- Continue where I left off
- Draft this blog post
- Show me companies visiting my site
- Show me what Ploy can do for my team

## 10. Copy contract

Every rendered email must include:

- recipient state;
- send day;
- eligibility and suppression rules;
- one message job;
- subject;
- preview text;
- complete body;
- one primary CTA;
- CTA destination or agent action;
- personalization fields and fallbacks;
- success event.

### Clarity rules

- Use literal, complete sentences.
- Name the exact deliverable: blog post, ABM page, account research brief, visitor list, conversion report, Reddit community map, campaign page, or named workflow.
- Never substitute generic words such as asset, thing, work, page, or workflow when a more specific output is known.
- Integrations must be framed through an outcome: “Connect GSC to find SEO opportunities,” not “Connect integrations.”
- CLI must name what it creates.
- Ploybook CTAs create the Ploybook in the account. They do not open settings or ask the user to configure it.
- Every email asks for one primary decision.
- Do not invent proof, keyword counts, visitor counts, deadlines, urgency, or performance claims.

### FOMO rules

Use opportunity-led FOMO rather than artificial pressure.

Good FOMO sources:

- a verified account returned to the website;
- verified companies are visiting anonymously;
- a verified keyword or content gap exists;
- competitors are already ranking for a relevant topic;
- campaign traffic is reaching a generic destination;
- an opportunity is waiting on unpublished work;
- a useful signal may go cold before the team acts;
- an analytics or market change may pass unnoticed;
- manual publishing or handoffs are delaying a known result.

When using a number, pull it from a verified source at render time. If the data is unavailable, use a non-numerical fallback. Never send `[verified count]` to a customer.

Do not use fake scarcity, countdown language, unsupported claims, or fear detached from a real signal.

### Ploy voice

- Clear, direct, proactive, and technically credible.
- Sentence case for subjects, labels, tags, and CTAs.
- No em dashes.
- No fragments used for manufactured drama.
- No “not X, but Y” constructions.
- No generic SaaS language or unsupported superlatives.
- Use Ploy, Ploy Web, Ploy Grow, Ploy Ads, PloyDB, and Ploybooks with correct capitalization.
- Use “visitor de-anonymization” as the formal feature name.

## 11. CTA system

### Create

Use when Ploy creates a specific result or recurring workflow.

Examples:

- Draft this blog post
- Build this ABM page
- Create my conversion report
- Run this Ploybook in my account

### Publish

Use only for a known publishable deliverable.

Examples:

- Show me how to publish this blog post
- Show me how to publish this ABM page
- Show me the safest publishing path

### Connect

Name the tool and outcome.

Examples:

- Connect GSC to find SEO opportunities
- Connect GA to monitor conversion
- Connect Salesforce to build ABM pages
- Send identified account visits to Slack

### Monitor

Examples:

- Create my weekly opportunity report
- Have Ploy keep a lookout
- Alert me when a target account returns

### Continue

Use for unfinished FTU or projects.

- Continue where I left off

## 12. CTA execution contract

A CTA should deep-link into a Ploy action with known context whenever possible.

Required action payload:

```json
{
  "user_id": "[USER_ID]",
  "workspace_id": "[WORKSPACE_ID]",
  "email_id": "[EMAIL_ID]",
  "module": "[MODULE_ID]",
  "persona": "[PERSONA]",
  "goal": "[STATED_OR_INFERRED_GOAL]",
  "deliverable": "[SPECIFIC_DELIVERABLE]",
  "source_signal_ids": ["[SIGNAL_ID]"],
  "requested_action": "[ACTION_ID]",
  "return_url": "[RETURN_URL]"
}
```

The user should arrive with the recommended action and relevant context already loaded. Avoid generic product-home destinations.

## 13. Ploybook creation logic

```text
Signal found
→ Ploy recommends one specific action
→ User clicks “Run this Ploybook in my account”
→ Ploy creates the expert-built workflow with known context
→ User reviews the workflow
→ Ploy monitors, reports, drafts, publishes, or alerts on the agreed cadence
```

Required Ploybook fields:

- Ploybook type
- stated or inferred goal
- input source
- monitored signal
- specific output
- cadence
- delivery channel
- approval requirement
- owner
- active or paused state

## 14. Suggested data model

```ts
type ActivationProfile = {
  userId: string;
  workspaceId?: string;
  ftuStatus: "completed" | "incomplete";
  persona: Persona;
  personaConfidence: "high" | "medium" | "low";
  goal?: string;
  goalSource: "stated" | "inferred" | "unknown";
  featureFocus?: string;
  generatedDeliverable?: {
    type: string;
    id: string;
    label: string;
    publishable: boolean;
    published: boolean;
  };
  connectedTools: string[];
  activityLevel: "low" | "active" | "high";
  signalIds: string[];
  createdPloybookIds: string[];
};

type EmailModule = {
  id: string;
  category: string;
  messageJob: string;
  eligible(profile: ActivationProfile): boolean;
  subject(profile: ActivationProfile): string;
  previewText(profile: ActivationProfile): string;
  body(profile: ActivationProfile): string;
  cta(profile: ActivationProfile): {
    label: string;
    actionId: string;
    payload: Record<string, unknown>;
  };
  fallbackModuleId: string;
};
```

## 15. Rendering and fallback rules

- Recompute the profile before rendering each scheduled email.
- Persist the selected module and rendered personalization for auditability.
- Every personalization field requires a fallback.
- If a specific deliverable is unknown, select a different module. Do not render a generic deliverable.
- If a numerical FOMO claim cannot be verified, use a truthful non-numerical subject.
- If an integration is already connected, do not send a connect CTA. Recommend the workflow it enables.
- If the selected deliverable is already published, do not use Publish confidence.
- If no specific signal exists, use persona education or a starter Ploybook.

## 16. Measurement

Track delivery and state transitions rather than relying only on opens.

Suggested events:

- `activation_email.scheduled`
- `activation_email.sent`
- `activation_email.delivered`
- `activation_email.clicked`
- `activation_email.unsubscribed`
- `activation_action.opened`
- `activation_action.approved`
- `activation_deliverable.created`
- `activation_deliverable.published`
- `activation_integration.connected`
- `activation_ploybook.created`
- `activation_ploybook.activated`

For every metric, define cohort, denominator, and attribution window.

Primary outcome by email: the state transition associated with the CTA.

Guardrails:

- unsubscribe rate;
- complaint rate;
- hard-bounce rate;
- repeated CTA errors;
- personalization fallback rate;
- module-selection failure rate.

## 17. Required production configuration

Fill before launch:

- ESP: `[ESP]`
- sending domain: `[SENDING_DOMAIN]`
- sender name and address: `[SENDER]`
- reply-to: `[REPLY_TO]`
- preference center URL: `[PREFERENCE_CENTER_URL]`
- unsubscribe mechanism: `[UNSUBSCRIBE_METHOD]`
- global frequency cap: `[GLOBAL_FREQUENCY_CAP]`
- production app base URL: `[APP_BASE_URL]`
- CTA action routes: `[ACTION_ROUTE_MAP]`
- event source of truth: `[EVENT_SOURCE]`
- company and visitor identification source: `[VISITOR_DATA_SOURCE]`
- CRM and integration field mapping: `[INTEGRATION_FIELD_MAP]`
- owner for copy approval: `[COPY_OWNER]`
- owner for lifecycle operations: `[LIFECYCLE_OWNER]`
- owner for engineering QA: `[ENGINEERING_OWNER]`

## 18. QA scenarios

Test at minimum:

1. Completed FTU, marketer, SEO/AEO, blog post generated, unpublished.
2. Completed FTU, marketer, content engine, non-publishable workflow.
3. Completed FTU, growth, visitor de-anonymization, CRM not connected.
4. Completed FTU, growth, campaign launch, page generated and unpublished.
5. Completed FTU, Sales/GTM, ABM page generated and unpublished.
6. Completed FTU, Sales/GTM, outbound research, Clay connected.
7. Completed FTU, founder, competitor launch research.
8. Completed FTU, founder, Reddit community research.
9. Completed FTU, founder, visitor de-anonymization.
10. Completed FTU, technical, CLI goal.
11. Completed FTU, technical, automation goal with tools connected.
12. Completed FTU, website team, PloyDB/CMS workflow.
13. Incomplete FTU with unfinished generated work.
14. Incomplete FTU with inferred persona and no project.
15. Unknown persona, unknown goal, low activity.
16. High-usage user eligible for expansion.
17. Already-published deliverable.
18. Integration already connected.
19. Missing numerical signal requiring a truthful fallback.
20. Unsubscribed or suppressed user.

For every scenario verify:

- five scheduled sends remain on Day 0, 3, 6, 10, and 14;
- the welcome subject and body remain invariant;
- the selected module is eligible;
- the deliverable is specific and grammatical;
- the FOMO claim is supported;
- the CTA names the action and opens the correct destination;
- impossible states cannot be selected;
- fallback copy never exposes placeholders.

## 19. Launch checklist

### Engineering

- [ ] Implement the activation profile resolver.
- [ ] Implement module eligibility and ranking.
- [ ] Implement fixed Day 0, 3, 6, 10, and 14 scheduling.
- [ ] Implement per-send profile recomputation.
- [ ] Implement state constraints.
- [ ] Implement CTA action payloads and destinations.
- [ ] Persist selected modules and rendered fields.
- [ ] Implement suppression and conflict rules.
- [ ] Emit measurement events.
- [ ] Add monitoring for failures and fallback usage.

### Lifecycle and copy

- [ ] Approve the invariant welcome email.
- [ ] Approve every persona and goal mapping.
- [ ] Approve module templates and fallback copy.
- [ ] Verify every FOMO claim source.
- [ ] Verify Ploy terminology and capitalization.
- [ ] Verify the subject, preview text, body, CTA, and destination for every QA scenario.

### Deliverability and compliance

- [ ] Verify sender authentication.
- [ ] Verify consent basis and audience eligibility.
- [ ] Verify unsubscribe and preference-center behavior.
- [ ] Verify suppression and frequency caps.
- [ ] Run seed tests across major mailbox providers.
- [ ] Verify mobile and plain-text rendering.

### Final launch gate

Launch only when:

- every placeholder in this document is replaced;
- all 20 QA scenarios pass;
- all CTA destinations work in production;
- no numerical or competitive claim lacks a current source;
- lifecycle, engineering, and copy owners approve the release;
- suppression, unsubscribe, and monitoring are active.

## 20. Acceptance criteria

The system is complete when:

- every eligible signup receives the fixed five-email cadence;
- each remaining email adapts to the latest valid signals;
- every email recommends one specific action;
- every deliverable matches the persona and stated or inferred goal;
- the welcome body stays consistent;
- no impossible state produces an email;
- publishing appears only for a known publishable deliverable;
- integrations, CLI, research, visitor de-anonymization, monitoring, PloyDB, and Ploybooks are represented where relevant;
- all FOMO is supported by a real missed opportunity or verified signal;
- the engineer can implement the workflow without inventing business logic or copy rules.